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
