No. "BCC" is a term, not a single algorithm. Some devices use XOR, some use additive sums, and some use CRC or LRC. Always check the vendor document.

Why does my device give a different BCC value for the same bytes?

Because the vendor's definition may use a different initial value, a different byte range, a final complement, or a different algorithm entirely. Verify the exact formula, initial value, and included fields.

Should I include the Modbus colon and CRLF in the LRC calculation?

No. The Modbus over Serial Line specification excludes the starting colon and ending CRLF from the bytes covered by the LRC.

Can a BCC detect every transmission error?

No. Single-byte checks detect some accidental changes but have many collisions and offer no authentication. Use a CRC or cryptographic mechanism when integrity matters.

What does "byte-sum modulo 256" tell me?

It is the low eight bits of the ordinary byte sum, shown as a diagnostic intermediate. The Modbus LRC and the raw sum add to zero modulo 256, so displaying both helps confirm which convention the device expects.

BCC Checksum Example: A Step-by-Step XOR-8 Walkthrough

A BCC checksum is a single byte produced by XORing every byte in a defined range of a serial frame together. The acronym stands for Block Check Character, and the formula is so short that it can be written in one line: start with 0x00, then for each data byte set accumulator = accumulator XOR byte, then transmit the final 0x00 to 0xFF value alongside the frame. Because XOR is commutative and carries are irrelevant, the order of the bytes does not change the result, and the algorithm needs no lookup table, no polynomial, and no final complement. That simplicity is exactly why so many embedded devices, RFID readers, and industrial PLCs ship it as their built-in integrity check. The catch is the word "BCC" itself: different vendors use it for additive sums, LRC values, full CRCs, or checksums taken over different parts of the frame, so a "BCC example" only makes sense once the exact formula and byte range are pinned down. This article walks through the canonical XOR-8 form on real hex bytes, contrasts it with the related Modbus ASCII LRC, and shows how to reproduce the same numbers locally.

What "BCC" Means in a Serial Frame

BCC is a label, not an algorithm. In its narrowest, most common sense it refers to a one-byte value appended to a frame so the receiver can spot accidental corruption. The byte is normally placed at the end of the frame, after the payload and before any trailing stop or end marker, and the transmitter appends the BCC of every byte it has just sent. The receiver runs the same operation over the received payload, compares its own BCC to the one transmitted, and raises an error if the two disagree.

The reason "BCC" causes confusion is that the same three letters appear in vendor manuals with different mechanics. Some define BCC as XOR-8 over the data bytes, some define it as the additive sum modulo 256, some define it as a longitudinal redundancy check with a final complement, and some define it as a CRC of a particular width. The Modbus community, for instance, reserves the term LRC for its specific two's-complement sum and uses a different byte from a raw XOR. Confirming which definition a given device uses is therefore the first step before any example will match a real instrument. For a compact reference across these conventions, the BCC Checksum Cheat Sheet collects the formulas side by side.

How XOR-8 BCC Is Calculated

The XOR-8 BCC starts with an accumulator equal to 0x00. Each selected byte of the frame is then combined with the accumulator using the bitwise exclusive OR operation, replacing the accumulator each time. Because the operator is its own inverse and is both commutative and associative, the order of the bytes can be rearranged without affecting the result, and running the same operation twice cancels out.

Three properties of the operation are worth keeping in mind for any worked example. First, the result is always one byte, so it is written as exactly two hex digits from 00 to FF and must be transmitted as such. Second, there is no carry propagation because XOR works bit-by-bit without arithmetic, which is what makes the calculation trivial to write in firmware. Third, the algorithm is symmetric: XORing the BCC back into the accumulator recovers 0x00, which is why receivers can simply fold the transmitted BCC into their running value to recheck the entire frame in a single pass.

BCC Checksum Examples on Real Hex Bytes

The clearest way to understand a BCC example is to trace one by hand. Take the four-byte sequence 0x01, 0x02, 0x03, 0x04. The accumulator starts at 0x00. After the first byte the value is 0x00 XOR 0x01 = 0x01. After the second it is 0x01 XOR 0x02 = 0x03. After the third it is 0x03 XOR 0x03 = 0x00. After the fourth it is 0x00 XOR 0x04 = 0x04. The BCC of the sequence 01 02 03 04 is therefore 0x04, written as two hex digits regardless of byte order.

