Go Down

Topic: nRF24L01+ and strange behavior of skipped packet counts  (Read 94 times) previous topic - next topic


I established my first NRF24L01 link recently using code published by iforce2D at
http://forum.arduino.cc/index.php?topic=260197.0   on Aug 10, 2014.  Thank you, iforce2D.

Now I want to establish a rapid rate data link (of a few bytes only per measurement) over a path with variable path loss, and plan to use the changing "skipped packet count" at the receiver (see iforce2D's code if necessary) as a indicator as to when to increase the transmit power to maintain the link.  To enable a fast data rate I am operating the link with no ack, no retry, attaining a transmit rate of about about 1,200 pkts/sec. (See link at http://forum.arduino.cc/index.php?topic=462707.0)  The receiver seems to be capable of handling up to 4,700 pkts/sec.

It is relatively easy to establish a link with zero skipped packets. If I then slowly move the transmitter and receiver apart, while viewing the receiver packet loss on the screen (printed for every 1000 packets received) I expected to see the packet loss to increase in a relatively smooth monotonic fashion. It does not.  Instead it stays at zero until a critical spacing when, in a couple of lines of printout it changes to 55 pkts (per 1000 pkts read) and often stays there, fixed at 55, for about 18 successive lines of printout before falling to 0.  Moving the transmitter further away the count remains at 55 until suddenly it start to jump all around, say 100, 145, 125, etc.,  even if the transmitter (and I) then become motionless.   Even then it may, surprisingly, spontaneously recover to 55, or sometimes occasionally even to zero (as mentioned before) - as if the link had some adaptive self healing properties - which I don't believe.

When repeating the experiment at a different time and with some location changes, the "stable" skip count (previously 55) has been low as 22 and as high as 61, but for a given experiment it is essentially fixed.
I note that 55 packets losses summed over about 18 lines of print out  =  1000 lost pkts.  This seems to be far more than coincidence especially since 55 skips on about 18 lines often repeats with subsequent trials

A lot is going on here that I do not understand. I am hoping someone can explain it to me, or point me to some appropriate link or give me some hint.  There are three main issues:
a) why the abrupt step in the packet skips count as the Tx/Rx separation increases
b) what decides the observed persistent "fixed" size of the step in a given experiment (even though it may vary between experiments)
c) how come the link often recovers to zero pkt loss after ~1000 pkts (18 rows of 55 skips) are lost.

I'll appreciate any advice you can offer.

For a couple of dollars the nrf24L01 is an amazingly rich learning/teaching device. But I need a hint or two to facilitate my learning.
(As an aside,  my present aim it to learn when I need to increase the transmit power (for my project). I am choosing to ignore, for the present, how I will learn when I need to reduce the transmit power)  


I'm not familiar with the code example you are using but the behaviour you mention does not surprise me. At its margins wireless transmission is unpredictable. That's why the nRF24 has the facility for acknowledgements and automatic retrires.

Can you describe the application that needs 1200 messages per second?

Simple nRF24L01+ Tutorial
Two or three hours spent thinking and reading documentation solves most programming problems.


From my career in satellite communications I am confident that most of my issue is more related to the nrf24L01 design and implementation than the predictability, or otherwise, of RF communications. This is not to imply that the design and implementation is deficient, I just don't know enough about it, yet, to take full advantage of its pretty amazing capabilities.  As an example I am confident that the abrupt step between 0 and 55 lost pkt/s sec is more related to the nrf24L01 design and coding than RF path loss ( which would not have a step).

The 1200 pkts/sec is what I determine the transmitter to be capable of.  When I get the observed skipped packet numbers to be more directly related to the actual RF path loss, then they will have statistical (noise) variations on them - as indeed they do when the RF path loss is deliberately increased to go beyond the 55 skips threshold.  The (fortuitous) high pkt rate will allow for statistical manipulation of the (noisy) skip values to (hopefully) determine the trends in RF path loss in sufficient time to take mitigating action, i.e. adjust the transmit power level.

The planned application (in model railroading) will do fine with 5 (good) datapoints/sec to determine the trend in received signal power.  Regrettably, the nrf24L01 does not provide for a continuous measure of received power level. I am trying to work around that absence.


From my career in satellite communications
In that case you probably know 100 times more about it than I do.

I am using nRF24's for model train control and I have had no problems. I send about 10 messages per second and if the locomotive misses more than 10 messages in a row it stops - I think the only time that happened in actual use was when the hand-unit batteries went flat. And in one application there are 4 pairs working on the same channel but with a different address for each pair.

Two or three hours spent thinking and reading documentation solves most programming problems.


Thank you for your interest. My project is a smidge more complex involving a big public museum Lionel O-gauge layout with very poorly documented proprietory locomotive remote control  at 455 KHz - which fails in tunnels. The plan is to use an Arduino + nrf24L01 on the loco to telemeter the measured strength of the 455 khz signal received by the loco in the tunnel out to a nrf24L01 + Arduino + laptop  outside the tunnels. This requires that the quality of the 2.4GHz link be very assured and certain, regardless of the tunnels. Hence the interest in understanding just what makes the 2.4 link work or fail.   


Sounds to me like it would be a lot simpler just to replace the existing remote control with a system using nRF24 modules, or maybe HC12 (433MHz) modules if there is a risk that the 2.4GHz signals cannot penetrate the tunnels.

On the other hand, it hardly seems necessary for model trains to receive wireless signals while in tunnels - can't they steam along at constant speed until they emerge?

Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up