The primary benefit of COBS is the “consistent overhead”. In your worst-case scenario (ie. a data portion of your message consisting mostly of SYN and/or ESC bytes) the simple stuffing approach could significantly increase the size of your transmitted data. The maximum overhead for COBS is 0.4% (1 Byte overhead/ 254 Bytes data) with an expected overhead of 0.23%. A slight alternative, COBS/Zero Pair Elimination, can even have a slight compression, given certain input data (eg. mostly zeroes). The whitepaper is very readable and explains it better than I could: http://www.stuartcheshire.org/papers/COBSforToN.pdf If the data in your case is tightly bound and/or not likely to collide with your SYN or ESC bytes, or consistency in the transmission overhead (and impact on effective throughput) is not a limiting factor then a PPP-style byte stuffing algorithm should be fine. -Robert
On Jan 29, 2016, at 12:24 PM, Gabriele Filosofi <GabrieleF@cosmed.it> wrote:
Thank you!
a) I agree with Richard about the need for Checksum. Sources of errors could be outside of the transport channel b) Regarding the problem of SYN (2B) occurrences within user data, assuming random values the probability of this event is LEN/(2*256*256) which is not negligible (in my case typ. LEN is 250), thus I agree on byte stuffing too. Robert, at first glance COBS seems more complicated than the usual way (before transmit replace SYN->ESC SYN and ESC->ESC ESC, do the inverse after received) c) Flow Control. Nate, I'm sure iAP2 Link has a mechanism for this. But I suspect iAP1 is somehow weaker. Who knows ? Do I need to adopt XON/XOFF ? d) A sequence number in each message. How could I effectively exploit such a feature ?
As regards the max LEN allowed, I guess 2048 could be a good starting point (the same value used by iAP2 over bluetooth transport)
Gabriele
-----Messaggio originale----- Da: robert carlsen [mailto:robert@robertcarlsen.net] Inviato: giovedì 28 gennaio 2016 17:21 A: Richard A. Smith Cc: Gabriele Filosofi; bluetooth-dev@lists.apple.com Oggetto: Re: Designing a communication protocol
The last protocol I designed used Consistent Overhead Byte Stuffing (COBS) for unambiguous packet framing. I would agree that including a simple CRC is a good idea. I've experienced data corruption that would have been difficult to detect otherwise.
-Robert
// mobile //
On Jan 28, 2016, at 10:54, Richard A. Smith <smith@whoop.com> wrote:
On 01/28/2016 02:55 AM, Gabriele Filosofi wrote:
Please, can you share your expertise or give suggestions about this ? Regards,
I would encourage you to not drop your CRC or at least add some sort of simple checksum for your message. Yes, the bluetooth layer has some delivery and message verification but there's more to a system than just the BT layer. There's UART HCI to the BT stack, Queues inside the BT stack, and various methods of things reading the data on the other side. Any of those sections can silently lose/corrupt data and you won't have any way to tell.
I'd also encourage you to add a sequence number into your header. It may or not be useful in your actual protocol but when you are trying to debug out of order messages or completely lost messages you will wish you had it in there.
You might also consider byte stuffing so your STX will never show up in your byte stream without some sort of escape.
-- Richard A. Smith smith@whoop.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/robert%40robertcarlsen...
This email sent to robert@robertcarlsen.net
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com