Probably not issue, but yes a problem with read.available . ¿ Pipe number 7 ?

[ortegafernando]

Hi, I have a complex project to works perfect (one central node and several battery nodes that send packets to the central nodes).

After 4 weeks of working perfectly, yesterday the serial output of the central node begin to write: "DEFAULT, pipe: 7" continuosly.

My sketch is like:

while(radio.available(&pipeNo)) { // Read all available payloads
    switch (pipeNo) {
            case 1:
                   //One battery node
                  radio.read( ......);
            case 2:
                  //Other
                 radio.read(......);
            default:
                 Serial.print("DEFAULT, pipe:");
                 Serial.println(pipeNo);
    }
 }

I have two questions: 1). Probably I have to make a "radio.read(.....)" in the "default" case of the switch part of the code in order to "delete that strange packet" from the RX buffer. 2). How is it possible that radio.available put the number "7" in &pipeNo when NRF24 only supports 5 or 6 (I don't remember exactly) pipes?

Probably this is not an issue, but I want to share my problem just in case anyone suffers the same.

Thanks a lot to all comunity.

[ortegafernando]

Hi, after checking source code in radio.available:

*pipe_num = ( status >> RX_P_NO ) & 0x07;

And after checking status register, it returns 111 if RX FIFO empty (see datasheet of NRF24 page 55 of 74)

So that is why i am receiving a "7" as the pipe. (111 & 0x07 = 7). (so it solves question number 2)

So my question number 1 is: NO. There is nothing to read

But I don't know how radio.available is returning TRUE, but then it is nothing to read. (some parts of the source code:

if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) )){

#define FIFO_STATUS 0x17
#define RX_EMPTY    0

RX FIFO empty flag.
1: RX FIFO empty.
0: Data in RX FIFO.

)

For me it is not a problem to autoreset my main arduino mega central node everytime I found a "7" in pipe Number (I don't know if in this library is a way to reset the nrf24, may be powerdown and starting it again? in that case do I have to reconfigure again all stuff about Reading and writing pipes?), but I don't know if it will work without powering off and on the NRF24 chip (that will be more difficult for me).

Does anybody suffers this? Can I do something in my sketch to improve it?

[Avamander]

You could try smoothing the power a bit more (100uF Tant. + 10000uF electrolytic), maybe it's some noise injected in the SPI bus?

[ortegafernando]

Thanks @Avamander .

NRF24 has been working since the first stage (more than one year) of my Project with 0.1uF ceramic capacitor and a 100uF electrolytic.

As we know, noise is not very predictable, so it could appear at anytime.

At the first step, I prefer to look for a software method to solve this, as probably noise will try to find his way ;)

I don't have also at this moment that kind of capacitors (i will buy them, but I will not recieve them soon).

Do you know any software option to check? (it is very difficult to check as when I power off my main central node to upload a new skecth and powering it on again, it can be more tan 4 weeks (or 1 day, or 1 year, how knows !!!!) to appear again noise; so it is no easy to know if that "software option" is the good one or the bad one the day after you upload it.

Also with hardware solution, as you can see noise next day or next year.

any software option?

Regards,

[Avamander]

You can try resetting the MCU to reinitialize or use a small transistor and pull the power off down, when the power is off the transistor should pull itself up with a resistor and the entire board should restart. Having a circuit like this trigger by itself might be a nice thing to have anyways, one may never know when a MCU just freezes, would be nice if it auto-recovered.

As long as the root cause it unknown it's quite impossible to recover from the error without starting just over.

[wmarkow]

Lets forget for a while about noises. I think the available method should be reworked a bit so it will act as it was defined in the datasheet. The first proposed change could be like:

bool RF24::available(uint8_t* pipe_num)
{
  if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) )){

    // If the caller wants the pipe number, include that
    if ( pipe_num ){
      uint8_t status = get_status();
      *pipe_num = ( status >> RX_P_NO ) & 0x07;
      // fix begin
      if(*pipe_num == 0x07) {
        return false;  // according to the docs there is no data available
      }
      // fix end
    }
    return 1;
  }

  return 0;
}

