Monitor a serial conversation inline

Scenario 3: monitor a serial conversation inline

Use this to investigate a private protocol, timing issue or intermittent failure between an existing host and device.

1. Prepare two independent serial adapters: connect endpoint A to the host side and endpoint B to the device side.
2. Match the original serial parameters on both endpoints and create an A ⇄ B bridge.
3. Use Hex in both panes for binary protocols and Text for readable protocols. The display mode does not alter forwarded bytes.
4. Enable Record both directions to one file so A->B requests and B->A responses share one ordered timeline.
5. Send a known request at low speed and confirm that the device behaves exactly as it did before the bridge was inserted, then begin the real capture.

Do not add another physical loop around two serial ports that are already wired together. If sustained traffic rises while queues never drain, the flood guard suspends the link. Correct the cabling and click Resume in the bridge manager.

Common checks after creating a bridge

• Both endpoint panes are open and show bridge badges. The manager should report Active rather than Degraded or Suspended.
• The direction matches the topology. A one-way bridge does not return responses automatically.
• Dropped counters should remain zero. A non-zero value means the sink is too slow, the buffer is too small or the source cannot be throttled. Fix the cause before merely increasing the buffer.
• Keep One client at a time for TCP servers by default. If several request/response clients must share the device, use Take turns together with idle-gap, delimiter or fixed-length framing. All clients share the port can interleave requests on the serial wire.
• Save the endpoints and bridge together in a .spu project for repeated use, and re-check the physical port assignments after loading it.