why don't you keep the conection active, and just send the data when needed (via a notification)?
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.
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.
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?
1 of 1 people found this helpful
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.