But it may not work for @ortegafernando when he will use bool RF24::available() instead of *bool RF24::available(uint8_t pipe_num) method (in available method we could check the pipe number always - even if the user do not asks about pipe number - and return false if it equals 7). Now we have some absurd thing because RX_EMPTY flag in the FIFO_STATUS says that there are some data available, but on the other hand the RX_P_NO from STATUS register says that RX FIFO is empty. Could it be the result of some noises? I do not know. One thing is for sure the RX_EMPTY bit in FIFO_STATUS should have a negative value of RX_FULL** bit in the same register (if I correctly understand the docs); we could use that to check if we have some noises: if both bits have the same value the we have some "forbidden state".

[TMRh20]

One can also use https://tmrh20.github.io/RF24/classRF24.html#a2e40fe66d1231a333aa2534e8491f828 to attempt to reconfigure the radio

On Dec 15, 2017, at 06:02, Witold Markowski notifications@github.com wrote:

Lets forget for a while about noises. I think the available method should be reworked a bit so it will act as it was defined in the datasheet. The first proposed change could be like:

bool RF24::available(uint8_t* pipe_num) { if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) )){

// If the caller wants the pipe number, include that
if ( pipe_num ){
uint8_t status = get_status();
  *pipe_num = ( status >> RX_P_NO ) & 0x07;
// fix begin
if(*pipe_num == 0x07) {
  return false;  // according to the docs there is no data available
}
// fix end
  }
  return 1;

}

return 0; } But it may not work for @ortegafernando when he will use bool RF24::available() instead of bool RF24::available(uint8_t pipe_num) method (in available method we could check the pipe number always - even if the user do not asks about pipe number - and return false if it equals 7). Now we have some absurd thing because RX_EMPTY flag in the FIFO_STATUS says that there are some data available, but on the other hand the RX_P_NO from STATUS register says that RX FIFO is empty. Could it be the result of some noises? I do not know. One thing is for sure the RX_EMPTY bit in FIFO_STATUS should have a negative value of RX_FULL bit in the same register (if I correctly understand the docs); we could use that to check if we have some noises: if both bits have the same value the we have some "forbidden state".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[MAKOMO]

Like this?

/****************************************************************************/

bool RF24::available(void)
{
  #if defined (FAILURE_HANDLING)
    uint8_t pnum;
    return available(&pnum);
  #endif
  return available(NULL);
}

/****************************************************************************/

bool RF24::available(uint8_t* pipe_num)
{
  if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) )){

    // If the caller wants the pipe number, include that
    if ( pipe_num ){
      uint8_t status = get_status();
          *pipe_num = ( status >> RX_P_NO ) & 0x07;
      // fix begin
      if(*pipe_num == 0x07) {
            #if defined (FAILURE_HANDLING)
             failureDetected = 1;
            #endif
        return false;  // according to the docs there is no data available
      }
      // fix end
    }
    return 1;
  }

  return 0;
}

[ortegafernando]

Thanks everybody. I will try a softwaare solution and I will try to log when happend so I think it will be better to get this issue opened. The problem is that I don't know when (pipeNumber == 7) will happend again. I will inform you, thanks a lot.

[ortegafernando]

Hi, I have upload my sketch again with this:

      case 7:
        //Failure from NRF24, probably NOISE, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        radio.stopListening(); 
        radio.powerDown();
        //re-config it as in void setup()
        nrf24reseteado = true;  //With I will send a message to my control system to detect it and verify if it works.
        nrf24 = nrf24Setup();
        break;

I will inform you some time ahead, who knows !!!! ;)

[wmarkow]

@MAKOMO, I was thinking that we could always check the pipe number, like this:

/****************************************************************************/

bool RF24::available(void)
{
  return available(NULL);
}

/****************************************************************************/

bool RF24::available(uint8_t* pipe_num)
{
    if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) ))
    {
         uint8_t status = get_status();
         uint8_t pipe = ( status >> RX_P_NO ) & 0x07;
         if(pipe == 7)
         {
             return 0;
         }

         // If the caller wants the pipe number, include that
         if ( pipe_num )
         {
             *pipe_num = pipe;
         }

        return 1;
     }
  return 0;
}

[MAKOMO]

Note that I don't have much experience with the nRF24 nor with C. Still, let me try to summaries the situation. The available() function should indicate if data is available or not. However, in some cases one receives conflicting information from the chip. Those need to recognised and the chip needs to be transferred in a "normal" state.

There are cases where RX_EMPTY indicates data available while RX_P_NO indicates at the same time that the RX queues of all pipes being empty

The nRF24 documentation does not say much about RX_EMPTY besides

p57: "1: RX FIFO empty. 0: Data in RX FIFO"

but states on p65

