This week, I worked on a handful of tasks. These included:
- Testing various system latencies and metrics
- Finishing up some mechanical work on the guitar
- Working on fixing the Pi’s reading of the Teensy’s UART data
- Implementing the buzzer on the Teensy
- Helped with determining the tempo of songs in the Pi software
System Testing:
The first thing tested was the functionality of all fretboard finger placement sensors and LEDs. I did this by using Tushaar’s functions and writing some firmware to light up the LED under where the user is pressing. With this in place, I tested each of the 56 possible finger placements 5 times each, and the corresponding LED lit up each time the sensor was tested. This has also been continuously tested as we have been testing various songs on the guitar during integration testing. This means that the control of the LEDs and the reading of the finger placement is 100% accurate.
The next requirement I tested was the current that can pass through the user. Our requirements state that this must be below 1mA, which is why we implemented a 3.3kOhm series resistor. This value was verified with a 0.1mA accurate multimeter before continuing with system construction and testing, but this week I performed formal testing with lab-bench equipment capable of 0.01uA accuracy. The average short circuit (assuming the user is a 0 Ohm short) was 5.37uA. This dropped to approximately 0.80uA when put through various individuals. This is over 1000-fold below our target average current, so this test was a success. Average current is so low because the fret sensors are only sampled for a handful of microseconds, and the full firmware loop is on the order of milliseconds. Using a series shunt resistor and an oscilloscope I measured the peak short circuit current to be 0.762mA, which lasts for 10us. This is ensured to be below 1mA by the series 3.3kOhm resistor and by a ~0.5V voltage drop on a diode.
By modifying Tushaar’s firmware with code to time the main loop, I was able to find that the system’s main loop time was 1555+-10us for both system modes. The similarity is because by almost all of the loop time is spent reading from the fretboard sensors and writing to the LEDs, which both modes do identically. This loop time directly corresponds to an LED refresh rate of 1555us, or 640Hz. This exceeds our requirement of 50Hz.
Strum to LED update delay was determined using an oscilloscope. I set the oscilloscope to trigger on a strum. This was done by probing the string the pick struck (while the pick was at ~3.3V minus a diode drop) and triggering on a falling edge, meaning the pick has left the string. I then probed the LED data line and determined that there is a 1850us delay between the strum and when the final LED on the fretboard receives its data. One interesting finding is that this is longer than the system loop time. I did observe that the system loop actually alternated between 1ms and 2ms, so I believe that 1. The NeoPixel library does not block on the functions used to write to the LEDs and 2. the library occasionally slows down the loop to 2ms to clear its output buffer. Nevertheless, the LEDs update far more frequently than our requirements, to the point where we are at the absolute limit of how frequently a strip of 60 NeoPixels can update.
Current consumption was measured for each component. The results were:
Pi: 0.45A
Teensy + Fretboard flip flops: 0.12A
LED current at 1/2 brightness rainbow*: 0.39A
The Pi draws far less current than expected, so we could run the LEDs at max brightness, but from our testing, this is too bright anyways.
*We color code each string, so this test was performed by lighting up each LED to its corresponding color
Strum rate was tested by strumming each string 200 times to the beat of a metronome and using the Teensy to count strums. I was able to strum up to 300BPM before strums began to be dropped (requirement was 200)
Buzzer audio level was 75 dB at the average user position
System battery life was ~3.5 hours, but this can be extended to around 4 hours. I take very good care of my LiPo batteries though and 3.5 hours corresponded to as discharged as I was willing to go for a test.
Metronome:
The main other task I worked on was implementing the buzzer firmware to alleviate some work from Tushaar. This involved doing some things with arduino that I was relatively unfamiliar with, such as working with structs, creating .h files, etc. I ultimately was able to create an easy to use function that takes in a BPM, which I had Tushaar provide via the data received over UART. I also worked on reading in the BPM from the MIDI file on the software, although we ultimately ended up going with Ashwin’s approach since my function failed on a select handful of MIDI files.
I am currently on schedule and have no hardware tasks remaining besides testing strum to webapp latency, which our current estimates put right around 250ms.
For next week I will be mainly working on the final poster, prepping materials for the demo, and working on the final report. I will also continue to offer firmware/software debugging help as needed