Step	Byte Added	Accumulator After XOR
0 (initial)	—	0x00
1	0x01	0x01
2	0x02	0x03
3	0x03	0x00
4	0x04	0x04

Three quick sanity checks follow from the same rule. A single-byte frame has a BCC equal to that byte, because 0x00 XOR b = b. An empty frame has a BCC of 0x00, which is why many specifications explicitly forbid the empty payload. A frame containing the byte 0xFF has a BCC of 0xFF, which is also a useful edge case because it confirms the accumulator does not wrap or saturate. Vendor references such as the BALTECH technical note document this same eight-bit XOR over the selected bytes and produce 0x20 for the illustrative sequence 01 A0 7C FF 02, a result a reader can verify by folding the chain 0x00, 0x01, 0xA1, 0xDD, 0x22, 0x20. The Checksum Calculator produces the same value automatically.

Compute a BCC Checksum in the Browser

The fastest way to confirm an example matches a real device is to compute it locally. The Checksum Calculator declares its three formulas up front and shows the byte count it actually processed, so it is straightforward to verify that the input matches the protocol specification.

Open the Checksum Calculator and choose the input mode that matches the protocol: UTF-8 text for human-readable payloads, hexadecimal bytes for raw frames.
If you selected hex, enter each byte as exactly two hex digits separated by whitespace; the tool rejects prefixes such as 0x, commas, odd nibbles, and comments rather than guessing.
Enter only the bytes the specification says are covered by the check; for Modbus ASCII that means excluding the starting colon and the trailing CRLF, and for many vendor BCCs that means excluding STX, ETX, length bytes, and the BCC byte itself.
Run the calculation and read the labeled result for XOR-8 BCC. The display always shows two hex digits, including a leading zero when needed.
Cross-check against the device documentation. If the device expects a final complement or a different initial value, the XOR-8 BCC will not match; the Modbus LRC line and the raw byte-sum-modulo-256 line are then useful for diagnosing which convention the manual describes.
Copy the labeled block, which includes all three values and the processed byte count, so a pasted diagnostic note preserves the interpretation that produced the number.

Modbus ASCII LRC: A Different 8-Bit Check

Modbus ASCII frames do not use a raw XOR. According to the Modbus over Serial Line specification, the LRC is computed by adding every message byte into an eight-bit field, discarding any carry that leaves the byte, and then taking the two's complement of the sum. Equivalently, the LRC is the negative of the byte sum modulo 256, which means the LRC and the raw sum always add to zero modulo 256 for the same input.

Two practical consequences follow for any example. First, the starting colon and the ending carriage-return-line-feed pair are framing characters and are not part of the message bytes supplied to the LRC; the specification excludes them explicitly. Second, two devices that report a "checksum" and a "LRC" on the same frame will almost always report different one-byte values, because the additive and XOR conventions diverge on most payloads. Running the same hex bytes through the Checksum Calculator exposes all three conventions side by side, which makes it easier to identify which formula a vendor document actually describes.

Limits of an 8-Bit Block Check Character

It is worth restating what a one-byte check can and cannot do. An eight-bit value can take only 256 distinct forms, so for any non-trivial frame many different inputs share the same BCC. The check can therefore catch some accidental bit flips and some framing errors, but it cannot detect every change, and it is trivial to construct a different payload with the same value. This is why BCC is a transmission-integrity check and not a security primitive.

Do not use BCC, LRC, or the raw sum modulo 256 to protect credentials, to authorize commands, to verify software downloads, or to authenticate untrusted network traffic. Use the mechanism the protocol actually requires: a CRC-16 or CRC-32 for stronger error detection, and a cryptographic hash or message authentication code for tamper resistance. The Checksum Calculator is explicit about this scope: it reproduces two named eight-bit formulas plus a diagnostic sum, it does not claim protocol compatibility beyond those formulas, and it does not claim authentication.

The page also enforces a 500,000-byte ceiling, never silently truncates input, and reports malformed hex without producing a partial value. Results are always exactly two lowercase hex digits. These guards matter when a long trace is pasted in for debugging, because a misread framing byte or a stray prefix character in the input is otherwise easy to miss. With the formula declared and the input auditable, the same worked example can be reproduced on paper, in firmware, and in the browser without ambiguity.