Tag: status report

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.

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).

In the previous status report, I assumed that the PCB would be at least delivered so we could at least check it out, but unfortunately that’s actually scheduled for next Tuesday. Thus, a lot of material items that I also wanted to do, such as assembling the PCB, trying out the LEDs…etc., were blocked. On the bright side, I was able to successfully set up my Arduino environment to connect with the Beetle (on-board LED blinking “Hello World” worked).

In the meantime, I’ve been working on compiling different projects’ uses of Neopixels (Adafruit has been particularly helpful). I don’t expect to be able to copy-paste code, of course, but being able to tweak existing code that I know is supposed to work should be easier to get working than writing from scratch. In addition, the multiple examples will help me understand the mandatory vs customizable components of the code. Here are the links I’ve been looking at:

• How To Control WS2812B Individually Addressable LEDs using Arduino goes over the anatomy of the LED strip, as well as has an example with connecting to Bluetooth to a web app to change the color of the lights.
• Overview | Gemma Color Touch Pendant Necklace | Adafruit Learning System necklace changes color based on touch (capacitive sensing); uses a calibration number in the code to adjust sensitivity, so perhaps we can try something similar when we are calibrating our mics
• Overview | Ursula’s Seashell Necklace | Adafruit Learning System a necklace that lights up by reacting to microphone signals. It also mentions calibration is necessary, but suggests manual hardware calibration rather than in the code (unfortunately we’re using a different mic that doesn’t have a screw to turn, but our equivalent is we can swap out different resistors to test out the gain). Finally, there are also some helpful debugging practices.
• Overview | Light-Up Costumes in Harsh Environments | Adafruit Learning System a mermaid costume, which is used underwater for cosplay. Of course, our system isn’t intended to be able to survive submersion, but it’s still helpful to know the kinds of design decisions made, such as minimizing wires at stress points, and how to connect wire ends securely.

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

Because we thought we’d have our PCB in this week instead of next week, all of the PCB assembly and testing of components had to be pushed as well. Our goal is to rapidly assemble the PCBs (ideally within a day or two of receiving them, depending on our schedule availability) so we can get to the coding, since I suspect we’ll probably run into errors there.

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

Since the PCB is expected to be in by then, I hope to be able to assemble all the components in the PCB lab, read up on the FastLED library that a bunch of the above projects used, and try some of their simple example code to make sure the PCB passes before trying to upload more complex code.