Author: calebson

We are almost done with a very rough end-to-end system from pad hit detection all the way to gameplay. Recently, we received our hardware parts and got most of our communications and developments rolled out for testing and further synchronization. Receiving our hardware parts almost 1.5 weeks late does push our schedule back slightly but with some of the work we did over the break we would say that we are almost on track. We just have to handle the interfacing between the central hub and the computer with a standardized communication protocol using MIDI format to convey our notes.

Some changes that occurred, is that we had to switch our transmitter modules from the Ebyte E01ML01S to the Aidepeen nRF24L01+PA+LNA modules because of some shipment hiccups but we were able to circumvent any large disruptions because these chips are all from Nordic and thus their libraries are mostly similar. Besides that we were still wondering if we should outsource our audio generation to our computer interface or through the Daisy Seed which has onboard DAC as well as SDRAM for storing our wav files for our DSP.

Part A: The main global impact of this project is how it reduces the barrier to learning drums for beginners. Typically, you would need to buy an expensive drum kit, an expensive teacher, and know how to read sheet music, etc. With PadL1, all that is needed are the few pads and access to a personal computer, which makes learning drums much more accessible on a global scale.

Part A was written by Abishek

Part B: This project attempts to accommodate cultural factors by having the learning platform not use any specific language and instead using universally understandable symbols and colors. For example, we identify the pad that needs to be hit matching each pad with a given color and the timing is shown by a note falling towards a designated hit zone. Also, in the case a missed note, we use an audio “error note” to designate this mistake. All of these features are culture agnostic and thus allows people for all cultures to enjoy our product.

Part B was written by Rishabh

Part C: This project does require a bit of resources from the environment for the hardware development of the pads such as rubber sheets, acrylic sheets, foam dampeners, and plywood backings. But in the future, with access to industry standard materials, I feel like we can make our system a lot more compact and thus avoid all the excess materials from prototyping. However, our system does not require further natural resources and is pretty compact without releasing any emissions thus presenting not much of a threat on the environment itself.

Part C was written by Caleb

Overall, the project is moving along and we are adapting to the delay in the material acquisition well by developing our software side and some hardware code which we find hard to verify without the presence of the actual circuitry we are implementing on. The biggest risk is not being able to verify our coding constructs because we do not have the hardware aspect to build upon for our interfacing between all of our respective areas of design. We are trying to mitigate this risk by unit testing our functionality of software and hardware systems with similar products such as the Arduino Uno to mock that of the Arduino Pro Mini developing our data packaging algorithm. In the case we are unable to acquire the necessary parts for the project we can change from our miniature model to a bit larger model using the Raspberry Pi’s in the inventory instead of our small Daisy Seed for processing and changing it so that our logic can be moved between RPi and the computer rather than having it fully onboard as in the Daisy Seed.

We made a few changes to the hardware requirements/design choices of this design. We moved from ESP32 to the Ebyte E01-ML01 series because of the nRF24L01+ performances compared to the performances of the ESP32 on average latency. This article provided a comprehensive study comparing the costs of the different Wireless transmitting modules and I found that the Ebyte E01-ML01 most closely aligns with our hardware requirements for low latency. We just need an additional, inexpensive Arduino Mini Pro 3.3v chip to communicate with this transceiver module and send data and power accordingly. Also the E01-ML01DP5 comes with a multiceiver functionality where they can receive packages from multiple channels simultaneously.

Another change to the hardware design is the change from FPGA to the Daisy Seed Microcontroller. After listening to feedback on our proposal presentation, we found that the complexity in the code was not enough to offset the tradeoff of the low latency it provides. Furthermore, the Daisy Seed is specifically a microcontroller built for audio mixing with 64 MB of onboard RAM, an onboard Audio output pin, SPI pins for the receiver, FPU compliant, and usb port to communicate and receive power from the computer. This is a relatively fast microcontroller capable of handling some expensive or complicated operations which gives us the same advantages of an fpga but this microcontroller has a lot of RAM to allow us to store our audio samples. The SPI pins allow us to communicate with our receiver module and the usb port allows for communication with the computer to alter game state.

 

PART A:

From a psychological health and welfare perspective, the interactive learning platform promotes motivation, engagement, and sustained skill development through structured feedback and clear progression. The level-based system and performance summaries provide users with measurable goals and positive reinforcement, which can reduce frustration and performance anxiety often experienced by beginners. By allowing users to practice at home with portable, configurable equipment and even upload their own music, the system lowers barriers to musical participation and supports long-term learning regardless of access to formal instruction or dedicated practice spaces. Overall, the product aims to enhance user well-being by making music education safer, more approachable, and more inclusive.

Part A was written by Abishek

PART B:

As mentioned in our use case audience we are targeting beginner / intermediate musicians who want both the authenticity of certain instruments coupled with a portable and engaging learning experience to grow. So our game experience allows the user to be able to interact with our system in a manner conducive to education and improvement. The use of partitioning the system into distinctive pads, central hub, and computer allows for the user to configure different amounts of pads, instrumental sounds, and bring anywhere compared to the clunky electronic drums now. This will lower the barrier of entry for musicians into any field allowing there to be a greater intake and participation of the musical arts. I would say our system tries to provide the closest real world feedback while maintaining the benefits of the portable electronic pads.

Part B was written by Caleb

PART C:

When design our product and considering economic factors, we had the benefit of having several previously made products which implement various drum pad features at prices ranging from $60 to several hundreds of dollars. We want our product to improve the configurability and usability of the cheaper existing products, and thus many of our components had to available at low cost. This decision to use cheaper products caused us to make several component changes such as moving our processing from an FPGA to the Daisy Seed Microcontroller and moving our networking from an ESP32 to the Ebyte E01-ML01 series. Additionally, our mission to reduce cost also caused us to adjust our product solution to have each distributed pad be as simple as possible with the central hub being where most processing takes place. Since each pad is extremely simple, they can be made cheaply and thus most of our costs will come from the central hub. Here we’re also able to reduce costs since our interface is able to plug into commonly available devices such as a computer and audio speaker. We have our interactive learning platform can be hosted on any computer and after simple processing from our MCU, the output can be played from existing speakers. Since these are commonly available items, it’s unlikely that consumers will have to bear these costs, reducing the expense of our product. Thus, by using highly modular components and taking advantage of existing products and interfaces, we’ve been able to design our product to reduce costs while maintaining the fundamental learning experience.

Part C was written by Rishabh

We have developed our presentation and reviewing our design, adding new information from research papers that have developed augmented drum pads before and going to be developing our network protocol soon. We are finalizing our BOM over this weekend and having our design checked by the faculty and TA soon.

The largest risk at this moment is not getting our parts on time to get prototyping to allow significant leeway for our versions in due time. In order to combat this we need to get our design checked and BOM finalized as soon as possible.

Attached is the link to our BOM currently as we begin to make adjustments and order backups in case our design needs additional requirements. There are no additional changes to our design as of now.