<?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+ payload lenght &amp;gt; 32</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/883/nrf24l01-payload-lenght-32</link><description>The documentation clearly state that if the payload length is read as &amp;gt; 32 byte, the RX FIFO must be flushed.
My question is, will that erase all other pending messages even if they have been acknowledged to the transmitter. 
 If other messages are</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 26 Nov 2013 13:08:19 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/883/nrf24l01-payload-lenght-32" /><item><title>RE: nRF24L01+ payload lenght &gt; 32</title><link>https://devzone.nordicsemi.com/thread/4331?ContentTypeID=1</link><pubDate>Tue, 26 Nov 2013 13:08:19 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6e01e5cb-eb76-485e-9c3c-4c6cda6ef65e</guid><dc:creator>H&amp;#229;kon Alseth</dc:creator><description>&lt;p&gt;Hi Mike,&lt;/p&gt;
&lt;p&gt;You can check if the FIFO is empty or full.
Then you have covered scenarios with either 0 packets or 3 packets.
However, if the FIFO STATUS register is not empty and not full, you have either 1 or 2 packets in the FIFO. There is no option to read out if it&amp;#39;s 1 or 2 packets.&lt;/p&gt;
&lt;p&gt;In theory you can come across a scenario where you get two packets back-to-back and you&amp;#39;re not servicing the interrupt fast enough (&amp;lt;250 us), and one is corrupted and one is valid. The only solution is to flush the FIFO.
Normally this is not an issue (especially when using ACK), as the ISR-handling usually does not take that long.&lt;/p&gt;
&lt;p&gt;Best regards
Håkon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>