Category: Katherine’s Status Reports

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

This week, I mostly worked on physical aspects of the system. I soldered the 200k resistors to a board (old design) to test mic gain; it’s difficult to tell if the result was an improvement, because oscilloscope/output pin testing was marked by drifting output values and the Beetle or mic overheating. As it turns out, the overheating was likely due to an issue with the mic connections, not resistor values. I also tested if the Beetle could function with battery power alone (not connected to a computer), and got it to respond to pressing the button intended for mode selection. Using https://docs.arduino.cc/built-in-examples/digital/Button/ and Freda’s code from https://courses.ideate.cmu.edu/60-223/f2022/work/date-calc/, I also got the Beetle to respond to a button press by changing state. This will be useful when we need to switch between instantaneous and average mode in the final system.

Button press video: https://youtu.be/_9XqhMuvDfU

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

Although the deadline of April 24th passed without complete functionality, it should be possible to get everything done by the 30th as promised in the slides.

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

Since this is due at the end of next week, my overall deliverables are to make sure that the system functions and as many tests are met as possible. More specific deliverables include having a complete and functional file for all integrated code, thresholding the mic output so that LED and transmitted outputs from the mic have some relation to dB values, and helping with remaining tests.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

• I needed to relearn how to properly solder things (out of practice). My strategy was to understand that it is possible to improve and that failures can be fixed, and ask for feedback from someone with more experience.
• Similarly, I needed to relearn how to program in C++. My strategy was to look at existing Arduino sample code, and run example code to determine if something is a software issue or Beetle issue.
• I learned more about how PCB design works (I never helped design a PCB before this semester), including that trace widths are relevant to resistance. My strategy: when reporting results, source the method and calculations so that the logic is apparent to others.

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

These are details of the panels for the new PCB design.

• Tasks from last time are all done except for BLE (Lucy is handling that now), with the caveat that we ended up not needing to order more diodes.
• There was an update to the flexPCB order: we ended up ordering both rigid and flex boards, both with the peak detector.
• I soldered mic gain resistors with different values to different PCBs and tested the mic responses on an oscilloscope (for values of 0, 10K, 33K ohms). This confirmed that 10K is sufficient for gain, which means the final design can use SMD 10K resistors. This should make final assembly easier.
• I verified that PCB trace widths for the new design shouldn’t create problematic resistances.
• I soldered header pins to the battery breakout board and boost converter so that the battery has a stable connection to the PCB.

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

• Progress is generally behind, and I hope to get more work done in the next week so that the final system is functional.

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

I hope to complete: final mic calibration code, which commands the LEDs to display different colors; button code, so that the Beetle responds when a button is pressed; putting all the code together into 1 file; and getting the Beetle to successfully run off of 1 battery (the connection is stable, but the Beetle doesn’t light up).

This week, I ordered plastic wrap, and failed to establish BLE on the microcontroller. Microphone signal processing continues, but is not yet complete. This is a video of me attempting to test microphone signal processing:

https://youtu.be/MO0vMsxbeHc

By using a variation of the example code for analogContinuousRead, we can now sample at 20 kHz and above! For voice and piano, this ought to be able to pick up everything but the very highest piano overtones; it also automatically averages the collected samples. I must note here that the datasheet for our analog microphones shows the typical microphone frequency response up to 10 kHz, implying that 10 kHz is the highest frequency the microphone can reliably pick up. The sampling speed could be set higher than 20 kHz in code, but this might have no effect if the microphones cannot interpret signals above 10 kHz.

A greater difficulty exists: as you can see in the video, the microphone input from the continuous ADC read seems to be following a cycle rather than actually responding to the environment. This could just be an error with loose connections that will be resolved when the final product is soldered together, or it could indicate that something is going wrong between the mic output (which is verified to output signals that increase in amplitude as sound volume increases) and the ADC input (which uses example code provided by the creators of ESP32). To be safe, we are going to implement a peak detector circuit for each mic-ADC connection on half of the flex PCBs that will be ordered.

While my progress is technically on schedule in that I have fulfilled the tasks I set last week, I think I am generally behind schedule. I do not think this project will be complete and functional in only 2 weeks if I continue working at my current pace.

Tasks I need to do before next meeting:

