The PCBs finally came in this week, so Lucy and I were able to assemble them in the PCB lab and hand solder on the rest.
A few takeaways: because everything is so small, the solder mask took a while to line up precisely, and we weren’t sure if there would be enough solder on the smallest component (microphones) to stick, but luckily it did. Another thing that was tricky was looking closely at the mics and LEDs since those have directionality in placing them. We are relatively sure we got the mics oriented correctly at least, since Katherine was able to get reasonable readings. LEDs deserve their own section later. Finally, we need to make sure not to run out of the SMD components like capacitors and resistors (took a bunch just in case), because apparently they’re not kept stocked and we’d have to order them, which causes delays. We could cut apart the PCB into each panel using scissors since it was thin and came with perforated marks.
Highlights of hand soldering include using tape to line up the headers relatively straight so the beetle will be able to fit properly. The single headers don’t have to be that straight because we were planning on wiring those connections.
I could now get started on trying to get the LEDs to work. At first, I tried to use the FastLED library since that’s what a bunch of example Neopixel projects on Adafruit’s website used. Unfortunately it led to a bunch of internal errors within the library itself, and everytime I fixed one, a new error would pop up. It was like playing whack-a-mole, except hitting things with a hammer would probably not solve the problem.
Next I tried the Adafruit Neopixel library since that was mentioned on the Neopixel page. That compiled fine, but then nothing happened. We tried checking the pins, debugging with print statements (nothing printed, not even in the setup() before any real code was run). Admittedly, our setup may not have been the most stable since we didn’t solder the battery/boost converter stuff yet (couldn’t find any solid core wires, which would’ve been more helpful), but I don’t think that should be the issue. In addition, we are relatively sure all of them are oriented correctly after consulting a pin out of the component online.
In other news, an ongoing conundrum has been how accurate our phones are for measuring dB. Previous data showed that each phone was relatively precise (Katherine consistently got the lowest readings and Lucy the highest), but I volunteered as tribute to formalize our findings with fun things such as box plots and outlier analysis and standard deviation!
For our recording session with the music students, we tried different variables to see how sensitive the mics are and how much specific placement really matters. Specifically, we tried trials where we lined up the phones in different orders, and for the last trial, we placed the phones as far away as possible (other side of the room).
Conclusions:
- no outliers, even with the very far away trial; it does skew the data ofc, and the box plots look more symmetrical without it
- mostly avg and max was affected by this ^
- std dev calculations not really affected, since everyone should be affected in about the same way
- katherine’s avg didn’t change without the last trial because the last trial didn’t have the lowest value XD
- Lucy’s phone seemed most sensitive (largest drop) to being farther away
- Everyone’s std dev were within 2 db if ignoring the last trial
I didn’t expect the light debugging to be so difficult, especially since there’s a bunch of straightforward example code to try. That was supposed to be done by the end of this week, but I’ll try to have it done by Friday’s recording session instead, and perhaps we should meet with prof to ask for help.