10 Error Detection: CRC and Checksums

10.1 Start With the Suspicious Packet

Connect the Check Result to a Receiver Action

Picture a pressure reading that reaches a pump controller with one changed bit. The receiver must decide whether to accept, reject, ask again, or enter a safe unknown state. A red error light is useful only if that decision and its limit are clear.

A checksum is a small value calculated from a stated part of a message. A cyclic redundancy check, or CRC, is a stronger form designed to catch common bit changes. Record the message version, protected bytes, method and settings, expected value, received value, receiver rule, and final result.

Flip one bit, swap two bytes, cut the message short, repeat it, change its order value, use the wrong format, and restart the receiver. Check accepted and rejected paths. Keep a known bad test that would pass if someone removed or narrowed the check by mistake.

A matching value does not prove who sent the message, whether it is fresh, whether the sensor is right, or whether every possible change was detected. Error detection is one bounded claim, not security or full reliability.

Practitioner builds the message and receiver test. Under the Hood explains parity, checksum behavior, CRC polynomials, coverage, undetected patterns, and how sequence and identity rules complete the decision path.

Use this receiver check:

• Save one known good message.
• Mark the exact protected bytes.
• Record the method and settings.
• Flip one bit and reject.
• Swap two bytes and reject.
• Cut the message and reject.
• Repeat it and check identity.
• Change order and check state.
• Restart the receiver and retry.
• Test the normal path again.
• Keep each bad case as a test.
• State what the check cannot prove.

Imagine a receiver facing one packet that might be corrupted, duplicated, truncated, or out of sequence. Detection mechanisms are useful because they help the receiver decide whether to accept, reject, retry, or escalate that packet. The review has to preserve both sides: what the check can detect and what it still cannot prove.

10.2 Overview: Detection Is a Bounded Claim

Error detection asks whether a receiver can notice a corrupted, malformed, repeated, or suspicious message before treating it as valid. Checksums, CRCs, parity bits, sequence values, and duplicate markers can all help, but each one supports only the claim it was actually designed and observed to support.

A useful IoT reliability review ties the check method to the message scope and the receiver action. The record should say what was protected, how the check was computed or interpreted, what evidence showed accept or reject behavior, what the evidence cannot prove, and which change requires retest.

For example, meter-12 sends a pressure sample with payload bytes, a sequence value, and a CRC. A useful review packet does not stop at "CRC failed." It records the exact frame or trace, the byte range covered by the check, the receiver rule, and the action that followed. If the receiver drops the malformed frame and emits a diagnostic, the evidence supports bounded rejection. If it silently retries, accepts a stale duplicate, or logs only a generic parsing error, the review conclusion changes.

The opening examples become reviewable only when the observed packet is connected to the receiver’s decision and to an explicit limit. Trace Figure 10.1 to see that complete evidence chain before comparing particular check methods.

Read Figure 10.1 from the protected message scope into the named check method and observed condition. Continue to the receiver result, then finish at the limit and retest trigger. That order separates detecting a mismatch from deciding what the system did about it, preserving the chapter’s bounded claim instead of turning one clean check into universal reliability proof.

Overview Check

10.3 Practitioner: Build the Error-Detection Record

Start with the question the record must answer: can this receiver notice and handle this failure condition in this transport path? Then separate the method from the outcome. The method describes how the check is interpreted. The outcome describes what the receiver did when the check passed, failed, repeated, or appeared out of sequence.

This separation matters in IoT systems because the same packet evidence can lead to different operational decisions. A routine telemetry sample might be dropped. A command might be rejected and alarmed. A repeated idempotent update might be ignored. A malformed frame might be quarantined for investigation.

To turn that evidence path into a reusable review artifact, inspect the field groups in Figure 10.2. They show what must be recorded together so a later reviewer can repeat the check and understand its consequence.

In Figure 10.2, begin with scope and method, move through the observed condition and receiver action, and only then read the decision, limits, ownership, and retest trigger. The progression keeps calculation details separate from operational behavior while still joining them in one record, which is exactly what the worked CRC example needs.

Worked Record

Assume a sensor frame is rejected after a CRC mismatch. The log names the frame, receiver, and rejection result, but not the configured CRC profile or included bytes. Keep the rejection as receiver-action evidence, then request the missing method details so another reviewer can recompute or interpret the result.

