Improving BLE immunity on nrf52840 with dynamic frequency hopping

[Thomas Gooijers]

I am a software engineer working on a product that will need to be certified for EMC in the near future. The product uses the nrf52840 for BLE and the software is being developed using Zephyr and the NRF-SDK. 

During a EMC pre-scan at the test lab that will also handle the certification the BLE connection would get interrupted when a 3V/m field was applied at 2,4GHz which which we would expect considering BLE operates between 2,4GHz and 2,48GHz. But it also occurred around 2,2GHz and 2,6GHz, which according to the test engineers working at the certifications lab is outside of the acceptable range for certification. 

The hardware engineers working on this product are working on a way to improve this in hardware. But the test lab also recommended we look into potential ways this could be improved trough changes in the software. They specifically mentioned "listen before talk" and "dynamic frequency hopping" as potential fixes.

I couldn't find much information about listen before talk with BLE. As far as I can tell dynamic frequency hopping should be possible with BLE but I can't find any indication in the Zephyr/NRF-SDK documentation that there is support for this feature and the following post suggests as much:  Adaptive frequency hopping with Bluetooth LE audio broadcast 

I did find a way to manually set a channel map to exclude specific channels, but if I understand how it's supposed to work correctly the BLE connections should switch between the channels all the time and and the device should figure out which channels yield the best performance automatically. 

Is it correct there is currently no support for either of these features? If so, will this be added in the near future?

Or is this something we could implement ourselves fairly easily?

The certification test engineers also mentioned they had run into similar issues certifying other Nordic devices and got better results using the "Direct Test Mode". We looked at this while preparing for the EMC pre-scan and concluded it's a nice tool that lets you select specific channels to try and sweep across channels but it wouldn't necessarily represent real word usage. 

Is direct test mode representative for how the device would behave in practice when maintaining a BLE connection with an application build with Zephyr and NRF-SDK and should we just use that instead for the certification tests?

Or is this just a tool that can help track down a specific issue and the certification test should be done with the actual application that will ship with the product?

Any other advice on how immunity can be improved in hardware or software would also be appreciated. 

Many thanks in advance,

Thomas Gooijers

[Simonr]

So I heard back from one of our HW experts regarding the EMC immunity tests and here is their feedback:

EMC immunity should be tested with the stack running and the final firmware I'm being told. There is a 120MHz "exclusion band" on both sides of the 2.4GHz band (EN 301 489.17). The fact that you're failing by losing the connection is strange though, what connection parameters are you using? Do you have enough time to re-send the data before a link loss/connection loss is triggered? The parameter of if one of these tests are failing or not is usually that "the user shouldn't notice anything", meaning it shouldn't disconnect or become noticeably slower, etc. However, in an application like this, more often than not re-transmitting some data packets is required.

Best regards,

Simon

[Thomas Gooijers]

Hi Simon,

Good to know the direct test mode is not representative enough for the actual test and we should indeed use the actual application we are going to ship with the device. 

The amount of time to resend data could be a factor indeed.We do have the supervision timeout set to 300ms because we are working with a application where timing and latency matters so our product would disconnect fairly quickly in case there is disturbance which causes packets to get lost. So we could as an experiment check if increasing this makes any difference. 

We also have another question about how Nordics implementation of adaptive frequency works.

Does it just jump between the channels continuously? So that even if a certain channel is busy packets would still get trough via the channels that work better. 

Or does it go further than that and create a record of how well each channel performs and use the channels with the best chance of the packet getting trough be used more often?

Also I didn't mention yet we are using Coded PHY (S=8). Does this make any difference and is adaptive frequency hopping also supported in this case?

Once again thanks for your quick response,

Thomas Gooijers

[Simonr]

Hi Thomas

300ms as supervision timeout sounds a bit low in my opinion. Do you also have details on the other intervals/parameters? 

An update and correction to my last reply. BLE is not adaptive by design as defined by ETSI, but we have a QoS module that can be used to enable adaptivity. Since it is the central that decides the channel mapping, it's not always possible to archive proper adaptivity. Thus, advertising will always happen on three channels. No BLE stack is adaptive by design. The Bluetooth spec does not have any requirements for adaptivity. So in case this is needed, it has to be a custom implementation and has to be handles by the application. The peripheral must always do what the central tells it to, including connection parameters and channel map.

I updated my initial reply to better reflect this. Sorry about that, I got confused myself as I found some contradicting information.

Best regards,

Simon

[Thomas Gooijers]

Hi Simon, 

We develop both the central and the peripheral for our application so we might be able to take advantage of this feature. 

If I understand you correctly, for the peripheral we would only have to enable the the QoS module to get dynamic frequency hopping to work. But for the central we would have to figure out how to determine the channels to use and set the channel map accordingly. 

I will discuss with my colleagues if this is something we would like to try to implement or if this problem is better addressed in hardware. 

Thanks a lot for all of the help,

Thomas Gooijers