nrf24l01 and dynamic payload width

Wireless & IoT
1

First up - thanks for the tutorials, which have been really handy so far. I have a remaining problem with getting Dynamic Payload Widths to work, which is pretty much the last thing I need to understand.

I have two NRF24L01 modules, attatched to individual MCU’s. Basic to and fro works fine, I’ve switched to DPL because I am wanting to send packets in excess of 32 bytes between the two, and don’t want to have to send in multiples of 32 bytes all the time.

On the TX side, my send routine cuts the packet into <32 byte chunks and sends them individually (sends the first, waits for an interrupt meaning it sent successfully or timed out waiting for an ack, then sends the second.) I can see that on a 36 byte packet the first 32 bytes send OK, and the remainder time out waiting for an ack. Maybe not the fastest way, but speed isn’t that critical.

On the RX side, bizarre stuff is going on! I receive the RX_DR interrupt, and drop CE. I then try and issue R_RX_PL_WID to read the payload width. This returns me 0x40, which is clearly wrong. I do R_RX_PAYLOAD which I cap at 32 bytes - if I try and read more I get gibberish as you’d expect. I then raise CE, but don’t get any more data.

Things I am not doing…

  • RX_FLUSH: tried this in various places to no effect.

  • Reading payload length AFTER reading the data - all this did was give me the return value of 0x4E instead of 0x40

I’d really appreciate some help on this as I’m struggling to see how this all fits together and up till now it’s been reasonably sane. :slight_smile:

2

If you use a PIC, I extended Brennen’s library with the DPL code and functions. Maybe that would help. It is running fine here.

3

I use the Atmel ATMegas actually, but the PIC code has been easily readable. If you’ve got DPL working, is there any chance I could take a look at the code? I get the feeling I’m missing something small and obvious and that’s why it’s not working.

4

Ah, I knew this would happen: all it takes is to make your predicament public and suddenly the answer comes to you.

I have this fixed now, and it was something silly. :oops: Where the product spec lists R_RX_PL_WID as a command with 0 (actually, unspecified, but I assumed 0) data bytes, I had that under the same case as commands like FLUSH_RX, NOP etc that return the result of shifting out the command with SPI. Which as we all know is the contents of the STATUS register. Shifting out R_RX_PL_WID and then a 0, I return the right value. :slight_smile:

5

Yeah, the datasheet is not very clear on that indeed. Cool that you have it working. If somebody wants to see or have my code, that is no problem!