# Module 11: RTU & ASCII Frames

> Frame structure, CRC vs LRC, silent intervals, and reading captures by hand.

**Phase:** Physical Network & Transport  
**Estimated time:** 7 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/rtu-ascii-frames

## What you'll be able to do
- Read an RTU capture byte by byte: address, FC, data, CRC.
- Compute a Modbus CRC by hand or with the workbench tool.
- Convert between RTU and ASCII framings for the same PDU.

## Three things people get wrong
1. **Writing the CRC high byte first.** Modbus appends CRC low byte then high. CRC = 0x0BC4 goes on the wire as C4 0B.
2. **Including the colon or CRLF in the LRC.** ASCII LRC covers the binary message bytes only — exclude ':' and the trailing CR/LF.
3. **Treating bad CRC as an exception.** A device that sees a bad CRC discards the frame silently. The client sees a timeout, not 83 xx.

## From the field
**The CRC that was off by one byte**

A homebrew script computed the CRC on the address plus PDU but forgot to include the byte count for FC 17. Every response looked right except the last two bytes. The fix was three lines of code, but the team spent a day blaming the cable.

## References
- [Modbus over Serial Line V1.02](https://www.modbus.org/file/secure/modbusoverserial.pdf) — Section 2.5 — frame description

## Lesson

# Module 11 Lesson: Modbus RTU And ASCII Frames
## Learner Outcome

By the end of this module, learners can label Modbus RTU and Modbus ASCII frames, separate serial server address from PDU address, explain CRC versus LRC at a troubleshooting level, and predict when a bad serial frame produces a timeout instead of a Modbus exception response.

## Key Concepts

- Modbus RTU and Modbus ASCII are serial transmission modes. They carry the same PDU shape inside different serial ADUs.
- RTU sends binary bytes, uses CRC-16, and relies on silent intervals for frame boundaries.
- ASCII sends each byte as two ASCII hex characters, uses LRC, starts with `:`, and ends with CRLF.
- The serial server address is part of the serial ADU. It is not the coil/register PDU address.
- Individual serial server addresses are `1` through `247`; address `0` is broadcast.
- Valid serial broadcast write requests do not receive normal responses.
- A CRC, LRC, parity, framing, timing, or unmatched serial-address failure is normally discarded silently and appears as a timeout. A request sent to the wrong active device is different: it may receive a valid response, exception, or plausible wrong data from the wrong server.

## Key Terms

- RTU: a binary serial Modbus transmission mode.
- ASCII: a serial Modbus transmission mode that represents bytes as ASCII hex characters.
- CRC: Cyclic Redundancy Check; the RTU error check sent at the end of the frame.
- LRC: Longitudinal Redundancy Check; the ASCII mode error check.
- Silent interval: the quiet time used to separate RTU frames.
- Serial ADU: the serial address plus PDU plus serial error check.
- Broadcast: a serial request to address `0` where valid write requests do not receive normal responses.

## Source-Grounded Explanation

The PDU is the Modbus operation. The serial ADU adds the serial address and error check needed on serial links.

```text
PDU:        Function Code | Data
RTU ADU:    Address | Function Code | Data | CRC Low | CRC High
ASCII ADU:  : | Address | Function Code | Data | LRC | CR | LF
```

| Mode | Encoding | Error Check | Boundary Signal | Practical Reading Habit |
|---|---|---|---|---|
| Modbus RTU | Binary bytes | CRC-16 | Silent interval before and after frame | Label bytes before calculating CRC. |
| Modbus ASCII | ASCII hex characters | LRC | Colon start and CRLF end | Convert ASCII pairs back to bytes before interpreting fields. |

RTU frames must be transmitted as a continuous stream. The project wiki summarizes the official serial-line guide this way: a silent gap greater than 1.5 character times inside an RTU frame means the receiver should discard the frame as incomplete, and a silent interval of at least 3.5 character times separates frames. At baud rates above 19,200 bps, the guide recommends fixed timing values; final course release should verify exact wording directly against the guide.

ASCII framing makes message boundaries visible, but it is still serial Modbus. It still has a serial address, PDU, and error check. It is not Modbus TCP written as text.

## Practical Example: Same PDU, Two Serial ADUs

Scenario: Read one holding register from serial server `0x11`.

| Field | Example |
|---|---|
| Transport | Modbus RTU or Modbus ASCII |
| Serial server address | `0x11` |
| Function code | `0x03` Read Holding Registers |
| Documented address | `40010` |
| Actual PDU address | `0x0009` |
| Quantity | `0x0001` register |
| Data type and scale | signed 16-bit, scale `0.1 deg C` |
| Expected normal response | address `0x11`, function `0x03`, byte count `0x02`, two data bytes, valid error check |
| Likely exception or failure mode | exception `83 02` if the range is unsupported; timeout if CRC/LRC, serial settings, timing, or serial server address is wrong |

RTU request before checksum:

```modbus-rtu
11 03 00 09 00 01
```

RTU request with locally generated CRC bytes:

```modbus-rtu
11 03 00 09 00 01 56 98
```

ASCII request with locally generated LRC:

```modbus-ascii
:110300090001E2\r\n
```

The function code, PDU address, and quantity mean the same thing in both modes. The serial ADU and error check are different.

## Broadcast Example

Serial address `0` is broadcast for supported serial broadcast operations. This lesson uses a synthetic broadcast write request because valid serial broadcast write requests do not receive normal responses. Do not teach broadcast reads as a normal lab pattern unless the exact behavior is verified against the serial-line and application protocol specifications.

Course fixture:

| Field | Value |
|---|---|
| Transport | Modbus RTU |
| Serial address | `0x00` broadcast |
| Function code | `0x05` Write Single Coil |
| Documented coil | `00020` if the map uses one-based coil notation |
| Actual PDU address | `0x0013` |
| Write value | `0xFF00` on |
| RTU bytes with locally generated CRC | `00 05 00 13 FF 00 7C 2E` |
| Expected normal response | none, because this is broadcast |
| Safety note | Keep broadcast write examples synthetic unless an instructor-approved simulator is used. |

## Common Pitfalls

- Confusing serial server address with PDU register address.
- Reading RTU CRC bytes in high-byte/low-byte order instead of wire order: low byte, then high byte.
- Treating a bad CRC as an exception-response problem. A bad CRC usually means silent discard and timeout.
- Forgetting that ASCII uses the same underlying bytes represented as ASCII hex characters.
- Expecting a normal response to a valid serial broadcast write request.
- Looking for a CRC in true Modbus TCP traffic.

## Instructor Flow

1. Start with the PDU, then wrap it in RTU and ASCII ADUs.
2. Label address, function, data, and error-check fields before doing arithmetic.
3. Use a request frame, an exception response, and a broadcast write to show three different response expectations.
4. Tie errors back to the three troubleshooting buckets: no valid response, exception response, wrong value.
5. Send learners to the worksheet after they can label the fields without a checksum calculator.

## Check-Your-Understanding

1. In `11 03 00 09 00 01 56 98`, which byte is the serial server address and which bytes are the PDU address?
2. Why does the RTU CRC appear as two bytes at the end of the frame?
3. Why does ASCII mode still need an LRC?
4. Why is "no response" expected for a valid broadcast write?
5. What evidence would move a timeout into function/address troubleshooting?

## Source Notes

- Official serial basis: Modbus over Serial Line Specification and Implementation Guide V1.02 for RTU/ASCII modes, serial addressing, broadcast behavior, timing, CRC/LRC fields, and serial defaults.
- Official protocol basis: Modbus Application Protocol Specification V1.1b3 for PDU structure, function codes, exception-response shape, and broadcast support boundaries.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for RTU/ASCII frame fields, RTU timing and ASCII framing, CRC/LRC checking, serial server address range and broadcast address, broadcast behavior on serial line, PDU vs ADU and general frame structure, and exception codes and exception response PDU shape.
- Local verification basis: checksum examples in this draft were generated with a local Modbus CRC-16/LRC calculation during course build.
- Needs verification: final release should compare checksum fixtures against an independent trusted calculator or library and directly review serial-guide timing/broadcast wording.

## Completion Checkpoint

Before moving on, learners should label one RTU request, one ASCII request, and one broadcast write expectation. They should explain why a bad CRC/LRC usually appears as timeout/no usable response, not as a Modbus exception response.

## Reusable Assets

- [RTU/ASCII frame worksheet](https://learnmodbus.studioseventeen.io/resource/rtu-ascii-frame-worksheet)
- [RTU CRC and ASCII LRC verification lab](https://learnmodbus.studioseventeen.io/lesson/rtu-ascii-frames?page=lab-1)
- [RTU/ASCII frame lab](https://learnmodbus.studioseventeen.io/lesson/rtu-ascii-frames?page=lab-2)
- [Module 11 quiz](https://learnmodbus.studioseventeen.io/lesson/rtu-ascii-frames?page=quiz)
- [Serial settings triage checklist](https://learnmodbus.studioseventeen.io/resource/serial-settings-triage-checklist)

## Diagram source

```mermaid
flowchart LR
  subgraph RTU["RTU frame"]
    A1["Addr"] --> F1["FC"] --> D1["Data"] --> C1["CRC-16"]
  end
  subgraph ASCII["ASCII frame"]
    S[":"] --> A2["Addr"] --> F2["FC"] --> D2["Data"] --> L["LRC"] --> CR["CR LF"]
  end
```

## Labs

### Lab 1

# Lab 2: RTU CRC And ASCII LRC Verification
## Learner Outcome

Learners can verify a Modbus RTU CRC and Modbus ASCII LRC for known request bytes, explain why the RTU CRC is sent low byte first, and classify a bad checksum as a no-valid-response problem rather than a Modbus exception response.

## Prerequisites

- Module 2: PDU and ADU.
- Module 4: exception-response shape.
- Module 9: serial settings and timeout triage.
- Module 11 lesson through CRC/LRC fields.

## Safety And Scope

This is a no-hardware worksheet lab. It does not send traffic to any device. The checksum fixtures are covered by the course-owned helper in `tools/modbus_fixture_helper.py`; final paid release should still compare them against one independent trusted calculator, library, or reviewed tool output.

## Scenario

A client wants to read two holding registers from serial server `1`, starting at PDU address `0`.

Bytes before the RTU CRC or ASCII LRC:

```text
01 03 00 00 00 02
```

## Procedure

1. Label the bytes: serial server address, function code, PDU address, and quantity.
2. Verify the RTU CRC bytes on the wire.
3. Verify the ASCII LRC byte.
4. Build the ASCII frame.
5. Classify what happens if the checksum is wrong.

## Auto-Graded Checks

```lab
type: crc
prompt: Compute the Modbus RTU CRC for the ADU bytes below. Enter both CRC bytes as they go on the wire (low byte first).
bytes: 01 03 00 00 00 02
hint: Modbus appends the CRC low byte before the high byte.
toolLink: /tools?tab=crc&hex=010300000002
toolLink: /tools?tab=crc&hex=01030000000A
```

```lab
type: lrc
prompt: Compute the Modbus ASCII LRC for the same message bytes (exclude the colon and CRLF).
bytes: 01 03 00 00 00 02
hint: LRC is the two's complement of the 8-bit sum.
```

## Worksheet

| Item | Learner Answer |
|---|---|
| Serial server address |  |
| Function code |  |
| PDU address |  |
| Quantity |  |
| RTU CRC bytes on wire |  |
| ASCII LRC byte |  |
| ASCII frame |  |
| Expected client symptom if CRC/LRC is wrong |  |
| What not to change yet |  |

## Answer Key

| Item | Answer |
|---|---|
| Serial server address | `0x01` |
| Function code | `0x03` Read Holding Registers |
| PDU address | `0x0000` |
| Quantity | `0x0002` registers |
| RTU CRC bytes on wire | `C4 0B` |
| ASCII LRC byte | `FA` |
| ASCII frame | `:010300000002FA\r\n` |
| Expected client symptom if CRC/LRC is wrong | timeout or silent discard, not a Modbus exception response |
| What not to change yet | documented address, data type, word order, scale, or unit |

## Verification Method For Draft Fixtures

- CRC fixture basis: Modbus CRC-16 initialized to `0xFFFF`, polynomial `0xA001`, transmitted low byte then high byte.
- LRC fixture basis: two's complement of the 8-bit sum of the message bytes, excluding ASCII `:` and CRLF delimiters.
- Course helper evidence: `python3 tools/modbus_fixture_helper.py checksum "01 03 00 00 00 02"` and `python3 tools/modbus_fixture_helper.py self-test`.
- Release gate: compare worksheet values against one independent trusted external calculator or library before publishing.

## Expected Observations

- The CRC/LRC protects the serial ADU bytes, not the learner's interpretation of scale, unit, or word order.
- A bad checksum usually prevents a valid Modbus frame from being accepted.
- The receiver normally does not send an exception response for a frame it discards before protocol handling.

## Troubleshooting Notes

- If the calculated RTU CRC does not match, re-check byte order on the wire before changing the documented address or quantity.
- If the ASCII LRC does not match, confirm that the colon and CRLF delimiters were excluded from the sum.
- If the client reports timeout/no usable response, treat checksum/framing as a transport-layer suspect before diagnosing exception codes.
- If a learner sees exception `83 02`, that is a parsed Modbus exception response, not the expected symptom of a bad CRC/LRC discard.

## Check Questions

1. Why are the RTU CRC bytes written as `C4 0B` instead of `0B C4` on the wire?
2. Which bytes are included in the ASCII LRC calculation?
3. Why should a bad checksum not lead directly to changing `40001` to another address?

## Instructor Notes

- Keep this lab arithmetic-light unless learners need the algorithm. The key professional skill is knowing what a checksum proves and what it does not prove.
- Pair this lab with Lab 12 so learners see checksum verification after frame labeling.
- Optional extension: add one version-pinned third-party tool command after the lab toolchain is selected.

## Source Notes

- Official serial source: Modbus over Serial Line Specification and Implementation Guide V1.02 for CRC/LRC fields and serial frame handling.
- Official protocol source: Modbus Application Protocol Specification V1.1b3 for function `03` request meaning.
- Synthetic source: request bytes are course-authored fixtures.
- Verification note: checksum values are now covered by the course-owned helper self-test and still need independent external release verification.

### Lab 2

# Lab 12: RTU/ASCII Frame Inspection Without Hardware
## Learner Outcome

Learners can label RTU and ASCII serial ADU fields, separate serial server address from PDU address, verify whether a checksum belongs to RTU or ASCII, and decide whether the expected result is a normal response, exception response, broadcast silence, or timeout.

## Prerequisites

- Module 2: PDU versus ADU.
- Module 4: function codes and exception responses.
- Module 5: documented address versus PDU address.
- Module 9: serial settings and timeout triage.
- Module 11 lesson through broadcast behavior.

## Safety And Scope

This is a no-hardware paper lab. It uses synthetic course-authored frames and checksum fixtures covered by `tools/modbus_fixture_helper.py`. Do not send broadcast writes to real equipment. Optional simulator or serial-client tracks require an instructor-approved isolated simulator and version-pinned tools.

## Scenario

A technician is learning to inspect serial Modbus frames before troubleshooting a real line. Each card includes enough information to label the serial ADU, PDU, and expected result.

## Frame Cards

| Card | Frame Evidence | Context |
|---|---|---|
| A | `01 03 00 00 00 02 C4 0B` | RTU request. Read two holding registers starting at PDU address `0`. |
| B | `:010300000002FA\r\n` | ASCII request for the same logical operation as Card A. |
| C | `11 83 02 C1 34` | RTU exception response. |
| D | `00 05 00 13 FF 00 7C 2E` | RTU broadcast write single coil. |
| E | `11 03 00 09 00 01 56 98` | RTU request. Read documented holding register `40010` if the map uses one-based `40001` notation. |
| F | `11 03 00 09 00 01 00 00` | Same request bytes as Card E, but with invalid placeholder CRC bytes. |

## Procedure

1. Identify whether each card is RTU or ASCII.
2. Label serial address, function code, PDU address, quantity or value, and error-check field.
3. For request frames, identify documented address when enough context is provided.
4. Predict the expected result: normal response, exception response, broadcast silence, or timeout/silent discard.
5. Explain what not to troubleshoot yet.

## Worksheet

| Card | Mode | Serial Address | Function | PDU Data Meaning | Error Check | Expected Result | What Not To Change Yet |
|---|---|---|---|---|---|---|---|
| A |  |  |  |  |  |  |  |
| B |  |  |  |  |  |  |  |
| C |  |  |  |  |  |  |  |
| D |  |  |  |  |  |  |  |
| E |  |  |  |  |  |  |  |
| F |  |  |  |  |  |  |  |

## Answer Key

| Card | Mode | Serial Address | Function | PDU Data Meaning | Error Check | Expected Result | What Not To Change Yet |
|---|---|---|---|---|---|---|---|
| A | RTU | `0x01` | `0x03` Read Holding Registers | PDU address `0x0000`, quantity `2` | CRC `C4 0B` on wire | Normal response if server and range are valid | Data type, scale, word order |
| B | ASCII | `0x01` | `0x03` Read Holding Registers | PDU address `0x0000`, quantity `2` | LRC `FA` before CRLF | Normal response if server and range are valid | RTU CRC byte order |
| C | RTU | `0x11` | `0x83` exception for function `0x03` | Exception code `0x02` Illegal Data Address | CRC `C1 34` on wire | Valid exception response | Baud, parity, CRC, physical wiring unless other evidence appears |
| D | RTU | `0x00` broadcast | `0x05` Write Single Coil | PDU address `0x0013`, value `0xFF00` | CRC `7C 2E` on wire | No normal response expected | Do not treat silence alone as a failed response |
| E | RTU | `0x11` | `0x03` Read Holding Registers | PDU address `0x0009`, quantity `1`, documented `40010` under one-based notation | CRC `56 98` on wire | Normal response if server and range are valid | Do not change to `40009` without map evidence |
| F | RTU | `0x11` | `0x03` Read Holding Registers | Same PDU as Card E | Invalid placeholder CRC `00 00` | Timeout or silent discard likely | Function, PDU address, data type, scale |

## Expected Observations

- RTU and ASCII can carry the same PDU meaning with different serial ADUs.
- CRC and LRC errors are not Modbus exception responses.
- A valid exception response proves a valid Modbus response was received.
- Broadcast write silence is expected behavior, not automatically a fault.

## Troubleshooting Notes

- Label fields before calculating or checking checksums.
- Keep documented references such as `40010` separate from the PDU address bytes.
- Treat checksum fixtures as training data until the course-owned helper output is compared against an independent external tool or the final chosen toolchain.
- Do not use real broadcast write examples outside an isolated simulator or reviewed training bench.

## Check Questions

1. Which cards carry the same logical read request in different serial modes?
2. Which card is a valid Modbus exception response?
3. Which card should be silent if the request is accepted by servers?
4. Why is Card F a timeout/silent-discard case rather than an exception-response case?

## Instructor Notes

- Ask learners to explain why the first byte in RTU/ASCII is not the register address.
- Use Card C to reinforce that an exception response is still a response.
- Use Card D to keep broadcast behavior and write safety visible.
- Helper command: `python3 tools/modbus_fixture_helper.py self-test` verifies the current frame-card checksum constants.
- Optional extension: after tool versions are selected, verify these frames with an external calculator/library and add the command output to the release notes.

## Source Notes

- Official serial source: Modbus over Serial Line Specification and Implementation Guide V1.02 for RTU/ASCII frame shapes, serial addressing, error checks, timing, and broadcast response behavior.
- Official protocol source: Modbus Application Protocol Specification V1.1b3 for function codes, PDU structure, and exception code `02`.
- Synthetic source: all frame cards are course-authored teaching fixtures.
- Verification note: checksum bytes are covered by the course-owned helper self-test and still need independent external release verification.

## Knowledge check

# Module 11 Quiz: Modbus RTU And ASCII Frames
## Questions

### Multiple Choice

1. In the RTU request `11 03 00 09 00 01 56 98`, what is `0x11`?
   - A. The serial server address.
   - B. The PDU register address.
   - C. The CRC high byte.
   - D. The byte count.

2. Which statement is safest about RTU CRC bytes?
   - A. They are sent high byte first.
   - B. They are part of true Modbus TCP.
   - C. They appear at the end of the RTU ADU on the wire as low byte, then high byte.
   - D. They replace the function code.

3. Which frame shape describes Modbus ASCII?
   - A. MBAP header plus PDU.
   - B. Colon, ASCII hex byte pairs, LRC, CRLF.
   - C. Silent interval, binary bytes, CRC, silent interval.
   - D. Ethernet frame with no Unit Identifier.

4. A client sends a valid serial broadcast write to address `0`. What normal response should it expect?
   - A. Every server responds at once.
   - B. Only server `1` responds.
   - C. No normal response.
   - D. A Modbus TCP MBAP response.

5. A receiver detects a bad CRC in an RTU request. What should the learner expect at the client?
   - A. Usually timeout or silent discard.
   - B. Exception code `02` from the receiver.
   - C. A normal response with byte count `02`.
   - D. A text ASCII response.

6. On a serial Modbus line, which range covers the individually addressable serial server addresses, and which address is reserved for broadcast?
   - A. Addresses `0` through `247`, with `248` as broadcast.
   - B. Addresses `1` through `247`, with `0` as broadcast.
   - C. Addresses `1` through `255`, with `255` as broadcast.
   - D. Addresses `0` through `255`, with no broadcast address.

7. In the RTU frame `01 03 00 00 00 02 C4 0B`, what are the last two bytes `C4 0B`?
   - A. The PDU register address and quantity.
   - B. The CRC-16, transmitted low byte (`C4`) then high byte (`0B`).
   - C. The CRC-16, transmitted high byte (`C4`) then low byte (`0B`).
   - D. An ASCII LRC followed by CRLF.

### Short Answer

1. Explain the difference between serial server address and PDU address.
2. Why should learners label a frame before calculating CRC or LRC?
3. How can the same logical read request appear in both RTU and ASCII?
4. Why is a valid exception response different from a checksum failure?

### Applied Scenario

A learner sees this RTU frame:

```text
01 03 00 00 00 02 C4 0B
```

Tasks:

1. Label the serial server address.
2. Label the function code.
3. Label the PDU address and quantity.
4. State the documented holding-register reference if the map uses one-based `40001` notation.
5. Explain what a bad CRC would likely look like to the client.

## Answer Key

1. Multiple choice: A. `0x11` is the serial server address in the serial ADU. The PDU address is `00 09`.
2. Multiple choice: C. RTU CRC bytes are transmitted low byte, then high byte, at the end of the RTU frame.
3. Multiple choice: B. ASCII starts with `:`, carries ASCII hex byte pairs, includes LRC, and ends with CRLF.
4. Multiple choice: C. Valid serial broadcast write requests do not receive normal responses.
5. Multiple choice: A. Bad CRC prevents the receiver from accepting the frame, so the client usually sees timeout or silent discard, not a Modbus exception.
6. Multiple choice: B. Individual serial server addresses are `1` through `247`, and address `0` is broadcast. The other ranges misplace the broadcast address or invent an out-of-range span.
7. Multiple choice: B. `C4 0B` is the RTU CRC-16, transmitted low byte first (`C4`) then high byte (`0B`), so the CRC value is `0x0BC4`. It is not the PDU address/quantity and it is not an ASCII LRC/CRLF.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | A | B is the later PDU register address, C is part of the final CRC field, and D belongs in normal read responses. |
| 2 | C | A reverses RTU CRC byte order, B adds serial CRC to true TCP, and D replaces the function code with the wrong field. |
| 3 | B | A is Modbus TCP, C is RTU, and D describes Ethernet/TCP framing rather than Modbus ASCII. |
| 4 | C | A/B would create response collisions or invent a single responder, and D applies TCP response framing to serial broadcast behavior. |
| 5 | A | B would require a valid exception response, C is a normal read response, and D changes the mode to ASCII text. |
| 6 | B | A/C/D misplace the broadcast address or use an out-of-range span; only `1`-`247` with `0` broadcast is correct. |
| 7 | B | A misreads the CRC field as PDU data, C reverses the wire byte order, and D applies ASCII framing to an RTU frame. |

Short answer:

1. The serial server address selects the serial node that should process the request. The PDU address selects the coil/register offset inside the requested function's data area.
2. Labeling fields first prevents learners from treating checksum arithmetic as the whole task. It also catches layer mistakes such as confusing server address, function code, and PDU address.
3. The server address, function code, PDU address, and quantity can be the same underlying bytes, while RTU carries them as binary bytes with CRC and ASCII carries them as ASCII hex characters with LRC and delimiters.
4. A valid exception response is a valid Modbus frame with an exception function and code. A checksum failure means the receiver normally discards the frame before Modbus exception handling.

Applied scenario:

1. Serial server address: `0x01`.
2. Function code: `0x03` Read Holding Registers.
3. PDU address: `0x0000`; quantity: `0x0002`.
4. Documented references: holding registers `40001` and `40002` if the map uses one-based `40001` notation.
5. A bad CRC would usually lead to silent discard and client timeout. It should not be diagnosed first as illegal data address, word order, scale, or unit.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for RTU/ASCII frame fields, RTU timing and ASCII framing, CRC/LRC checking, serial server address range and broadcast address, broadcast behavior on serial line, PDU vs ADU and general frame structure, and exception codes and exception response PDU shape.
- Current checksum fixtures remain draft until independently verified against a trusted calculator or library.

---
_Learn Modbus · learnmodbus.studioseventeen.io · Module 11/16 · v1.0.0 · Exported for offline / agent use._