The binary for 'b' is the 8-bit sequence 01100010 (decimal 98, hex 0x62) that microcontrollers and digital systems use to represent the lowercase letter 'b' in standard ASCII encoding. When you type 'b' in a serial monitor or send it from an ESP32 to a motor controller, the processor doesn't see a letter; it sees this exact string of ones and zeros, which it then translates into physical voltage pulses on a wire.
Understanding this translation is the difference between a working prototype and hours of staring at a logic analyzer trying to figure out why your device is ignoring your commands. In this guide, we will break down the physical reality of this character, how it behaves on a UART line, and the specific traps that catch hobbyists and engineers alike.
The Exact Binary for 'b' (And Why Case Matters)
In digital logic, characters are just numbers mapped to a standard. For standard 7-bit ASCII (which fits inside an 8-bit byte), the mapping is strict. Here is how the letter 'b' compares to its uppercase counterpart and its literal hex value.
| Character / Value | Binary (8-bit) | Hexadecimal | Decimal | Meaning in ASCII |
|---|---|---|---|---|
| 'b' (lowercase) | 01100010 |
0x62 |
98 | Lowercase letter b |
| 'B' (uppercase) | 01000010 |
0x42 |
66 | Uppercase letter B |
| 0x0B (literal hex) | 00001011 |
0x0B |
11 | Vertical Tab (Control Char) |
Serial.write(0x0B); when the developer intends to send the letter 'b'. The hex value 0x0B does not mean 'the letter b'; it is the literal decimal number 11, which ASCII defines as a 'Vertical Tab' control character. If your receiving device expects the letter 'b', it will reject 0x0B as an invalid command.
What This Changes on the Physical Wire
What does this binary sequence actually change in a real circuit? It dictates the exact high/low voltage pulse sequence (e.g., 3.3V and 0V) and timing that a microcontroller's UART TX pin must output to transmit that character over a serial line.
Let's look at a worked numeric example of transmitting the binary for 'b' (01100010) over a standard UART connection at 9600 baud.
- Bit Timing: At 9600 baud, each bit takes exactly 104.16 µs (1 / 9600 seconds).
- Start Bit: The line idles HIGH (3.3V). To start the frame, the TX pin pulls LOW (0V) for 104.16 µs.
- Data Bits (LSB First): UART transmits the Least Significant Bit first. The binary
01100010is sent right-to-left:0, then1,0,0,0,1,1,0. Each pulse lasts 104.16 µs. - Stop Bit: The line returns HIGH (3.3V) for at least 104.16 µs to signal the end of the frame.
The entire 10-bit frame (1 start + 8 data + 1 stop) takes exactly 1.0416 milliseconds. If your receiving device is set to 115200 baud instead of 9600, it will sample the line every 8.68 µs, completely misinterpreting the pulse widths and resulting in a framing error.
Where You Meet This in Practice
You will encounter the binary representation of text characters in several common embedded scenarios:
- G-Code Parsing (3D Printers & CNC): Marlin firmware parses ASCII characters to move stepper motors. Sending a lowercase 'b' might trigger a specific bed-leveling or backward movement routine, while an uppercase 'B' is ignored or throws a syntax error.
- Serial Motor Controllers: Devices like the Sabertooth or RoboClaw often use simple serial packetization where a specific character (like 'b' for backward or 'f' for forward) acts as the command byte.
- USB-to-Serial Debugging: When using a CP2102 or CH340 breakout board to view ESP32 logs, the raw binary
01100010is shifted out of the USB chip's TX pin and into your PC's RX pin, where the terminal software maps it back to the glyph 'b' on your screen.
For deeper configuration of hardware serial ports on Espressif chips, refer to the official ESP-IDF UART API documentation, which details how FIFO buffers handle these exact byte sequences.
Real-World Scenario Walkthrough: The 'Backward' Command That Failed
To see how a misunderstanding of binary character encoding causes physical failures, let's walk through a real bench scenario.
The Setup: An engineer is using an ESP32-WROOM-32 to control a generic serial-based motor driver. The driver's manual states: 'Send the character b at 115200 baud to engage reverse throttle.' The ESP32 TX pin is wired to the driver's RX pin, sharing a common ground.
The Numbers: The ESP32 is configured for 115200 baud, 8 data bits, no parity, 1 stop bit (8N1). Logic levels are 3.3V.
The Outcome: The engineer uploads the code. The motor does not move. The motor driver's status LED flashes red, indicating a 'Packet Checksum / Framing Error'.
What Went Wrong: The engineer wrote the Arduino code as follows:
Serial2.write(0x0B); // Intended to send 'b'As established in our table, 0x0B is the Vertical Tab control character (binary 00001011), not the letter 'b' (binary 01100010). The motor driver received an unexpected command byte, which corrupted the expected packet structure. The driver's internal parser rejected the byte, flushed its UART buffer, and threw a framing error.
The Fix: The code was changed to explicitly send the ASCII character:
Serial2.write('b'); // Sends 0x62 (01100010)Alternatively, sending the correct hex value Serial2.write(0x62); would also work. Once corrected, the physical wire saw the correct 3.3V pulse train for 01100010, the driver parsed the command, and the motor spun in reverse.
Debugging Binary Character Errors (FAQ)
Why does my logic analyzer show the bits for 'b' backward?
If you capture the UART transmission of 'b' (01100010) on a logic analyzer, the data bits will appear on screen as 0, 1, 0, 0, 0, 1, 1, 0. This is not backward; it is LSB-first (Least Significant Bit first) transmission, which is the universal standard for UART. The analyzer is reading the wire chronologically, while you are likely reading the binary number mathematically (MSB first).
Is the binary for 'b' different in UTF-8?
No. For all standard English alphabet characters (the first 127 characters of the ASCII table), UTF-8 uses the exact same single-byte binary encoding as ASCII. The binary for 'b' remains 01100010 whether your ESP32 is sending raw ASCII or a UTF-8 encoded string.
How do I verify the exact byte my Arduino is sending?
Use the Arduino Serial reference to switch between Serial.print() and Serial.write(). Serial.print('b') sends the ASCII character (1 byte). Serial.print(98) sends the literal characters '9' and '8' (2 bytes: 0x39 and 0x38). Always use Serial.write() when you need to send raw binary bytes to a peripheral.
What if my circuit uses 5V logic instead of 3.3V?
The binary sequence (01100010) remains identical. The only physical change is the voltage threshold. A logic HIGH will be 5V instead of 3.3V. However, if you connect a 5V TX line directly to a 3.3V ESP32 RX pin without a level shifter or voltage divider, you risk destroying the ESP32's GPIO pin, regardless of how perfectly formatted your binary data is.
Mastering the physical layer of text encoding bridges the gap between writing code and building reliable hardware. The next time a serial device ignores your commands, hook up a logic analyzer, check your LSB pulse trains, and verify that your hex values actually map to the ASCII characters you think they do.
