What BLE configuration is IDEAL for getting data within 450msec

[jayesh]

Hello All,

I have a requirement where temperature Sensor is collecting temperature data constantly.  If temperature data is changed by at least 10% from previous value. When this change occurs, if the phone is nearby, the data must be delivered to the phone within 450msec. 

For Above requirement I am bit confused between this two approach, 

Approach 1) Phone always connected when nearby. Configure Sensor as Peripheral mode and keep it in continuous connection (Bonded) with Phone. For sending data within 450Msec i will keep Min Connection interval as 100 and Max connection interval as 400 and Slave latency to value for saving power i:e 5. So keeping Connection interval 450Msec ,Slave latency 5 and Rx/Tx payload to 20, Device consumes around 5.1uA. Refer https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble This satisfies above scenario where i want data within 450msec. But here I have to keep Peripheral device always connected to Phone. Not sure if this is a good approach.

Approach 2) Increase ADV rate for sending fast. Configure Sensor as Peripheral and keep on Advertising at 1000Msec. If there is change in sensor data ADV will switch too Fast mode for example 20Msec for next 1 min. Once new sensor data are available then in ADV frame will raise flag. Based on new ADV frame flag phone will decide too connect with sensor and collect data. Here also connection interval and other parameters will be same as above scenario. But here I am not sure if this whole thing can complete within 450msec. Usually how long it takes for establishing a connection ?

 

Is there any other approach I can use if not above then.

Your inputs are highly appreciated. 

Regards,

Jayesh

[daviddedwin]

Approach 2 is likely slower and has more variance in performance across multiple phone OSes and OS versions.
Connection establishment can take a significant amount of time which will depend on the scan interval and window of the phone scanner.
When the phone app is running in the background, it is likely to get less scan bandwidth and takes more time to establish the connection.
I would expect this connection to be established in 100s of milliseconds in the best case (when app is in background and scan duty cycle is usually 1%), then the link must be encrypted which can take about 3-5 connection events (60ms to 100ms on a 20ms connection interval), then the data can be sent as a Handle Value Notification.

(if your link is not encrypted and GATT caching is not present, you will hit close to 1500ms to 2000ms for each connection as service discovery will run for each connection, this can be avoided by pairing the phone and the sensor, which will use an encrypted link)

I think Approach 1 has less variance across phones and the sensor should always attempt to get connected and keep the sensor connected to the phone. Slave latency turned on, devices are paired(to get an encrypted link). You most likely want to have a margin of error so you would have a connection interval that is lower than 450ms so the link does not get disconnected due to the clock drift as you have a radio sync only every slave latency X connection interval when there is no data to transmit, likely more of an issue when using the RC for the low frequency clock and will be worse if the sleep clock accuracy of the phone is also bad (like 500ppm). You most likey have to check the min/max connection interval to be used. Can use the PPCP (Preferred Peripheral Connection Parameters) to signal the phone on your required link params but will have to watch to verify that the OS did actually do the link params update and implement fallbacks when it does not.

I would suggest Approach 1. It has its own fiddly problems to deal on slave latency with but will have less variance across phone OSes and OS versions.

[jayesh]

Hello David,

I really appreciate your Prompt response. 

Even I personally think Approach 1 makes more sense as whenever there is change in data and if its already connected. Then that can easily send data within 450msec. 

So if I send Min connection interval as 300msec and Max Connection interval 400msec Should that be OK because right now I don't have any Phone OS information? At same time I also need to think on power consumption. 

If you don't mind can you explain or share info What happens when Central tries to connect with Peripheral. What all packets are exchanged. 

Thanks,

Jayesh

[daviddedwin]

Notes:
I think depending on the phone OS the max interval is chosen over the min interval
Look at the Apple guidelines for picking the numbers, https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf and as usual there will be differences between the Android and Windows folks but you should be able to pick some intervals that work.

This is what happens on the phone side after the device and phone have established the initial relationship(i.e. this is a re-connect):

Scan for connectable advertising (back ground scan duty cycle ~1% and foreground scan can be much larger )
Connect with connect request
If GATT caching is not present and If devices are not bonded
         - Do Service Discovery and then enable the Characteristic that will send Handle Value Notifications
If Devices are bonded - Do encryption procedure
Wait for previously subscribed Notifications/Indications

Please accept my answer and give it an upvote if this is helpful.