Increasing Coverage of nRF51822 BLE module

[Vaio]

For some sort of geofencing application, we want to include the BLE module nRF51822 into a Base Station (BS), and a small mobile device (MS). The MS should detect the presence of a signal from the BS. If it is/is not present, certain actions are being triggered.

1.) While the maximum TxPower seems to be +4dBm, I heard that using an amplifier one can send up to the regulated limit of +20dBm.

---

2.) Alternatively, I heard on the nRF51822 a custom protocol can be implemented. The design goal would be to reach maximum coverage (ideally, beyond walls inside a house).

---

For both cases, the same questions arise:

Does anybody have experience / more infos on this? Mainly:

• what is the maximum coverage (in theory and practice)?
• what are the implications on power consumption (as this will be done in the BS, it shouldn't really matter)?

Thanks!

[Håkon Alseth]

Hi,

Power-wise, I do not believe that you will run into issues, as the base station will act as a master device (always in RX mode) and it's most likely connected to the wall.

We're usually reluctant to say anything on the range, as this varies in different environments. If you're in a building where the walls are thick and made of concrete, this will reduce range across different rooms.

If you reduce the on-air datarate (supports 2M, 1M, 250k), you should get better coverage. When running on 2 MBit on-air datarate, the range is around 10-15 meters in an office environment. 250 kBit in an open area (outside, line-of-sight), you will get more than 200 meters. This is with a well-tuned design.

However, in buildings you will always have walls, wifi, and other factors that comes into play.

The best way to test this is to get two eval-kits, set them up with 250 kBit mode and test it in your natural application environment.

Best regards Håkon

[Vaio]

Thanks Håkon,

in our setup the BS would be the transmitter (always advertising), and the MS the receiver (checking for the BS beacon's presence, e.g. once per minute). The MS doesn't even need to make an actual connection to the BS - it is sufficient to detect its presence.

The BS is connected to the wall, so no power problems there. The MS of course has very tight power requirements. Since we only check for presence e.g. once per minute, this should hopefully allow for multiple weeks of battery runtime.

Of course, coverage in buildings is hard to say. 200m LOS sounds promising however. Regarding decreasing the data rate: it seems for BLE, using 1 Mbps is the only valid datarate. Were u referring to a custom protocol (where 250kbps can be used)?

Other than decreasing the datarate, can sbdy think of any other means to extend the range? (could we equip the BS with a better antenna for instance, to get closer to the allowed +20 dBM?)

Best Rgds, Mike

[Håkon Alseth]

Hi,

Note that ~200m LOS is with 250 kBit data rate. With BLE this might be 50-100 meters line-of-sight.

You're correct. BLE can only do 1MBit data-rate, so if BLE does not satisfy your range requirements, then I would recommend checking out our proprietary protocols (ESB or Gazell) and set the on-air data rate to 250 kBit. You could also add an RF PA, but note that BLE does not allow more than +10 dBm output power. Using a proprietary protocol, then you can go over this limit, but you have to make sure that you're within teleregulatory requirements.

Using a good antenna (like a WiFi antenna) will most likely give you better coverage, but it may not be enough. What I would do is to test this out with both BLE and 250kBit proprietary protocol, and see if the range is acceptable.

Best regards Håkon

[Vaio]

Thanks for clarification. In this case, I'd like to test the 2.4 GHz proprietary protocol w/ 250 kbps. ESB and Gazell are provided by Nordic and can be easily used on the devboards I assume?

What remains unclear to this point: could I use the custom protocol (for presence detection of a mobile device near the base station, long range), and switch the nRF51822 later to use it with BLE protocol (to synchronize some data to a smartphone, shorter range)? I.e., can we switch the protocols during runtime (= controlled from our firmware)? I suppose this is not possible in parallel, but at least sequentially?

Using a proprietary protocol, then you can go over this limit, but you have to make sure that you're within teleregulatory requirements.

I suppose you refer to region-specific regulations? Afaik, for Europe this should be limited to 100mW (20dBm) EIRP in the 2,4 GHz band then.

In terms of testing, can you clarify/confirm what would be required for such a 2.4 GHz custom protocol range test? It seems either 2 evaluation kits (probably cheaper?), or alternatively 1 development kit (more flexible?) would do the trick?

Thanks, Mike

[Håkon Alseth]

Hi,

ESB and GZLL examples can be found in the nRF51 SDK. Note that they are setup with 2Mbit data-rate by default, so you will have to set the desired datarate on both receiver and transmitter.

You're looking into running both BLE and proprietary on one firmware. This is possible (we do it on some of our reference designs, like nRFready Desktop 2.) At this moment, it has it's restrictions. In order to use proprietary communication, you will have to disable the SoftDevice. There's an example in the SDK, called "ble_app_gzll" which switches between gazell and BLE.

For a range test, I would setup a transmitter (based on Enhanced Shockburst example) which sends quickly, let's say every 5 ms. On your receiver, toggle a LED for each 50 packets received.

Note: you will have to set the automatic re-transmit delay to >2700 us for 250kbit on-air mode, as stated here in the documentation: devzone.nordicsemi.com/.../a00896.html

Best regards Håkon