> After a lot of mumble-mumbling, the definition of weird protocols and so =
on, I
> rediscovered an ancient, existing, protocol:
> SOH, data (eventually DLE), EOT, and finally CRC
>=20
> It works although it has the defect that it will double the bandwidth req=
uired if
> you send certain bytes.
>=20
> Has anybody a better solution to suggest? :)

You can tweak the protocol slightly to allow data compression within the pa=
cket. I used to work on some equipment that used a similar protocol, and th=
ey used one of the control bytes to pack data within the stream. I can't re=
member which control byte was used, but let's assume it was ESC, then the c=
ompressed part of the packet would look like ESC<length>Char where length i=
s a binary count of 2..31 (there is no advantage in compressing a repeat of=
 less than 2 ). This compression could also deal with any control character=
s in the stream where there are several repeated ones in one spot.

Secondly the remote end would respond with ACK or NAK, depending on how the=
 packet CRC checked out. If a NAK was returned the sending end would repeat=
 the packet up to 2 more times (3 tries in total including the original) in=
 an attempt to get a good packet through.

In my case the protocol was known as QSP, which stood for Qantel Standard P=
rotocol. It looks they still have gear out in the wild that may use the pro=
tocol.


--=20
Scanned by iCritical.

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.