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]

In addition to Nordic's resources, I found this overview to be a very useful BLE primer.

[endnode]

I believe the timings you require are in general achievable but you will have problem to synchronize them. Also any packet loss will break your data flow, won't it? BLE connection interval is more or less fixed so unless it perfectly fits to your timing scheme it will drift away and break your ESB availability. But I might be missing the whole point of this high-precision timing in your solution (I'm also very skeptical you will achieve any precise timing between things over radio down to the clock cycle - or to be specific that you will achieve it for longer then few periods = hundreds of milliseconds - but that's just my feeling based on some experience with embedded systems and radio, I haven't run any practical feasibility with such strong requirements so you might be OK).

[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.

[endnode]

Well that's part of my worry, you have never really access to LL through the SD API, except radio_notification event handler...

[abc]

@endnode. Yes, I see from the SD 132 v4.1 spec in section 16.1 that interrupt latency can be up to 1us even when SD is disabled. Therefore, I guess tasks needing clock cycle level accuracy will need to be triggered via the PPI as much as possible.