Weekly Status Reports

This week, I mostly worked on mic-related stuff, but also tried out the casing assembly.

For the casing, I gently placed the board into the tube to check the fit, which it did.

The tube is easily compressed, so even if the board is flexible, there should be enough room such that it won’t get caught on the walls from friction and buckle. If that doesn’t work, I still have the option of cutting some notches in the tube to expand it even more (probably needed some holes for the mics to work well too). For the ends, I think I can get away with not needing to laser cut acrylic stoppers and instead just press them into a line with enough hot glue and/or tying them down with the thread. The folding doesn’t quite close all the way because of the curve, so I cut a notch into the side to help it meet. You can see the pictures for a comparison.

The only thing I didn’t try was drilling holes into the tube, because I didn’t think of that idea (the box cutter knife I was using to cut the tube worked pretty well, but those are better for slits than holes). I can probably find a drill sometime soon to try it though.

I didn’t glue anything in because it’s probably best to have easier access to the boards while we’re testing the mics for now.

For the music session, we noticed that the number of samples printed to the CSV varied widely, from 1200 samples per second on the high end to about 800. Because of this, we started to think something weird was going on. After further research, such as refining the code to use ints instead of floats in case implicit float->int conversion was sus, since analogRead returns ints (so having a float output was useless).

Unfortunately, that was nowhere near the full problem: apparently Serial printouts are what significantly slow down the sampling, but how else would we know how fast it’s sampling at if we don’t have the printouts to show the timing? Katherine will explain more in her part of the report (continuous analog read).

Since we still can’t reliably get the mic to work, we are proceeding with having the peak detector added as a back up. We think it might be easier to have 2 types of boards made: one with the peak detector and one without, and ship them together to reduce cost. Prof Fedder since alternatively we can also have a jumper wire connection to switch between reading directly from the mic output and reading from the peak detector. Either way, that still means I have to design a new PCB and hope the components can be rearranged to still fit on the same size board (might have to increase the board side a little though).

According to the Gaant chart, I have to wait on other parts (like the mic and Bluetooth) to be done since I just have integration tasks left. However, the Gaant chart didn’t account for needing to significantly modify the PCB, so that’s going to be my focus for next week. Like this week, I’ll also probably still be working with Katherine to keep testing the mics, because we’re not sure how responsive they are still/what range of values we should be getting. For example, tapping seems to output in the thousands, while speaking is only in the tens/hundreds. This doesn’t feel quite right. (Which is why we also plan to make the modified PCB with the signal envelope detector as a backup.)

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours)

I solved a few problems mentioned in the previous status report.

1. Nothing prints in the Serial Monitor: in Arduino, go to Tools -> USB CDC On Boot “Enabled”. If “Disabled”, nothing prints.
2. Beetle connection isn’t recognized/won’t upload code: often, when I switch out a Beetle and/or data cable (we have 2 of each), the upload process will fail. Sometimes it fails because the port is grayed out and won’t allow you to connect, or sometimes it’ll say some Serial data error. Here are solutions I do to fix this:
   • Unplug/replug Beetle, restart Arduino/computer
   • Spam the Beetle buttons for boot/reset during compilation. You should hear the USB connect/disconnect sounds if your computer has those. It might not work the first time, but eventually you get the timing right and it’ll finally agree to upload. I usually do the blink test for this, since it’s pretty easy to tell if it worked. If the Arduino IDE says “upload successful”, but you still don’t see any light, click the reset button once (right button), and then the light should start blinking.
3. Lights not lighting up: at first we thought it was the Polulu boost converter not boosting our voltage to 5V correctly, because we triple checked all our connections and they looked correct. So the next solution was to find a 5V supply directly and skip the Polulu middle-man. Techspark has some of those, so after connecting the Beetle to common ground, as soon as the 5V probe touched the V_regulator pin I set up, we were treated to a glorious array of wonderful colors! They were bright and rainbow and all we could’ve ever hoped for!*

*We actually were hoping that all the boards would have working lights, but when we tested boards 3 and 4, there was no reaction from applying the 5V. It’s pretty strange, since the Neopixels are bigger and thus easier to place and solder correctly compared to the mics. We also placed all the Neopixels in the same orientation, so wrong connections shouldn’t be an issue. Our success rate for lights is 3 out of 5 boards, so 60%.

Turns out, it was just a poor connection issue with the Polulu, because if you press on the boost converter at a certain angle, the lights will turn on. We also transferred all our wiring to header pins/breadboard connections to be more stable instead of just floating around. We will be soldering it on for the final product, so that won’t be an issue. We’re just hesitant to solder things on now because things aren’t finalized and soldering is a pain to undo.

Light video

