The achievable shortest CPU blocking time and longest interval while being detectable by other BLE devices

[Hailang]

Assuming the system is composed of one device using nRF51822 and iPhone/PC, If we want nRF51822 detectable by iPhone/PC so that iPhone/PC can connect nRF51822 when they want, how short CPU blocking time and how long interval between two blocking time can we achieve?

Thanks!

[Ole Morten]

The CPU will be blocked for each radio event, either an advertising event or a connection event. These happen with user configurable intervals, advertising events every advertising interval and connection events every connection interval. The advertising interval will determine how fast it is possible to create a connection, while the connection interval will set a limit for maximum throughput.

The length of an advertising interval will be dependent on the size of the advertisement packet, and whether or not someone sends a scan request, which will be responded to with a scan response. The minimum time should be around 2 ms.

The length of a connection interval will be dependent on the data transmitted and the accuracy of low frequency crystal on both Central and Peripheral. If no data is transmitted and 20 ppm crystals are used, the time for a connection event should be a little less than 1 ms.

Edit: Logic analyzer screenshots added, for code that does a continuous GPIO toggle in the main loop, thereby essentially showing the blocking time. Advertising data is ~28 B, no data transmitted in the connection event. Time to run between advertising channels is ~0.2 ms, blocking time ~0.8 ms. Block in prepare is ~0.1 ms, block time last channel ~1 ms.

Connection interval is 500 ms, Central device is Master Control Panel. Main blocking is ~1 ms, prepare is ~0.1 ms.

Please note that this should be considered experimental data and not specification, just an example of how this can work in a specific application.

[Hailang]

Thank you for your quick reply, Ole.

Now I understand it better: In advertising event: P -> CPU_available1-> Ch37 -> CPU_available2 -> Ch38 -> CPU_available3 -> Ch39. The P(preparation), Ch37, Ch38 and Ch39 are durations those CPU is blocked.

• According to <S110_SoftDevice_Specification v1.1.pdf>, P<= 150us, Ch37/38/39 is 550~1300us for each channel (affected by the payload, and whether there is a scan request).
• According to the experiment shown here, the CPU_available1/2/3 are about 1.5ms/0.2ms/0.2ms. (as I understand, CPU_available1 is affected by t_ndist shown in <S110_SoftDevice_Specification v1.1.pdf> and not assured. CPU_available2/3 are always there and the duration requires experiment to know but kind of consistent.)

In connection event: P -> CPU_available -> data_transferring.

• According to <S110_SoftDevice_Specification v1.1.pdf>, P<= 150us, data_transferring is 900~5800 us (affected by the number of packets, the payload, whether encrypted or not and the accuracy of low frequency crystal on both Central and Peripheral).
• According to the experiment shown here, the CPU_available is about 1.4 ms. (as I understand, CPU_available1 is affected by t_ndist shown in <S110_SoftDevice_Specification v1.1.pdf> and not assured.)

With this understanding in mechanism, I can make relatively good estimation for the worst case about CPU available time and interrupt latency, and get specific data by doing similar test as the one you do.