ScopeBoy: Handheld Mixed-Domain Oscilloscope (MDO)

This project builds ScopeBoy, a handheld, dual-core mixed-domain oscilloscope (MDO) on the Raspberry Pi Pico RP2040, featuring real-time spectral analysis and gain control.

Using the RP2040 microcontroller, we created a device that samples signals at 500 kSps. It leverages the dual-core architecture to separate signal processing (FFT math) from the user interface (drawing waveforms), ensuring a lag-free 60 FPS experience.

Key Features

• Oscilloscope Mode: Adjustable timebase (10ms-1s), voltage scale, and live cursors.
• Spectrum Analyzer Mode: 64-bin real-time FFT with Hanning windowing and peak frequency detection.
• Easter Egg: A fully playable "Snake" game triggered by a hidden button combo.

Rationale and sources of your project idea

We wanted a portable, battery-friendly instrument for quickly debugging real-world signals (especially PWM control signals and small audio circuits) without needing a bench scope.

• Motivation / constraints: A handheld tool that is fast to deploy for labs, demos, and quick iteration, while still providing both time-domain and frequency-domain visibility.
• Inspiration: The Cornell ECE4760/ECE5730 course structure and prior RP2040 oscilloscope projects motivated a dual-core approach that keeps the UI responsive while running DSP in parallel.

Background math

• Nyquist-Shannon Sampling Theorem: With a sampling rate of 500 kSps, the highest measurable frequency without aliasing is 250 kHz (the Nyquist frequency).
• Discrete Fourier Transform (DFT): Our computeDFT() converts a block of \(N\) time samples into frequency bins:

  X_k = Σ_{n=0}^{N-1} x_n · e^{-j2πkn/N}

  Where:

  • x_n is the input voltage sample at index n.
  • X_k is the output spectral component (magnitude and phase) at frequency bin k.
  • We compute real/imaginary components and then convert to magnitude, \( |X_k| = \sqrt{Re^2 + Im^2} \), to find peaks.
• Windowing (Hanning Window): Because we capture a finite “slice” of a continuous signal, the start and end of the sample buffer rarely align perfectly. This discontinuity causes spectral leakage, where energy from one frequency bleeds into neighboring bins. We apply a Hanning window before running the FFT/DFT to taper the edges:

  w(n) = 0.5(1 − cos(2πn/(N−1)))

Logical structure

The system uses an Asymmetric Multiprocessing (AMP) model to ensure the User Interface (UI) never stutters, even when performing heavy calculations.

Create a block diagram showing:

• Core 0 (The Application Processor):
  • Responsibilities: Handles all User Input (Joystick, Buttons, Rotary Encoder), manages the Trigger Logic (detecting rising/falling edges), and drives the SPI TFT Display.
  • Architecture: Runs a cooperative scheduler (protothreads) to toggle between input polling and screen rendering at 60Hz.
• Core 1 (The DSP Coprocessor):
  • Responsibilities: Dedicated entirely to number crunching. It runs an infinite loop that waits for fresh data, applies the Hanning Window, computes the DFT, and updates the FFT output array.
  • Benefit: Because this math happens on a separate core, the oscilloscope trace on screen never “freezes” or lags, even if the math takes milliseconds to complete.
• Shared Memory & Synchronization:
  • The frame_buf (ADC samples) and fft_output arrays reside in shared RAM.
  • Access is managed via flags and semaphores to ensure Core 1 doesn't try to calculate the FFT while Core 0 is simultaneously writing new data from the ADC.

Hardware/software tradeoffs

1. Signal Processing (FFT): Software (Core 1) vs. Dedicated DSP Hardware

• Decision: Implemented Software FFT on the secondary Cortex-M0+ core.
• Performance: While a dedicated DSP chip or FPGA would calculate DFTs microseconds faster, the RP2040's dual-core architecture allowed us to offload the math to Core 1. This prevents the UI (Core 0) from freezing, achieving a "good enough" real-time update rate (approx. 15-30 Hz for FFT) without additional hardware.
• Cost & Complexity: Using the existing microcontroller reduced the Bill of Materials (BOM) cost by ~$5-10 and significantly reduced PCB complexity.
• Maintainability: Doing the math in C allows for easy adjustments to windowing functions (e.g., swapping Hanning for Blackman) without rewiring hardware.

2. Analog Front End: Digital Zoom vs. Analog Gain

