Radio Rick by Bluestem: Final Documentation
By Maggie, Helios, Hua
Embedded Files
Introduction
Introduction
For our final project, we have a client from university's Facilities Management Service (FMS). Our client is Rick, who is is an mason with 50 years of experience and does every little part of his work smoothly! He enjoys his work and loves his family. Sometimes he listens to music during work for entertainment.
We decided to build Rick a brick-shape radio which could play stations from his children’s cities and some other stations with quality music. Rick mentioned that He uses earbuds often during work, so we want the radio to be able to connect with his earbuds through Bluetooth besides including a speaker in the radio.
What We Built:
What We Built:
The radio is constructed from laser-cut 1/8" plywood, with overall dimensions derived from the size of a standard class brick (194 × 92 × 57 mm). All corner joints were generated using an online box-joint generator to ensure a precise fit. The device is powered by four AA batteries housed on the back, allowing Rick to easily replace them as needed. The front interface includes an on/off switch and a Bluetooth toggle that lets Rick switch audio output between the radio’s built-in speaker and his earbuds. Two primary dials serve as the main controls: the left dial adjusts volume and is surrounded by an etched pattern that indicates volume levels, while the right dial is used to cycle through a set of curated stations selected based on the cities where Rick’s children live and his personal listening preferences. At the center, an LCD screen displays the current audio output mode (speaker or earbuds) as well as the name and city of the station being played.
Images
Images
Front interface of the radio
Detail 1: Close-up front interface with LCD screen on
Detail 2: Back side of the radio
C0002.MP4The video shows using the left knob to adjust volume and the right knob to switch stations when the radio is on.
Detail 3: electronics inside the radio
Detail 4: Laser etched volume pattern around dial
Narrative Sketch:
Narrative Sketch:
When Rick gets to work early in the morning, he goes out to his cart and gets ready to start his day with some music. Instead of turning to a random Spotify algorithm, he turns to his Radio Rick speaker, attaches it to the top of his cart with the magnets on the back, and turns it onto a random Paris station, driving off to his working location with French rap music blasting, reminding him of his daughter currently working in Paris.
Once Rick gets to the site, he presses the Bluetooth button to switch the sound over to his headphones, and turns the volume down using the knob so he can hear his surroundings while he works, also deciding to switch the station to a Las Vegas station to remind himself of his son currently working in Las Vegas.
How We Got Here
How We Got Here
Prototype
Prototype
This prototype was designed to help answer the design question: Eventually how will the radio look like? Is the interface easy to understand and intuitive to use for Rick? Is there any other features Rick prefer to add?
Our prototype wasn't designed to work, but instead designed to be a proof of concept, mostly with all the knobs and buttons in where we figured they would be so that Rick could adjust their locations and functions as he saw fit. It consisted of a left knob, right knob, LCD screen, Bluetooth button, switch, and speaker, none of which worked, but were where we originally thought they would be for the final product.
The overall appearance of the prototype. It looks a lot like the final design.
A closeup from another perspective, showing the slot we planned to insert charger, instead of batteries.
Our electronic development while still in the prototype state.
Interactions with the bluetooth button.
IMG_3557.MOVOur electronic development while still in the prototype state. The video is showing interactions with a Pico, the controller we planned to use.
Rick and the team had a user test with the prototype.
Rick provides feedback to the team.
Rick happily holds the prototype.
During the feedback session, we have learned a lot about how Rick understands and uses the radio. We have answered the question we brought up ---- Rick likes the design of the radio. He even stated that he prefers it to be in its original shape rather than painted. However, our current design of the interface was not intuitive enough. Rick didn't realize that the toggle was the ON/OFF switch. He also coudn't differentiate the volumn and the station dial. Besides, Rick described his use case wth the radio. He decided to put it on the top of his working minitruck window, listening to it when in the car. He also asked us if we can add magnets to the back so he could attach it to the car ceiling.
All of those were great feedbacks, so we took most of them when further developing. We decided to replace the toggle with an actual switch. We also developed a new design system where there's volumn representation around the dial so he could tell the volumn dial from the station dial. We also planned to add a bluetooth icon underneath the bluetooth button so every interaction was labeled.
We were suprised that Rick prefered the vanilla look. Another surprise is that Rick mentioned Paris as one of the places his children once stayed in. As a result, we decided to incoporate Paris as one of the cities we have in the final radio station lists.
Process
Process
The closeup to a raspberry pi pico, a controller we planned to use.
The initial pico electronics that we experimented on.
Initially, we planned on using a Raspberry Pi Pico 2 W, because it was small, had Wi-Fi and Bluetooth, and would be easy to program for. What we didn't know, was that the type of Bluetooth the Pico was able to transmit was only able to send small data to phones and other IOT devices, nowhere near powerful enough to transmit audio, let alone powerful enough to decode the audio stream from an URL, live and play it on speakers. This was a massive setback, as much of our development and schedule had been built around the Pico and being able to use it as an all in one solution.
The Adafruit speaker bonnet that we used along with the Pi Zero.
The closeup to a TDA7297 module, a replacement sound device we decided to use with a ESP 32 (another type of controller) if the speaker bonnet didn't work.
In our scramble to come up with a Plan B, we stumbled upon two possible solutions: A Raspberry Pi Zero with an already attached Adafruit Speaker Bonnet, and the ESP32, another microcontroller that was much more powerful than the Pico 2 W. Despite spending hours trying to get both devices to work, including trying to find amplifiers in IdeATE that would be compatible with the ESP32, we finally were able to get sound out of the Zero, then eventually the radio stations we wanted to play in the first place. The next few days were spent designing and coding around the newly decided hardware, not only having to account for the lack of analog ports with an ADC and the smaller space tolerance due to the increased size of the Zero compared to the Pico, but also in software. Rather than using MicroPython or ArduinoC, the Zero is an actual computer and thus would have to run a Python script that would need to monitor button presses, knob changes, Bluetooth compatibility, and handle the radio stations. This was the major bottleneck, especially in terms of maneuvering around the interface and dealing with the threaded processes in order to make everything work as intended.
The final work scene. We were tring to figure out how did the batteries work.
The last accident we have. The speaker and the LCD collided with each other.
The final working station, with the raspberry Pi zero connected to a monitor.
Once the software was mostly implemented, the hardware was the next bottleneck, with us not being completely sure how to power the Zero with the battery pack (or if the battery pack would be able to provide enough power). But once we believed everything was correctly wired up, we tried to close the device only to find that there wasn't enough clearance for the original speaker, meaning we would have to downgrade to a smaller speaker. But somehow in this downgrade, we messed up the wiring to the point where the Zero was no longer getting power, adding more hours to what was an already arduous process, late at night, the week before finals. Finally, everything was powered and working as intended, and we were able to present the final product despite our many setbacks and hilariously inaccurate Gantt chart.
IMG_3609.MOVA working demo from the speaker which streams a Jazz station.
Conclusions and Lessons Learned
Conclusions and Lessons Learned
For the final crit, it seemed like a lot of people appreciated the thought and effort put behind the device, praising our intuitive design and very simple use case. We received comments on having "the exact size of a brick", which we did intentionally to honor Rick's masonry skills, and for our seemingly seamless integration of Bluetooth, which was both "good, very useful," and made the device "feel even more polished". But with our praise, came valid criticisms and advice, the two most notable being "an encoder to change stations" and the addition of an aux port. When designing our device, we chose to use a potentiometer with the though that each city would have its own section of the potentiometer, and you would know where to twist the knob for a specific city. But by using a encoder instead, despite losing the general area of the cities, you would gain physical feedback in knowing whether or not you actually switched channels, which would be much more beneficial in the long run. An aux port would also add to the convenience of the device, despite not being completely practical for Rick's use of it, other than upgrading the admittedly weak onboard speakers.
Working with a client was interesting, it was challenging trying to figure out what we as a team could realistically build with the limited tools and knowledge we had about both physical computing and masonry to create a device that would actually be beneficial to Rick in his daily job. As much as we love the final product we came up with and the overall design process as a whole, we wish we had more time to spend with Rick to build him something that would somehow fix an actually issue or petpeeve in his work process. Granted, there's little we as college students could do to help someone who has already spent 50+ working on his craft, but with more time maybe we could've found an easily fixable hassle or annoyance for him to fix.
That being said, the project was fun and insightful, not just on phsyical computing and its computer based counterparts but on working with someone in mind as a whole. In terms of difference choices, our big lesson learned was truly understanding the limits of every piece of technology we wanted to work with. Our original Gantt chart wasn't accurate because by the time we realized the the Raspberry Pico wouldn't be capable of completling the device on its own, we were days away from the final presentation. We learned we need to research and account for every piece we had, and knew that they would work as intented to do what we needed them to do. But we also gained insight into how computers worked, the design process and timeline, and how to build on each others strengths and weaknesses to work as a team and accomplish a project.
Technical Details
Technical Details
Block Diagram
Block Diagram
Schematic
Schematic
Code
Code
Our code is avaliable through Github:
https://github.com/danappyboi/RadioRick
Page updated
Report abuse