January 2016 - Bluetooth-dev

Re: R: Designing a communication protocol
by Gabriele Filosofi 30 Jan '16

30 Jan '16

Great job Virendra. And what the throughput you achieved? Richard, I do not expect to see out of order messages. Nevertheless a seq number will allow the receiver to give back a Nak with the seq number of the missed/corrupted message it refers to, in such a way the sender can decide to retransmit. Robert, the COBS is very good stuff. Due to the fact the stuff()/unstuff() functions are pretty compact and localized, I could easily test both the COBS and the ESC methods with few effort. Now it's time to write down the specs. Sent using OWA for iPhone ________________________________________ From: Virendra Shakya <virendra(a)skully.com> Sent: Friday, January 29, 2016 8:01:18 PM To: Richard A. Smith Cc: Gabriele Filosofi; robert carlsen; bluetooth-dev(a)lists.apple.com Subject: Re: R: Designing a communication protocol In one of my apps that involved ble, I had designed a very simple protocol: - only one characteristic used - write - the central writes n bytes on this characteristic- with start byte and end byte - the sender puts all the packets in a queue (so I didn't need sequence number) - the receiver will assemble the packet back - again putting all the fragments in a queue and then re-assembling once an end byte is encountered It worked perfectly in my case. :) Sent from my iPhone > On Jan 29, 2016, at 10:09 AM, Richard A. Smith <smith(a)whoop.com> wrote: > >> On 01/29/2016 12:24 PM, Gabriele Filosofi wrote: >> >> d) A sequence number in each message. How could I effectively exploit >> such a feature ? > > If you can have out of order messages and need re-assembly then you use the sequence number. > > In some fully asynchronous protocols I've done there are multiple commands outstanding the sequence number is used to link the command response back to the original command. > > But the main use for me has been while doing protocol debugging. Gaps in the sequence numbers indicate bad things. > > -- > Richard A. Smith > smith(a)whoop.com > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/virendra%40skully.com > > This email sent to virendra(a)skully.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Lowest possible response time for single command?
by Craig Dooley 29 Jan '16

29 Jan '16

Hi Christian, The connection interval determines how often the two devices can talk over the radio, and the connection event length determines the number of transactions that can happen each connection interval. With a minimum of 20ms, you are correct that on average, you will be in the middle of the interval, so the time to send a command will be 10ms. If the command does not require a response, then you can send multiple commands in one connection interval. If the command does require a response, it will take two connection intervals per command (one for the request, and one per response). There are other factors that can affect things (queuing time in the radio, interference, other queued packets), but that’s a good place to start. - Craig > On Jan 29, 2016, at 5:10 AM, Christian Ridderström <christian.ridderstrom(a)gmail.com> wrote: > > Hi, > > I'm interesting in sending a command from an iOS device over BLE to a piece of hardware and wonder what kind of delay i could expect when trying to make it as fast as possible? > > From reading documents etc, I've understood that the lowest connection intervall for iOS is 20 ms [*]. And also that writing a characteristic without an acknowledgement is faster. So let's assume the iOS device is the central device, and that the app at some point in time initiates writing a characteristic without acknowledgement. Should we then expect the peripheral device to have received the value at say 1 ms to 20 ms later (uniformly distributed)? > > Is this correct, or could the delay be even larger? > > Can we make the delay smaller somehow? E.g., I think I've read that iOS can send up to four ... "packets" in one intervall, does this mean it's somehow possible to reduce the maximum delay to 5 ms, e.g. by writing the same command four times? > > Best regards, > Christian Ridderström > > [*] Unless it's a HID, in which case it's 11.5 ms. > > -- > Christian Ridderström, +46-70 687 39 44 > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/cdooley%40apple.com > > This email sent to cdooley(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: R: Designing a communication protocol
by Virendra Shakya 29 Jan '16

29 Jan '16

In one of my apps that involved ble, I had designed a very simple protocol: - only one characteristic used - write - the central writes n bytes on this characteristic- with start byte and end byte - the sender puts all the packets in a queue (so I didn't need sequence number) - the receiver will assemble the packet back - again putting all the fragments in a queue and then re-assembling once an end byte is encountered It worked perfectly in my case. :) Sent from my iPhone > On Jan 29, 2016, at 10:09 AM, Richard A. Smith <smith(a)whoop.com> wrote: > >> On 01/29/2016 12:24 PM, Gabriele Filosofi wrote: >> >> d) A sequence number in each message. How could I effectively exploit >> such a feature ? > > If you can have out of order messages and need re-assembly then you use the sequence number. > > In some fully asynchronous protocols I've done there are multiple commands outstanding the sequence number is used to link the command response back to the original command. > > But the main use for me has been while doing protocol debugging. Gaps in the sequence numbers indicate bad things. > > -- > Richard A. Smith > smith(a)whoop.com > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/virendra%40skully.com > > This email sent to virendra(a)skully.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: R: Designing a communication protocol
by Richard A. Smith 29 Jan '16

29 Jan '16

On 01/29/2016 12:24 PM, Gabriele Filosofi wrote: d) A sequence number in each message. How could I effectively exploit such a feature ? -- Richard A. Smith smith(a)whoop.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com If you can have out of order messages and need re-assembly then you use the sequence number. In some fully asynchronous protocols I've done there are multiple commands outstanding the sequence number is used to link the command response back to the original command. But the main use for me has been while doing protocol debugging. Gaps in the sequence numbers indicate bad things.

1 0

Re: Designing a communication protocol
by Robert Carlsen 29 Jan '16

29 Jan '16

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(a)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(a)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(a)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(a)whoop.com > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/bluetooth-dev/robert%40robertcarlse… > > > > This email sent to robert(a)robertcarlsen.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

R: Designing a communication protocol
by Gabriele Filosofi 29 Jan '16

29 Jan '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Lowest possible response time for single command?
by Christian Ridderström 29 Jan '16

29 Jan '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Designing a communication protocol
by robert carlsen 28 Jan '16

28 Jan '16

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(a)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(a)whoop.com > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/robert%40robertcarlse… > > This email sent to robert(a)robertcarlsen.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Designing a communication protocol
by Richard A. Smith 28 Jan '16

28 Jan '16

On 01/28/2016 02:55 AM, Gabriele Filosofi wrote: Please, can you share your expertise or give suggestions about this ? Regards, -- Richard A. Smith smith(a)whoop.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com 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.

1 0

Designing a communication protocol
by Gabriele Filosofi 28 Jan '16

28 Jan '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0