Output device
Group Assignment
Learning from Group Task: Measuring Power Consumption
-
I learned how to practically measure both voltage and current using a multimeter by setting up the probes correctly and choosing the right dial setting for DC voltage.
-
Understood the importance of connecting the multimeter in series to measure current and in parallel for voltage.
-
Realized that power consumption changes depending on the number of segments lit up on the 4-digit display.
-
Got comfortable using the Min/Max function on the multimeter to track fluctuations during operation.
-
Learned how to apply the formula P = V × I to calculate actual power usage based on live readings.
-
Understood why it's important to check power needs—helps in choosing the right power supply and avoiding overloading components.
For this week group work, detailed version is on Sharvari page.
Individual Assignment
A. What are Output Devices?
Output devices are components that allow a microcontroller or computer to communicate with the user or the outside world. These are the parts that show us the result of what’s happening inside the circuit or code — by creating movement, sound, light, or displaying information.
-
Some common output devices include:
-
LEDs for visual feedback
-
Motors for motion
-
Displays for showing numbers, text, or animations
-
Speakers for sound
In this assignment, I explored a few different output components and tested them with my custom PCB board (RP2040-based).
Link to PCB Board Fabrication: PCB Board Fabrication
NOTE: To play video, please click on particular image.
B. Touch Sensor with LED
The outcome I was aiming for was simple: when I touched the sensor, the LED should turn on, and when I removed my finger, the LED should turn off. It was a basic way to link an input (the sensor) with an output (the LED).
Connections
I connected the touch sensor to my PCB board so that it could detect my touch.
| Component | XIAO RP2040 Pin | Notes |
|---|---|---|
| Touch Sensor VCC | 3.3V | Power supply for the sensor |
| Touch Sensor GND | GND | Ground connection for the sensor |
| Touch Sensor OUT | D2 (GPIO2) | Digital input pin for touch sensor |
| LED Anode (+) | D3 (GPIO3) | Output pin to control LED |
| LED Cathode (-) | GND | Ground connection for the LED |
Then, I connected an LED to the PCB board, which is the output device. The idea was that the LED would light up when the sensor was touched.
I wrote a program to make the LED turn on or off depending on whether the touch sensor was activated.
This was just to try out simple functioning output on my PCB Board.
C. Servo Motor Positioning
The goal was to get the servo motor to rotate to a specific angle when triggered. This worked out well, and I was able to control the servo's movement through the signals from the PCB board.
Connections
Connected the servo motor to my PCB board, so it could move based on signals from the board.
| Servo Motor Pin | XIAO RP2040 Pin | Notes |
|---|---|---|
| VCC (Red) | 3.3V or 5V (if external) | 5V (for MG995) |
| GND (Black/Brown) | GND | GND |
| Signal (Yellow/Orange) | GPIO3 (or any PWM pin) | - |
The whole reason I kept things simple at first was because I wanted to test things directly on the PCB board and make sure everything was working before adding any complexity. By using basic devices like the touch sensor, LED, and servo motor, I was able to see how input and output devices interacted in a real-world setup. Testing on the board made everything so much easier to troubleshoot and adjust, which helped me learn how each component worked in action.
D. Connecting NeoPixel Ring
I wanted to make my NeoPixel Ring glow using an RP2040 board (Raspberry Pi Pico). Turns out, it’s pretty simple once you know what to do!
Connections
| NeoPixel Ring Pin | RP2040 Pin | Notes |
|---|---|---|
| DIN (Data In) | GP6 | Data pin for NeoPixel Ring |
| VCC (Power) | 3.3V or 5V | Power supply for NeoPixel (choose 5V for more brightness) |
| GND (Ground) | GND | Ground connection |
What was Next?
1.Made each LED light up one by one (looked like a moving dot ).
2.Changed colors from red to green to blue in a loop.
3.Made a smooth rainbow effect (this looked SO good!).
4.Tried a random color sparkle effect—it was super fun!
NeoPixels look amazing but are power-hungry. I experimented with brightness levels and saw how quickly power consumption could increase. Also, animations that used delays caused blocking issues, so I tried using non-blocking code for smoother transitions.
E. TM1637 Multiplication Displaying
Instead of using a clock, I decided to focus on multiplication for this project. I wanted to play around with numbers and show how they multiply, which could have practical uses like teaching multiplication, creating math games, or even for interactive displays in educational tools or apps. It was a fun way to experiment
Connections
| TM1637 Pin | RP2040 Pin | Notes |
|---|---|---|
| CLK (Clock) | GP2 | Clock signal for the TM1637 (for data transfer) |
| DIO (Data) | GP3 | Data signal for communication with the TM1637 |
| VCC | 3.3V | Power supply to the TM1637 (usually 3.3V) |
| GND | GND | Ground connection |
The TM1637 display uses a two-wire communication protocol (not I2C), and it’s important to update the digits manually using the correct library. It was fun to use a display to show live values, and I understood how displays can be a great feedback system for projects.
F. Text on 8x8 Matrix
I’d use an 8x8 LED matrix to create cool pixel art and make things blink, like I’m in a retro video game! I started by experimenting with writing text and seeing how it looked on the display.
Connections
| MAX7219 Pin | RP2040 Pin | Notes |
|---|---|---|
| VCC | 3.3V or 5V | Power supply to the MAX7219 (choose 5V for higher brightness) |
| GND | GND | Ground connection |
| DIN (Data) | GP3 | Data input pin for communication with MAX7219 |
| CS (Chip Select) | GP4 | Chip select pin for selecting the MAX7219 |
| CLK (Clock) | GP5 | Clock pin for serial data transfer to the MAX7219 |
The matrix uses SPI communication. Designing my own text and animations on an 8x8 grid was a bit challenging, especially when working with pixel-based font maps, but very satisfying once it worked. Scrolling text across multiple matrices would be my next step.
Programming Process
For every output device I used, the programming process followed a pattern: Understanding → Exploring Example Code → Adapting → Debugging → Testing → Finalizing.
1.Understanding the Device Before I wrote any code, I spent time understanding how the device works. For example, I checked whether the device needs digital, analog, or PWM signals. I also noted if it required a library, or if I could control it directly using GPIO.
2.Exploring Libraries & Example Code I usually start by searching for a reliable library. For most components like NeoPixels, TM1637 display, and the 8x8 matrix, I used libraries like:
-
Adafruit_NeoPixel (for NeoPixel ring)
-
TM1637Display (for the 4-digit display)
-
LedControl (for the 8x8 LED matrix)
-
Servo library (for the servo motor)
I opened the example sketches from these libraries to understand how functions were written, what values were being passed, and how the timing or animations were handled.
3.Pin Mapping & Adapting Code One of the most important steps was changing the pin numbers in the code to match the pins I had used on my custom RP2040 board. This sounds simple, but forgetting to update even one pin often caused devices to stay unresponsive.
I also customized the logic — for example:
-
Making the NeoPixel ring pulse instead of just blink
-
Changing the TM1637 display to show multiplication results
-
Making the servo rotate to specific angles based on input
4.Debugging with Serial Monitor I heavily used the serial monitor. When something didn’t behave as expected, I printed messages like “Touch detected”, “Motor moving”, or the value being passed to the LED matrix.
This helped me understand if the problem was with:
-
the hardware (like poor wiring),
-
the code logic (like incorrect conditions), or
-
the communication (like wrong libraries or baud rates).
Sometimes, I also printed sensor readings continuously to understand how touch or signals were being picked up.
5.Using Delays vs. Non-blocking Code In the beginning, I used a lot of delay() to control timing. It worked, but I noticed it caused other parts of the system to “pause” — for example, when the LED animation was running, the servo wouldn’t respond quickly.
6.Testing One Thing at a Time I learned not to write a lot of code at once. Instead, I would:
First check if the component responds
Then write basic code for its main function
After that, gradually add layers — like animations, logic conditions, or combinations with other devices
This “step-by-step” method helped a lot in reducing confusion and debugging faster.
Key Learnings from Programming
-
Always check pin capabilities (e.g., use PWM pins for servos and analogWrite).
-
Libraries save time, but you should still read their documentation to avoid using unsupported functions.
-
Serial Monitor is your best friend during debugging.
-
Avoid combining too many components at once unless each works individually first.
-
Use comments generously in your code. I even commented failed attempts to remember what not to repeat!
About the Codes
Most of the codes I used in my projects were ChatGPT-tied. It made things a lot easier, but I still had to tweak a few things—changing pin numbers, adjusting for my board, and making sure everything actually worked. It’s a great support, but you can’t just copy-paste and expect it to run perfectly.
I realized it’s more important to understand how things work rather than just getting the code. Like:
Power matters – Some components say they work on 3.3V, but they run much better on 5V. Always check.
Signal levels – The RP2040 runs on 3.3V logic, so if a module expects 5V, a level shifter might be needed.
Polling vs. interrupts – If I keep checking a sensor in the loop, it slows things down. Interrupts are way more efficient.
Library choice – Not all libraries are the same. Some are lightweight, some have extra features. Picking the right one makes a difference.
Making it my own – Sure, I can display numbers on an LED matrix, but what if I want it to scroll? Or detect patterns on a touch sensor instead of just ON/OFF?
So yeah, getting code from ChatGPT is just the start. The real work is understanding it and making it work for my project.
Problems in way
-
One of the first issues I faced was with the LED not lighting up. It turned out that I had connected it the wrong way — the anode and cathode were reversed. After correcting it, everything worked fine.
-
With the NeoPixel ring, I initially saw random flickering. I realized I was powering it directly from the board, which wasn't enough. Once I switched to an external 5V power source and added a capacitor, it worked perfectly.
-
The servo motor jittered a lot during testing. I learned that the power from the USB port wasn’t enough, especially for a larger motor like the MG995. I added an external power supply and shared a common ground, which fixed the problem.
-
For the TM1637 display, nothing showed up at first. I had to try a few different libraries before finding one that worked well with RP2040. I also ensured I was using the correct clock and data pins.
Learnings from Output Devices Week (Point Form)
-
Understood the difference between various output devices like servo motors, DC motors, stepper motors, LEDs, and buzzers.
-
Learned how PWM (Pulse Width Modulation) works and how it's used to control things like motor angle and LED brightness.
-
Realized the importance of using motor drivers or transistors when controlling motors—can’t just plug them directly to microcontroller pins.
-
Got familiar with voltage and current requirements—some components need external power or protection (like diodes for motors).
-
Practiced reading datasheets and figuring out pin configurations before wiring.
-
Faced issues like twitching servos or overheating components due to wrong connections—learned from real mistakes.
-
Understood that timing, delays, and pulse width affect physical movement in motors.
-
Debugging involved both code-level fixes and hardware checks—sometimes the problem was physical, not just in the code.
-
Used multimeters to check voltage and continuity—helped in identifying broken or shorted parts.
-
Learned to write cleaner code using libraries like Servo.h and to avoid overloading the loop function with delays.
-
Developed more confidence in making circuits that result in visible, moving output—taking the project from static to interactive.
Reflection
This week helped me understand output devices in depth. Testing different types (LEDs, motors, displays) gave me a broader view of how devices communicate visually and physically with users. It also showed me the importance of planning for power requirements and matching pin functions (PWM, digital, analog) correctly.
I also realized how much trial and error is involved — and how each time something doesn’t work, it becomes a chance to understand the system better. Documenting each step made it easier to backtrack when things failed.