Is it possible to update multiple characteristics in a single connection interval?

[Anonymous]

I'm currently trying to develop a high data rate application using BLE. I had intended to send data over bluetooth at 100 Hz. The amount of data in each packet is about 18 bytes. The throughput should not be an issue.  However if I place a requirement that says I must connect 100 times per second to transfer data that means I have a connection event every 10 ms. If the minimum connection interval that means nothing else can be allowed to begin a connection interval. My question is can I write to a few small characteristics as well as this data characteristic and trust the lower layers to push it all through?

       

Otherwise I can just half the transfer rate and buffer the data, but I'd like to get the data to the central as soon as possible so 100 Hz is preferable.

[HeLi_263931]

why don't you keep the conection active, and just send the data when needed (via a notification)?

[Anonymous · Accepted solution]

Hi Nate,

   

If you use notifications (unacknowledged transfers), then you can push more than one update per connection interval from the peripheral to the central. If you need do move data in the other direction, from central to peripheral, you can achieve the same thing with the write-without-response (a.k.a. write-command) operation. The best efficiency will be achieved if you bundle all data that must be updated on the same interval (e.g. 100 Hz) into the same characteristic, if it will all fit.

   

Theoretically, you are allowed to send one unacknowledged packet every 1.25ms. However, most platforms cannot maintain this rate due to buffering and processing requirements, even assuming perfect RF conditions. You should not have any problem achieving an average of one unacknowledged packet every 10 ms. However, if the central device is a smartphone, note phones usually restrict the number of incoming packets per connection interval in order to help ensure that one peripheral cannot dominate the link if multiple devices are connected. I have read anecdotal evidence that iOS, for instance, will not accept more than four packets per interval. With a fast enough interval, this should still not pose a problem for 100 Hz updates, but keep that restriction in mind.

   

Jeff

[Anonymous]

@ hli

   

I never disconnect. Maybe I just have a fundamental misunderstanding of the low level BLE operation, but I was under the impression that when data is to be written it initiates a connection event wherein the data is transferred. This connection event exists for a set amount of time that must not be less than the minimum connection interval or greater than the maximum connection interval. I am using notifications to transfer the data, but I apparently do not understand how those change the picture I described above.

       

@jrow

   

I am using notifications to push the 100 Hz data through a single characteristic(it all fits inside just the one).  I have been limiting to write with response when communicating from the central to peripheral, but I couldn't seem to figure out how to receive the no response write without causing an error. I'll go back into the event handlers and figure out how to get that implemented. However, I don't expect to send anything at any appreciable frequency from central to peripheral.

   

So, if I'm understanding you correctly using notifications when writing from peripheral to central and using write without response when writing from central to peripheral allows me to update single characteristics at a time, but at a higher frequency than would be possible if considering the minimum connection interval for regular writes?

[Anonymous]

Hi Nate,

   

Your understanding is correct. Unacknowledged transfers are inherently faster for two reasons. First, there's no reply packet required, which saves 50% immediately (each packet regardless of payload uses one connection timeslot, i.e. 1.25ms segment). Second, when acknowledgements are required, the ack has to wait until the next connection event (i.e. whatever the connection interval is set to).

   

So, if you assume a 20ms connection interval with an iOS device, you can send four unacknowledged packets every 20ms, or one packet every 5ms. But in the acknowledged case, you would need the first 20ms interval for the transfer and then the second 20ms interval for the acknowledgement, for a full round-trip time of 40ms for a single transfer with the same maximum per-packet payload as before. This is a potential throughput difference of 8x.

   

Jeff