How to Translate Hexadecimal to ASCII for ESP32 and Arduino Serial Debugging

The One-Sentence Definition and Why It Matters

Translating hexadecimal to ASCII is the process of mapping base-16 byte values to their corresponding human-readable text characters using the standard 7-bit lookup table. When you are staring at a serial monitor or a logic analyzer dump, this translation is the bridge between the raw binary data your microcontroller processes and the readable text you need to debug it.

What it changes in a real circuit: In a physical installation, this translation dictates whether your microcontroller's UART TX pin shifts out raw binary command bytes or literal text strings. This is the exact difference between a slave device executing a register read and throwing a CRC checksum error. The electrical pulses on the wire are identical in format (8N1 UART), but the payload interpretation changes entirely.

What people commonly confuse it with: The most frequent bench mistake is confusing the hex value 0x41 (which the ASCII table defines as the character 'A') with the literal ASCII string "41" (which is actually transmitted as the two hex bytes 0x34 0x31). If a datasheet tells you to send the hex command 0x41, and you write Serial.print("41"); in your Arduino IDE, you are sending the wrong data.

The Math: A Worked Numeric Example

Let us trace a 5-byte hexadecimal sequence and translate it into its ASCII string equivalent. This is exactly what happens when your ESP32 receives a text payload over MQTT or UART and you need to read it.

Input Hex Sequence: 4D 41 58 34 38

Output String: MAX48 (as in the MAX485 RS-485 transceiver chip). Notice how the numeric digits '4' and '8' are not hex 0x04 and 0x08; they are offset by 0x30 in the standard ASCII table. This 0x30 offset is the root cause of 90% of serial parsing bugs in hobbyist embedded projects.

Where You Meet This in Practice

You will run into hex-to-ASCII translation boundaries constantly in embedded systems and industrial wiring. Here are the three most common environments:

• Modbus RTU over RS-485: Industrial sensors and charge controllers expect raw hex bytes. If you accidentally send ASCII strings, the slave device will reject the frame due to a CRC mismatch.
• GPS NMEA Sentences: A u-blox NEO-6M GPS module outputs ASCII text strings (like $GPGGA,...). If you try to parse these by reading raw hex values without converting them to char arrays, your coordinate math will fail.
• MQTT and HTTP Payloads: When an ESP32 publishes sensor data to a broker, the network stack expects ASCII-encoded UTF-8 strings. Sending raw hex bytes without encoding them first will result in garbled text or dropped packets on the receiving dashboard.

Bench War Story: When Hex and ASCII Collide on RS-485

To understand why this matters, let us look at a real-world debugging scenario that cost me three hours on the bench last month.

The Numbers: According to the Modbus RTU specification, the exact hex command to read holding register 0x0101 from slave ID 01 is:

01 03 01 01 00 01 D5 CA (where D5 CA is the 16-bit CRC checksum).

The Outcome: The Renogy Rover remained completely silent. The ESP32 timed out waiting for a response. I swapped the MAX485 chip, checked the biasing resistors, and verified the A/B differential pair with a multimeter. Nothing.

What Went Wrong: I hooked up a logic analyzer to the RO (Receiver Output) pin. The analyzer showed the ESP32 was transmitting 16 bytes, not 8. My C++ code looked like this:

Serial2.print("010301010001D5CA");

By using Serial.print() with a string literal, the ESP32 translated my human-readable text into ASCII hex bytes. It sent 0x30 0x31 0x30 0x33... instead of 0x01 0x03.... The Rover saw an invalid slave ID (0x30 is ASCII '0', which is decimal 48) and ignored the frame. The moment I switched to a raw byte array using Serial.write(), the controller responded instantly.

How to Correctly Send Hex Bytes in C++

When you need to send raw hexadecimal commands to a device, you must bypass the ASCII translation layer of the standard print functions. Follow these steps to ensure your UART or RS-485 bus sends the exact binary values required.

1. Define your payload as a byte array: Use the 0x prefix to explicitly declare hexadecimal literals in C++.

   uint8_t modbusCmd[] = {0x01, 0x03, 0x01, 0x01, 0x00, 0x01, 0xD5, 0xCA};

2. Use the write() function: According to the Arduino Serial API reference, Serial.write() sends binary data, while Serial.print() sends ASCII characters.

   Serial2.write(modbusCmd, sizeof(modbusCmd));

3. Flush the buffer: RS-485 transceivers like the MAX485 require you to toggle the DE/RE pins. You must wait for the UART hardware shift register to empty before switching the transceiver back to receive mode.

   Serial2.flush(); // Waits for TX buffer to empty
   digitalWrite(DE_PIN, LOW); // Switch MAX485 to RX mode

Frequently Asked Questions

Why does my serial monitor show weird symbols when I send hex data?

If you send raw hex bytes (like 0x01 or 0x80) and view them in the Arduino IDE Serial Monitor set to 'ASCII' mode, the monitor attempts to map those values to text. Values below 0x20 are non-printable control characters (like Start of Heading or Null), and values above 0x7F fall into the extended ASCII range, resulting in accented letters or block symbols. To view raw hex, you must use a terminal program like PuTTY or Tera Term and set the display mode to 'Hex'.

How do I convert an ASCII string back to a hex byte array in C++?

If you receive a text string like "FF0A" over WiFi and need to convert it to the bytes 0xFF and 0x0A, you must parse the string two characters at a time. You can use the strtol() function in C++, passing the two-character substring and specifying base 16. Do not attempt to cast the characters directly, or you will just get the ASCII hex values (0x46 0x46) instead of the intended payload.

Does endianness matter when translating hex to ASCII?

Endianness (byte order) does not affect the translation of individual bytes to ASCII characters. 0x41 is always 'A' regardless of whether your MCU is little-endian (like the ESP32) or big-endian. However, endianness does matter when you are grouping two ASCII characters together to form a 16-bit integer register value in protocols like Modbus.