To convert the 8-bit binary number 10110101 into decimal, the exact answer is 181 (assuming standard unsigned integer format). The formula used is the sum of each bit multiplied by 2 raised to the power of its position index, starting from 0 on the far right. Substituting the values for 10110101:
(1 × 2⁷) + (0 × 2⁶) + (1 × 2⁵) + (1 × 2⁴) + (0 × 2³) + (1 × 2²) + (0 × 2¹) + (1 × 2⁰)
= 128 + 0 + 32 + 16 + 0 + 4 + 0 + 1 = 181.

While the raw math is universal, applying this conversion in embedded electronics—like reading an Arduino analogRead() or an ESP32 SAR ADC register—requires strict attention to bit-width, signedness, and physical scaling. Below is the complete decision framework for moving from raw binary logic to actionable decimal engineering values.

The Core Formula and Neighboring Values

When debugging a digital bus or tuning an ADC threshold, you rarely need just one number; you need to recognize the neighborhood. The table below shows the exact binary, hex, and decimal equivalents for our target value (181) alongside a ±20% range. This is critical when setting hysteresis bands on a comparator or defining dead-zones in a PID control loop.

Decimal (±20% Range) 8-Bit Binary Hexadecimal Typical Embedded Use Case
145 (-20%) 10010001 0x91 Lower hysteresis threshold / minimum PWM duty
163 (-10%) 10100011 0xA3 Low-battery warning trigger
181 (Target) 10110101 0xB5 Target ADC setpoint / nominal sensor read
199 (+10%) 11000111 0xC7 High-temperature fan kick-in speed
217 (+20%) 11011001 0xD9 Upper fault limit / over-current trip

What Assumptions Fix Your Answer (And When Conversion is Meaningless)

The decimal value 181 is only correct if you assume an unsigned, 8-bit, Big-Endian integer. Change any of those assumptions, and the physical reality of your circuit changes.

  • Signedness (Two's Complement): If 10110101 is read as a signed 8-bit integer (like a temperature sensor output), the leading '1' indicates a negative number. Using two's complement inversion, the decimal answer shifts to -75.
  • Bit-Width & Endianness: If that byte is the lower half of a 16-bit I2C register, the final decimal depends on byte order. In Little-Endian, if the upper byte is 0x01, the combined binary is 00000001 10110101, yielding 437.
When the conversion is meaningless: Do not blindly convert binary to decimal if you do not know the data encoding. If those 8 bits represent the exponent byte of an IEEE 754 32-bit floating-point number, converting them to 181 tells you nothing about the actual physical value. Furthermore, if the data is Binary-Coded Decimal (BCD), 10110101 is an invalid state (since the nibble 1011 equals 11, exceeding the 0-9 BCD limit). Always check the microcontroller datasheet for the exact register format before doing the math.

Scaling Decimal to Physical Mains Voltage (120V vs 230V vs 3-Phase)

Pure binary math is voltage-agnostic, but in power electronics, the decimal scaling factor shifts drastically depending on the AC grid you are monitoring via an ADC (e.g., using a ZMPT101B voltage transformer module).

Assume a 12-bit ADC (decimal range 0–4095) centered at a 2048 DC offset:

  • 120V RMS Systems (North America): The peak voltage is ~170V. Your voltage divider is tuned so the ±170V AC swing maps to a decimal delta of roughly ±1500 from the center. A peak decimal read of 3548 equates to 120V RMS.
  • 230V RMS Systems (EU/UK/AU): The peak voltage is ~325V. If you use the exact same hardware divider, the decimal value shifts to ~3900, dangerously close to the 4095 clipping limit. You must increase the divider resistance to bring the 230V peak back down to a safe decimal ceiling of ~3800.
  • 3-Phase Systems: You are no longer reading a single decimal value. You are reading three independent ADC channels. The decimal-to-voltage conversion must account for the 120-degree phase shift, and calculating line-to-line voltage requires multiplying the phase-to-neutral decimal equivalent by √3 (1.732).

Decision Tree: Picking the Right Data Type and Scaling Factor

Use this decision path to terminate your binary-to-decimal pipeline with the correct C/C++ data type and scaling logic. Never use a generic int for hardware registers.

If your binary source is... And the physical parameter is... Then cast to this C++ Type Apply this Scaling Logic
8-bit I2C/SPI GPIO Expander On/Off States, DIP switches uint8_t Bitwise AND (&) for masks
12-bit SAR ADC (ESP32/STM32) DC Voltage, Current (0-3.3V) uint16_t val * (3.3 / 4095.0)
16-bit Temperature Sensor (DS18B20) Sub-zero Temperatures int16_t Two's complement / 16.0
32-bit Energy Monitor IC Accumulated kWh / Power uint32_t Multiply by datasheet LSB weight

The Default Pick: For 90% of hobbyist and prosumer microcontroller sensor reads (ADC, encoders, light sensors), cast your raw binary buffer to uint16_t to prevent 8-bit overflow, and apply a floating-point scaling factor only at the final display/MQTT transmission step to preserve integer math speed in your control loops.

FAQ: Common Binary-to-Decimal Debugging Traps

Why does my logic analyzer show 181, but my Serial Monitor prints 4294967221?

You are experiencing a signed-to-unsigned casting error in C++. If your code stores the signed 8-bit value (-75) into a 32-bit unsigned integer (uint32_t) without proper casting, the compiler sign-extends the leading 1s across all 32 bits, resulting in 4294967221. Always cast to the exact bit-width of the source register first.

Do I need to convert binary to decimal to set an Arduino PWM duty cycle?

No. The analogWrite() function accepts decimal integers (0-255), but you can pass binary directly using the 0b prefix. analogWrite(pin, 0b10110101); is perfectly valid, compiles to the exact same machine code, and often makes bit-masking visual debugging much easier on the bench.

How do I handle binary fractions (e.g., 0.1011) in decimal?

Microcontrollers do not natively process binary fractions in hardware registers; they use fixed-point or floating-point integers. If you encounter a binary fraction in a DSP algorithm, the math shifts to negative exponents: (1 × 2⁻¹) + (0 × 2⁻²) + (1 × 2⁻³) + (1 × 2⁻⁴) = 0.5 + 0 + 0.125 + 0.0625 = 0.6875. In practice, multiply the fractional binary by 2¹⁶ and store it as a standard uint16_t to avoid floating-point CPU overhead.