• Decision: A Hybrid approach. We use hardware switches (Gain Modes) for coarse range adjustment, refined by software scaling.
• Performance: Purely software "zoom" (multiplying the ADC value) destroys signal resolution; zooming 10x on a 10mV signal amplifies the quantization noise. Hardware gain (using Op-Amps/Relays) preserves the Signal-to-Noise Ratio (SNR) before it hits the ADC.
• Complexity: Adding hardware gain stages increases circuit complexity and power consumption compared to a simple voltage divider, but it was strictly necessary to measure small signals accurately.

3. Display Driving: Hardware SPI vs. Bit-Banging

• Decision: Hardware SPI Peripheral.
• Performance: Driving a 320x240 display requires pushing ~153,000 bytes per frame. "Bit-banging" (toggling pins in software) would cap the frame rate at ~5 FPS. Using the RP2040's hardware SPI block allows us to reach 60 FPS with minimal CPU overhead.
• Power: Hardware peripherals are more power-efficient as they allow the CPU to sleep or perform other tasks (like polling inputs) during data transmission.

Program details

This project required solving several complex graphics and concurrency problems to achieve a stable 60 FPS update rate on the RP2040.

Program Details: Technical Challenges & Solutions

1. The "No-Fly Zone" Rendering Algorithm

One of the most persistent issues in digital oscilloscope displays is text flickering or overwriting. If the waveform is drawn across the entire screen width, it inevitably scribbles over the voltage axis labels (e.g., "3.3V", "1.65V") on the left side. Redrawing these labels every frame is computationally expensive and causes flashing.

• The Solution: We implemented a viewport clipping algorithm in the drawWaveformFromBuffer function. By defining specific WAVE_MARGIN constants (Left: 35px, Top: 25px, Bottom: 20px), the renderer creates a "protected" area for the UI.
• How it works: The drawing loop starts at x = MARGIN_LEFT rather than 0. Any signal sample that exceeds the vertical bounds (MARGIN_TOP or MARGIN_BOTTOM) is mathematically clamped before drawing. This ensures the waveform "emerges" cleanly from behind the axis labels without ever corrupting the text pixels.

2. Flicker-Free Graphics (Smart Erase)

Standard graphics libraries often rely on tft_fillScreen(BLACK) to clear the frame before redrawing. On SPI displays, this bulk pixel transfer is too slow and results in a visible "scanline" flicker.

• Snake Mode Implementation: Instead of clearing the screen, we used a differential rendering strategy. The game logic tracks the exact position of the snake's tail before it moves. We draw a single black block over the old tail position and a colored block at the new head position. This reduces the SPI bus load from ~76,000 pixels per frame (full screen) to just ~200 pixels per frame.
• Oscilloscope Grid: Similarly, when the waveform erases its old trace (drawing black lines), it often accidentally deletes the grid lines. We added a "Repair Bot" logic inside the draw loop: if the eraser crosses a known grid coordinate (e.g., x=160 or y=120), the function immediately repaints that specific grid pixel, maintaining a solid, unbroken reticle.

3. Dual-Core Concurrency

The RP2040 features two ARM Cortex-M0+ cores, which we leveraged to separate the real-time blocking tasks from the math-heavy processing.

• Core 0 (The Interface): Runs the protothreads scheduler to handle high-speed SPI display rendering and user input (Joystick/Buttons). This ensures the UI remains responsive (60 FPS) at all times.
• Core 1 (The Math Coprocessor): Dedicated solely to the FFT calculations. Using multicore_launch_core1, this core continuously processes the ADC buffer, applying the Hanning window and computing the Discrete Fourier Transform (DFT).
• Synchronization: Shared memory access to the frame_buf array is protected using semaphores to prevent race conditions (read-while-write errors).

4. Rotary Encoder

The rotary encoder generates pulses on its CLK and DT pins when rotated. The direction is determined by looking at if the pulse on CLK or DT was first. Professor Bruce had previously worked with rotary encoders, so we started by referencing his work (found here). He used a protothread and would sample the GPIO pins at a set interval. While this solution works, we wanted to use interrupts to make the driver cleaner.

• Interrupts: The RP2040 uses a single ISR to handle all GPIO interrupts. We set up the interrupt once for rising edges on GPIO pins, then check which pin triggered it.
• Delta: When the interrupt is triggered, a counter is incremented or decremented depending on whether the CLK or DT pin was triggered. When we process the input, we use the counter value to determine how many times the encoder was rotated, then reset the counter.
• Debouncing: In order to prevent bouncing, we placed on the CLK and DT pins of the encoder. We found that 10 nF capacitors were enough to reduce bouncing, while still keeping the encoder responsive.

5. ADC

