Re: Designing a communication protocol
Re: Designing a communication protocol
- Subject: Re: Designing a communication protocol
- From: robert carlsen <email@hidden>
- Date: Thu, 28 Jan 2016 11:20:46 -0500
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
> email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bluetooth-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden