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.
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.
We have legit mic output now, huzzah! It turns out that we needed to solder pins to the Beetle and use a socket to connect the Beetle to the board. Now that the connection is secure, we have realized two things:
The connection wasn’t secure before, and the mic output from before might not have been meaningful.
The mic does in fact respond proportionally to output. The variance can be improved by using a higher resistance value… well, we thought so. It doesn’t significantly improve past a certain point.
Music studio updates: from testing during one session, we note that the system can pick up on some sounds. The baseline output value seems to drift higher over time. Over the time of 2 songs in the music studio, the input from the tested mic varied within a song by as much as 150 mV. The first song began at approximately 200 mV and ended at approx. 350 mV. The second song began at approximately 400 mV and ended at approximately 500 mV. This effect could possibly be mitigated by introducing calibration.
Beginning of 1End of 1Beginning of 2End of 2
We tested a large range of resistor values, including those greater than the 33k max recommended, in hopes of getting better sensitivity. We tested 50k, 100k, and 200k. The resistance of 200K and 50k were not significantly better/different than 10k. Thus 100K resistors will be used on the new boards since we did have promising potential with those.
This video shows a plot of the mic (above) and peak detector (below) output values as the system responds to music with voice and percussion, using the 100K mic resistor.
Freda and Lucy also assembled 2 new boards successfully.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
Significant risks include:
Us not getting the new batteries (Katherine ordered the wrong battery size). This messes with the size requirements we have (although not significantly), and we can still use the batteries we have (and batteries of the correct size have been ordered).
Something going wrong with BLE. Lucy is planning to meet with a person from another group who has experience in order to understand how to get BLE to work. Another risk is that the BLE connection is too slow (can’t match 1-second speed requirement). In that case, we would want to look into strategies to make the code (either bracelet or webapp) create faster results.
Assembly issues. Our contingency plan is to make several copies of the final PCB, both rigid and flex, and to keep the original PCBs as emergency backups.
The Beetle randomly freezes. Is it possible that it is going into deep sleep mode? The plan is to research deep sleep mode and make sure that the Beetle does not go to sleep for the duration of its usage.
Microphone drifts. While the contingency plan is to calibrate microphone outputs at the start of each session, it would be nice to know what’s causing the drift in the first place.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
We are no longer doing directionality: the mic location on either side of the Beetle is not different enough to matter. Also, it is hard to solder mics, so it is rare that both L and R mics work for the same board.
When testing the Beetle on the battery, there is not always a response if battery direct output is plugged into BAT, but it will respond if boosted 5V output plugged into VIN (rated for 5V).
It is possible that the system might require start-up time for mic outputs to settle. The mic datasheet says start-up time for a mic is max. 800 ms, but the peak detector at its output might change things.
Provide an updated schedule if changes have occurred.
There are no updates to the schedule. Everything has to be done by the 30th still.
List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.
We unit tested the button, lights and mics. Button and lights work fine. As you could probably guess, we’re still having mic issues.
Remaining tests include comparing decibel meter output to system output, as well as evaluating other qualities of the complete system: weight, adjustability, thickness, durability, timeliness, battery life (to be calculated using data from the battery’s output current), and operating temperature.
It may be concluded from our previous remarks that the system test has failed. We are in the process of asking Erin and Prof. Fedder for help.
This week I was mostly invested in experimenting with the mics because those are still not done and I think that’s more important than iterating on the casing.
After our presentation Monday, Prof Fedder met with us to look at the peak detector after the mic output because he thought our graphs looked different than what he expected. Turns out, it was the usual culprit of bad connection due to not soldering things because we didn’t want to make something permanent before we knew if it worked. (Ironically, we would still not know if things worked because the bad connection results in unstable results.) So after I soldered on some female header pins to go along with the male ones on the board, we got some much more stable results on the mic. This led to needing to double check the mic resistor values we used, as Katherine thought there wasn’t much difference between the 10k and 33k earlier, but now we can’t trust that because of the poor connection being a confounding variable.
She can probably tell you about those shenanigans more in her report, but the reason it matters to me is because the PCBs were expecting SMD resistors, so if the values in the PCB lab don’t match up with the ideal resistor values, then we were going to need to be creative in order to get that value. For example, the highest resistor value on the datasheet is 33k, but we only have 10k and 100k. In particular, I tried 2 approaches: stacking SMD resistors (three 100k resistors in parallel is about 33k) and soldering through-hole resistor legs to a SMD pad (can directly pick a 33k through-hole resistor). Theoretically, it’s also possible to do things like place the resistors in teepee style or Stonehenge style to be in series, but stacking them directly on top of each other was already a lot of work because of how small they were: they are easy to nudge out of alignment, and stick to the tweezers. Both the approaches I tried worked when tested with a multimeter! This is great because that means we don’t need to order new SMD resistors, which would take more time and delay us even more.
We stacked 3 SMD resistors of value 100k each, so now that they are in parallel, we’d expect about 33k. And sure enough we do! While this is a viable option for changing the reistance, we would rather not do this again because it took so long compared to the through-hole resistor soldering onto SMD pad method.While soldering a through-hole resistor onto a SMD pad may seem sacrilegious, it seems to work functionally! Plus the extra leg room can allow the resistor to bend in a configuration so that it’s out of the way of other components.
Funnily enough, we ended up not needing to stack resistors, because we discovered that the 100k seems to be more sensitive than the 33k in providing a larger range of values (which would be helpful for scaling/converting to dB). For 33k, the range was very small, around 50mV, but for the 100k we had about 300mV range.
So the next step was making the new PCBs. We are trying out the hard boards first to sanity check some things such as the new mic resistor value. This time, whoever made the stencil was clearly not doing their job properly, because the offsets between each of the 3 board strips were larger than the actual distance: basically, we could only align one strip at a time 🙁 This meant needing to pre-cut the boards before they went in the oven (otherwise, the stencil would smear previous solder paste when we tried to move on to soldering the next strip), which leads to the PCBs being smaller and later, which lead to the middle PCB flying off the rack and being a sad pile of unsoldered parts (the lights, capacitors, and one mic fell off before they could be soldered). Trying to spot-fix things with a heat gun didn’t work because the air would blast away all the other pieces out of alignment before the solder could melt. Next time, we will try to group all the PCBs nearer to each other so hopefully they will not be blown away. This may not be a problem with the flex PCB because the board strip can bend away from the stencil after solder paste is applied to avoid subsequent smearing, so we can keep the PCB in one piece in the oven. Another tidbit about the new boards: because of the Fusion360 grid snapping pain I mentioned a few weeks ago, the right mic of the board is a little bit closer to the LED pad than the left mic. Hypothetically, it should still be enough room to not interfere. Based on mic validation tests, the right mics of both boards didn’t respond to anything compared to the left mics. But we also only have 2 boards so far, so it could be due to small sample bias.
Unfortunately, even for the left mics, when we tried to recreate the large range we saw earlier with the new PCB it went back to being around 50mV, which is very sad. Not sure how much of this is due to the different testing environments, since the first room had a lot of background noise and the second room didn’t.
In terms of scheduling, the stuff I’m officially tasked with, which is casing construction and Arduino code integration, are still blocked from being finalized by the whole “things aren’t all working yet” that I’ve also been talking about for the past few weeks. I made a basic mock-up of the case already, but I can’t try sealing it yet because again we are still using the boards for testing, so it’s more convenient for the board not to be in the case for that part. So in reality I’ve just been continuing to help with trying to get the mics to work. For the next week, if the mic (and battery, beetle, bluetooth…etc) issues are resolved, then I will be making a lot more PCBs, presumably both flex and hard PCB just to be safe. And then I will finalize the casing structure with the board inside.
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, 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.
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.
The two main things I’ve done since the last progress report are related to the PCB, case assembly, and testing.
First, I remembered that I have IDEATE access so I went to the physical computing lab to look at what they had. Happily, they have the fast-switching Zener diodes that we need, so we don’t need to order those anymore. They also have a variety of op-amps (which we thought were needed at the time) and Polulu boost converters so we don’t need to order any of those anymore, and I also took some buttons and switches. Then I also went to the PCB lab to count out the SMD resistors and capacitors to make sure we have enough of all our values. I labeled each strip since there’s no markings on the components themselves.
As a side quest, I also noticed that some of the header pin connections weren’t adequate (since the holes were still visible), so that made me wonder if that’s the reason the lights don’t work for all the boards. Especially since the lights are big enough and the soldering pads are far enough away that I can clearly see that SMD solder connections shouldn’t be the issue. After touching up the connections, we now have all the board’s lights working properly! Woohoo! That means the success of the boards only depends on mics, so by redoing the calculations, we’d need about 10 boards to be safe. Turns out the minimum number we can order is 15 so this will be fine (we bought enough Neopixels for about 28 boards so this will be fine ish, even with 2 designs which would be 30 boards total). I also took this opportunity to demonstrate how to solder to Katherine so she could try different resistor values for the mics (even electrical tape had a slightly sus connection, so soldering was necessary to properly test).
Next was redesigning the PCB to include the peak detector. For a while, we were debating whether we needed the op-amp. I preferred having as few components as possible since we were running low on space and it was going to be difficult to route things around such a large object. Prof Fedder also drew a simpler diagram where we only needed the “top half” of the peak detector, since we didn’t really care about enveloping the bottom-half of the signal, which further reduced the number of components in the original diagram by half. After Katherine did some simulations in Lspice, she confirmed that we don’t need the op-amp, thank goodness! That made my life easier. What didn’t make my life easier though, was Fusion 360 being weirdly different since the last time I designed it. For some reason, some components just didn’t snap to the same place in the grid as they did in the previous design, even though the grid granularity and components were the same. This was solved somewhat by rearranging the component order and then putting them back, or just sucking it up and saying “this slight difference shouldn’t affect the functionality” and moving on. Katherine did some calculations for the trace width resistance and ordered PCBs.
Cutting the plastic for the casing was also such a big pain! The tubing was decently easy to slice along the open edge, but the knife (and all other pointy objects I could find) were all not sharp/strong enough to puncture the tubing for cutting holes. I tried drilling to make the hole bigger, but the drill bit ends aren’t sharp enough to do much 🙁but it made the hole slightly larger so I could try fitting a small wire cutter in there to widen the hole. It took so long, and the hole ended up looking very jagged. Later, I realized that the battery couldn’t fit through the opening, even when squishing the pipe, and especially not if you need to add a PCB on top of that. So we’re not going to be using the tubing anymore.
The back-up option was the rectangular plastic wrap, which we’d need to measure and cut and glue together again. This is more work than being given a tube, but it gives more customization options (and the plastic is also much thinner). It has the same problem as the tubing where it’s pretty puncture-proof (this is pretty good for durability, but it’s a pain when we’re trying to make holes), but a helpful Techspark person showed how to use the hole-puncher, so we were able to make some holes where the mics would be. I also tried the method of just gluing the edges of the top and bottom pieces of the plastic together, and testing the durability from bending. It starts off ok, but it takes a lot of glue to seal it well, and over time the glue cracks and the edges start opening.
So for the next iteration I tried overlapping more surface area (thus, making the top piece of the casing much larger than the bottom piece). This time, I calculated how much I’d need for each piece instead of guesstimating. It’s hard to guess exactly how much I need because there are some variables that are hard to measure, such as the curve of the top piece. However, I think the sizing is all right because the height of the bracelet can be adjusted based on how much is overlapped with the bottom piece.
First iteration of casing, where both the top and bottom piece are the same size.Calculating dimensions needed for top and bottom pieces.2nd iteration top view.2nd iteration side view.
Prof Fedder also suggested that we need some netting to help protect the mics, so I found this plastic netting that we could use.
Originally, we planned to be done integrating (including the case) and onto testing by now, but of course that hasn’t happened. It’s hard to know if the casing design I have now will be greatly affected by having a flexible board instead, but I’ve discovered so many roadbumps in creating the casing that I think it’s important to keep going through the building process, even if it needs to be with a hard PCB. I aim to have a case finished by Wednesday (as in, the case is glued together, has the correct number of holes, and fits the battery and PCB with some room to spare). If the flex PCB arrives early enough, perhaps I will have time to test the fit and make adjustments before the next status report as well. I also plan to assemble the PCB with Lucy like last time, and also try to debug the button press.
Throughout this process, the way I’ve learned new things is through a few methods. Mainly, I try searching for tutorials (ex: on YouTube for PCB design like creating library components), and reading forums for how people have solved similar problems). In addition, I think an important method is knowing who’s an expert and consulting them for questions. The obvious one is our Prof and TA, but this also includes classmates (who are working on similar projects), and Techspark people (since they know what specialized tools are available and how to use them).
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The most significant risk is that we do not finish in time. As of the interim demo, web app progress is proceeding well, but hardware is somewhat behind where we expected to be; for example, microphone signal processing is taking much longer than anticipated. This risk is being managed by trying to do tasks that require significant waiting (like ordering parts or PCBs) as soon as possible, and by having multiple versions of the PCB to test with.
The second most significant risk is that the microphone output does not correctly connect to the PCB ADC input, making it impossible to extract meaningful data from the microphone values. This is being managed by implementing a peak detector circuit between the microphone and ADC on one of the final board designs. If this issue is due to loose connections, then the original design on flexPCB will work as expected once everything is soldered together; if this issue is due to some fundamental problem with the mic-PCB relationship, then the peak detector circuit will resolve it. If this is an assembly issue due to how tiny the mic is and how difficult it is to solder precisely, making many boards will help solve it by increasing the expected value that at least one board will end up with working components.
This is Prof. Fedder’s sketch of how the peak detector circuit should be included in the overall design.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
Changes were made to the block diagram: for one version of the final design, a peak detector circuit (composed of 2 resistors, 2 capacitors, 2 op-amps, and 2 diodes) now exists between each mic output and microcontroller ADC input.
Provide an updated schedule if changes have occurred.
All code, assembly, and testing must now take place before April 21st. The flexPCBs will be ordered this week.
Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements? Verification is usually related to your own subsystem and is likely to be discussed in your individual reports. Validation is usually related to your overall project and is likely to be discussed in your team reports.
We have not yet run any of the tests under the explicit rules stated in the design review, because they require either a complete bracelet or a complete mic-LED system. Since the results of each test are directly related to the requirements, considering which requirement is fulfilled by passing each test (with reference to the chart in the design review) should suffice.
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:
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 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.
It fits in the tube!
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 side with the notch closes much tighter than the side without the notch.
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).
The op amp fits under the Beetle, but there’s not that much room left for wires to go around it.
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.)
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.
