CRC-16 / CRC-32 Checksum Generator (Modbus)

If you're wiring up a Modbus RTU system—maybe connecting a PLC to an actuator, building a sensor chain, or sending commands to a drive—every message you send needs a correct CRC checksum. If the CRC isn’t right, the device on the other end simply ignores the message. This CRC-16 / CRC-32 Checksum Generator lets you manually check or generate CRC values for your hex data bytes, using the algorithm and CRC type that matches your application. Reliable CRCs aren’t just a formality in industrial automation and embedded systems—they’re the backbone of reliable serial communication. On this page you’ll find the actual calculation routines, an explicit worked example, and technical notes for engineers.

What is a CRC Checksum?

A CRC (Cyclic Redundancy Check) is a short value at the end of your data packet. The sender computes the CRC from all the other bytes in the message and appends it when transmitting. The receiver then recalculates the CRC from the incoming data. If it doesn’t match the transmitted CRC, the whole message is rejected.

Simple Explanation

Think of a CRC as a basic way to double-check if your data survived the trip. It’s like adding up the numbers on a receipt: if the total doesn’t add up, something’s wrong. A CRC scrambles your data with XORs, shifts, and a fixed polynomial to create a simple fingerprint. Even the smallest change anywhere in the data—just one flipped bit—will almost always cause the CRC to change.

📐 Browse all 384 free engineering calculators

📹 Video Walkthrough — How to Use This Calculator

How to Use This Calculator

1. Type your hex data bytes, separated by spaces, into the Data Bytes field. Don’t include the CRC itself (for example: 01 03 00 00 00 0A).
2. Pick CRC Type—stick with CRC-16 Modbus for standard protocol messages, or try CRC-32 for less common cases.
3. Double-check the hex string to be sure it’s just the data, no CRC at the end.
4. Click Calculate to get the CRC value and a complete frame ready to transmit.

Simple Example

If you want to read 10 holding registers from address 0x0000 on Modbus slave address 0x01, you would use:

• Input bytes: 01 03 00 00 00 0A
• CRC Type: CRC-16 Modbus
• CRC Result: C5 CD
• Full frame to transmit: 01 03 00 00 00 0A CD C5 (low byte first)

Mathematical Formulas

CRC-16 Modbus Algorithm

The CRC-16 Modbus calculation uses polynomial division with the following parameters:

Use the formula below to calculate the CRC-16 Modbus checksum.

CRC-32 Algorithm

Use the formula below to calculate the CRC-32 checksum.

Complete Technical Guide to CRC Checksums in Modbus

CRC is a basic tool for error checking in data links, especially for Modbus RTU and similar protocols. This calculator just gives you a way to check or generate CRCs to help make sure your frames will be accepted when transferring data between real controllers, sensors, or actuators.

Understanding CRC Error Detection

At its core, a CRC computes a remainder from dividing your data, treated as a big binary stream, by a set polynomial; the remainder becomes your checksum. Repeat this process at the other end. If you get a zero remainder after slapping the CRC on, your frame was received intact.

The nitty-gritty is a lot of XOR with shifting and polynomial masking, in what’s called GF(2) arithmetic. Your choice of generator polynomial determines the CRC’s ability to catch certain errors. Modbus RTU uses x¹⁶ + x¹⁵ + x² + 1 or 0x8005 in normal form (0xA001 in reflected form).

Modbus RTU Frame Structure

A Modbus RTU message is made of:

• Slave Address (1 byte): Which device you’re talking to
• Function Code (1 byte): What operation to perform
• Data (variable): Any data for the command or reply
• CRC Checksum (2 bytes): For error checking (sent as low byte, then high byte)

The CRC is computed on everything from the slave address up to the last data byte—not counting the CRC itself. This ensures the whole frame is protected in one go.

Practical Implementation Example

Say you want to poll 10 holding registers at address 0x0000 from slave 0x01 with a standard Modbus read:

Industrial Applications

CRCs are vital on noisy, long, or industrial networks where you can’t afford undetected errors. For example, Modbus-controlled linear actuators use CRCs to ensure that commands and feedback aren’t corrupted, especially when position or limit switch data matters.

Common cases include:

• Position Control: Validating actuator position or command frames
• Sensor Feedback: Making sure sensor readings (temperature, pressure, etc.) are valid
• Motor Drives: Checking integrity of speed/torque commands
• PLC to PLC Links: Keeping distributed logic from drifting due to missed bytes

CRC-16 vs CRC-32 Selection

Which CRC to use comes down to protocol rules and data size:

CRC-16 Modbus (For Modbus RTU, use this):

• It’s the requirement in the Modbus RTU standard
• Good enough for the size of typical Modbus packets
• Only two extra bytes tacked on
• Detects all single- and double-bit errors; pretty robust for smaller packets
• Keeps processing time low, fits well with PLC scan times

CRC-32 (For unusually large or custom packets):

• More overhead, but better error detection—useful for data transfers (not Modbus RTU)
• Gives some insurance on big packets (over about 1 kB)
• Standard in files and protocols like Ethernet, not usually required for Modbus
• More CPU time and code size

Implementation Best Practices

1. Byte Order:
Modbus RTU always puts the CRC as “low byte first.” Watch for this—many calculation libraries output the bytes in the other order by default.

2. Timing:
Modbus runs on fixed serial timing. Don’t let slow CRC calculations delay your transmission, especially if you have more than one slave device in the loop.

3. Dealing with Errors:
If you get a CRC mismatch, the usual routine is to ignore the packet, log an error, or resend. Build this into your application: don’t just retry endlessly.

4. Testing:
Use common test vectors to check your CRC code. For example, "123456789" as input must give CRC-16 Modbus 0x4B37 or CRC-32 0xCBF43926. If it doesn’t, your implementation has a bug.

Hardware vs Software Implementation

Lots of micros now provide a hardware CRC block. If speed matters (for fast or large transfers), use it. Hardware CRC runs much faster than most software routines and has less timing jitter.

• Hardware: Great for rapid, repeated checks
• Software: Lets you change the CRC type, good for testing or old architectures
• Watch your micro’s documentation—some hardware CRCs only support one polynomial

For custom protocols or legacy devices, sometimes software CRC is your only option. In those cases, squeeze as much speed out as possible if you’re running near real time.

Troubleshooting Communication Issues

If you see CRC errors cropping up, the cause could range from cabling to code bugs. Some things to check:

• Noise/Interference: Make sure cabling is shielded and grounded
• Serial Timing: Check baud, parity, and stop bits; tight Modbus timing often causes breakage
• Software: Confirm your CRC parameters (polynomial, initial value, endianness)
• Physical: Look for loose connectors, dodgy termination resistors, or corroded pins

This CRC Modbus calculator is one way to double-check that your calculated CRCs match what your devices expect, helping sort out problems during setup, troubleshooting and integration.

📐 Explore our full library of 384 free engineering calculators →