We decided to use the ADC built into the RP2040, mostly due to time after loosing the PCBs.

• Sample Rate: The internal ADC operates at 500 kS/s. We wanted to use the full sampling rate to get as much data as we could. This meant not using the clock divider for the ADC.
• DMA: To read data from the ADC without blocking a CPU core, we used DMA channels. We had a two-channel configuration, with a control channel and a data channel. The data channel would read data from the ADC when it was available and store it in a buffer array. When it reached the end of the array, the control channel would trigger and reset the data channel's pointer to the start of the array.

Hardware details

The hardware design prioritizes modularity and low cost, using off-the-shelf components to create a professional-grade instrument. Figure 1 in Appendix C shows the full schematic for the breadboard version of the ScopeBoy.

Bill of Materials (BOM)

• Microcontroller: Raspberry Pi Pico (RP2040)
• Display: Adafruit 3.5" TFT Breakout (320x480) with HX8357D driver
• Input: Adafruit Mini Gamepad (I2C Gamepad with Analog Joystick)
• Control: KY-040 Rotary Encoder (for precise zoom/scale adjustment)
• Interface: Breadboard and jumpers for rapid prototyping

Breadboard Analog Front End BOM

Components used for input coupling, biasing, protection, and gain/trigger circuitry. See the schematic in Figure 1 for more details.

Item	Part / Value	Qty	Notes
Op-amp	MCP6242 (dual, rail-to-rail)	1	Gain/buffer stages
Comparator	AD8561	1	Fast edge/trigger detection
DAC	MCP4822	1	Adjustable trigger threshold
Analog switch	ADG621 (dual SPST)	1	Gain range switching
Input resistor	1 MΩ	1	Scope-probe style input impedance
Compensation capacitor	10–22 pF	1	Input compensation (probe-dependent)
AC coupling capacitor	0.1–1 µF	1	Blocks DC before biasing
Bias divider resistors	10 kΩ	2	Generates ~1.65 V mid-bias
Connector / adapter	BNC-to-terminal block	1	Connects standard scope probes to breadboard

PCB BOM

Download the full BOM CSV: Download CSV

Reference	Value	Qty
C1,C3,C8,C10,C11	2.2u	5
C2,C26	1u	2
C4,C5	10n	2
C6	4.7u	1
C7	1p	1
C9	6.8p	1
C12,C13,C14,C16,C18,C19,C20,C21,C22,C23,C27,C28,C29,C30	100n	14
C15,C17,C24	22u	3
C25	160p	1
C31,C32	10nF	2
D1,D2,D3	D	3
J1	SMA Samtec SMA-J-P-X-ST-EM1 EdgeMount	2
J5	SM04B-SRSS-TB	1
J6,J7	SM03B-SRSS-TB	2
Q1	DMG2305UX-7	1
R1,R2	87k	2
R3	680k	1
R4,R6	50k	2
R5	100k	1
R7,R8	0	2
R9,R14,R17,R23	1k	4
R10	47	1
R11,R12,R15,R16,R18	100	5
R13	680	1
R19,R24	22	2
R20,R21	4.7k	2
R22	1MEG	1
U1	LP2985-3.3	1
U2	LM27762	1
U3	OPA354	1
U4	ADG621	1
U5	LMH6629	1

Pin Mapping

The system uses SPI0 for the display and SPI1 for the DAC. Running them both on the same bus caused interference.

Component	Pico Pin	Function
TFT Display	GPIO 14	SPI0 SCK (Clock)
	GPIO 15	SPI0 TX (MOSI)
	GPIO 18	TFT_CS (Chip Select)
	GPIO 16	TFT_DC (Data/Command)
Rotary Encoder	GPIO 19, 20	CLK, DT (Encoder Lines)
	GPIO 6	SW (Push Button)
I2C Gamepad	GPIO 2, 3	I2C SDA/SCL
Analog In	GPIO 26	ADC0 (Probe Input)
Gain Select	GPIO 8, 9	Sel1, Sel0
DAC SPI	GPIO 10	SPI1 SCK (Clock)
	GPIO 11	SPI1 TX (MOSI)
	GPIO 13	DAC_CS (Chip Select)

Analog Front End (Gain Scaling)

While the current version uses a software-simulated gain stage, the architecture is designed to support a hardware op-amp frontend.

• The system implements three gain modes: Low (0.21x), Med (0.39x), and High (1.98x).
• The adc_to_volt function dynamically scales the raw 12-bit ADC reading (0-4095) based on the active mode. This allows the scope to measure signals ranging from millivolts (High Gain) to ~15V (Low Gain), with the software automatically adjusting the grid labels to display the correct "Real World" voltage.