The bounded conclusion is narrow: this receiver rejected this observed frame under the recorded condition. It does not prove every frame format, every corruption pattern, every parser revision, or the semantic correctness of later accepted payloads.

Practitioner Check

10.4 Under the Hood: Know What the Check Cannot Prove

Different checks answer different questions. A simple checksum can catch many accidental changes, but a weak checksum may miss some error patterns. A CRC can be much stronger for a configured error model, but the record must still name the actual profile and receiver behavior. Parity can support a narrow bit-level check. Sequence values and duplicate keys can reveal gaps, repeats, or stale observations, but they do not validate payload meaning.

Error detection also sits below several other review layers. A clean check value does not authenticate the peer, authorize the action, decrypt the payload, prove freshness by itself, confirm idempotent application behavior, or decide whether a retry is safe. Those claims need their own evidence.

Mechanically, the receiver recomputes the check over the same byte range and compares the result with the transmitted value. Two correct implementations can disagree if one uses a different byte order, seed, polynomial profile, included-field set, padding rule, or trailer encoding. A review record should therefore describe the calculation contract, not just the word "CRC" or "checksum." The check can say that the protected bytes arrived in a form consistent with that contract; it cannot say whether those bytes represent the current command, the right actuator, or a safe side effect.

The limits of a CRC are easiest to understand by following the bytes through both endpoints. Figure 10.3 exposes the calculation and comparison points where two implementations must agree before the receiver can make its narrow accept-or-reject decision.

Trace Figure 10.3 from the sender’s header and payload through the configured polynomial calculation and appended check value. On the receiver side, follow the same protected byte range through recomputation and comparison, ending at accept or reject. The flow explains why profile, byte order, seed, and included fields belong in the record—and why even a match says nothing by itself about freshness, authorization, or safe application meaning.

Failure Review Prompts

Use the prompts to widen the review one boundary at a time. Begin by testing whether a clean check can still carry stale or unauthorized meaning, then confirm that both implementations share the calculation contract. Compare positive and negative receiver evidence, match the receiver action to application risk, and finish by naming the change that makes the check stale. The sequence keeps packet detection separate from freshness, authorization, and safe outcome.

Preserve the exact artifact behind each answer. A trace can identify protected bytes and transmitted values, while endpoint logs show recomputation, rejection, quarantine, or application delivery. A sequence or duplicate record answers a different question from a checksum. Keeping those sources separate makes the resulting accept, retry, alarm, or hold decision defensible.

• Could a clean check value still carry stale, unauthorized, or semantically wrong data?
• Could another parser, byte order, seed, or excluded field calculate a different result?
• Does the record show both a normal accept case and a failed-check or duplicate case?
• Does the receiver action match the application risk: drop, retry, quarantine, alarm, or hold?
• Which later change reopens the review: format, firmware, parser, gateway, security layer, retry policy, or receiver action?

Under-the-Hood Check

10.5 Retries and Sequence Numbers

10.5.2 Overview: Retry Only Means Something With Boundaries

Retries and sequence numbers help an IoT system reason about loss, duplication, delay, and reordering. They do not prove that every message arrived or that every command was safe. They support a reliability decision only when the sender limit, receiver state, duplicate rule, and side-effect boundary are explicit.

A retry policy says when a sender tries again, when it stops, and what state remains after the limit. A sequence policy says how the receiver recognizes a new, duplicate, stale, missing, or reordered message.

For example, gateway-east sends command C-512 with sequence 181 to a valve controller and expects acknowledgement A-181 before the response window closes. If the acknowledgement is missing, a reviewable retry policy might wait a short interval, add jitter so a fleet does not retry in the same millisecond, try twice, then mark the command unresolved and leave the valve state at last-confirmed. That record is stronger than "three retries" because it names the command identity, the acknowledgement identity, the stop condition, and the state after the sender gives up.

The receiver side needs the same discipline. If sequence 181 arrives twice, the receiver may acknowledge the duplicate so the sender can stop, but it must not apply the valve command twice unless the command is explicitly idempotent. If sequence 183 arrives after 181, the receiver needs a rule for the missing 182: wait inside a reordering window, reject the gap, or flag the state as incomplete. Without those sequence rules, retries can turn a recoverable timeout into a duplicate write, stale dashboard value, or unsafe actuator action. The important evidence is the tested state transition, not the fact that a retry occurred.