_"When a valid packet has been received (matching address and correct CRC), the payload is stored in the RX-FIFO, and the RX_DR bit in STATUS register is set high. The IRQ pin is active when RX_DR is high. RX_PNO in STATUS register indicates what data pipe the payload has been received in."

So RX_P_NO indicates the pipe number while RX_DR is active. It remains unclear what happens to RX_P_NO the moment RX_DR is cleared.

@wmarkow: I don't agree that RX_EMPTY should be the negative (inverse) value of RX_FULL according to the documentation. RX_EMPTY is set if data is available in the FIFO. RX_FULL is set if the FIFO is fully filled (no available locations in RX FIFO). Therefore RX_FULL will not help us here to detect "forbidden states" and I feel that it is also not necessary as with RX_P_NO a good candidate for this was already identified.

Looking around I found two more strange situations reported from other libs

a) A Python lib documents that sometimes the radio specifies that there is data in one pipe but doesn't set the RX_DR flag.

  RX_P_NO = 1
  RX_P_NO_MASK = 0x0E

  status = self.get_status()
  result = False
  if status & NRF24.RX_DR or (status & NRF24.RX_P_NO_MASK != NRF24.RX_P_NO_MASK):
      result = True

  ..
  return result

translated it would be something like

  uint8_t status = get_status();
  if status & _BV(RX_DR) or (( status >> RX_P_NO ) & 0x07 != 7) {
      return 1;
  }

So RX_EMPTY is not consulted, but RX_DR is checked instead.

b) For the MySensor.org lib it has recently reported that sometimes the RX IRQ is triggered, but no data is available. Their fix is to just clear the RX interrupt

For us a

write_register(NRF_STATUS,_BV(RX_DR) | _BV(MAX_RT) | _BV(TX_DS) );

could do this.

Regarding the "recovery" part of our problem. It remains unclear if those strange system states require to clear the RX interrupt register, a complete restart of the chip or if those states are just temporary and can safely be ignored. It might even be that the chip state is totally fine, but the lib is receiving wrong data due to a SPI read fault.

We might overdo things by setting failureDetected=1 as in my proposal. One has to see if just ignoring that status will keep the radio working, or if the radio needs a restart. How to test?

@wmarkow: So I suggest to follow your proposal for now, but I would replace the test (pipe == 7) by (pipe > 5) for robustness and add a comment as below. Only drawback is the extra SPI transaction for the get_status() over the previous available() implementation.

/****************************************************************************/

bool RF24::available(uint8_t* pipe_num)
{
    if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) ))
    {
         uint8_t status = get_status();
         uint8_t pipe = ( status >> RX_P_NO ) & 0x07;
         if(pipe > 5)
         {
             // RX_P_NO indicates "RX FIFO Empty" despite RX_EMPTY states "Data in RX FIFO"
             return 0;
         }

         // If the caller wants the pipe number, include that
         if ( pipe_num )
         {
             *pipe_num = pipe;
         }

        return 1;
     }
  return 0;
}

One more note: the sequence read_register(FIFO_STATUS) & _BV(RX_EMPTY) also occurs in the definition of isAckPayloadAvailable. Should one apply a similar check for the status of RX_P_NO there too?

[wmarkow]

@wmarkow: I don't agree that RX_EMPTY should be the negative (inverse) value of RX_FULL according to the documentation. RX_EMPTY is set if data is available in the FIFO. RX_FULL is set if the FIFO is fully filled (no available locations in RX FIFO). Therefore RX_FULL will not help us here to detect "forbidden states" and I feel that it is also not necessary as with RX_P_NO a good candidate for this was already identified.

Thanks @MAKOMO for this analysis. I think you are right. I took again a look at the docs. There is a state where the RX FIFO is not empty and is not full. So we can not use this to detect "forbidden states".

Could it be that some cheap clones - which are available on the market - sometimes doesn't conform to the docs?

[ortegafernando]