3D Assembly Views

The following exploded views illustrate the physical assembly of the ScopeBoy device:

Reused code/design

This project stands on the shoulders of open-source libraries and hardware designs, modified for high-performance needs:

• TFTMaster.h: A highly optimized SPI library for the RP2040, originally developed by MEng students at Cornell University. It provided the low-level pixel pushing primitives.
• Protothreads (pt): A lightweight threading library by Adam Dunkels, used here to implement the cooperative multitasking scheduler on Core 0.
• RPScope: A Pico based dual-channel oscilloscope design by Jenny List. We modified their PCB to make it single channel, and work with our TFT screen, encoder, joystick, and battery charger.

Things which did not work

Our biggest failure was in the PCB. Not because the PCB didn't work or anything. We don't know whether the PCB worked because it wandered off (read: was stolen) over Thanksgiving break. This forced us to think on our feet and redesign the analog front end. We built a working front end, but it had significantly less bandwidth than we originally planned. We had planned for 1 MHz of bandwidth, but ultimately ended up at around 70 kHz. While it has substantially less bandwidth, the scope would still work for audio-range signals, so it serves a purpose.

We also designed an enclosure for the PCB, which we planned to 3D print. After we lost the boards, we scrapped the enclosure because the breadboard was fragile enough that it didn’t make sense to keep the system handheld. This also meant that we scrapped our plans to power it with a LiPo battery. We had the battery charger component from Adafruit, but since the board wasn’t handheld, it didn't make sense to power it.

Even though we lost the PCBs and had to redesign the front end, this allowed us to correct some design flaws in the original we had used as the base. Initially, our board had a Coax connector instead of the standard BNC connectors used by scope probes. This was because the design lacked the 1MΩ resistor and 10-22 pF capacitor used in oscilloscopes for 10x mode. So, using a coax SMA made more sense. However, that would have been annoying, since we would have had to make our own probe cable or get a coax-to-BNC connector adapter. We ordered a BNC-to-2-terminal block, which we used with the breadboard to connect standard scope probes, and put the proper resistor and capacitor in the circuit. This made connecting a scope probe easier, but it was still not a perfect solution. The scope probe's impedance wasn't matched, and 10X mode still didn't work because the signal was attenuated to the point that it was lost in the noise by the time it reached the gain stage.

The original PCB design also included a -3.3 V rail for the op-amps, allowing signals to reach negative voltages. For the breadboard design, we used the 3.3V and grounds directly from the Pico. This added more noise and, more importantly, required biasing all signals to prevent clipping at the op-amp rails. We blocked the DC bias in the original signal using a capacitor at the input, then applied our own 1.65 V bias. This meant that the scope couldn’t measure DC signals, with a minimum frequency of around 2 kHz.

Thorough discussion of AI use

1. Tools Used

• Models: Google Gemini (Pro/Flash) and OpenAI GPT-5.
• IDE Assistants: CoPilot in VSCode

2. Application of AI

• Feasibility Checks: Before writing code, we used AI to estimate the feasibility of adding complex features like the FFT spectrum analyzer and the "Snake" game on the secondary core without disrupting the 60Hz oscilloscope refresh rate.
• Code Refactoring & Reuse: AI was instrumental during the major overhaul of the input system. We needed to add new modes (Menu navigation, Snake game) that required reusing existing low-level button reading logic. We prompted the AI to "wrap" our raw bit-masking logic as the part of our modular state machine (handleInput) that could support multiple contexts (Scope vs. Game) without duplicating the low-level driver code.
• Website Formatting: AI was used to assist with the creation of the website. It helped with formatting parts of the website, like the image gallary, and some tables.

3. Verification Steps

• Manual Code Review: Every block of AI-generated C code was manually reviewed for hardware safety.
• Signal Measurement: For the math functions suggested by AI (such as the gain scaling factors), we verified the output by injecting known voltage signals from a function generator and confirming the oscilloscope displayed the correct values.

4. AI-Generated Content NOT Used

Attempted TFT Display Driver Port: Early in the project, we attempted to use AI to port an existing Arduino-based TFT library (Adafruit_ILI9341) to the Raspberry Pi Pico C SDK.

• Why it was discarded: The AI hallucinated compatibility with Arduino-specific hardware abstraction layers (like SPI.h and Adafruit_GFX.h) that do not exist in the bare-metal Pico SDK environment. It produced code with heavy dependency chains and incorrect SPI timing constraints that could not compile.
• Resolution: We discarded the AI-generated driver entirely and adopted the TFTMaster.h library (developed by MEng students), which provides optimized, hardware-specific SPI functions for the RP2040.

