Category: Caleb’s Status Reports

I have completed most of the hardware debugging and finishing the digital audio conversion on the hardware. Furthermore, the debouncing achieves a 94% accuracy on no erroneous double hit registers. So I am just planning to meet with the software side for one final run before integrating the system fully and recording the video. There are some difficulties in powering on each pad so I will try to augment the current design to make space for it later which was a shortcoming on my end as the designer. Otherwise we are looking pretty good in terms of integration and hardware capabilities.

I am mostly on schedule and am going to focus on adding the hardware details to the poster and the final design report. For future steps we could have been faster on the overall system wide integration to be able to pinpoint small bugs earlier; however, I feel like our unit testing on each of our own ends helped to make the transition as seamless as possible.

I just went over all the code within the hardware to make sure they had the most updated versions and did not register erroneous double hits. In the test/validation I described in the team status report I achieved a 97.3% no double hit rate on all pads by increasing the debouncing window between hits and slightly increasing the threshold of the hit activations.

Center hits are classified by having all piezo sensors reading within 1% margin of error from each other. Rimshot hits are classified as having 1 or 2 sensors being greater than 1 V and 1.5 V. An edge hit is classified as at most one sensor being greater than or equal to 1.5V

For center hit:  set at 100 bpm we achieved 100% no double hit rate,  set at 140 bpm we achieved 92% no double hit rate but 4% missed hits, set at 85 bpm we achieved 100% no double hit rate.

For rimshots: set at 100 bpm we achieved 92% no double hit rate, set at 140 bpm we achieved 88% double hit rate, set at 85 bpm we achieved 100% no double hit rate.

For edge shots: set at 100 bpm we achieved 88% no double hit rate, set at 140 bpm we achieved 83% no double hit rate, set at 85 bpm we achieved 96% no double hit rate.

We hit the target rates (<8% double hit rate) for center hits and rimshots but could not hit it on the edge shots which makes sense because I was not able to procure rubber stoppers in time for the final presentation so when you hit the edge of the drum casing, the vibrations are still preserved rather than being dampened and cause the piezos to pick up twice.

I finished up adding additional functionality to the central hub where it intakes keyboard inputs to set the mode to freeplay (audio generated by daisy seed on its own but needs a 5V 150 mA power supply), interactive game mode (interim demo but having the pads interface via bluetooth to the computer as inputs to a guitar hero-esque game), or multiplayer (a networked multiplayer game where 3 pads are split among the 2 players, each with their own central hub and laptop seeing the same game).

Overall, I would say I got a lot more comfortable looking at documentation especially on github repos and forums for open source resources. It also really consolidated my embedded understanding of nRF32L01+ protocols while trying to find a bandwidth of 2.4GHz WiFi that wasn’t too convoluted or noisy. Lastly, it also really helped with the overall design process; I feel like I practiced the idea of iterative designs well especially for the development of the pads which helped me to really streamline the process and get it done early so that I could focus on other features of the central hub. Also this helped consolidate my interpersonal skills when trying to meet deliverable deadlines as a team and gave me experience in being able to divvy up the work and trust my partners.

In terms of the schedule I am on schedule and have enough slack time to be able to debug anything that arises in final presentation day in time for the actual final presentation for capstone. For next steps, I will try to stress test the hardware to uncover any bugs that I may not be expecting.

The hardware aspect is mostly done and just needs to be reproduced to be able to make 6 pads. There are a few things that need to be modified however. We were originally using a plexiglass/acrylic material for our impact plate but making 6 of those were difficult due to the inability to laser cut them so we changed to acrylic which is a lot denser than the plexiglass. This does have its downsides because the dampening of the acrylic is most likely a lot less than the plexiglass. Therefore, there will most likely be a lot more double hits registered due to residual sound waves as I noticed in the interim demo.

A short fix for that is that I can increase the debouncing window on the arduino code to account for the residuals or increase the threshold for activation.

Some other variances with the hardware that I noticed was that the rims could register shots but there was low dampening from the environment which is not ideal. A fix for that is adding rubber pads on the screw heads of the pads so that the rubber can act as the dampener from the environment.

One concern is that I noticed that some of the piezos on the impact plates I just made had a very large negative voltage spike compared to other pads which were mostly net positive peaks. It could be an issue with the soldering but I will have to test it in the entirety of its configuration to be sure.

Lastly, for future steps I am planning to incorporate another daisy seed central hub with configurable settings such that 2 users are able to play multiplayer over a network with each daisy seed acting as a client server interface.

I have successfully developed most of the pad hardware to be easily recreated and will develop 6 pads within the next few weeks for our minimum viable product. Using the Arduino Pro Mini 3.3V allows for easy reprogramming to calibrate for any threshold modifications needed. Usually will have to do with time latency window in between hits as well as the minimum voltage threshold floor.  There usually might be very slight differences in tolerances because of the piezo disc manufacturing.

Finally, I will finish implementing digital playback audio on my central hub so that the system can be a stand alone product to be able to produce its own sounds. Furthermore, I will start implementing code on a separate daisy seed so that we can create a dual-networked system splitting the 6 pads into 3 pads for each player.

I would say I am pretty on schedule and in order for the whole team to be on schedule I will try to see in what areas I can help out with the assembly of the product on the software and networking side.

This past week I was able to get the multiceiver functionality to work completely and able to register “simultaneous” hits to the drum pads. I also worked on developing the framing of the drums to make it look nice but also secure. I also finished the overall design including the foam dampeners added to the underside of the impact plate which greatly improved overall reading of the pad and isolation of signals from the pad. I also soldered extra wires onto these pads to improve signal integrity as well as the connection between pad and the breadboard.

