Unable to Receive Advertisements from Multiple Beacons

[TheoM]

Setup: 

1 NRF21540dk (Receiver)
Multiple custom nRF52840-based Beacons
nRF Connect SDK V2.3.0 + VSCode 
Latest Version of Windows 11 

Problem: 

I'm working on a project which has multiple Beacons that send out (non-connectable) Bluetooth advertisements (both extended and legacy) containing various types of data. There is a receiver, which scans for the advertisements, and then does operations with the data from these advertisements. The program does not use any scanning filters – the first 4 bytes of the advertisement data are used to identify messages from our Beacons. Valid advertisements from our Beacons are handled by the Receiver on a first-come first-served basis (I.e. we are not using work queues or threads), and advertisements that do not come from one of our devices are ignored. Ideally, the Receiver should be able to see and handle the advertisements from all of the Beacons, which brings me to the issue. 

The main problem is that when scanning for advertisements, the Receiver tends to only "see" advertisements from one of the Beacons, and rarely "sees" advertisements from the others. For example, If I were to print every advertisement from the Beacons that the Receiver "sees" when scanning along with the corresponding Beacon's MAC address, advertisements from one MAC address (Beacon) would make up at least 95% of the ones printed. 

It's almost like the Receiver "latches on" to that one Beacon, or that one Beacon "dominates" all the others. I don't think it's an issue of signal strength or anything of that nature, as tx power is constant for all devices, and the "dominant" Beacon can be 10+ ft away from the receiver, while the other "ignored" Beacons are right next to it.

What could potentially be the cause(s) of this? Are there any things that can be done to remedy this? Is there anything I should try, or are there any best practices to make sure to follow? Thanks.

[TheoM]

I took a look at the RSSI values for my Beacon's advertisements. The "dominant" Beacon's advertisements had RSSI values around -40 to -30 dB on average, whereas another Beacon that I tested had values around -80 to -70 dB, on average. This would at least partially explain my issue. Regardless, I'd still appreciate some help.

[Hieu]

Hi TheoM,

It is a very strange observation. We don't usually see this.

I would like to ask for some details:

• Are all of the beacons identical? In details:
  • Are they running the same application?
  • Are they configured to advertise at the same intervals?
• Without processing of the 4-byte advertising data, and just printing out any advertisement packet you receive, do you observe the same problem?
• If you turn off the "dominant" beacon, does the issue disappear, or does it happen with another beacon instead?

By the way, it is not related to this issue in particular, but please know that there is a problem with the nRF21540 FEM where TX Power is lowered when in a connection. This issue affects NCS v2.3.0. Therefore, please consider using later version of NCS for your application with the nRF21540.

Hieu

[TheoM]

In the initial scenario, we had 2 beacons. One was on our custom board using a custom build config based on a bl654-dvk, which we were having the issues with. The other "dominant" beacon was running on a 21540dk dev board. Our receiver was another 21540-dk. Otherwise, in terms of software the Beacons were identical in every way (i.e. same application, same advertising intervals, etc.)

The issue persisted even without processing the 4-byte part of the message, and we had trouble receiving messages from the problematic Beacon, even when the "dominant" Beacon was turned off. 

That led me to believe that it's an issue with the TX power, as the (admittedly somewhat useless) RSSI values for the packets indicated a very strong signal from the "dominant" 21540dk, and a weak signal from the custom board based Beacons. This could possibly be caused by somehow incorrectly setting up the bl654-dk configuration, but we're not sure. 

[Hieu]

If I understand correctly, the issue is more that the 21540dk is not receiving very well the packets from your bl654-dvk beacons, is that right?

I am not familiar with bl654-dvk. Looking up the internet, it seems to be a Laird Connectivity product, but I am not clear if it is development kit from them, or a custom hardware from you.

If it's a custom hardware, you can also open a private hardware design review ticket. We do offer schematic and PCB review on DevZone.

Regarding your doubt about the TX Power, you can read the TXPOWER register in code, or with nrfjprog using the command --memrd.

Besides that, I think it's also a good idea to just flash a super basic beacon sample on the bl654-dvk hardware and look at the performance. The nrf21540dk_nrf52840 build target does setup some TX Power changes, which can create a difference in TX Power between the 21540dk and the bl654-dvk build.

[TheoM]

It's a custom board that's based on a BL654 PA module, which has an nRF52840 + a skyworks FEM. Based on some further research, it looks like I'm not correctly utilizing the FEM. I've set the 2 GPIO's according to Laird's and Nordic's documentation. 

From what I've read - it looks like getting this to work heavily depends on using the SoftDevice, which will require some additional code that wasn't required when I was using a 21540DK. Am I correct in this? 

[Hieu]

I assume the "additional code" you are referring to are the Kconfig and DTS? If so, yes.

To be fair, for the nRF21540 DK, Nordic already provided the board files with the FEM setup. You can see that the DTS node for the FEM, the SPI interface, and the radio node property are defined. 

For the Kconfigs, you can also find the necessary ones are enabled by default for both Skyworks FEM and nRF21540.

I am not familiar with Laird's support for their modules. If they already provided such DTS or overlay files, then you don't need to do anything. I haven't found anything after a quick search, however. For a definitive answer, I think you need to contact Laird.

[TheoM]

I should clarify - I'm no longer working with a 21540-DK. I'm using a custom board, which uses the Laird BL654 (52840 + Skyworks FEM). So for my build, I'm NOT using the 21540 or 52840 configs from Nordic. Rather, I'm using a modified version of the "bl654 dvk" board configs. I had to add support for a FEM, using the two-wire simple GPIO mode according to Laird's documentation (See link below - Laird's guide is based on a heavily outdated SDK version, and hasn't been updated in over 2 years)

https://www.lairdconnect.com/documentation/application-note-nordic-sdk-based-application-development-bl654pa  

As I just mentioned, I've already made the required DTS/KConfig changes that supposedly would allow use of the FEM, but Laird's documentation mentions that the SoftDevice must be used to initialize/control the FEM, which I haven't tried yet.

I tried contacting Laird already, but my support request was denied because I'm not directly working for a business.

[Hieu]

TheoM said:

I should clarify - I'm no longer working with a 21540-DK. I'm using a custom board, which uses the Laird BL654 (52840 + Skyworks FEM). So for my build, I'm NOT using the 21540 or 52840 configs from Nordic.

Thank you for the clarification. I went into the details on the nRF21540 DK was due to address an implied comparison in your question:

it looks like getting this to work heavily depends on using the SoftDevice, which will require some additional code that wasn't required when I was using a 21540DK.

In that guide, section 4, you will see that it is targeted for the nRF5 SDK, which is an entirely different SDK, now in maintenance mode. We don't recommend you use this SDK for new projects.

TheoM said:

had to add support for a FEM, using the two-wire simple GPIO mode according to Laird's documentation (See link below - Laird's guide is based on a heavily outdated SDK version, and hasn't been updated in over 2 years)

https://www.lairdconnect.com/documentation/application-note-nordic-sdk-based-application-development-bl654pa  

As I just mentioned, I've already made the required DTS/KConfig changes that supposedly would allow use of the FEM, but Laird's documentation mentions that the SoftDevice must be used to initialize/control the FEM, which I haven't tried yet.

The SoftDevice in the nRF5 SDK is a predecessor of the SoftDevice Controller in the nRF Connect SDK (NCS). However, a lot of changes has happened, and the APIs and code mentioned in the Laird guide is likely completely not applicable in NCS.

I recommend you follow this guide to get FEM working in NCS instead. It works with Skyworks FEM. I have followed it to setup a Skyworks FEM in a previous DevZone case.