This week, we reported on our progress to the music studio in our final visit. We have emailed asking for another session on Thursday or Friday, to hopefully test our final bracelet with calibrated mic values as well as casing.
We started committing by soldering components, which helped determine resistor values so we can switch to SMD to save space. The peak detector circuit is implemented on final (flex) PCBs, and expected to arrive this coming week. We also ordered hard PCBs as a backup in case soldering a flimsy surface goes wrong. All parts for PCB assembly have been acquired.
Our remaining tasks include: BLE, final code for Beetle, mic stuff, and building the bracelet.
For BLE, relating to web apps: we’re using ble-manager instead of ble-plx to connect with the Beetle, and still working on connection and backend. The Beetle is a peripheral for the purpose of the BLE connection.
The final code for the Beetle should include everything we’ve been working on: mic signal processing, LED commands, button input, etc.
Mic signal processing continues. Peak detector values are definitely better, since the peak detector filters out the weird wave pattern we noticed with the previous mic input. One potential issue is that the peak detector output seems to occur in “levels”– almost like high/low values. In order to use this output to command the LEDs, we need to adjust the (one) threshold to be between these two values.
Here’s a video: https://youtu.be/tRXVAB-vj1g
Sorry about the camera quality, but the top 2 moving lines (yellow and gray) represent the values using peak detector, while the bottom 2 moving lines (red and blue) represent values without using the peak detector. As you can see, there are times when the bottom 2 lines are just flat, but the top 2 lines can detect a change, which is promising. The range of values isn’t very large, but could probably fixed with calibration.
In building the bracelet, it was discovered that the pipe from McMaster-Carr didn’t suit our purposes, so we gave it away. We are using multiple overlapping pieces of plastic now.
One remaining issue is that our button doesn’t work. Using the Arduino example code and setup for buttons, we found that the button being pressed does not register. We hypothesize that it might be the Beetle doing internal pull up or down resistors, which messes up the reading because it’s always reading as “off”. One option is to use the example GPIO code for the ESP32, which uses a different method of setting up the button. A back up option exists: we have a header pin, so we can manually reroute to another Beetle pin if necessary if another pin ends up working.
Another remaining issue is that our battery connections are soldered decently but still don’t power the board. As long as this is true, we can’t test the switch for on/off. The cause needs further investigation, but it could be a bad cable.
Our schedule has been updated. The system needs to be functional by 4/24, because that is the day before the first possible day for testing in a music session.