nRF52832 1 MBit/s vs nRF52811 Coded PHY range improvement 10 % - expected 100 %

[Otso Jousimaa]

Hello, 

We're piloting updating our sensor beacons RuuviTags to use Coded PHY for better range. The current design has nRF52832, our update would be to drop in a nRF52811.

The beacons work by broadcasting sensor data in manufacturer specific format in advertisements, there's no GATT connection. 

Our test setup had 5+5 tags and 2 prototypes of Ruuvi Gateway as receiver. Ruuvi Gateways have nRF52811 + LNA on BLE side and ESP32 to send the data to the Cloud via WiFi. The gateway collects all advertisements to 10 second batches and sends the data in one batch, if a tag is received at least once in 10 second window it's considered to be in range. 52832 tags sent at 221 ms interval, 52811 tags at 1285 ms interval to compensate for energy consumption of Coded PHY. Both tags send at +4dBm. 

We placed the gateways on a harbor by a lake and started speeding away in a boat with tags pointed to gateways, i.e. as clear line of sight as possible. The 1 MBit / s tags dropped first after a bit over kilometer range and Coded PHYs about 10 % later. We were expecting the range to be doubled.

Is there something specific in our test setup which would explain the result of only 10 % more range? For example our use case is extremely tolerant for dropped packets, to be considered in range 52832 can lose 44/45 packets in 10-second period, 97 % packet loss is acceptable. On the other hand 52811 can tolerate losing only 6/7 packets => 77% packet loss is acceptable.

[Marjeris Romero]

Hi,

I think you already got a good answer about checking the Fresnel zone, there are different Fresnel zone clearance calculators online which you can use to calculate the best high for the poles. Just wanted to add that Coded PHY is generally more sensitve to interference because of the longer packets so it's difficult to say for sure what improvements in range one can expect, but I agree that 10% sounds a bit low.... Here are also some other things you can check when you are back on the boat:

• Make sure you are advertising on all three BLE channels
• You can try to adjust the scan window and scan interval in the gateway device when the advertising interval of the tags has been adjusted for coded PHY. Sending packets more often or scaning more when using 1M PHY could explain why the differences were small between the two modes in your first test.
• It could be interesting if you can do the test with 221ms interval on coded PHY as well so you can the results with the same interval settings.
• Check if there is a lot of 2.4GHz activity in the area which could be interfering with your measurements?

I wish you good luck with further testing. Let us know if you are able to achieve a longer range next time.

Best regards,

Marjeris

[Otso Jousimaa]

Hello Marjeris, thanks for the reply.

• Make sure you are advertising on all three BLE channels

Yes

• You can try to adjust the scan window and scan interval in the gateway device when the advertising interval of the tags has been adjusted for coded PHY. Sending packets more often or scaning more when using 1M PHY could explain why the differences were small between the two modes in your first test.

We had scan on at 100% duty cycle, this should not be an issue

• It could be interesting if you can do the test with 221ms interval on coded PHY as well so you can the results with the same interval settings.

Yes, we'll need to retest this

• Check if there is a lot of 2.4GHz activity in the area which could be interfering with your measurements?

No, it was in a lake in a middle of forest

Marjeris Romero said:

Just wanted to add that Coded PHY is generally more sensitve to interference because of the longer packets

This was news for me, I thought that Coded PHY should be more interference-tolerant because the packets have the error correction codes. Thanks :) 

[Marjeris Romero]

Otso Jousimaa said:

We had scan on at 100% duty cycle, this should not be an issue

 Depends on the size of your scan window. If the scan window is too small you will risk dropping packets.

[Otso Jousimaa]

Marjeris Romero said:

 Depends on the size of your scan window. If the scan window is too small you will risk dropping packets.

 

That's another point I didn't consider, but we're using 7 seconds per channel anyway so that should not be an issue. 

[Marjeris Romero]

I see, then it doesn't look like that would be a problem, 7 seconds should be more than enough.

Can I also ask which Softdevice version you were using in your tests?

[Otso Jousimaa]

We're using S140v6.1.1

[Marjeris Romero]

I see, then the Softdevice is not a problem. I just asked about this because in some earlier versions the support for long range was still not maximize for max range, but this was a long time ago, S140 v6.1.1 is pretty new and one version older than the one used in our latest test: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/testing-long-range-coded-phy-with-nordic-solution-it-simply-works-922075585

I think we just need to wait until you do new testing taking care of all the considerations mentioned above and see if the results are different then. We are very interested in knowing what kind of range customers achieve with our products in different conditions so please keep us updated!

Best regards,

Marjeris

[Otso Jousimaa]

As a summary, we'll test with equal advertising rates and try to find taller poles to hang our tags from. I'm not sure how we're going to get over 4 meters in practice though, maybe we should place the tags in a mast of a sailboat :) 

I marked on my TODO to follow-up on this, but on the other hand the important discovery for us is the Fresnel zone limitation. Vast majority of our customers won't be installing the sensors above their reach without ladders, and if the Coded PHY is more sensitive to 2.4 GHz noise we're probably not going to see improvement in noisy environments either.

Thanks for your help, I'll mark this answered and will follow-up when/if we have a more controlled test result.

[Otso Jousimaa]

It's been a while, but here's a follow-up :) 

We have not been able to get a practical range improvement using Long Range over using +4 dBm broadcasting at 1 MBit / s PHY. This is probably in big part because of our data transmission model, we put the data in BLE advertisement manufacturer specific field and we can tolerate a lot of packet losses. 

The limiting factor in the range is always the environment, either the Fresnel zone or metal and concrete in urban environment

[Marjeris Romero]

Hi,

Testing over water is more difficult as water have different absorption and reflection/refraction properties, if the tag was very close to the water the water might absorb most of the signal. But to be honest I don't know how much range would it be expected under these conditions, as we haven't conducted tests over water.

This test was conducted over the line of sight in the coast, but with mostly land and only some water below the two points: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/testing-long-range-coded-phy-with-nordic-solution-it-simply-works-922075585

If you are having a similar range to the test above it's perhaps as good as it gets under your testing conditions. The test above is also performed using +8dBm, +4dBm will give a lower range.

You can also check with a sniffer if you are in fact transmitting CODED PHY packets or if for some reason the phy update failed (but in that case you would have gotten a phy_update error return value).

Best regards,

Marjeris