Using BLE like ESB

[abc]

I have an application with hard real-time requirements (i.e. down to the clock cycle). My topology and desired timeline can be seen below. Concerning the timeline, I believe I will not have any issue guaranteeing interval-to-interval synchronization among PTX and PRX devices by using PTX packets as a timing beacon. Further, real-time can be achieved by verifying that ESB packet payloads and ACK retransmit attempts do not exceed the allocated time period.

However, I am wondering if it is possible to use BLE in the same way I intend to use ESB. Specifically, I would like the BLE peripheral (running S132) to be a timing master that the central (smartphone) syncs its write command 'ACKs' to. Otherwise, e.g. two +/-20ppm clocks could have a 40us/sec mismatch. Additionally, I would like the central to be able to send its write command in quick succession (e.g. pre-loaded packet configured to be sent at the link layer). Because the minimum transmit window for a BLE connection event is 1.25ms, I'm hoping both notification and write could be completed within 3-4ms. Assuming 20B payloads, is this possible?

If this question is too application specific, I can open up a support ticket instead.

---

Edit: I did read the following from the BT v4.2 spec 6.B.4.5.1 "Connection Events", which leads me to believe I will need to the change the peripheral (BLE slave) and central (BLE master) roles in my topology in order to meet the requirements:

The start of a connection event is called an anchor point. At the anchor point, a master shall start to transmit a Data Channel PDU to the slave.

Figure 4.13 of 6.B.4.5.4 further illustrates the master initiating the connection event:

T_IFS can be determined from 6.B.4.1:

The Inter Frame Space is designated “T_IFS” and shall be 150 μs.

Assuming max packet size of 37B (BLE 4.0 and 4.1) and 1Mbps throughput, that would result in a total connection event time of 2*(37*8) us + 150 us = 742us not including radio startup/shutdown. This answer confirms that calculation. Additionally, Section 16.3.3.4 of the SD 132 v4.1 spec gives a worst case send+receive central event processing of 250us (see calculation in document). Even though a fair amount of this processing may overlap with the 742us calculated above, we can add them together to get a conservative worst case estimate of about 742+250=992us overall, though there still could be some variability based on GATT/ATT/SMP SD operations. Therefore, a BLE central send+receive event should be able to occur well within the desired 3-4ms window, and perhaps even within 1ms.

Concerning BLE synchronization, I see in 6.B.4.5.7:

Because of sleep clock accuracies (see Section 4.2.2), there is uncertainty in the slave of the exact timing of the master’s anchor point. Therefore the slave is required to re-synchronize to the master’s anchor point at each connection event where it listens for the master.

[abc]

@endnode Concerning meeting the real time requirements, I plan to give each segment in the timeline a fixed number of 'master timer' clock cycles per period. Segment time should be long enough to give some buffer and may accommodate a predetermined number of re transmit attempts. Ultimately, all relevant nodes should have completed their activities and be inactive by the time the segment timer expires.

Because the master timer will be initiating all radio comms (as ESB PTX or BLE LL master), I don't expect there to be any drift on master radio events, though the PRX/slave radios will need to continually sync themselves. However, I guess I still need to investigate how the high level API commands accepted by Soft Device map to link layer activity, e.g. I would want to control the number of re transmit attempts and verify that BLE activity only occurs in its allocated segment.