connection latency from nRF5340 deep sleep to iOS 18

[Kirak]

I am trying to keep nRF5340 in sleep state, and wake it up when there's a user input (e.g., button) and send a packet as fast as possible to iOS18. What would be the latency for sending the first packet to iOS, including making a connection to the phone? We assume the device is already paired with the phone.

I asked the question to chatGPT and it says the bottleneck is iOS scanning, which may take a couple seconds, but I'm curious real measurements form experts:

https://chatgpt.com/share/e/68386486-e9ec-8002-af8b-7924ba4d6fe4

Thanks in advance!

[Sigurd Hellesvik]

Hi,

I asked the question to chatGPT and it says the bottleneck is iOS scanning, which may take a couple seconds, but I'm curious real measurements form experts:

Did you know that we have our own AI, trained on nRF stuff specifically, which may be more useful than ChatGPT for this:

I am trying to keep nRF5340 in sleep state, and wake it up when there's a user input (e.g., button) and send a packet as fast as possible to iOS18. What would be the latency for sending the first packet to iOS, including making a connection to the phone? We assume the device is already paired with the phone.

I recommend that you see https://academy.nordicsemi.com/ and specifically our Bluetooth Fundamentals course over there to learn about Bluetooth.

What would be the latency for sending the first packet to iOS, including making a connection to the phone?

It depends. What kind of sleep do you need?
Alternatively, how low current do you need from your sleep state and how often do you expect to wake up?

Regards,
Sigurd Hellesvik

[Kirak]

Thanks! The Nordic AI chatbot is great, very helpful.

After talking with the chatbot, and inspecting datasheet, it seems like the reconnect latency from deep sleep is dominated by iOS discovery scanning frequency not by Nordic wakeup. I'll keep digging (with real experiments) since a lot of iOS things are not well documented, their policy is pretty dynamic and hidden.

[Vidar Berg]

Hello,

There is generally a trade off between low latency and low average current. But you can maintain a very low (relatively) average current even if the devices are allowed to remain connected. Please try our online power profiler at  Online Power Profiler for Bluetooth LE.  Here you can estimate the expected current draw under various condition and states (connected vs non-connected etc.,) Note: the latency will be more consistent in the connected state as you will not rely on the iOS discovery process. 

[Kirak]

Very interesting, thanks! I put some params in the online tool, e.g., connection (peripheral), and the current is pretty low 40 uA. 

Does this mean the entire nRF5340 can go this low while keeping BLE peripheral connection to iPhone? or is there extra load from non-BLE part of nRF that needs to be awake?

[Vidar Berg]

Yes, the estimate includes the total system current and with the resources needed to maintain the BLE link alive. The FW application will automatically enter System ON mode (sleep) between BLE protocol events.