This week, I continued serial integration with the local application. We were able to demonstrate end-to-end communication at the interim demo which was a promising milestone.
Early in the week, I collaborated with Rahul to confirm how we would define the byte commands sent between the Raspberry Pi and local application. These were the commands we decided on:
“S\n” → Start “P\n” → Pause “C[measure_number]\n” → Current measure number “T[tempo_number]\n” → Current tempo “F[file_name]\n” → File incoming
On the Raspberry Pi side, start and stops received from the serial port and update the state of the scheduler (namely whether or not the piece is paused and if it is started, what time and measure number it starts at). The current measure number received will update the current measure played, while current measure number packets are sent back to the computer after every measure change to let the GUI know to change the measure as well.
Once this specification was in place, I tested the roundtrip latency for serial communication. Using the serial port on my computer, I timed how long it took to send a test command to the Raspberry Pi and receive a response back. This resulted in around a 3 ms delay which was well below the requirements we had for starting and stopping the playing. Using a similar method, we tested sending an entire XML file over USB but found that the latency for one page was already reaching 13 seconds. The time it takes to send longer files would scale linearly, so we decided that serial communication was too slow from a user’s perspective. Thus we are deciding to use scp over ssh to copy files onto the Raspberry Pi.
In addition to running these latency tests to validate the system, I have been running tests as I have developed the scheduling algorithm. In terms of scheduling accuracy, I have been generating custom sheet music that targets specific features, converting them into XML files, and running them through the scheduling algorithm to see the outputs. I ran two chromatic scales with sharps and flats through the system to make sure that all the pins were accurately mapped and that all the possible pitches were activated correctly. I also have one piece that is a repeated quarter note at 60 bpm and another at 120 bpm that I have used to test the tempo accuracy. Using a metronome app, I measured the tempo to match the target tempo. Another piece attempted to play a six note chord to ensure that only five pins max were high at one time.
Currently I am on schedule since our updated Gantt chart has me finalizing the serial communication up until Carnival.
Next week, I plan to finish the serial communication to incorporate opening the files based on the file name sent through the serial port. I will also need to add support for changing the tempo, which should be relatively straightforward since I just need to update the variable that keeps track of the measure duration in milliseconds.