Protocol decoding

1. What ships with the build

Modbus RTU

Function code, register address and CRC decoded into fields.

Modbus ASCII

The same fields with ASCII framing.

DL/T 645

Metering frames recognised and decoded.

IEC 60870-5-101

Telecontrol frames recognised and decoded.

NMEA 0183

GNSS sentences recognised and decoded.

AT commands

Command and response lines recognised.

Decoding is a Professional feature. In the free, trial and standard editions the plugins still run, but every decoded value is replaced by the placeholder **** before it reaches the screen: the Protocol and Summary columns, the protocol field tree in the detail pane, the Table view's remark column (the protocol name) and the dashboard's proto / parse fields.

2. Where decoded output appears

• The Protocol view lists the frames the active plugin recognised and the fields it produced.
• The Modbus view adds Modbus-specific decoding, including the exception responses.
• Decoded fields appear alongside the original bytes rather than replacing them, so you can always fall back to hex.
• Without protocol analysis both views still list the frames: the protocol name and the decoded fields read ****, while lengths, directions, timestamps and the raw bytes are unchanged.

3. Enabling and reordering plugins

Plugins can be enabled, disabled and reordered in Settings. Order matters when a frame could belong to more than one protocol: the first plugin that recognises it wins.

Turning a plugin off does not change what is captured - it only changes how the frames are interpreted.

4. Honest limits

The protocol set is the one that ships with the build. There is no user-supplied plugin format in this release, and a frame that no plugin recognises is simply shown as raw bytes rather than guessed at. The mask is a licence boundary, not a capture boundary: a masked frame is not lost, it is only not interpreted for you.