Improving BLE immunity on nrf52840 with dynamic frequency hopping

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

Parents
  • Hi

    We recommend that certification tests are done with the radio_test sample project for 2.4GHz short range, as it's the most malleable radio sample. You want certification to be done with the barebones radio peripheral, and then rather do tests with your product's application separately to see that it behaves as intended.

    BLE does indeed not have listen before talk, and uses adaptive frequency hopping already to find the least busy channels for data transmissions, and is AFAIK very similar to dynamic frequency hopping, but on the 2.4GHz band and suitable for BLE.

    I don't have any good suggestions as to why the device is blocked on the 2.2GHz and 2.6GHz fields, and have asked one of our HW experts to take a look, unfortunately he's out of office today, but I'll get back to you as soon as I hear back from him.

    I'd also suggest opening a HW review ticket so we can take a look at your schematics and PCB layout to make sure everything looks okay from a HW point of view. You can create a private ticket in DevZone that will be handled confidentially by Nordic engineers.

    Best regards,

    Simon

Reply
  • Hi

    We recommend that certification tests are done with the radio_test sample project for 2.4GHz short range, as it's the most malleable radio sample. You want certification to be done with the barebones radio peripheral, and then rather do tests with your product's application separately to see that it behaves as intended.

    BLE does indeed not have listen before talk, and uses adaptive frequency hopping already to find the least busy channels for data transmissions, and is AFAIK very similar to dynamic frequency hopping, but on the 2.4GHz band and suitable for BLE.

    I don't have any good suggestions as to why the device is blocked on the 2.2GHz and 2.6GHz fields, and have asked one of our HW experts to take a look, unfortunately he's out of office today, but I'll get back to you as soon as I hear back from him.

    I'd also suggest opening a HW review ticket so we can take a look at your schematics and PCB layout to make sure everything looks okay from a HW point of view. You can create a private ticket in DevZone that will be handled confidentially by Nordic engineers.

    Best regards,

    Simon

Children
  • Hi Simon,

    Thanks for your quick response. Good to know Adaptive frequency hopping is used already and listen before talk is not supported. 

    We are using the radio_test sample already for emission testing to check the harmonics emitted by the device. The problem we are trying to fix is related to immunity, the connection is lost when a field is applied externally on 2.2GHz and 2.6GHz. 

    We are interested to know if the direct test mode is a suitable way to test EMC immunity or if it should be done using the actual application because that's more representative for how it would work in practice. 

    Best regards,

    Thomas

Related