Float to Hex and Hex to Float: IEEE 754 and Modbus Byte Order

One application reads 3F 80 00 00 as 1065353216; another reads it as 1. Both results follow from the same four bytes. The first application treats them as a UINT32 integer, while the second interprets them as an IEEE 754 FLOAT32 value.

Changing an integer's number base preserves its value: decimal 255 is hexadecimal FF. Converting a float to hex exposes its stored bit pattern, which is why the float 1 becomes 3F800000. Signedness matters too: FFFF is 65535 as UINT16 and -1 as INT16. Before converting a device reading, find its data type in the manual. Knowing that the input is hexadecimal does not tell you how to interpret it.

Compare the conversions

Each link below opens the data converter with the input format, value, type and byte order already selected. Replace the sample input to try your own data.

UINT16 occupies two bytes, so decimal 255 appears as 00 FF: the leading zero preserves the width. A 16-bit value has AB and BA byte-order options. The four-byte arrangements ABCD, DCBA, BADC and CDAB apply to 32-bit values.

To decode 3F 80 00 00, select Hexadecimal, FLOAT32 and ABCD. The DEC result is 1. FLOAT32 takes four bytes; if the manual specifies a FLOAT64 double, you need all eight bytes. Both formats divide the bits into sign, exponent and fraction fields. Oracle's IEEE arithmetic reference describes those layouts.

Enter only the bytes belonging to the value. For a complete Modbus RTU response, use the frame parser to locate the data first. The device address, function code, byte count and CRC are separate fields.

Where the extra digits in 3.14 come from

The 3.14 to hex example produces these four bytes:

40 48 F5 C3

Read them back as FLOAT32 and the displayed value is 3.140000104904175. There is no exact, finite binary representation of 3.14, so storing it as FLOAT32 rounds it to a nearby representable value. Showing more decimal places reveals that difference; rounding the display to two decimal places gives 3.14 again.

FLOAT64 has more precision and reduces this rounding error, but it still cannot represent every decimal fraction exactly. Keep FLOAT32 when that is what the device expects. Switching to FLOAT64 changes the length from four bytes to eight, and switching to an integer changes the encoding. Display precision can be adjusted independently of the device's data format.

Reading a float from two Modbus registers

A Modbus register holds 16 bits, so FLOAT32 occupies two registers. Modbus sends the high byte of each register first. Which register holds the float's upper 16 bits is a separate question for the device manual. The Modbus Application Protocol covers data encoding in section 4.2 and the Read Holding Registers response in section 6.3.

Suppose the manual specifies the high word first, and you read 0x3F80, followed by 0x0000. Entering 3F 80 00 00 as FLOAT32 in ABCD order gives 1. A device that returns the low word first would send 0x0000, then 0x3F80. Keep that received order, enter 00 00 3F 80, and select CDAB to obtain 1.

A, B, C and D label the bytes of a 32-bit value from most to least significant; they are not register addresses. ABCD keeps that order. CDAB swaps the two 16-bit words, BADC swaps the bytes within each word, and DCBA reverses all four bytes. Let the converter do the rearranging: manually swapping the input and selecting a swap option would undo the first swap.

BADC can be useful when a logger or gateway has already rearranged the data. Its presence in the converter does not imply that standard Modbus transmits the low byte of a register first. Establish whether the hex came from a raw frame or from a software-generated register view.

A plausible value can still come from the wrong address

Reading from the wrong starting register can combine adjacent words into a float that happens to fall within the expected range. Trying every byte order until a result looks reasonable is therefore insufficient. Confirm the starting address, type and register count in the register map, apply the documented word order, then compare the result with the device display or a known measurement. The Modbus RTU reading walkthrough shows how to check the request and response.

For a huge value or one close to zero, check for missing bytes, an incorrect address, or a type or byte-order mismatch. If the result is off by a factor of 10 or 100, look for scaling, units or an offset in the manual; the converter cannot infer these from the bytes. Invalid or overly long input calls for a check of the source data: frame headers, checksums and non-hex characters may have been included with the value.