**Project and hex files for testing this is attached in the end of this blog.
There has been a lot of discussion/testing/confusion about testing the long range feature of Bluetooth Low Energy (BLE) with Nordic Semiconductors latest chip nRF52840 Rev C. This blog post demonstrates that the long range feature works the way it is supposed to. You can test it yourself with the attached project/binaries
The intention of this blog post is to:
There are two ways how you can increase range in your BLE product. Before Bluetooth 5 (BT5), there was only one way to do that, namely by increasing the radio transmit power. But doing so, will significantly increase the average current of your product. And the other is by using the long range feature newly introduced by BT5.
You should also know a bit about path loss, which is explained a bit clearer in this external post. Note that just considering the air path loss (thus not considering the signal loss due to absorption by materials in the path)the post gives the following information:
Path loss is the reduction in power density that occurs as a radio wave propagates over a distance. The primary factor in path loss is the decrease in signal strength over distance of the radio waves themselves. Radio waves follow an inverse square law for power density: the power density is proportional to the inverse square of the distance. Every time you double the distance, you receive only one-fourth the power. This means that every 6-dBm increase in output power doubles the possible distance that is achievable."
But in the real world, the path loss is a little bit more than the ideal air path loss. This is due to the precipitation, humidity, reflected signals, and so on, which deteriorates the signal more in the path.
Understanding the obtained long range results?
This blog post aims at making it simple for you to analyze the results you get with long range. The places where you test long range will surely have different signal propagation characteristics and different path losses than the places where I tested this. To make it simple and to keep these random variables that will affect your range out of the equation, we will do the range test with both 1M PHY and Coded PHY (long range) and compare the results. This way we can minimize the effect of all the random variables on the radio signal and concentrate solely on the improvement that the long range feature gives over 1M PHY.
Why are we not doing this test indoors?
This is because your indoors architecture is not symmetric. The results I get in my office/home building will be very different that the results you get where you do this test. The surrounding materials around you indoors, does not cause linear path loss like outdoors (it might not be a linear path loss even outdoors if the landscape you choose is not a plain open ground). This is due to the difference in the absorption/reflection/diffraction properties of materials around you. This is also the reason why I am doing this test outdoor, to keep this as simple as possible.
Test Setup and Equipment
3 x PCA10056v0.12.0 (at least nRF52840 with Rev C chip)
Power supply (coin cell battery or USB power bank)
Let me stress that this experiment is not about determining the power consumption of long range, but about testing the comparable range between 1M and coded PHYs. Since the adv/scan/connection parameters are set to a very low value, this experiment is not power-friendly. It will therefore drain your coin cell battery faster than you expect. This is because we are trying to keep the radio active most of the time, and were also using LEDs as a visual tool. I recommend you use a USB power bank, to get a steady power supply throughout your test. Of course this is not the requirement of this setup, so you can also use a coin cell battery, if you do not have any USB power bank handy.
Attached is a simplified ATT_MTU project at the end of this blog, that you should unzip into the SDK15\examples\ble_central_and_peripheral\experimental folder. I have tested this with Keil, so I deleted other versions of the compiler projects to remove confusion and irregularities (keeping it simple)
The button and LED assignment is as shown in the picture:
Holding your test kits in the correct position/direction
The picture below shows the front side of the DK, where you can see the Nordic chip (nRF52840), the matching network (marked with a red box), and the connector for the external antenna. We are not using an external antenna, and just using the PCB antenna that is printed on board. So with this specific PDK, the radio pattern radiates strongest on the front side. It radiates on the backside of the PDK as well, but you will observe a radio signal strength loss of about 3-4 dBm on the backside. This is due to many reasons (material of PDK, underlying printed metal circuit, etc). Therefore, it is best that when you are testing with PDKs, you set them facing each other as shown below. They do not need to be aligned to the same altitude. Facing them each other with any individual altitude should be ok.
You might ask yourself if this is really required? Well, It is not absolutely necessary that the PDKs face each other for this test, but you MUST be consistent in positioning your PDKs in the same direction for both the 1M range test and the Coded PHY range test. This way the signal loss due to the material of the PDK for both tests will remain constant and hence the range comparison results would look reasonable.
Now, lets program the boards and start testing!
We need 3 PCA10056 DK with atleast a RevC Nordic chip. I will from now refer to the kits as Alpha, Beta, and Omega to avoid confusion.
Testing non connected states (0 dBm Tx power):
The distance I got for 1M PHY 0 dBm TX was 654.92 meters.
The distance I got for Coded PHY 0 dBm TX was 1300 meters.
So the range increase was ((1300 - 654.92) * 100 ) / 654.92 = 98.49% increase in range with Coded PHY compared to 1M in non connected state at 0 dBm.
Testing connected states (0 dBm Tx power)
The distance I got for 1M PHY 0 dBm TX in a connection was 681.90 meters.
The distance I got for Coded PHY 0 dBm TX in a connection was 1300 meters.
So the range increase was ((1300 - 681.9) * 100 ) / 681.9 = 90.64% increase in range with Coded PHY compared to 1M in connected state at 0 dBm.
why is there a small difference in non connected and connected state? Technically there should not be, but there are many variables that can affect this range. If this difference is consistent in our future tests, then we will try to analyze it in a different blog post.
Testing connected states (8 dBm Tx power)
You can perform the whole test again changing the radio TX power to 8 dBm for adv/connections to clearly see that the range now significantly increases. In the project you can do it by changing RADIO_TX_POWER to 8 and restarting the test from the section "Testing non connected states".
There are several conclusions that can be drawn from this test:
Please ask questions if you have any. We will try to answer to as many as we can.
Please post your achieved range in different configuration and the GPS location so that we know more about your achievements.
Project and binary attachment below
I have encounter difficulty running this demo using the coin cell battery as the power source.I am running on hardware PCA10056 v1.1.0 (2019.12).I have tried using the precompiled hex non_connected_8dBm and softdevice 6.0.0.However, i have tried on the two PCA10056 i have and they do not power up using the battery. Only by USB power bank.I have verified it is not a battery issue: Using the same hardware and battery, i am able to use the Battery to power the board using the BLE plinky example.I have read some other thread that disabling UART could make the board run on the coin cell battery. However, i am very new to the embedded device development and my first time to work with Nordic DK. I can use some guidelines on how to disable UART for the battery to run if that is the solution. Thank you.
you can use the ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput example, which contains SES version project.This is the directory of where the example is located in SDK16.I copied the main.c from here to replace the original one, then added SCAN_INTERVAL and SCAN_WINDOW to sdk_config.h
Hi Susheel I want to ask using 125 kbps when you achieved distance of 1300 meter what was the PER (packet error rate) on that time. did you consider that as well or not. thanks
Hello. How does the use of internal RC or external XTAL source clock affect distance?