Coded vs 1Mbps PHY performance evaluation. Feedback requested

[mkuiken]

Hello,

I've been looking into the performance of the coded PHY (S8) to see if it fits the needs for a product we intend to make. All research and documentation I found about the long range feature of BT5 did not focus on relevant aspects for our situation. I would like to get some feedback on the results of the tests I have done with coded and 1Mbps PHY in a connected and non-connected scenario.

Let me first elaborate a bit about the details of this product so it's clear what the requirements are with regards to the Bluetooth communication.

The idea is to make an energy meter which send its captured data to some other device. This other device can then use the captured energy data for control purposes. For installation convenience the communication between both devices needs to be wireless. As being used in houses/buildings/vehicles the wireless communication should be as robust as possible, though this is difficult to quantify.

The energy data consist of Power, Voltage and Current (each 12 bytes payload) and is time critical. The maximum latency should not exceed 300ms (but preferred is below 100ms). The Power data should be received at a minium of 4Hz and the Voltage/Current should be received at a minimum of 1Hz. As there is no constraint on power usage of both devices, data may be transmitted at a higher rate than 4 Hz (to increase robustness).

As said, I've been testing the connected scenario and the non-connected scenario by using the nRF52840 PCA10056 both for sending and receiving. The connected scenario uses a 7.5 ms connection interval and data packets are sent 10 times/sec. In the non-connected scenario advertisement packets (BLE_PACKET_TYPE_ADV_NONCONN_IND) are transmitted every 20msec (thus 50 times/sec which as I understand is allowed for BT5).

In my test setup I store the number of received packets per second. This gives the following graph for the connected scenario (1Mpbs & S8 Coded):

For both coded and 1Mbps the same route in and around the house was taken. The Coded PHY was behaving better in terms of packetrate and disconnections. Still, from everything being said and promised about the long range feature I found the improvement in reallife a bit disappointing. The locations where 1Mbps disconnections happened were on the edge of the range, not way beyond the range. I expected that on those "on edge" locations, the coded PHY would not disconnect and would also not have a decrease in packet rate.

Then I cranked up the packets/sec to 90 and did some latency tests with coded PHY:

As expected, when the link budget decreases the retransmissions start to kick in and introduce latency. Although the latency in this graph is acceptable, it does show that when using the connected mode some kind of latency detection is required to filter out packets with a latency >300ms. 

The advantage of using non-connectable advertisement packets to convey the energy data, is that latency is automatically handled: either a packet is received (with no latency) or a packet is not received (and no retransmission). However the lack of retransmission also makes the system more prone to data loss I think:

1 Mbps PHY non-connectable test; TX 8dBm

Coded PHY non-connectable test; TX 8dBm

To be honest, I'm not impressed at all with the performance of the coded PHY when using non-connectable advertisements. Possibly there's a small performance gain, but the effect is minimal in the testing I've done.

To come to a conclusion, I would like to get some feedback from Nordic on the above results:

-What is Nordics experience when using coded PHY for non-connectable advertisment packets? Should it show the same improvements as seen in the connected scenario?

-In general, do you consider non-connectable advertisements less robust than a connection for conveying data with a low bitrate (but with latency requirements)?

-Does the lack of retransmissions (and possibly also due to only using the 3 advertisement channels instead of all channels) indeed negatively influence the range when using non-connectable advertisements? 

-Do you have quantifyable data you can share regarding 1Mbps vs S8 in and around buildings? So a more reallife scenario and not an optimized scenario without obstacles etc. Also, what to expect from the effective data bitrate and latency under such conditions?

-Any hints or feedback in general to improve the range under the given circumstances/requirements?

[ovrebekk]

Hi 

The problem with the coded PHY mode in general, which might be the cause for some of the issues you see, is that it doesn't help much in situations where you have a lot of noise from other 2.4GHz sources, such as WiFi. 

If the receiver is hit by noise at a stronger level than the signal you are trying to receive, then the improved sensitivity of coded PHY doesn't help at all, and because the coded PHY packets are 8 times longer than normal packets the chance of being hit by interference from other sources is larger. 

Being in a connection alleviates this to an extent by allowing you to use a larger number of RF frequencies, and retransmit lost packets. In particular if the central makes sure to change the channel map based on local interference in the area. 

This is not done automatically, but can be implemented using the Quality of Service additions available in the later SoftDevices. My colleague Jimmy Wong wrote a small blog on this here.  

-What is Nordics experience when using coded PHY for non-connectable advertisment packets? Should it show the same improvements as seen in the connected scenario?

I am not aware of any extensive testing done on this unfortunately. 
It is also important to note that long range advertising uses the extended advertising feature to advertise a small (relatively speaking) advertise packet on one of the advertising channels that point to a longer packet on one of the data channels which include the user data. 

This is done to avoid blocking the 3 advertise channels with long coded PHY packets, but has the side effect that you need to receive both of these packets in order to get the data on the scanning side. If just one of them is blocked by interference then the data is lost. 

-In general, do you consider non-connectable advertisements less robust than a connection for conveying data with a low bitrate (but with latency requirements)?

Advertising in general is definitely less robust than BLE connections, since you lose the ability to retransmit packets, and the ability to utilize all 37 data channels. 

The only case where an LE connection loses out to advertising is in a situation where packet loss is very high, and you keep retransmitting data over and over even if that data is outdated. 

When advertising you can make sure to always update the packet with the latest sensor data, but you will never know for sure which packets are received or not. 

One of the main additions in the Bluetooth 5.2 specification is the ability to control the number of retransmits in a connection, to avoid retransmitting the same data over and over (intended for audio applications primarily). 

-Does the lack of retransmissions (and possibly also due to only using the 3 advertisement channels instead of all channels) indeed negatively influence the range when using non-connectable advertisements? 

Yes. As I mention above there are a couple of reasons why advertisements in coded PHY mode are less robust compared to being in a connection. 

-Do you have quantifyable data you can share regarding 1Mbps vs S8 in and around buildings? So a more reallife scenario and not an optimized scenario without obstacles etc. Also, what to expect from the effective data bitrate and latency under such conditions?

I don't think we have any proper test results on this, but I will do some checking internally and get back to you. 

-Any hints or feedback in general to improve the range under the given circumstances/requirements?

One hint as mentioned above is to utilize the channel map update procedure on the central side to select channels with less interference. 

Also, if current consumption is not an issue you could consider adding a PA to your design to boost the output power of the radio. The drawback of this is increased hardware complexity and cost. 

Best regards
Torbjørn