Serial packet structure COBS

This is a question that came to mind when reading @PowerBroker's excellent Tutorial in the Introductory section. I don't want to derail the Tutorial

This is a quote from Reply #4 of the Tutorial

Consistent Overhead Byte Stuffing (or COBS) is a low-byte-overhead method of avoiding false start/end bytes within the packet payload. The main idea behind COBS is to add a field in the transmitted packet that contains a pointer. This pointer will point to the first occurrence of the value of the start/end byte in the original packet payload.

My own approach to sending data that may contain a value the same as a start- or end-marker has been to use a third marker byte. For example 254 might be the start marker and 255 might the end marker and 253 will be the "special character marker". When deciphering the incoming data if the system sees a 253 in the stream it will treat the following byte as a legitimate value rather than a marker. For example to include 254 in the stream one would send 253 254 and to include 253 in the stream one would send 253 253

My question is whether the COBS system is more efficient?

And, with a slightly different slant on the same problem (my preference being to send human readable characters) for some of my own projects I have developed a couple of small functions that will encode and decode a number into either 2 characters or 3 characters (depending on the size of the number) in the range (IIRC) ASCII 48 '0' to ASCII 111 'o'. This is a range of 64 characters. Two characters can store a value from 0 to 4160 and 3 characters can store up to 266,000. It allows for the data elements to be identified without needing separators (because the length is known in advance) and decoding is very much faster than the atoi() function.

...R

Robin2:
My question is whether the COBS system is more efficient?

it depends how you measure efficiency.

I think your approach is called "Byte stuffing". You transform a byte stream that may have reserved values (ie your packet marker) into a longer sequence that disambiguates the payload.

Your algorithm can encode and stream on the fly, if you see a marker in the payload, you just send the escape character and the marker.

The BS in COBS is also Byte Stuffing but with a different approach as you remove the marker from the stream and replace it with the relative position of the next marker in the payload (or FF if there is none in sight) --> so with COBS you need to store a look ahead buffer of 254 bytes before you can start streaming (and accumulate the next bytes in parallel if you can). This could create a latency issue

The advantage of COBS is that you only add (at most) 1 byte every 254 bytes so the time to broadcast a payload is pretty predictable whereas your approach may introduce lots of jitter depending on the payload (worst case is you double the size of the payload)


for your second point are you creating a new representation of the ASCII representation of the number with 64 symbols instead of 10 ?

J-M-L:
for your second point are you creating a new representation of the ASCII representation of the number with 64 symbols instead of 10 ?

I guess that's correct - I had not thought of it like that.

...R