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.

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