Hello,
I have a device that I want to operate on the lower range of RSSI (but still around -80dBm and have problems with disconnect. I would like to understand if there is any software change I can change to improve connection reliability. See attached source file for my BLE class.
Much appreciated!
Jens
FILE:
Hi Jens,
There are some generic things you can do to improve performance under low signal conditions. Different products has different needs though, so all may not be auitable.
Einar
Thanks for quick reply:
1) OK - I think i have maxed out supervision timeout according to Apple spec (18sec)
2) OK - Coded PHY is not compatible with iOS as I understand it.
3) FOLLOW UP - How can I shorten the package size even further? The payload is only 4 bytes. What setting are you refering to? When analyzing the packages in NRF Sniffer the "send handle value notification" is 38 bytes (from peripheral).
4) FOLLOW UP - NRF52840 max at 8db as you say, do you know what iPhone is transmitting at? The reason for my question is that it would bring some light on wether or not a relay device could fix the problem.
Other questions:
5) I have tried listening to music using airpods at the exact same position that my device is, and that seems to work. Perhaps this implies that when the iphone is communicating with airpods, they increase TX power?
Note I am using a Raytec based NRF52840 board, so the antenna config should be OK.
Hi,
jber1 said:1) OK - I think i have maxed out supervision timeout according to Apple spec (18sec)
That is good. But note that the relationship between supervision timeout and connection interval is important. If you shorten the connection interval and keep the same supervision timeout, that means that there are more connection events within the spervision timeout, so more packets has to be lost in order to trigger a timeout (there are more chances to get a packet successfully transfered).
jber1 said:3) FOLLOW UP - How can I shorten the package size even further? The payload is only 4 bytes. What setting are you refering to? When analyzing the packages in NRF Sniffer the "send handle value notification" is 38 bytes (from peripheral).
If the actual data is 4 bytes this is allready wery short, so there is not much you can gain here. If packets were much longer you could have considered splitting the data and seding as two notifications instead.
jber1 said:4) FOLLOW UP - NRF52840 max at 8db as you say, do you know what iPhone is transmitting at? The reason for my question is that it would bring some light on wether or not a relay device could fix the problem.
I do not know, unfortunately. I suspect Apple may be changing the Tx power dynamically to optimize range and power consumption, but I do not know the details. Note that there is a limit to how high it can be though, as for instance in Europe the regulatory limit is 10 dBm (20 in the USA).
jber1 said:5) I have tried listening to music using airpods at the exact same position that my device is, and that seems to work. Perhaps this implies that when the iphone is communicating with airpods, they increase TX power?
Yes, that could be. But I assume the Airpods are using Bluetooth classic for Audio, which is very different for BLE (it also includes a simple forward error correction). Maybe there is also some propritary stuff on top that improve this further when using Apple devices in both ends, but that I do not know.
Hi,
I have been continuing work on this, but has not made any big progress. What surprised me most is the following:
- I have tried Coded PHY (the peripheral/central_hr_coded examples) to get an idea if would perform much better. For each heart rate I mesaure RSSI and they are about -80 dBm, not good for non coded BLE, but I would expect coded phy to perform without any issues, but I still get disconnects
- in the central I have conn_params->timeout = 1600, do i need to set this in peripheral somehow as well?
- A audio headset can stream music from the exact same position (not airpods). and yes they use FEC, but coded phy should do that as well?
Any ideas are welcome, otherwise I have to consider switching to some other standard, which I would like not to...
0> 00> [00:02:02.477,844] <inf> main: scan_filter_match: Filters matched. Address: C4:51:17:91:F5:5F (random) connectable: yes 00> 00> [00:02:02.480,529] <inf> main: scan_filter_match: Connection pending 00> 00> [00:02:02.584,625] <inf> main: connected: Connected: C4:51:17:91:F5:5F (random), tx_phy Coded, rx_phy Coded 00> 00> [00:02:03.388,397] <inf> main: discover_hrs_completed: The discovery procedure succeeded 00> 00> [00:02:03.388,519] <inf> main: discover_hrs_completed: [SUBSCRIBED] 00> 00> [00:02:04.190,124] <inf> main: notify_func: Heart Rate Measurement Value: 103 bpm 00> 00> [00:02:04.190,490] <inf> main: notify_func: RSSI: -71 dBm 00> [00:02:05.190,185] <inf> main: notify_func: Heart Rate Measurement Value: 104 bpm 00> 00> [00:02:05.190,521] <inf> main: notify_func: RSSI: -79 dBm 00> [00:02:06.188,385] <inf> main: notify_func: Heart Rate Measurement Value: 105 bpm 00> 00> [00:02:06.188,751] <inf> main: notify_func: RSSI: -80 dBm 00> [00:02:07.188,446] <inf> main: notify_func: Heart Rate Measurement Value: 106 bpm 00> 00> [00:02:07.188,781] <inf> main: notify_func: RSSI: -80 dBm 00> [00:02:08.188,385] <inf> main: notify_func: Heart Rate Measurement Value: 107 bpm 00> 00> [00:02:08.188,751] <inf> main: notify_func: RSSI: -78 dBm 00> [00:02:09.188,385] <inf> main: notify_func: Heart Rate Measurement Value: 108 bpm 00> 00> [00:02:09.188,781] <inf> main: notify_func: RSSI: -78 dBm 00> [00:02:10.188,385] <inf> main: notify_func: Heart Rate Measurement Value: 109 bpm 00> [ 15 min later] 00> [00:18:18.475,708] <inf> main: notify_func: RSSI: -83 dBm 00> [00:18:18.922,943] <inf> main: disconnected: Disconnected: C4:51:17:91:F5:5F (random) (reason 0x08)
Hi,
jber1 said:- in the central I have conn_params->timeout = 1600, do i need to set this in peripheral somehow as well?
It should not be needed. It is the central that decide the connection parameters (including timeout), but it is possible for the peripheral to request a different set of paramteers, and then it depend on the implementation if the central use it or not. If y ou are not sure what is used, you could add some logging on connection parameter updates, or check with a sniffer.
jber1 said:- A audio headset can stream music from the exact same position (not airpods). and yes they use FEC, but coded phy should do that as well?
There are other factors that can play a part as well. Which Tx power is used for Audio? If it is say 10 dBm, thaty would increase range. And imporant, what hardware are you using? Is it a DK or a custom board? If it is a custom board, has it been reviewed and possibly tuned by Nordic? If it is not properly tuned, that can significantly affect the range.
I use two Raytec DK boards, so I assume that should be fine. I am not sure what TX audio is using since I have no control over that code.
But regardless, the RSSI measurement is from the board, and my impression was that coded phy should handle RSSI of even -100dBm. I don't understand that part.
I use two Raytec DK boards, so I assume that should be fine. I am not sure what TX audio is using since I have no control over that code.
But regardless, the RSSI measurement is from the board, and my impression was that coded phy should handle RSSI of even -100dBm. I don't understand that part.
Hi,
Yes, if perfectly tuned, the sensitivity is about -100 dBm (+/-, dependin on 125 or 500 kbps mode). But this is under ideal conditions, so if there are interference or non perfect matching you may not get as good results. Regarding the Raytec DK boards, I would assume that they have properly tuned those, but I do not have data on how well they perform, so it could be worth checking with them or comparing with nRF52840 DKs in the same environment if you have.
Hi,
I finally purchased two NRF52840DK boards, installed the central_hr_coded and peripheral_hr_coded. Went out to a open field and tried it. Unfortunately I do not come even close to the 100dBm (lowest i measured was -89dBm, so little better than the Raytec, but again, this was in an open field, not in a building.
I have tried using ESP32 to compare using WIFI, and the signal robustness is much better. I assume this is because they can go up to +20dBm in signal strength making a huge difference.
Any final ideas what we could do to improve things? Would you think an external antenna will make a significant impact, or would that only give a few + on the dBm compared to PCB antenna?
Thank!
Did you measure the sensitivity or the range? How did you measure? As you write, if you are testing other devices with +20 dBm that will have a significant impact on range.
I do not expect you will get a significant improvement with a different antenna (unless you were to use directional antennas for stationary devices)
Both - the sensitivity was measured by outputting the RSSI value.
Range was measured by estimating distance after walking away with one of the devices.
I estimate that i get disconnects starting from 50m.
For reference, the field is an outdoor horse riding arena.
Hi,
jber1 said:Both - the sensitivity was measured by outputting the RSSI value.
You cannot measure the sensitivity like this. That has to be done in a controlled setting where you know the actual power and measure if reception is possible or not. The RSSI estimate in the radio is only valid down to -90 dBm. See RADIO electrical specification.
jber1 said:I estimate that i get disconnects starting from 50m.
That is an unexpectedly short range in an open environemnt if transmitting with + 8 dBm (?), but it depends a lot on other factors as well like RF interference and connection parameters (how many packets you can loose before a disconnect). For reference, see this post.