We are on track for being able to show a somewhat viable demo by interim demo and I am on track to develop more pads for the final. Might have to tweak the 3D printing iterations to make a larger rim to secure the pad.

My next goals will be to create the housing as well as the digital sound output from the central hub processor itself. I was held up debugging the wireless multiceiver communication protocol.

This communication protocol can only support up to a max of 6 simultaneous mailboxes and then we can later tackle networking and being able to play across different location if time permits. But the immediate goal is to be able to create 6 pads and have it create a fault-proof end-to-end system by demo.

In this week I was able to link the pad system to the transmitter and then have it transmit the correct hit levels to the central hub. I am still calibrating the sensitivity and I will most likely have to increase the voltage threshold for the sending to make sure that noise is not caught. Currently it’s at 50 mV but will bring it up to 80 mV as most soft hits are around 100 mV on its first peak. I have started implementing the Multiceiver functionality of the Nordic nRF24L01+ where it can bin incoming messages to make it seem as if they come simultaneously and allow the receiver to hear on multiple channels. Also have started working on the DSP to make sure the audio is produced and heard on the user end.

I would say I am a little behind in terms of the schedule so I will definitely be in the lab this week to finish up these last few features and connect it with the software side. However, I feel as though this will not be too much of an issue as the synchronization can be made up with a sliding window of 5 ms to make sure that the hits are registered on time for the game.

I also have to measure end to end latency and notify the team so that they can create a game with enough of a leeway to accommodate for the delay.

In the past two weeks, I was able to successfully communicate between pad and central hub transceivers using the code with low latency on LPA mode (low power) meaning that it will most likely see an increase in throughput and decrease in lossy-ness if we increase the Power and transmission settings. Additionally, I was able to assist in developing our drum pad system with the voltage regulators. I am currently working on the MIDI format as well as the audio system playback from the central hub after being able to process the incoming packets.

Some things that are to note: On startup and flashing both the RX and the TX code need to be powered on and off otherwise it does not work correctly off of boot. I am trying to debug that currently but for now the simple fix is to disconnect the power source and reconnect it. It’s important to note that the TX circuitry requires and operates on 3.3V logic. I am still figuring out the Daisy Seed Library as it has a lot of documentation and capabilities for digital signal processing, audio output, and MIDI format outputs via USB.

I would say that I am pretty on schedule with my progress but could do a bit more research on the daisy seed to put our team ahead of schedule.

The Link Lost message printed because the transmitter only activates every second to send a packet and otherwise sleeps to save on battery prompting the loss of connection.

I developed the nRF24L01 communication protocol on C++ for both the receiving logic and the transmitting logic that should be on both the  Ebyte E01-ML01DP5 and the transmitter. We had to quickly order a new set of transmitters because our order for ML01S were cancelled. I am currently testing the code on the pair of ML01DP5 modules I have right now and it seems as though the protocol is working with consistent 5 ms latency. I did this by taking timestamps of both transmission and reception of ack packets from the transceiver. My only concern would be the ability to supply power to the pads but for now it should be sufficient to plug in 9V batteries with a step down convertor to 5 or 3.3V which should last a couple of hours (2-3 hrs).

Furthermore, I am working on the assembly of the pad and will get to cutting up the wood backing, acrylic impact plate, both backing and padding foam.

One of the big bottlenecks is not having the receiving & central hub modules on hand to actually implement and test the code; additionally, we don’t have the piezo discs to actually test the implementation and threshold. So instead of waiting to develop the pad until the piezos come I started with the implementation of the wireless communication protocol allowing for us to still be on schedule. 

This week I got (1) the BOM finalized and ordered the items for the very first prototype of both the pad and central hub system, (2) found online free drum sample libraries to load onto the central hub microcontroller for real time convolution to mimic real drum audio, and (3) developed the specific circuitry and connectivity of all hardware systems.

I don’t really think that the central hub will have too much variation in architecture so I feel confident that we don’t have to change the architecture/design. However, for the pads I ordered the very preliminary design which uses a rubber head and piezos to detect impact. This might not give the sensitivity we require to pinpoint location and impact characteristics so we might have to look for a different configuration but this requires the prototype to be tested using FSR, PVDF, and mesh head.

I started developing the base bootloader code for the Arduino Pro Mini  & Daisy Seed that we will be using for data packaging and central hub logic respectively. The Arduino Pro Mini can be flashed using an Arduino Uno so that should be fine but in the Daisy Seed I need to flash both the RAM with the audio samples on boot as well as the code I want to flash it with. So I am reading the datasheets currently to figure out the setup code for each of these.

I feel as though my process is only a couple days behind because we cannot start developing or testing the code until we have the hardware components and that is our biggest bottleneck in this project. However, the software side seems to be making some progress in their translation.

By next week we hopefully receive the materials we ordered so that we can develop a working prototype of our central hub ecosystem with the hardware and basic unit testing code for the audio output and the SPI interconnect with the receiver hub.

I spent this week mostly preparing for the proposal presentation on Wednesday and researching papers from the NIME that have done previous percussive augmented designs to draw inspiration from. After researching I have compiled a basic list of parts for the hardware aspect that are not specific yet.

I plan to finalize the hardware portion of the BOM by Sunday or Monday but after finalizing this I would say I am slightly behind schedule for prototyping. I can get on schedule only once I obtain the materials to start the prototyping.

I need to converse with the faculty and TA more to get more specifics on the designs and vendors for our product.