Happy new year to everybody. Finally I managed to get the same issue as a month ago. I have found in my web page the magic log: "ERROR: NRF24 reseteado por recibir pipes IMPOSIBLES" (transtale to ERROR: NRF24 has been reset because I have recieved impossible pipes".

If you remember, my code is:

      case 7:
        //Failure from NRF24, probably NOISE, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        radio.stopListening(); 
        radio.powerDown();
        //re-config it as in void setup()
        nrf24reseteado = true;  //With I will send a message to my control system to detect it and verify if it works.
        nrf24 = nrf24Setup();
        break;

With nrf24reseteado == true, in my loop I log that message to my system

The log has been recored at 23:51 Dec 31st, so I have taken my micro SD card from the "central node" serial output SD logger and this is the log:

STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xe7e7e7e7e7 0x65646f6e4a
RX_ADDR_P2-5     = 0x47 0x43 0xc5 0xc6
TX_ADDR      = 0xe7e7e7e7e7
RX_PW_P0-6   = 0x00 0x0c 0x0c 0x0c 0x00 0x00
EN_AA        = 0x3f
EN_RXADDR    = 0x0e
RF_CH        = 0x6c
RF_SETUP     = 0x25
CONFIG       = 0x0f
DYNPD/FEATURE    = 0x3f 0x06
Data Rate    = 250KBPS
Model        = nRF24L01+
CRC Length   = 16 bits
PA Power     = PA_HIGH

So everything has been ok.

May be @TMRh20 or @Avamander think that there is something to do with the library, buy if anyone is using this or, probably, any other NRF24's library, I will recomend to check pipe nº 7 and reset/reconfigure again your NRF24 chip.

May be is not the best option, but, at this moment, is works perfect

NOTE: I am fitting now with ackPayloads with my differents pipe (up to 3, no more, like the TX buffer), no luck.

Regards.

[MAKOMO]

What would be interesting to know is if this restart/reconfigure (powerDown(), nrf24Setup() in your code) is strictly needed to overcome this issue. Wouldn't it be enough to just ignore this case (eg. modify available() to return false in those situations as in the code proposals above) until new data is received? Would this new data fix the pip number returned by available()? Also of interest would be if your nRF24 chips that show this issue are original ones from Nordic or not.

[ortegafernando]

Hi, first of all it is very difficult to detect the problem. My previous code, as I say in the first post, only print in serial port that there is something from Pipe 7, but each loop, radio.available returns true for that pipe. I haven't tried to read pipe 7 (probably impossible), so I prefer to restart it.

I dont want to change the library's code because i am not an expert.

Chips were bought some years ago in ebay, I can't ensure that they are originals (as I don't buy them from Nordic., but it is also true that they seem original, and thet were bought when there weren't such kind of fake chips. If you know a way to know if they are origina or not, please, tell me.)

If you or anyone more think that is better to change the library, it will be also perfect way to solve this problem .... or not ?

Regards and happy new year.

[MAKOMO]

I think this should be handled in the library as it might happen thus rarely also in other cases. I understand that this is difficult for you to further dig down on this and that the restart resolves it for you. Still it would be good to better understand this and you seem to be the first/only to be able to reproduce this (rarely). It would be helpful if you could try what would happen if you replace your case 7 by the following

        //Failure from NRF24, probably NOISE, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        //radio.stopListening(); 
        //radio.powerDown();
        //re-config it as in void setup()
        nrf24reseteado = true;  //With I will send a message to my control system to detect it and verify if it works.
        //nrf24 = nrf24Setup();
        Serial.println("case 7 encountered");
        break;

and see if the system works beyond the point the "case 7 encountered" is printed.

[ortegafernando]

Hi, it pefectly works beyond that point, but you will fine each loop "case 7 encountered" forever, as you "can't read and take away from the hipotethycal RX buffer the payload from pipe 7".

Your pseudo-code is what I had before and after connecting the serial output data logger (in micro sd) was when I detect this issue/problem/nothing.

I don't know, may be you have to say to NRF24 IC to reset/empty the RX buffer., or whatelse.

Regards,

[MAKOMO]

There is a function to flush the RX buffer exported

uint8_t flush_rx(void);

[ortegafernando]

Ok, I could try and inform you again. I hope it wil be less than a month ;)

[MAKOMO]

Excellent! Thanks a lot for this. If this is successful, we could add this flush_rx to the library patch discussed above.

[ortegafernando]

Hi, I have just updated my sketch:

      case 7:
        //¿Failure? from NRF24, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        //¿noise?

        //Solucion del 17/12/17: intentar resetear el NRF24 
     //   radio.stopListening(); 
     //   radio.powerDown();
        //Y ahora lo reconfiguro de nuevo
     //   nrf24reseteado = true;
     //   nrf24 = nrf24Setup();

        //Solucion 180102: vaciar el buffer RX
        radio.flush_rx();
        nrf24reseteado = true;

        break;

Now, I have to wait,

