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.
