<?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>on air address handling in the nRF52 family radios</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/125767/on-air-address-handling-in-the-nrf52-family-radios</link><description>Hi there 
 I have a question about the way the nRF52 radio handles on air addresses. I currently am developing custom software that uses the nRF52810 radio for a custom protocol. 
 I am exchanging data between two transceivers every 4ms. This works very</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 24 Nov 2025 10:10:22 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/125767/on-air-address-handling-in-the-nrf52-family-radios" /><item><title>RE: on air address handling in the nRF52 family radios</title><link>https://devzone.nordicsemi.com/thread/555171?ContentTypeID=1</link><pubDate>Mon, 24 Nov 2025 10:10:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a5348fc5-372e-46ba-ae62-0a63a1875c21</guid><dc:creator>H&amp;#229;kon Alseth</dc:creator><description>&lt;p&gt;Hi Rob,&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
[quote user="Rob Garner"]&lt;p&gt;A quick update. EVENTS_ADDRESS is actually 1, so a valid address was received. However, the actual data packet looks scrambled. EVENTS_CRCERROR is also 1. Is it possible that there was an error during the EasyDMA transfer?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;[/quote]
&lt;p&gt;Thanks for the update. There should not be a payload without an address match, so this makes sense.&lt;/p&gt;
&lt;p&gt;There are some errata that also includes the radio peripheral, for instance this one:&lt;/p&gt;
&lt;p&gt;&lt;a href="https://docs.nordicsemi.com/bundle/errata_nRF52810_Rev3/page/ERR/nRF52810/Rev3/latest/anomaly_810_245.html"&gt;https://docs.nordicsemi.com/bundle/errata_nRF52810_Rev3/page/ERR/nRF52810/Rev3/latest/anomaly_810_245.html&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;However, this one should present itself quite quickly, and deterministic, if you are hit by it.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
[quote user=""]My understanding regarding the on air address behavior is that if the transmitter&amp;#39;s on air address does not match the receivers on air address then I will not receive a (corrupted) data packet at the receiver end, meaning the receiver will not generate an EVENTS_END and or EVENTS_DISABLED event. Is this correct? Or is it possible that the receiver will flag that there was no EVENTS_ADDRESS event, but it will still receive the (corrupted) data packet?[/quote]
&lt;p&gt;In all wireless applications, you can get a address match based on demodulated noise, but this will usually be handled by the CRC, and not present itself as an actual payload (with correct CRC).&lt;/p&gt;
&lt;p&gt;Choosing the RF address, to avoid certain patters that resembles preamble and longer static bit patterns, should therefore be avoided &lt;span style="text-decoration:underline;"&gt;atleast on the start of the RF address&lt;/span&gt;.&lt;/p&gt;
&lt;p&gt;Ie. 0xAA / 0x55 / 0xFF / 0x00&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Q1: Could you elaborate on how your custom protocol works? Do you use any channel hopping or similar?&lt;/p&gt;
&lt;p&gt;if yes; how do you perform time-synchronization, especially when having an on-going payload being processed mid-sequence?&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Q2:&amp;nbsp;You mention every 14 seconds, is this a repeating pattern? Ie. is it always around 14 seconds, or can it sometimes be 1 second to&amp;nbsp;20 seconds?&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Q3: Does the corrupted payload show signs of valid data, or is it completely random every time?&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Kind regards,&lt;/p&gt;
&lt;p&gt;Håkon&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: on air address handling in the nRF52 family radios</title><link>https://devzone.nordicsemi.com/thread/555149?ContentTypeID=1</link><pubDate>Mon, 24 Nov 2025 08:29:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6a55fa07-007f-4d8a-908c-df842ef0716a</guid><dc:creator>Rob Garner</dc:creator><description>&lt;p&gt;A quick update. EVENTS_ADDRESS is actually 1, so a valid address was received. However, the actual data packet looks scrambled. EVENTS_CRCERROR is also 1. Is it possible that there was an error during the EasyDMA transfer?&lt;/p&gt;
&lt;p&gt;Thanks&lt;/p&gt;
&lt;p&gt;Rob&lt;/p&gt;
&lt;div id="highlighter--hover-tools" style="display:none;"&gt;
&lt;div id="highlighter--hover-tools--container"&gt;
&lt;div class="highlighter--icon highlighter--icon-copy" title="Copy"&gt;&lt;/div&gt;
&lt;div class="highlighter--icon highlighter--icon-change-color" title="Change Color"&gt;&lt;/div&gt;
&lt;div class="highlighter--icon highlighter--icon-delete" title="Delete"&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>