Indoor BLE Range Improvements

[Ziga Miklosic]

Hello everyone!

Background

We are in development phase for indoor household appliances with many wireless connected entities. There is a requirement to support following topology: 8 battery powered devices and single mains powered device. As the target environment is indoor and low rate of data exchange (low bandwidth) is needed, we agree to test out BLE5 LE CODED PHY (S=8, 125kbit/s) aka. LongRange, using Minew MS88SF3 module that features nRF52840 chipset

So, we prepare a simple mockup test application to check out how the system will behave in real-life scenarious. Test application was very simple, central BLE device scans continuously and stops after all 8 connections are established. Peripheral BLE devices advertise when not in connection. With such approach system shall always converge to have all devices connected, as if one device gets disconnected advertising/scaning shall re-started and the drop connections should re-established. Every second 64 bytes of dummy data were exchange between central and peripheral device based on server-initiate update (notification type). Tx power for adverising and connection was set to 8dBm. Connection interval was set to 1500ms, SlaveLatency to 2 and Supervision Timeout to 15000ms. Well, it works perfectly on a desk! 

After couple of tests with single BLE central device and 8 peripheral devices on real life scenarios (each developer took mockup system home and tested) we found out that stability/reliability of the BLE connection was not consistent. As expected, house construction and size did have a great impact on overall system. In one case there was zero problems, devices was connected immediately after power-on and connections was stable over one week of measurement period. On the other cases there was quite the opposite. Some of the devices did not connect at all, some of the devices were connected and couple of hours later was permanently disconnected.  

Typically, house construction that we plan to use the system consist of bricks and reinforced concrete slabs. 

Platform description:

• IC:               nRF52840
• Module:       Minew MS88SF3
• SDK:            nRF5_SDK_17.1.0_ddde560
• Softdevice:  s140_nrf52_7.2.0 
• IDE:             SEGGER Embedded Studio for ARM Release 7.10a Build 2022121504.52072
• OS:              Windows 10

Test Setup

Questions

1. As posted on other DevZone threads improving BLE range from SW point of view boils down to TX power settings (and PHY afcourse, as mentioned we are using CODED PHY). So all we can do in SW to increase BLE range is to adjust TX power output? How about connection/advertisement parameters, do they play a role in BLE range?
2. How can we increase reliability/stablity of BLE connections indoor?
3. Are there any general BLE parameters guidence for indoor applications?
4. What connection/advertisment parameters do Nordic recommends to achieve stable/reliable BLE CODED PHY connections, without consideration of power consuption? 
5. Should we considering making a non-battery powered repetitor devices in order to achieve stable/reliable BLE connections when used in larger houses?

Additional

Interesting effect arose at larger houses where it was observed that some peripheral devices block other from being connected. Moving most distant peripheral device closer to central device did not only cause to re-establish connection with that device, but also triggers re-connection of other peripheral devices. It seems as it some peripheral device blocks other from being connected. At least those were observations.

So what can be a couse of that? Can that be test application logic, that after connection is drop peripheral start advertising? Do you have any recommendations for mitigation of that effect?

Thank you for all the help!

BR, Žiga

[Sigurd]

Hi,

As posted on other DevZone threads improving BLE range from SW point of view boils down to TX power settings (and PHY afcourse, as mentioned we are using CODED PHY). So all we can do in SW to increase BLE range is to adjust TX power output? How about connection/advertisement parameters, do they play a role in BLE range?

Correct, the main factor is TX-power. Make sure that both sides of the link uses the highest possible tx-power for max range. Other parameters plays a more important role for reliability and discoverability.

Are there any general BLE parameters guidence for indoor applications?

No.

What connection/advertisment parameters do Nordic recommends to achieve stable/reliable BLE CODED PHY connections, without consideration of power consuption? 

How can we increase reliability/stablity of BLE connections indoor?

I believe having a conflict-free scheduling could improve the reliability somewhat, since then no connection events will be skipped. We have page about suggested parameters here. https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/suggested_intervals_windows_s132.html

1) What is the value of NRF_SDH_BLE_GAP_EVENT_LENGTH in your application(for both the central and peripheral) ?

2) I see that you have scan interval == scan window. So you are trying to use the radio to scan 100% of the time, so this might cause connection events to be dropped. I suggest reducing the scan window when you have 1 or more connections. And only use scan interval == scan window when you don't have any devices connected.

3) You can also try to increase the supervision timeout even more. Max permitted is 32sec.

Should we considering making a non-battery powered repetitor devices in order to achieve stable/reliable BLE connections when used in larger houses?

That could an option yes. We have an example for that here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/ble_sdk_app_rscs_relay.html , alternatively some mesh technology might be suitable as well.

BR,

Sigurd

[Ziga Miklosic]

First, thank you for quick response!

Today I'm out of office and will try to test all recommendations ASAP. So, expect more feedback at the end or start of next week. 

 

Answers:

1) What is the value of NRF_SDH_BLE_GAP_EVENT_LENGTH in your application (for both the central and peripheral) ?

NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 6 in our test application. We didn't pay to much attention to that settings and will need to look into deeper. What value do you recommend for given scenario?

 

2) I see that you have scan interval == scan window. So you are trying to use the radio to scan 100% of the time, so this might cause connection events to be dropped. I suggest reducing the scan window when you have 1 or more connections. And only use scan interval == scan window when you don't have any devices connected.

Will try it out, expect feedback end of week. 

 

3) You can also try to increase the supervision timeout even more. Max permitted is 32sec.

Yes, we'll adjust also that. Does increasing supervision timeout really gives us higher reliability/stability of the connection?

 

Can you also comment a little bit of "Additional" chapter? Have you ever heard or observed described effect? Do you have any technical analysis/explanation of that?  

[Ziga Miklosic]

 For now we have only touch scanning parameters and first preliminary results seems promising. We've changed scanning parameters from 100ms/100ms (window/interval) to 100ms/1000ms. 

During that test central device was collecting connection state and RSSI values of each individual peripheral device. Measurements were done with old scanning settings (100ms/100ms) and with new (100ms/1000ms) to make back-to-back comparison. We assume that connection event skipping effect can be observable via RSSI sample rate. If RSSI sample rate drops, then we can conclude that connection events are skipping due to scheduling conflict.

Test results 

Result of scanning parameters of 100ms/100ms. Measurements were done couple of times and repeatablity of tests was high. Connection events start to drop after 80 sec into test and after that device starts to lost connection one at the time. At the end no devices were connected. 

Results of changed scanning parameters to 100ms/1000ms. Connection was stable, there was no sign of connection event skipping. We conclude that scheduling conflict must be reduced a lot or completely solved.

Measurement conclusion

Scanning parameter significantly changed multilink BLE connection stability. As it can be seen from test results connection events seems to be more regular and determine. Meaning that scheduling conflict was mitigated or probably complete removed. 

Further questions

1. Is a measurement approach valid to confirm connection event skipping (scheduling conflict)? Do you think this is a proper way to observe scheduling conflict? Or do you have a better way to measure/observe that?
2. Our dev team have done a couple of tests at our houses with 100ms/100ms scan parameters and in some cases the system works as expected. For example, at medium size house system work OK , but when moved to larger house system just does not work (very likely as you mention, due to scheduling conflict). So, my question here is, why in some cases scheduling conflict does not have any impact and in order cases it ruins complete system?
3. According to conflict-free scheduling theory connection interval must be defined according to following equation: , meaning we need to know connection event time duration. Where we can get connection event duration for:
   1. CODED PHY, send 64 bytes. t_event =?
   2. CODED PHY, send 240 bytes. t_event =?
   3. UNCODED 1M PHY, send 64 bytes. t_event =?
   4. UNCODED 1M PHY, send 240 bytes. t_event =?
4. What is the recommended reserve "t_ScanReserved" time value? For 1sec connection interval, is it enough to have 100ms reserve? 

[Ziga Miklosic]

I might found the answer to question 3. 

From S140 SoftDevice Specification V2.1 (page 78, chapter 15.10 Suggested intervals and windows):

If I understand that correctly, connection event duration is defined by the number of packet pair sended, where packet pair is 27 bytes in size. Meaning that when sending 64 bytes using CODED PHY:

         t_event = ceil( 64byte / 27byte ) * 7.5ms = 3 * 7.5ms = 22,5ms

Is my understanding correct? Is that calculation OK?

[Ziga Miklosic]

Hi Sigurd , 

I hope you're doing well.

It has been over a month since I posted my questions seeking support, but unfortunately, I haven't received any responses yet. I kindly request your assistance and guidance. Your help would be greatly appreciated.

Thank you!

BR, Žiga

[Ziga Miklosic]

Update regarding NRF_SDH_BLE_GAP_EVENT_LENGTH parameter.

I verified with nRF Sniffer that with value of 40 for NRF_SDH_BLE_GAP_EVENT_LENGTH parameter (46ms for each connection) is sufficient to exchange 200 bytes of data in single connection interval.

Wireshark sniffed file:

Testing_DLE__30_06_2023.pcapng

Wireshark packet info for write: 

Wireshark packet info for notification:

I believe that gives me connection event time duration:

t_event = 46ms

And for connection interval of 1000ms, time left for scanning with 8 connections is:

t_scan_window + t_scan_reserved >= 1000ms - ( 8 * 46ms) = 632ms

Is my understanding correct? Is that calculation OK?

Thank you for the help!

BR, Žiga

[Ziga Miklosic]

Hi Sigurd , 

I hope you're doing well.

It has been over a month since I posted my questions seeking support, but unfortunately, I haven't received any responses yet. I kindly request your assistance and guidance. Your help would be greatly appreciated.

Thank you!

BR, Žiga