The duplicate-command example needs one continuous route from the first timeout to the receiver’s final state. Use Figure 10.4 to follow that route before deciding whether the retry policy is safe.

Trace Figure 10.4 from the missing acknowledgement or sequence gap into the retry decision. Next inspect acknowledgement and receiver sequence state, then follow the path to the final state and retest trigger. The diagram connects sender limits to receiver-side duplicate handling, showing why visible retries alone do not prove delivery or side-effect safety.

Message Boundary

Name the telemetry report, command, queue item, gateway handoff, or state update that retry and sequencing protect.

Retry Boundary

Record timeout observation, delay behavior, retry limit, acknowledgement result, and the final state after stop or success.

Sequence Boundary

Record accepted sequence state, duplicate rule, missing-message rule, reordering window, reset behavior, and wraparound rule.

Side-Effect Boundary

Show whether repeated or late messages can change stored state, actuator state, command status, or operator decisions.

Review rule:

Do not approve retry behavior from repeated attempts alone. The evidence must show a bounded decision and the state left behind.

10.5.3 Practitioner: Build the Evidence Record

A practitioner should review retry and sequence behavior as a record, not as a slogan. The record starts with the message boundary and observed condition, then ties retry policy, acknowledgement handling, sequence state, side effects, final decision, and retest trigger together.

This works for TCP-based reconnect decisions, UDP paths with application acknowledgements, CoAP or MQTT message IDs, gateway queues, and application command logs. The exact protocol changes the signals available, but the record still needs bounded evidence.

The practitioner record must preserve both sender policy and receiver state without hiding either inside a generic retry count. Figure 10.5 shows the fields to inspect in order.

In the diagram Figure 10.5, begin with the protected message and observed condition, then compare the retry policy with the acknowledgement and accepted sequence state. Continue through the side-effect boundary to the final decision, owner, and retest trigger. This order makes the record suitable for TCP reconnects, datagram acknowledgements, and queue handoffs while keeping each conclusion tied to its tested path.

Evidence Flow

1. State the boundary Identify the message, receiver expectation, state update, and observation point.

2. Record the condition Name the timeout, missing acknowledgement, duplicate, stale value, sequence gap, reorder, or reset.

3. Review the retry Capture delay behavior, jitter if used, retry limit, stop condition, and final sender state.

4. Review receiver state Capture acknowledgement identity, late response rule, accepted sequence value, duplicate rule, and gap rule.

5. Close the record Record side-effect guard, final decision, owner, and retest trigger.

Review Signal

Weak Evidence

Stronger Evidence

Decision Pressure

Timeout

A log says "timeout" without the expected response or observation point.

Expected acknowledgement, message identity, timer start, observation point, and state at timeout.

Retry, hold, fail safe, reconnect, or mark unknown.

Retry

A counter increments with no delay rule, limit, or final state.

Delay behavior, limit, stop condition, final state, and congestion or battery concern when relevant.

Accept for scope, revise policy, or add operational alert.

Sequence value

A sequence number appears in a trace without an accept or reject rule.

Prior accepted state, duplicate rule, gap rule, reset boundary, and wraparound rule when finite.

Accept, ignore, reject, wait for repair, or retest after reset.

Side effect

The command is retried without saying whether repeating it is safe.

Idempotency rule, command identifier, receiver state, duplicate action, and rollback or hold behavior.

Guard side effects before accepting the retry path.

10.6 Summary

Error detection gives reviewers evidence that a receiver noticed a mismatch, duplicate, malformed message, or suspicious sequence condition. The evidence is strongest when it names the message scope, check method, checked fields, observed receiver action, known limits, and retest trigger.

Checksums, CRCs, parity, sequence values, and duplicate markers answer different questions. None should be stretched into a broad reliability, security, or application-correctness conclusion. Use error-detection evidence to decide the bounded claim, then hand off retry behavior, application state, authorization, freshness, and data-quality questions to the right review layer.

10.7 Key Takeaway

10.8 See Also