Passive observation comes first
Preserve a working exchange between the original software and device before transmitting experimental bytes. Capture both directions with timestamps and record the operator action and device state associated with each exchange.
- Verify electrical level and pinout without disturbing handshake behavior.
- Record baud rate, data bits, parity, stop bits and flow control.
- Collect repeated examples of one action before varying an input.
- Keep raw binary bytes; a terminal’s text view can hide delimiters and zeroes.
Build a protocol model
| Clue | Question to test |
|---|---|
| Stable prefix or suffix | Header, terminator, address or checksum? |
| Changing byte after each request | Counter or sequence used for response correlation? |
| Response only in certain conditions | Device state, initialization or inter-command timing? |
| Length changes with payload | Explicit length field or delimiter framing? |
| Final bytes vary broadly | Checksum/CRC, compression or unrelated measurement data? |
Use controlled experiments that change one value or state at a time. Validate proposed fields against captures not used to derive the hypothesis.
From knowledge to replacement
Implement only the required command subset, with framing validation, bounded timeouts and retry rules appropriate to the operation. A repeated read may be safe; a repeated movement or write may not be.
Begin with traffic capture and resolve cable uncertainty through pinout diagnosis. The unknown protocol guide covers deeper frame inference, while RS232 development covers replacement clients.
Provide
Device model, cables, port settings, original software, raw bidirectional captures, required operations and access to representative device states.