Low-level RS232 - How to resynchronize a block-wise transmission after a failure ?

Giganews Newsgroups
Subject: Low-level RS232 - How to resynchronize a block-wise transmission after a failure ?
Posted by:  R.Wieser (addre…@not.available)
Date: Sat, 29 Jun 2019

Hello all,

I'm trying to wrap my head around some simple block-wise RS232
communication, in specific what the receiving end should do when it detects
/something/ has gone wrong (bits, and/or whole bytes got lost)

With "block wise" I mean that I intend to chop the stream up into blocks,
allowing resending of the damaged ones (instead of the whole thing).

The problem is that when one block is damaged I have no good idea how to
detect the start of the next block.

Or rather, I've got several ideas, all with their own problems :

In a /fully wired/ connection I can (ab)use one of the handshake lines to
indicate a start-of-block.

Though this would (ofcourse) be unusable for any 3-wire connection (TXD,
RXD, ground), or when an intermediate device (modem) is involved.

The old "send a block and wait for it to be acknowledged before sending a
new one" method ofcourse would work well for short distances, but not really
for longer ones where the turn-around time can be measured in tenths of, or
even whole seconds.

I also could introduce pauses between send blocks, but those would need to
be long enough to allow for some inter-byte delay (caused by the sender),
likely slowing the whole transmission down quite a bit.

Argh!

The infuriating part of all of this is knowing that its (most likely) a
rather common problem, and as such has been solved decades ago - but I can't
seem to find anything worthwhile(1) while googeling for it.  :-\

(1) other than making the start-of-block bit pattern unique - forcing a
re-encoding / escaping of the actual send data (causing its own problems.
Including what would happen when a startbit is missed and the subsequently
receieved byte patterns are up for grabs ...)

Regards,
Rudy Wieser

P.s.
Although the first machine (server if you like) will (currently) be a
Windows machine, the second one (client) might also be DOS, Linux or even a
microcontroller.  In other words, I need an approach I can implement myself.

Replies