• State Verified Answer
  • Replies 8 replies
  • Subscribers 67 subscribers
  • Views 4361 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 100579
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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!

  • 0 in reply to Ole Morten

    Hi Ole, I have one more question:) I saw "Table 14 Radio Notification timing ranges" in <S110_SoftDevice_Specification v1.1.pdf>. t_evnt is: 550 to 1300us Advertiser - 0 to 31 bytes payload, 3 channels). P is: <=150 us. According to this, for an advertising event, the blocking time can be P+t_event: 700us ~1450us. The minimum 700us is less than 2ms. Does your 2ms count a scan response in? or I have some misunderstanding here? Thanks.

  • 0 in reply to Ole Morten

    Please take a look at the screenshots I added to my answer here. 550 µs is the time for one channel, my 2 ms is total time over all channels, excluding the time you get to run in between.

    If you need specific data on this, I'd recommend you to do a similar test to the one I did, just making a GPIO toggle in main and capture the pin with a logic analyzer.

    The sequence will always be 37, 38, 39.

  • 0 in reply to Ole Morten

    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.

Related