Thanks.

[ortegafernando]

Hi, it has finally appeared. First it appeared the day I powered my central node and flush_rx forced my central node to send more than 70 times the GSM message (one per minute), but yesterday it happened again and only with one message it has worked perfect.

I mean, every time I "get" some data in "pipe 7" I stablish "nrf24reseteado = true" and after I send a GSM message and put nrf24reseteado = false.

First day, as flush_rx didn't work, my central node was resending each loop the GSM message, as it was receiving continuosly in pipe 7. After 70 minutes (and more or less 70 GSM messages) it stopped.

Yesterday, with only one flush_rx worked.

I don't know what it is. May interference, or another thing.

I think that people that read this could implement one solution, reset NRF24 completely or ony flush_rx.

        radio.stopListening(); 
        radio.powerDown();
        //Y ahora lo reconfiguro de nuevo
        nrf24reseteado = true;
        nrf24 = nrf24Setup();

or

        radio.flush_rx();
        nrf24reseteado = true;

I will choose the first one, as I don't mine to reconfigure it again.

I hope this helps somebody.

Regards and thanks to everybody. If you have any more question, please, tell me.

.

[ortegafernando]

HI, today I have found again the same error. I have registered in my web page that my central node "has received again a packet in pipe 7". After call radio.flush_rx() one time, the central node has worked perfectly.

I think we could consider that flush_rx is enought, so if you recieve some information in pipe 7, please, flush_rx or reset your RF24.

Regards,

[Avamander]

@ortegafernando Thank you for your help on solving this issue, it's quite valuable for everyone using nRF24s, it's really appreciated. I'll definitely keep it in mind when building my own projects, that's for sure.

[ortegafernando]

Hi @Avamander , the real help is yours and @TMRh20 and all people that develop this great libraries. Regards,

[MAKOMO]

@Avamander: shouldn't available() be changed to get rid of this issue at the level of the lib for all users?

/****************************************************************************/

bool RF24::available(void)
{
  #if defined (FAILURE_HANDLING)
    uint8_t pnum;
    return available(&pnum);
  #endif
  return available(NULL);
}

/****************************************************************************/

bool RF24::available(uint8_t* pipe_num)
{
    if (!( read_register(FIFO_STATUS) & _BV(RX_EMPTY) ))
    {
         uint8_t status = get_status();
         uint8_t pipe = ( status >> RX_P_NO ) & 0x07;
         if(pipe > 5)
         {
             // RX_P_NO indicates "RX FIFO Empty" despite RX_EMPTY states "Data in RX FIFO"
             // we flush the RX buffer to resolve this for now
         flush_rx();
             return 0;
         }

         // If the caller wants the pipe number, include that
         if ( pipe_num )
         {
             *pipe_num = pipe;
         }

        return 1;
     }
  return 0;
}

[Avamander]

@MAKOMO The issue I see with this is that it somewhat breaks backwards compatibility with those projects that have already built an error recovery system, it also isn't a guaranteed and documented solution (we really don't know what causes it and with what hardware, maybe it's a clone behaviour because I've never seen it?). I'd gladly add this code to one of the examples and the documentation though if someone makes a pull request.

[MAKOMO]

@Avamander I only partially agree as I don't see how this could break backwards compatibility. The source of the issue is indeed unclear but I guess I suffered from this myself (without having a concrete proof). In my recent experiments using only original Nordic chips connection was lost after longer periods (3-4 weeks with a 1min ping interval) and never recovered. Only a restart resolved this in any case, but I was not able to catch really catch and document the real cause yet mostly because it happens that rarely. Might have been exactly the issue discussed here. I would prefer to have this resolved on the level of the library and don't see how it could interfere with any regular operation. Sure this wastes some additional bits of program code...

[Avamander]

@MAKOMO As I said, somewhat break, when case 7 is already dealt with, system triggering some external reset circuitry for example, changing that would then require modifications to the library to revert the in-library handling.

[ortegafernando]

Hi everybody again. I have still mantained the serial output logger from my central node. Today I have check my database and I have more than 200 messages about "packet in pipe 7". And very "crazy" output from the data recieved by NRF24. It has last more than 6 hours, some times recieving illogical data form nodes and sometimes with a continuosly "pipe 7's packets".

So "flush_rx" doesn't work well in my case.

but why I know that resetting the NRF24 will help?

Because the central node has finally exit from this endless loop as it reboot itself (watchdog) when it doesn't recieve any packet from any node in two hours.

