<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/105265/improving-ble-immunity-on-nrf52840-with-dynamic-frequency-hopping</link><description>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</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 09 Nov 2023 12:20:02 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/105265/improving-ble-immunity-on-nrf52840-with-dynamic-frequency-hopping" /><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/454899?ContentTypeID=1</link><pubDate>Thu, 09 Nov 2023 12:20:02 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d99bc290-c004-4e5c-b222-fadb6b365a06</guid><dc:creator>Thomas Gooijers</dc:creator><description>&lt;p&gt;Hi Simon,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;We develop both the central and the peripheral for our application so we might be able to take advantage of this feature.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Thanks a lot for all of the help,&lt;/p&gt;
&lt;p&gt;Thomas Gooijers&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/453968?ContentTypeID=1</link><pubDate>Fri, 03 Nov 2023 12:51:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:dbc6412e-6011-4d75-8645-0a68799e3b3e</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;Hi Thomas&lt;/p&gt;
&lt;p&gt;300ms as supervision timeout sounds a bit low in my opinion. Do you also have details on the other intervals/parameters?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;An update and correction to my last reply. BLE is not adaptive by design as defined by ETSI, but we have a &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/nrf_desktop/doc/ble_qos.html#nrf-desktop-ble-qos"&gt;QoS module&lt;/a&gt; that can be used to enable adaptivity. Since&lt;span&gt;&amp;nbsp;it is the central that decides the channel mapping, it&amp;#39;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.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;I updated my initial reply to better reflect this. Sorry about that, I got confused myself as I found some contradicting information.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Simon&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/453732?ContentTypeID=1</link><pubDate>Thu, 02 Nov 2023 13:12:32 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5f408968-a251-4949-a73a-21e73124716e</guid><dc:creator>Thomas Gooijers</dc:creator><description>&lt;p&gt;Hi Simon,&lt;/p&gt;
&lt;p&gt;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.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;The amount of time to resend data could be a factor indeed.We do have the s&lt;span&gt;upervision timeout set to 300ms because we are working with a application&amp;nbsp;where timing and latency&amp;nbsp;matters so our product would disconnect fairly&amp;nbsp;quickly in case there is disturbance which causes packets to get lost.&amp;nbsp;&lt;/span&gt;&lt;span&gt;So we could as an experiment check if increasing this makes any difference.&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;We also have another question about how Nordics implementation&amp;nbsp;of adaptive frequency works. &lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Does it just jump between the channels continuously?&amp;nbsp;So that even if a certain channel is busy packets would still get trough via the channels that work better.&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;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?&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Also I didn&amp;#39;t mention yet we are using Coded PHY (S=8). Does this make any difference and is&amp;nbsp;&lt;/span&gt;&lt;span&gt;adaptive frequency hopping also supported in this case?&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Once again thanks for your quick response,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Thomas Gooijers&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/453685?ContentTypeID=1</link><pubDate>Thu, 02 Nov 2023 11:29:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9eff7539-fdc6-4624-93fd-7ac087e01f78</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;So I heard back from one of our HW experts regarding the EMC immunity tests and here is their feedback:&lt;/p&gt;
&lt;p&gt;EMC immunity should be tested with the stack running and the final firmware I&amp;#39;m being told. There is a 120MHz &amp;quot;exclusion band&amp;quot; on both sides of the 2.4GHz band (&lt;a href="https://www.etsi.org/deliver/etsi_en/301400_301499/30148917/03.02.04_60/en_30148917v030204p.pdf"&gt;EN 301 489.17&lt;/a&gt;). The fact that you&amp;#39;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 &amp;quot;the user shouldn&amp;#39;t notice anything&amp;quot;, meaning it shouldn&amp;#39;t disconnect or become noticeably slower, etc. However, in an application like this, more often than not re-transmitting some data packets is required.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Simon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/453628?ContentTypeID=1</link><pubDate>Thu, 02 Nov 2023 08:25:30 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3a036280-d646-4863-a8c5-e9f8d87ef1ef</guid><dc:creator>Thomas Gooijers</dc:creator><description>&lt;p&gt;Hi Simon,&lt;/p&gt;
&lt;p&gt;Thanks for your quick response. Good to know Adaptive frequency hopping is used already and listen before talk is not supported.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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&amp;nbsp;&lt;span&gt;2.2GHz and 2.6GHz.&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;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&amp;#39;s more representative for how it would work in practice.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Thomas&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Improving BLE immunity on nrf52840 with dynamic frequency hopping</title><link>https://devzone.nordicsemi.com/thread/453621?ContentTypeID=1</link><pubDate>Thu, 02 Nov 2023 07:33:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6dead660-1c76-4b31-b519-dc274db83d97</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;We recommend that certification tests are done with the &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/peripheral/radio_test/README.html"&gt;radio_test sample&lt;/a&gt; project for 2.4GHz short range, as it&amp;#39;s the most&amp;nbsp;malleable radio sample. You want certification to be done with the barebones radio peripheral, and then rather do tests with your product&amp;#39;s application separately to see that it behaves as intended.&lt;/p&gt;
&lt;p&gt;BLE does indeed not have listen before talk&lt;span style="text-decoration:line-through;"&gt;, 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.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;I don&amp;#39;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&amp;#39;s out of office today, but I&amp;#39;ll get back to you as soon as I hear back from him.&lt;/p&gt;
&lt;p&gt;I&amp;#39;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.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Simon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>