Team Status Report for 4/27

General Updates

We completed the final presentation slides.

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:

  1. The connection wasn’t secure before, and the mic output from before might not have been meaningful.
  2. 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 1
End of 1
Beginning of 2
End 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.

https://youtu.be/_pMX454oqqs 

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.

Leave a Reply

Your email address will not be published. Required fields are marked *