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:email@hidden]
Inviato: giovedì 28 gennaio 2016 17:21
A: Richard A. Smith
Cc: Gabriele Filosofi; email@hidden
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 <
email@hidden> 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
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Help/Unsubscribe/Update your Subscription:
>