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