I have seen the logger and after two hours of horrible "pipe 7's packets", the central node has reset itself (not only NRF24), and after that, good packets, no more pipe 7's packet, no more illogical data from nodes, ....

So for me, and for finish it I would use this solution:

      case 7:
        //Failure from NRF24, probably NOISE, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        radio.stopListening(); 
        radio.powerDown();
        //re-config it as in setup()
        nrf24reseteado = true;  //With I will send a message to my database to detect it and verify if it works.
        nrf24 = nrf24Setup();
        break;

As during this strange behaviour I have also recieved data in pipe 0 (my switch case has also a "default case" just in case), I will do the same, reset my NRF24. It seems that the NRF24 get some noise. I don't know. but suddenly it begins to work bad

My final code is:

  while(radio.available(&pipeNo)) { // Read all available payloads
    switch (pipeNo) {
     case 0:
        Serial.println(F("NRF24, something from pipe 0"));
     case 1:  
        radio.read(&data, sizeof(data));
        //Do stuff with data from node 1.
        break;
     case 2:  
        radio.read(&data, sizeof(data));
        //Do stuff with data from node 2.
        break; 
     case 3:  
        radio.read(&data, sizeof(data));
        //Do stuff with data from node 3.
        break; 
     default:
        //Failure from NRF24, see: https://github.com/nRF24/RF24/issues/394#issuecomment-352171932 
        //Fue detectado por mi, a veces te dice que tienes RADIO.AVAILABLE pero luego al leer no tiene nada,  y provoca un 7 como pipe (lo cual es imposible).Puede ser NOISE

        Serial.print(F("DEFAULT, ERROR recibido desde pipeNo: "));
        Serial.println(pipeNo);

        //Solucion del 17/12/17: intentar resetear el NRF24 
        radio.stopListening(); 
        radio.powerDown();
        //Y ahora lo reconfiguro de nuevo
        nrf24reseteado = true;
        nrf24 = nrf24Setup();

        //this solution doesn't seem to work well.
        //radio.flush_rx();
        //nrf24reseteado = true;
    }
  }

The central node and others nodes are for my brother in law, as he doens't ask for them yet, I will have them in my house so I will continue logging data from the serial output of central node.

I hope you find this solution good if you notice some strange behaviour in your DIY projects. It is also a good advice to have a good serial output logger (in my case in MicroSD) to find this kind of probems.

Bye.

[MAKOMO]

@ortegafernando thanks for this further piece of information. Now that we know the flush_rx() is not enough to resolve this, I am interested in how exactly you "reset" your nRF. I see that you call radio.stopListening(); and radio.powerDown(); and I assume the nrf24Setup() is just doing a radio.begin(); radio.startListening(); and maybe sets also the PA level via a radio.setPALevel(RF24_PA_LOW); right?

[ortegafernando]

Hi @MAKOMO nrf24Setup() actually is the function that I also call in the setup part of my sketch. I mean, it is exactly whole setup process.

In my case, this is:

boolean nrf24Setup() {
    // Setup and configure radio RF24
  radio.begin();
  radio.setAutoAck(1);                    // Ensure autoACK is enabled (is on by default)
  radio.enableAckPayload();               // Allow optional ack payloads
  radio.setRetries(15,15);                  // In multiples of 250us, max is 15. 0 means 250us, 15 means 4000us.
  radio.setPayloadSize(MAXIMOPAYLOAD);
  radio.enableDynamicPayloads();          //Recomiendan por si acaso hacer esto (con el AckPayload es necesario)
  //Solo activo el IRQ para lo recibido
  #ifdef WITH_SLEEP
    radio.maskIRQ(1,1,0);
  #endif
  radio.setDataRate(RF24_250KBPS);

  radio.setChannel(108);           //above wifi
  radio.setPALevel(RF24_PA_HIGH);  //MAX gives more errors (usually)

  radio.openReadingPipe( 1 , addresses[0]);      //Open a reading pipe on address 0, pipe 1 
  radio.startListening();                 // Start listening

  radio.powerUp();

  #ifdef DEBUGRF24
    printf_begin();
    radio.printDetails();                   // Dump the configuration of the rf unit for debugging
  #endif

  return radio.isChipConnected();
}

[zhekaus]

Hello. I also get data from pipe 7 with 1 byte zero-valued payload. However, if I use simply available(), there is no such payload. Weird.