After that, we tested all the mics with Prof Fedder’s tutelage. He explained that the mics DC voltage was around half of our power supply of 3.3V (so about 1.1V). So we first use the oscilloscope to measure our mic output pins to see if we get anywhere in that range. (Unfortunately, we can’t check the mic pins directly because they’re SMD, and thus directly under the mic.) Once we have a confirmed reasonable voltage (the bad mics register voltage levels in the mV), we move on to AC voltage. The test here is to play a tone near the mic and test different distances: we should see the amplitude of the sine wave on the oscilloscope change accordingly. For the non-working mics, we just saw “noise”.

Since the mics are so tiny, it’s very hard to apply solder on them to balance between falling off from not enough solder, or shorting all the connections because the solder reflow was too much. During the PCB assembly, we tried 2 methods; on the left side (mostly likely) of each board, Lucy applied a bit of extra solder manually to help the mics stick better. On the right side, I set the mics with just the initial amount of solder that made it through the solder mask. Here are the results for the boards’ mics that made the cut.

1: both mics work

2: right mic only

3: right mic only

4: left mic only

5: neither

It looks like the right mic technique may have had a bit of a slight advantage over the left mic, but honestly since the sample size is so small I’m not sure we can derive statistical significance from this. The survival rate of mics is 50%, but if we want both mics to work, the survival rate drops to 20%.

Since LED survival rate is 60%, the overall board success rate would be 30% if optimistic, and 12% if not optimistic (multiplying the survival rates because “and” condition). So optimistically we’ll need to build 4 boards, and non optimistically, 10 (expected value math). Then we apply backup calculations by doubling these amounts to get 8 or 20 boards. They will probably all cost the same amount so it’s not much of a cost thing as it is more of a “we need to make sure we have enough of the other components”. For example, our LEDs deplete the fastest since there’s 6 per board. We used up 30 of them for the prototype boards, so we have 70 left in our pack. If we are optimistic, we would have enough if we built 8 boards, but not enough if we want to build 20 boards. Prof Fedder gave us more microphones and says he has many more, so that probably won’t be our limiting factor. We also grabbed a bunch of the SMD resistors and capacitors, and only use like, 2 per board so we should be good there too.

Then was the music recording session where, for the first time, we had both the professional decibel meter and our own DIY mics (uncalibrated). Hopefully, we would see some trends between them so we could have an idea of what kind of math is needed to calibrate our mics. I used board 1, since we established that both mics were supposed to work, and put the decibel meter and board right next to each other on the music stand in the middle between the piano and singer. Observations:

• FAST, Lo, dbA settings: during ambient noise, it’s pretty close (both in the 40’s), but when music starts, the professional mic picks up the noise way better than the board mics; think i spotted around 60 on the board mic when I moved it closer, which is still less than the 70s to 80s that the decibel meter says.
• FAST, Hi, dbC settings: ambient now around 60 on the decibel meter instead of 40, and music is around 80s to 90s. Board values still stay around the same range as last time though.
• Something a bit concerning: the left mic seems to be more sensitive and goes up to 60, but the right mic stays solidly at 48-49 the whole time, even though both of them are supposed to work and I assumed they’d be around the same sensitivity level? They have the same resistors at least. The left mic is closer to the singer, the right mic is closer to the piano, but that shouldn’t make that much of a difference? Maybe the decibel meter mic was nearer to the right mic which may affect things.

The code was sampling with delays at this point so we’d know the sampling frequency exactly. Later we just got rid of the delay to sample as fast as possible, and based on the timestamped CSV logs, it calculated about 1200 readings per second, which is abysmally slow compared to the range that singers and pianists use. So perhaps that’s why the mic readings were suffering from such a limited range/sensitivity during the music session. Katherine can tell you more about her plans for fixing this in her section.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Amazingly, I have actually finished all my tasks on time for once! I also have code that changes the color of lights based on mic readings. Since the mics are uncalibrated, the thresholds are bogus, but as a proof of concept, you can see the video in the team report where clapping changed the light color from yellow to red. We could add gradient colors to interpolate smoothly between the yellow and red (orange) through HSV conversions to show the user more precision in the readings instead of just “buckets”, but when we were testing, we noticed the lights were sometimes flashing between yellow and red so quickly that it looked orange already due to persistence of vision, so perhaps gradient is unnecessary and we can keep the code simple.

What deliverables do you hope to complete in the next week?

I can try physical fabrication of the bracelet with the hard PCB, just to have some practice. Perhaps I’ll run into surprise issues that I didn’t know were going to be a thing. In particular, since our plastic sheet got lost to the void, we only have plastic tubing right now, so I can experiment with how viable of an option that is or if we really need the plastic sheet instead. We can also test how much the mics are affected by being in plastic; although depending on how noisy the uncalibrated data is, I’m not sure if we’ll be able to derive meaningful results if testing uncalibrated.

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.