<?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>nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/19548/nrf24l01-addressing-issues</link><description>Hey everybody, I&amp;#39;m having &amp;#39;intermittent&amp;#39; issues with device addresses on the nRF24L01+. I&amp;#39;ve read the documentation on what you&amp;#39;re not supposed to do as far as device addressing goes (i.e. 0xAA and 0x55 are preamble bytes and 0x00 and 0xFF can cause packet</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 03 Mar 2017 08:09:04 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/19548/nrf24l01-addressing-issues" /><item><title>RE: nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/thread/75989?ContentTypeID=1</link><pubDate>Fri, 03 Mar 2017 08:09:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2f113ab9-d809-4266-941e-38330a66fa98</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Those addresses look much better. In our older address generation guide lines (for the nRF24L01) we recommended to avoid repeating the same byte over and over, but if you don&amp;#39;t notice any higher packet loss it&amp;#39;s probably fine.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/thread/75988?ContentTypeID=1</link><pubDate>Fri, 24 Feb 2017 17:36:32 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:21c0b06c-bb6b-482d-80d6-047b71bbdb7e</guid><dc:creator>gacekky1</dc:creator><description>&lt;p&gt;Hmmm... That&amp;#39;s unfortunate. But thank you for replicating the test! Now I can say for sure to avoid these addresses.&lt;/p&gt;
&lt;p&gt;I have each TX Pipe set up like so:
Default for pairing: 0xD2, 0xD2, 0xD2, 0xD2, 0xD2
PIPE0: 0x0A, 0x01, 0x01, 0x01, 0x01
PIPE1: 0x0B, 0x01, 0x01, 0x01, 0x01
PIPE2: 0x0C, 0x01, 0x01, 0x01, 0x01
... And so on. This seems to work fine.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/thread/75987?ContentTypeID=1</link><pubDate>Wed, 22 Feb 2017 12:03:25 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5fc6b1e1-79f1-4b95-ac5c-de9180fcbec4</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi again&lt;/p&gt;
&lt;p&gt;On closer inspection my test was a bit flawed. I was just measuring received packet loss, not the loss of ACK.
When measuring the received ACK&amp;#39;s (not just the received packets) I also got 100% packet loss on the worst addresses:&lt;/p&gt;
&lt;p&gt;Lost ACK percentage:
FFFFFFFFFF: 4.5%
0000000000: 100%
0100000000: 100%
0000000001: 1.4%&lt;/p&gt;
&lt;p&gt;With the modified test I got better results when setting byte 1 to 0x4D, compared to 0x21 (&amp;lt; 0.5% packet loss).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/thread/75986?ContentTypeID=1</link><pubDate>Wed, 22 Feb 2017 08:54:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9a1e1e47-693e-4ac6-b20a-a47f51654d9c</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;Probably our address generation guide lines should be a bit more demanding.
Having very few bit shifts in the address is sure to cause issues, as is addresses starting with 0x55 or 0xAA (since it matches the preamble).&lt;/p&gt;
&lt;p&gt;I ran som tests on the addresses you mention, and my results were comparable to yours:&lt;/p&gt;
&lt;p&gt;All 0xFF: ~5% packet loss&lt;br /&gt;
All 0x00: ~50% packet loss&lt;br /&gt;
0100000000: ~40% packet loss&lt;br /&gt;
0000000001: ~1.2% packet loss&lt;/p&gt;
&lt;p&gt;If the first byte of the address is good I think you can choose the remaining bytes freely without risking massive packet loss. I did some testing on my own and found that there were plenty of options for the first byte that would yield good results even if the remaining bytes were all 0&amp;#39;s or all 0xFF&amp;#39;s.
As an example 0x21,0x00, 0x00, 0x00, 0x00 showed 0% packet loss across the board (100 packets on 3 different frequencies, 2Mbps bitrate and the default retransmission setting of 3).&lt;/p&gt;
&lt;p&gt;I am not able to explain why some of the poor addresses are better than others. I will check with one of the analog designers in case they have some theories.&lt;/p&gt;
&lt;p&gt;Best regards&lt;br /&gt;
Torbjørn&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF24L01+ addressing issues</title><link>https://devzone.nordicsemi.com/thread/75985?ContentTypeID=1</link><pubDate>Fri, 17 Feb 2017 09:37:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:68a48145-3caa-4658-99f2-ed35d07ac5da</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;In general you should avoid addresses with very few bit shifts, such as the ones you include here, but I wouldn&amp;#39;t expect communication to fail completely.
I will try to reproduce the issue on my end, and get back to you when I get some results.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>