• Choose resistor/capacitor values for the peak detector circuits
• Find instances of the chosen diode (1n4148) and op-amp (LM248) in the Fusion 360 library if they exist
• Find datasheets for the chosen diode and op-amp
• Order 3 more Beetles, another 100-pack of NeoPixels, and diodes in preparation for assembling the flexPCBs
• Place the order for flexPCBs (2 board designs: with and without peak detector)
• Verify that a BLE connection can exist between the Beetle and my phone without security issues
• Make sure that the microcontroller can send and receive data via BLE connection

Testing status: as of today, I have not explicitly fulfilled any of the tests set out in the design review. I will definitely run the loudness and directionality tests, and will perform other tests as needed. For all tests, including the loudness and directionality tests, the anticipated/measured result directly relates to one of the requirements of the system (as shown in the testing charts on the design review slideshow).

This week, I used this pySerial tutorial (https://www.instructables.com/Capture-Data-From-Arduino-to-CSV-File-Using-PySeri/) to update the microphone testing code to save input data to a CSV file. These resources were helpful: https://forum.arduino.cc/t/compilation-error-read-econnreset/1114185, https://www.developer.com/languages/python/map-event-codes-python/. I also put together a test circuit (with Zeynep’s help) to confirm that the bracelet hardware can run entirely off of the battery as planned in the circuit diagram. Thank you, Freda, for suggesting these tasks!

Some of my deliverables from last week are behind schedule. However, the context and importance of some of these deliverables has changed.

Microphone signal processing is done (with Freda’s help) in the sense that microphone inputs can be obtained and used to affect other components like the LEDs. However, further improvement/debugging is needed. For example, I need to look into increasing the speed at which the Beetle runs so that microphone input can catch higher-frequency inputs such as those expected from piano or higher voices. This resource is useful for determining which frequencies correspond to notes we want to catch: https://www.omnicalculator.com/other/note-frequency.

In testing, we are not currently scaling microphone input values to correspond to decibel meter readings. It seems like the scale value varies among microphones, so the best thing to do might be to wait until we have assembled the final hardware components on the flex PCB before tuning the scale values. Similarly, the microphone testing code does not currently average samples over time. Although it is not correct for our final product to register short noises like tapping near the microphone, it is useful in testing. Also, as long as we are not weighting the input based on frequency, it is likely not necessary to perform an FFT for determining the dB value.

Visualization of decibel readings was not complete by March 30th; it is likely that this will be completed after the interim demo.

Some testing of the device has begun. It is not possible to complete the timeliness test now, because the webapp and device are not yet integrated. Similarly, since the bracelet is not assembled, passing the heat test has not happened yet. We are attempting to improve the accuracy of the microphone, but its results do not yet correspond to dB meter readings.

Deliverables for next week include placing an order for plastic wrap, helping bring the hardware subsystem (microphones and LEDs) to a testable state, and testing it in music studio sessions.

This week, I wrote and tested out a program that relates microphone input values to dB values (multiplying/dividing input by a constant) on the PCB. I can get a Serial Monitor reading of the left and right microphone values that has approximately the right magnitude when the input from each microphone is scaled down by 10.

Unexpectedly, using no resistor (open) in the spaces meant for the gain resistor on the analog microphones returns reasonable values. The values returned are on the order of the values for minimal resistance (when the space for the gain resistor is occupied by a wire).

This photo shows sample results from the microphones without any resistor.

This photo shows sample results from the microphones when they have a gain connection of minimal resistance (wire).

Progress was technically behind on microphone signal processing, the Bluetooth-webapp connection, and visualization of decibel readings. Microphone signal processing is now expected to be complete by this Friday. Bluetooth is most relevant to webapp-device integration, and can be addressed after the interim demo. However, it might be useful to continue searching for resources/information if other tasks are completed early. Visualization of decibel readings is expected to be complete before March 30th.

Bluetooth research proceeded. I attempted to go through the steps of the Bluno basic demo (https://wiki.dfrobot.com/Bluno_Beetle_SKU_DFR0339, https://wiki.dfrobot.com/Bluno_SKU_DFR0267#Bluno_Basic_Demo, troubleshooting information https://wiki.dfrobot.com/Bluno_SKU_DFR0267#target_7, https://support.arduino.cc/hc/en-us/articles/6554914611228-Compilation-error-exit-status-1), under the assumption that it would be fairly similar to the Beetle’s BLE system. I was unsuccessful. However, I was able to install the APK on my phone and look at the names of Bluetooth devices in the area (resources: ttps://www.lifewire.com/install-apk-on-android-4177185, https://www.softwaretestinghelp.com/how-to-open-apk-file/, https://support.google.com/googleplay/thread/56676897/how-do-i-install-3rd-party-apps-and-apk-files-on-my-motorola-g-stylus?hl=en). I looked at these resources (https://www.arduino.cc/reference/en/libraries/arduinoble/, https://www.arduino.cc/reference/en/language/functions/communication/serial/println/) when trying to debug the code; it printed an error reading “controller lib commit: [77d09ce]”. This error apparently stems from a conflict between the ESP32-C6 module and the main controller module (https://github.com/h2zero/NimBLE-Arduino/issues/645). It seems like we would have to change how the Bluetooth module and the Beetle interact with each other in order to fix this problem.

Most of my tasks this week will focus on microphone signal processing. I’m going to tune the scale that determines output values: gather microphone data from an established sound, measure the sound dB externally, and improve the microphone results by adjusting the scale value to better match the external measurement (thank you, Freda, for suggesting this experiment). I would also like to graph some portion of these results (both from the external measurements and the microphones’ measurements).

For Friday, I intend to update the microphone signal processing code to:

Take multiple samples per second and average or otherwise combine them in order to account for external noise not relevant to the user (for example, tapping the device near a microphone location).

Use an FFT (https://en.wikipedia.org/wiki/Fast_Fourier_transform) like https://projecthub.arduino.cc/abhilashpatel121/easyfft-fast-fourier-transform-fft-for-arduino-03724d to define dB value as based on the highest amplitude of the highest relevant frequency in the microphone input, and use Serial Plotter to visualize the frequency results.

This week, I also intend to participate in timeliness, accuracy, and heat tests for the hardware components of the bracelet.

To correct an error from last week: this week, I was supposed to be working on microphone signal processing, not LED signal setup, in addition to electronic prototyping.

In our weekly check-in discussion, I got an idea of how microphone signal processing is going to work in the context of our project. My eventual plan to determine the necessary sampling frequency is to test the bracelet microphones by sampling at the higher rate (including all expected overtones) when at a music practice. I hypothesize that the overtone frequencies will tend to be softer/have smaller amplitudes, which will reduce the frequency range we would have to work with and therefore our required sampling speed as well.

Some of my progress is on schedule, while other parts are behind.

The on-schedule elements are as follows. I wrote the logic for the ratio of microphone decibel values affecting the color of each LED when in directionality mode. When in directionality mode, the LEDs light according to a dB value that is a weighted average of the dB value for either direction (the weights differ depending on the LED’s location relative to either microphone). The farthest and second-closest LEDs from the Beetle on each side will display the color value corresponding to their side’s microphone input, while the LEDs closest to the Beetle will display a color value corresponding to ⅔ of their side’s microphone value added to ⅓ of the other side’s microphone value. When not in directionality mode, all LEDs will display a color corresponding to the average of the two microphone input amplitudes. The logic for determining direction already exists (I believe last week’s “how determining direction… will work” was in the context of LED colors?). For the record, it takes the ratio of the amplitude from each microphone input and assumes that a sound equidistant from each mic will have a 1:1 L:R ratio, while a sound completely from the left or right will have a ratio of X:1 or 1:X (X being the maximum ratio). It then scales based on the ratio of input amplitudes to find an angle value between these. X will be iterated on during directionality testing.

I am behind on establishing the Beetle-Bluetooth connection. According to https://github.com/espressif/esp-idf/issues/6550, in order to establish a connection to my phone with the correct security, I need to turn on secure simple pairing or change the mode to mixed mode; I need to research if it is recommended to change these features of the Beetle’s Bluetooth module. Further research suggests that it would be useful to connect to the Beetle through a third-party app (https://wiki.dfrobot.com/DFRobot_Bluetooth_4.1__BLE__User_Guide#target_2 states that it is required for Bluetooth 4.1, and our Beetle uses Bluetooth 5), but none of the apps I tried could recognize the Beetle.

Tasks that depend on having the PCB are also behind. The PCB is scheduled to arrive on Tuesday. Once the PCB is assembled, I plan to continue work on electronic prototyping (including researching the Beetle-Bluetooth issue) and microphone signal processing. I will also help with testing the webapp if necessary and with visualizing decibel readings if time permits.

Over the past 2 weeks, I participated in completing the design report, ordered the PCB from JLCPCB (it should arrive in 4-6 business days), and completed the first-time use tutorial on the DFRobot Wiki for using the Beetle to display “Hello, world!”.

I also realized that the circuit diagram I created for the design report did not mention its sources; it was compiled based on diagrams from the AKU1126 acoustic microphone datasheet, Beetle pin diagram/definition, NeoPixel (SKC6812RV) datasheet, and Pololu boost converter description.

Here is a sketch of the bracelet that was not included in the design report.

All deliverables from last week are complete. The Gantt chart has been updated so that we can catch up to the new schedule.

When first attempting to use the code, I was able to see the device on my phone and click to establish a connection; however, an SMP error occurred shortly afterwards. For next week, I want to implement the Beetle-Bluetooth connection described in the tutorial without errors, and be able to maintain a Bluetooth connection between the Beetle and my phone.

The timing of the next deliverables on the Gantt chart depends on when the PCB comes in; after that, I can work on electronic prototyping and LED signal processing. I will also write non-code algorithms for how determining direction from a microphone will work (with the inputs being two microphone input values in dB).

After last week’s report, we completed the slides for the design review. On Monday, I presented the design review slideshow in class.

I have mostly fulfilled last week’s deliverable to order all parts. Because the PCB design is not completely designed at this time, the PCB was not ordered. However, the boost converter (https://www.pololu.com/product/2564) and battery (https://www.digikey.com/en/products/detail/adafruit-industries-llc/2011/6612469), the remaining electronic components, were ordered. In addition, all of the following physical components were ordered: plastic wrap (https://www.amazon.com/dp/B09PJQNMCM), 10 feet of plastic tubing (the smallest available length) of 1” inner diameter with a thickness of 0.25” (https://www.mcmaster.com/products/tubing/tubing~/soft-plastic-tubing-for-air-and-water/), polyester cord (https://www.amazon.com/dp/B07TZW1DBW/), and plastic cord locks (https://www.specialistid.com/products/black-adjustable-neck-cord-lock-2135-4001). I have also updated our purchase tracking spreadsheet to reflect our latest purchase requests. Also, since the microcontroller and LED orders have arrived, it is now possible to begin electronic prototyping.

For the next status report, I want to have a finished PCB design and place the order for multiple rigid PCB prototypes. Furthermore, I want to start electronic prototyping with available materials; I plan to use the Beetle to display a test message in order to familiarize myself with how it works. Since the report for the design review is due next Friday, I will also participate in completing the design review report.

Following up from last week’s report, I made sketches of the physical design of the bracelet.

Drawing these made me think of some discussion topics for our group meeting.

• Are we proceeding with designing the bracelet to use 2 batteries in series rather than one large battery? (Yes– the bracelet can have a more even weight distribution and more easily meet size requirements if it uses two small batteries.)
• How will wire management work? Now that most of our design will be on a PCB, the major wire connection remaining is the battery cable.
•  How many LEDs do we want to use? Because an array of NeoPixel LEDs can be connected to one output pin on the microcontroller, we can include more than the 6 LEDs we originally planned to have; however, more LEDs will draw more current, which will then decrease the battery life. Similarly, we can afford to have more than 3 (digital) microphones now, but it remains to be seen if this is necessary for our design.

In another follow-up to last week’s assignment, I created an optional Google Form survey for the music studio. Results from the Google Form seem to indicate that potential users would want a device with a long battery life. From the form answers, the longest duration of a music session could be 4 or 6 hours. Involvement with the music studio means that our use case is now more specific; we are aiming our product toward people who are regularly creating music and want to make sure that their practice/rehearsal environments are safe. With these two assignments completed, my progress matches our schedule.

This week, I submitted orders for the Beetle microcontroller (https://www.dfrobot.com/product-2778.html) and NeoPixel LEDs (https://www.adafruit.com/product/3094) that we intend to use in our bracelet. Since we need to have all design decisions finalized by Sunday at midnight, which includes knowing all components that we will buy, I am assigning myself the task of submitting all orders for materials in the coming week. (I also changed this website’s header image to a picture from Pixabay, which is free to use.)

This week, I researched possible battery and microcontroller choices for the bracelet.

I was behind on finalizing materials.

Before next week’s meeting, I will sketch the physical design of the bracelet. Before class time on Monday, I will create a Google Form with the questions we want to ask the music studio participants.