Range testing of any RF scheme is inherently limited by the RF environment, antenna design, tuning and many other factors. The usefulness of range testing is to provide a basis for comparison while keeping as many variables as possible constant. When applying this information to your own situation, the saying: “your mileage will vary” certainly applies.
This document records range testing on an open range in rural Florida, USA with very little 2.4GHz interference. The distance above ground level for all tests was about 1 meter.
The hardware used for all of the tests was the nRF52840-DK using its built-in PCB monopole antenna. Care was taken not to orient the monopole null towards the other device.
All boards were powered by coin-cell batteries.
The protocols and power settings tested were as follows:
BLE tests were performed using two nRF52840-DK’s. One was programmed as a heart rate service Central and the other as a heart rate service Peripheral. The Central was placed statically at 1 meter above ground, clear of any obstacles and the Peripheral was walked away. The Peripheral was switched on periodically to determine at what distance it would form a BLE connection with the Central. This was determined by LED1 on the Peripheral DK lighting solidly. When the Peripheral was turned off, the Central drops the connection in about 3 seconds. Transmit power settings and PHY modifications were made in main.c of the code of both DK’s. The original firmware used is found in SDK v15.2 at:
ZigBee tests were performed using three nRF52840-DK’s. One was programmed as a ZigBee Coordinator and another as a ZigBee Router (bulb). Both were co-located statically at 1 meter above ground. The third was programmed as a ZigBee End Device (switch) and was walked away. The End Device was switched on periodically to determine at what distance it would form a connection with the Router. This was determined by the ZigBee End Device DK LED4 lighting. Additionally, control of the bulb by the light switch was verified. Transmit power modifications were made in main.c of the code of all DK’s.
The original firmware used is found in SDK for Thread and ZigBee v2.0.0 at:
Thread Tests Thread tests were performed using two nRF52840-DK’s. One was programmed as a Thread CoAP Server and was located statically at 1 meter above ground. The other was programmed as a Thread CoAP Client and was walked away. The Client was switched on periodically and control of LED4 on the Server via a button on the Client was tested to determine at what distance a connection was made and control was possible.
Transmit power modifications were made in main.c of the code of all DK’s.
Distance between the static board(s) and mobile board was determined with a GPS application on a Samsung S8 phone. The “home” location was reset before each test.
Results were as follows:
Distances are in meters.
It's interesting how little the 2Mbps BLE range is decreased from the 1Mbps BLE range. ZigBee range is less than BLE, while Thread is nearly the same. BLE long-range is clearly a contender for long-range purposes.
Hex files (merged with the SoftDevice when needed) can be found here.
Ah, I found the text. It's about BT5: In Bluetooth 5, a new physical layer has been introduced. This physical layer doubles the modulation rate as compared to Bluetooth 4.2. The change from 1 Mbps to 2 Mbps is done by doubling the symbol rate; because of this, the bandwidth becomes twice as wide.
I don't remember in which document I read it, but it said that the range would not be affected by increased bandwidth, possibly using slightly different words. So that is great!
1. I'm sure that the hex files are less the issue than testing over wide-open water.2. One would think that the 2Mbps rate would impact the range vs. the 1Mbps rate to a greater degree. But that's what I measured.
The dongle uses a meandering antenna which reduces nulls (great for mice, for example), but doesn't have the performance of a monopole. I'd expect the dongle to have significantly less range.
I don't know a definitive answer to why they are different. Since the H/W is identical I can only assume something in the stack causes the difference.