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

[mkuiken]

Hello Torbjørn,

Thanks for your extensive feedback! Much of it is confirmation of what I thought might be the explanation (which is really good to know). Some of it is new:

I was aware of the possible 'endless' retransmission issue with audio but I never coupled this to my problems. I had already been looking into the availability of a "flush timeout" on link level or something similar but was not able to find it. Controlling the number of retransmission would actually solve the latency problem in a very neat and simple way while still having the benefits from retransmission in noisy environment.

Is or will the SDK S140 support BT5.2? I see that the 52840 is already 5.2 qualified but the nordic website only talks about 5.1 for S140. More important even, will the SDK allow the user to control the number of retransmission in a connection?

I will also take a look at the QoS you mentioned. I was not aware that the channel map is not automatically changed based on the local interference. I thought this is something that was handled automatically by the baseband. It's worth investigating for the connected scenario to see if I can get some improvement using that.

Yes the PA/LNA is also an option, but I guess that also means extra BT qualifcation effort. Currently we use a pre-qualified module which makes the whole BT qualification process pretty simple. Changing the implementation with respect to antenna and radio signal amplification I like to avoid if possible. If it's the only way to make it work then I will definitely look into it, but it's not a preferred option :-)

BR

Martijn

[ovrebekk]

Hi Martin

mkuiken said:

Is or will the SDK S140 support BT5.2? I see that the 52840 is already 5.2 qualified but the nordic website only talks about 5.1 for S140. More important even, will the SDK allow the user to control the number of retransmission in a connection?

We are not planning to update the SoftDevices beyond Bluetooth 5 unfortunately. 

We are slowly migrating to a new software architecture called nRF Connect SDK (NCS), and will not focus on adding new features to the nRF5 SDK. 

The Bluetooth stack in NCS does not support Bluetooth 5.2 yet, so I can't really comment on specifics.   

mkuiken said:

I will also take a look at the QoS you mentioned. I was not aware that the channel map is not automatically changed based on the local interference. I thought this is something that was handled automatically by the baseband. It's worth investigating for the connected scenario to see if I can get some improvement using that.

The Bluetooth specification only specifies how to do a channel map update, not how often you should do it, or how you should identify which channels should be mapped out, so how this is handled varies greatly depending on the host used. 

In the SoftDevice case it is up to the application to handle it. 

mkuiken said:

Yes the PA/LNA is also an option, but I guess that also means extra BT qualifcation effort. Currently we use a pre-qualified module which makes the whole BT qualification process pretty simple. Changing the implementation with respect to antenna and radio signal amplification I like to avoid if possible. If it's the only way to make it work then I will definitely look into it, but it's not a preferred option :-)

I totally understand your viewpoint. Adding a PA adds significant complexity to the design, and will also complicate qualification work as you mentioned. 

Do you have any timeline for when your product should be ready for production?

Best regards
Torbjørn