SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By lucicop
#33143
Have you guys checked out the new version of the nRF24L01 specifications ? It does explain better some things, and adds documentation for some hidden features of the chip, like dynamic packet width and TX with no ACK ;)

I will try tonight to solve the addresses problem... It is very strange that if I write only to Pipe0's address, then the communication works, but if I write also the addresses of Pipe1 and Pipe2, I cannot get to communicate with Pipe0 neither. This keeps going until I power cycle the nRF... so it seems that I am overwriting Pipe0's address when I think I'm writing Pipe1 or Pipe2 address...
By lucicop
#33144
Guys !

The problem is solved. With the aid of Nordic's technical support, I've found my mistake: the LSByte was unique only for pipes 1 to 5. I had misunderstood the datasheet and thought that for pipe 0 it is completely independent. It's not ! The last byte need be unique for all 6 pipes.

Now I'm happy because a small creepy problem with nRF24L01 has disappeared :)

Thank you all for your replies !

Regards,
By brennen
#33147
I found it at http://www.nordicsemi.no/files/Product/ ... n_v2_0.pdf.

This new spec is a bit bittersweet. After learning just about everything there was to know about this little guy (or so I thought), they come and say that they had kept like 3 features hidden that would have been really helpful. Now I have to go back and rewrite Tutorial 0. :x

On the other hand, it is pretty sweet to get the use of the additional features, especially the dynamic payload feature. If nothing else, the user manual is far superior to the old one (although I almost knew the old one by heart 8)).
By lucicop
#33153
You are right about the reaction to the new specs. I have a driver almost developed, and now I need to redesign some parts to take advantage of the new features "unlocked". I find also useful the TX_NO_ACK feature, in order to have some packets acknowledged, and the broadcast ones sent without acknowledgement.
By lucicop
#33235
Does any of you have managed to use the new features ? Especially the dynamic payload length...I don't know how to get the length of the packet by using that SPI command...
By lucicop
#33404
Well, in the meantime, I have managed to get them working. Reading the payload width is done like reading a normal register. There was a strange problem that it was returning sometimes values greater than 32. If I flush RX after receiving a packet, it works. The selective ACK feature also works OK, and I was expecting something like that, because it's useful for broadcast packets, that need a special treatment. I plan to send the broadcasts a few times, in order to get them through. If you need help, I am available to answer your questions about what I've already got working with the nRF24L01.
By kpainter
#33425
Hello lucicop,
After you pointed me to take a look at my addresses in another thread, I got auto-ack to work. Shortly there after, I moved on to dynamic payloads which seems to work fine. Many thanks.

I wonder if the reason you are getting values greater than 32 is that there are really more than 32 bytes available in the FIFO? If I understand correctly, there are 3 - 32 byte FIFOs. According to note b. of table 24 of the v2 datasheet, you are supposed to read the payload, clear the RX_DR interrupt and then read FIFO_STATUS to see if there are more payloads available.

I don't know if that explains it but apparently you can write up to 3 tx_payloads before initiating a transmission. I think I am going to try writing 3 32 byte payloads and see if the reported number of bytes is 96.
Regards,
kpainter
By lucicop
#33431
Hi,

I'm glad I could help.

Yes, your idea is interesting and worth checking. But according to the datasheet, this shouldn't be the case. They say that the payload width is indicated for the top FIFO packet...

Regards,
By kpainter
#33434
Hi,
I tried loading up all three FIFOs and 32 bytes is reported on the receive side. I have not seen it report more than 32 bytes as of yet so not sure why you are seeing that. If you figure it out, I would like to hear what caused it.
Regards,
kpainter