Big-endian mode of Modbus protocol (Big-endian)

Question-solving class: Why is your sensor data “inaccurate”? A brief discussion on the big and small endian modes in Modbus

In daily technical support, we often encounter customer feedback: "Your sensor data jumps hugely, which is completely wrong!" After investigation, the problem is often not the sensor itself, but a key communication concept - byte order (Endianness), which is what we often call big-endian mode and little-endian mode. Today, we will explain this issue thoroughly.

In daily technical support, we often encounter customer feedback: "Your sensor data jumps hugely, which is completely wrong!" After investigation, the problem is often not the sensor itself, but a key communication concept - byte order (Endianness), which is what we often call big-endian mode and little-endian mode. Today, we will explain this issue thoroughly.

1. Understand “byte order” from writing habits

Imagine that we want to write the number "one thousand two hundred and thirty-four". We naturally write it as "1234", that is, the thousands digit "1" (the highest digit) is at the front, and the units digit "4" (the lowest digit) is at the end. This is a "big-endian" order that fits our intuition.

But if there were a culture that insisted on writing numbers starting with the ones, then the number would be written as "4321." This is a "little-endian" order.

When the computer stores or transmits a multi-byte data (such as 32-bit floating point number, 16-bit integer), it also faces the same "writing order" problem: Should the high-order byte be put first or the low-order byte first? This results in two modes:

• Big-endian mode: high-order byte first (such as "1234" is written). The high bits of data are stored at low addresses, and the low bits are stored at high addresses.
• Little-endian mode: low-order byte first (such as "4321" is written). The low bits of data are stored at low addresses, and the high bits are stored at high addresses.

Please note: The Modbus communication protocols of the main water quality online monitoring sensors produced by our company strictly adopt [Big Endian mode] for data transmission.

2. Practical analysis: a "Rashomon" of turbidity data

Let us use a real data interaction case to see how the big and small endian modes affect the final result.

Scenario: Your host software sends a command to our turbidity sensor, requesting a reading of the current turbidity value.

1. Query command (host → sensor) 03 03 02 43 00 02 35 85

• 02 43: Tells the sensor which "room" to start reading from (register address 0x0243).
• 00 02: Inform that the data of 2 "rooms" need to be read (because a floating point number occupies 4 bytes, that is, 2 16-bit registers).

2. Response data (sensor → host) 03 03 04 3E B3 26 1F 7E 54

• 04: Indicates that I returned 4 bytes of valid data.
• 3E B3 26 1F: These 4 bytes are the core data representing the turbidity value!

Point of disagreement: How does your software interpret the string of numbers 3E B3 26 1F?

• Correct way (big-endian mode/ABCD): Keep the original order and interpret: 3E -> B3 -> 26 -> 1F. Parse it into a 32-bit floating point number and get the result: 0.3499 NTU. This is a very normal turbidity value.
• Keep the original order of interpretation: 3E -> B3 -> 26 -> 1F
• Parsing this into a 32-bit float gives the result: 0.3499 NTU . This is a very normal turbidity value.
• Wrong way (common in software that defaults to little-endian mode): The software automatically interprets the byte order reversal: 1F -> 26 -> B3 -> 3E. Parsing this reversed sequence into a floating point number may result in a value such as 2.84E-21 or a huge outlier.
• The software automatically reverses the byte order and interprets: 1F -> 26 -> B3 -> 3E
• Parsing this reversed sequence into a floating point number may result in something like 2.84E-21 or a very large outlier.

Look, the same raw data, just because of different interpretation rules, gives very different results! This is the culprit that causes you to feel like your data is “off.”

3. How to quickly solve this problem?

When you encounter data anomalies, please do not rush to conclude that it is a sensor failure. There is a high probability that your software "translator" used the wrong "grammar".

Please check as follows:

• Locate the configuration interface: Open your configuration software, SCADA system or data acquisition platform, and find the device driver or Modbus protocol configuration page.
• Look for key settings: In the definition of a data point (or label), look for an option called Byte Order, Word Order, Endianness, or Byte Swap.
• Choose the correct option: Be sure to select Big-Endian (big-endian mode). It may also be labeled ABCD, Motorola, etc. Please avoid selecting Little-Endian (little-endian mode) or DCBA, Intel, etc. options.
• Be sure to select Big-Endian (big-endian mode).
• It may also be labeled ABCD, Motorola, etc.
• Please avoid selecting Little-Endian (little-endian mode) or DCBA, Intel, etc. options.

Tips: If you are not sure how to operate, consult the help documentation of the software you are using, or search for "endian" related keywords directly in the settings, which can usually help you locate it quickly.

Conclusion

Big endian and little endian are just two coexisting rules in the computer world, and there is no right or wrong in themselves. But ensuring that both communicating parties use the same "dictionary" is a prerequisite for accurate communication.

We hope this popular science article can help you understand and solve the confusion of data analysis. As a professional instrument company, we are not only committed to providing high-precision and high-reliability sensor products, but are also willing to share knowledge with you to jointly ensure the smoothness and accuracy of every link in the data link.

If you still have questions about configuration, feel free to contact our technical support team and we'll be happy to help.