Using BLE like ESB

RE: Using BLE like ESB

ovrebekk — Tue, 01 Aug 2017 07:19:33 GMT

I doubt very much that you will be able to get the same timing accuracy over a BLE link as you can get with ESB.

The problem with BLE is that you can't know for sure how much delay there will be between uploading a packet, and the packet being received on the other side. You might be able to estimate when the connection event occurs, but the BLE link layer don't provide any information about possible retransmits, so you don't really know the exact time at which your packet is sent and received.

I think the most reliable solution would be to send a timing beacon at regular intervals from your timing master, over ESB, with retransmits disabled. For each timing beacon you can update the payload with accurate timing information, and if you send a bit more of them then you need then it should work fine even if the PRX's don't receive all the beacons (this has to be calculated based on the accuracy of your crystals, and the accuracy that you need).

Best regards
Torbjørn

RE: Using BLE like ESB

abc — Sat, 29 Jul 2017 22:25:13 GMT

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

RE: Using BLE like ESB

endnode — Sat, 29 Jul 2017 15:21:25 GMT

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

RE: Using BLE like ESB

abc — Sat, 29 Jul 2017 14:42:17 GMT

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

RE: Using BLE like ESB

endnode — Sat, 29 Jul 2017 09:05:38 GMT

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

RE: Using BLE like ESB

abc — Fri, 28 Jul 2017 21:21:48 GMT

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