Embedded Files
We live in a world of high-level abstractions. In networking, we look at Wireshark captures, IP headers, and payload structures. In software, we look at clean lines of code and serial monitors confirming data delivery.
But what does a digital packet actually look like when it travels across a physical wire?
Just for fun down in the lab, I wanted to pull back the curtain on Layer 1. Instead of trusting that the bits are moving across the copper, I hooked up a pair of Arduino Nanos and an oscilloscope to physically trap, measure, and decode a serial transmission in real-time.
The Lab Architecture & Hardware Setup
The Lab Architecture & Hardware Setup
To pull this off cleanly without losing our ability to troubleshoot, the bench setup requires a few deliberate choices:
The Dual-Arduino Setup: We are using two Arduino Nanos.
Power & Monitoring Strategy:
The Receiver Nano is plugged directly via USB into the workstation, letting me view the real-time serial monitor on screen to confirm data integrity.
The Transmitter Nano is powered independently using a secondary bench power supply delivering a clean 5V signal.
The Golden Rule of Bench Electronics: A shared common ground (GND). Without tying the ground rails of both Arduinos and the oscilloscope together, your reference voltage floats into chaos.
SoftwareSerial: We use SoftwareSerial on pins 2 and 3 for our transmission line. Why? Because keeping the native hardware TX/RX pins (0 and 1) free allows us to keep debugging output active on our computer screen without interference.
The Code: Keeping It Simple
The Code: Keeping It Simple
For initial testing, we don't need heavy protocols or complex logic. We just want a reliable stream of data.
1. The Transmitter Code
This sketch initiates a software serial channel at 9600 baud and continuously transmits the ASCII character 'A'.
2. The Receiver Code
The listening Arduino catches the incoming byte, assigns it to a variable, and echoes it back out to the serial monitor so we can verify software-side reception alongside our hardware scope.
Software Verification: The receiving Arduino Nano captures the incoming byte via SoftwareSerial and echoes it back to the computer's serial monitor. Seeing Received:A a stream continuously confirms that our physical transmission and baud rate synchronization are working perfectly at the application layer, matching what we see on the oscilloscope.
A top-down view of the dual Arduino Nano bench setup. The transmission line crosses over from the sender's TX (top Arduino) to the receiver's RX (bottom Arduino), while a shared common ground ties everything together. The oscilloscope's probe channel connects to monitor the active TTL serial line (red line going into D3 on Top Arduino, with the ground reference securely clipped to the shared ground rail (Blue line) alongside the secondary 5V bench power supply.
Capturing the Ghost: The Oscilloscope View
Capturing the Ghost: The Oscilloscope View
With the probe clipped directly onto the transmitter's TX pin and the ground clip secured to the breadboard ground rail, we fired up the FNIRSI 1014D oscilloscope.
Setting a falling-edge trigger and dialing the time base to 200 µs/div transformed a fleeting, millisecond data flash into a crystal-clear, frozen square wave on the screen.
Decoding the Physical Layer
If you look closely at the capture, those "two pillars" aren't random—they are the exact binary blueprint of ASCII 'A' (decimal 65, or 01000001 in binary) transmitted Least Significant Bit (LSB) first:
The Start Bit: The sharp drop from 5V down to 0V that triggers our scope and signals the receiver that a byte is incoming.
The Data Bits (The Pillars): The high 5V pulses separated by low valleys representing our 1s and 0s.
The Stop Bit: The return to a steady 5V state, concluding the transmission.
The Anatomy of ASCII 'A' on the Scope
The Anatomy of ASCII 'A' on the Scope
To understand what those "two pillars" represent on the screen, let's look at the math behind the transmission:
The Character: ASCII 'A' has a decimal value of 65.
The Binary Byte: In 8-bit binary, 65 is represented as 01000001.
The Transmission Order: UART standard transmits data Least Significant Bit (LSB) first, meaning the bits fly across the wire starting from the far right of our binary sequence and moving left: 1, 0, 0, 0, 0, 0, 1, 0.
When mapped out against the 5V / 0V square wave on this oscilloscope from left to right:
The Start Bit (Logic 0 / 5V drop to 0V): The line rests HIGH at 5V. When transmission begins, it drops sharply to 0V. This falling edge is what triggers your oscilloscope and alerts the receiving Arduino that a byte is incoming.
Data Bit 0 (LSB = 1): The first bit is a 1, causing the line to shoot HIGH (5V). This creates the first pillar.
Data Bits 1 through 6 (0, 0, 0, 0, 0, 0): The next six bits are all zeros, keeping the line pulled LOW (0V) for a sustained duration, creating that long flat valley across the grid.
Data Bit 7 (MSB = 1): The final data bit is a 1, causing the line to jump HIGH (5V) one more time. This is your second pillar.
The Stop Bit (Logic 1 / Return to 5V): Finally, the line returns to a steady HIGH state, signaling the end of the frame and resetting the bus for the next transmission.
Seeing that exact sequence materialize as two distinct physical pillars separated by a valley on a 200 µs/div time base is proof that abstract math is literally just electricity moving through copper!
The Takeaway
The Takeaway
As IT professionals and network builders, we spend a lot of time in upper-layer tools—tracing routes, analyzing PCAPs in Wireshark, or configuring Cisco gear. But understanding how those abstract packets translate down into raw voltage transitions on copper wire bridges the gap between software and the physical world.
When you can troubleshoot a link from the configuration file all the way down to the physical waveform on an oscilloscope, you truly understand the full stack.
Page updated
Google Sites
Report abuse