Test data / traces / waveforms

Images of the scope in action:

Speed of execution

• Latency / responsiveness: The UI runs in a dedicated Core 0 protothread loop that targets ~60 FPS by yielding for ~16.7 ms per frame. Input is polled every frame so knob/joystick actions feel immediate.
• Flicker / hesitation: Instead of clearing and redrawing the full screen each frame (too slow over SPI), we use “smart redraw”: only update the parts that change (waveform/menus) and repair any grid pixels that get erased. This avoids visible scanline flicker.
• Concurrency behavior: The heavy math (DFT/FFT) runs on Core 1, while Core 0 focuses on rendering + input. This separation prevents spectrum calculations from freezing the oscilloscope trace.
• DMA for ADC: DMA channels move data from the ADC to an input buffer to keep the CPU free to draw the UI and perform calculations.

Accuracy

• We did not take direct measurements to compare the expected and actual outputs. We did verify that the signals looked mostly correct, although we do expect noise in the system and the RP2040's ADC to introduce artifacts in the system.
• We performed this informal verifiaction by comparing our signal to a real oscilloscope's output to make sure they aligned. However, we should have recoreded actual measurements to formally verify out output.

Safety enforcement

• Due to the analog front end, the scope is fundamentally limited to signals of 30V peak to peak. This voltage level is relatively safe, especially given that the scope doesn't work with signals of less than 2kHz. Still, being on a breadboard does mean that there are semi-exposed wires, so users should be careful. This problem would have been solved with the enclosure.
• We had originally planned on using a LiPo battery to power the board. LiPos can be dangerous if charged incorrectly or punctured. We were going to use a battery charging circuit to prevent improper charging, and would have enclosed the battery.
• We did not use the watchdog or any other safety features on the Pico. This is a low-stakes device, and crashes would only inconvenience the user, not harm them. We still tried to make the code robust to prevent crashes.

Usability

• The final version of the oscilloscope worked, but was not the most usable. Its biggest constraint was that it had two breadboards, which made it fragile and hard to transport. This version would not be handheld, and we had to be careful when transporting it.
• The controls all worked, but users had to hold the rotary encoder and joystick/button controller in their hands. Ideally, these would have been integrated into the case. The rotary encoder occasionally registered an incorrect input due to our pure-hardware debouncing. Accessing the snake minigame required precise button inputs, which didn't always trigger.

Conclusions

Appendices

Appendix A: Permissions

Project on the course website

Include exactly one of the following sentences:

• “The group approves this report for inclusion on the course website.”

Project video on the course YouTube channel

Include exactly one of the following sentences:

• “The group approves the video for inclusion on the course youtube channel.”

Appendix B: Commented program listings

• GitHub Repository: Link
• The code is stored in the top level. Final_Project.c is the main file.
• ScopeBoy contains the PCB KiCAD project
• ScopeBoyBreadboard contains the breadboard KiCAD project with the schematic
• website contains the website code

Appendix C: Schematics

Appendix D: Team member task breakdown

• Robbie: Rotary encoder driver, PCB design, analog circuit redesign and breadboarding, analog circuit code
• Robbie Leslie:
  • Software & Firmware:
    • Developed the interupt driven rotary encoder driver.
    • Developed the ADC code using the DMA channels, and trigger logic.
  • Hardware & Mechanical:
    • Modified the PCB we found to accomodate screen, rotary encoder, I2C joystick, battery circuit, and debug connectors. Modified component selection on PCB.
    • Procured all components used in the project.
    • Redesigned analog front end after loosing PCB.
    • Assembled and debugged the analog front end on the breadboard.
• Immanuel Varghese Koshy:
  • Software & Firmware:
    • Developed the complete User Interface (UI) system, including the oscilloscope grid, menu navigation, and real-time waveform rendering.
    • Implemented the Spectrum Analyzer (FFT) mode, including windowing functions and frequency bin visualization.
    • Wrote the I2C drivers for the Adafruit Seesaw Gamepad to handle joystick and button inputs.
    • Engineered the "Smart Redraw" graphics engine to eliminate screen flicker and optimize SPI bus usage.
    • Created the "Snake" game Easter egg, demonstrating isolated game loop logic within the scope architecture.
  • Hardware & Mechanical:
    • Designed the mechanical housing, creating custom STL models for the 3D-printed enclosure to fit the Pico, display, and controls.