mtwieg:
brennen:
The way that the code is written in Sparkfun’s example isn’t correct. When you receive a packet at the RX, you are supposed to bring CE low and then read out the payload. Once you read the payload, you bring CE high again to start trying to receive data. This way, the 24L01 will delete the packet out of the FIFO automatically. You don’t need to flush the RX FIFO manually by doing it this way. This confused me when I was first learning about the 24L01, too.
I can’t find any reference to this in the datasheet at all. You also mention it in your tutorial 0. I’m not saying you’re wrong, since I have no hands on experience with the device. But it would seem odd that such a very important nuance isn’t mentioned in the documentation. Or am I just missing it?
There are some things that were actually better in the old version of the 24L01 datasheet. It gave a relatively clear sequence of events on what to do to transmit or receive packets. Here is the section on receiving:
old 24L01 manual:
Enhanced ShockBurstTM Receive Payload:
-
RX is selected by setting the PRIM_RX bit in the configuration register to high. All data pipes that shall receive data must be enabled (EN_RXADDR register), auto acknowledgement for all pipes running Enhanced ShockBurst™ has to be enabled (EN_AA register), and the correct payload widths must be set (RX_PW_Px registers). Addresses have to be set up as described in item 2 in the Enhanced ShockBurst™ transmit payload chapter above.
-
Active RX mode is started by setting CE high.
-
After 130μs nRF24L01 is monitoring the air for incoming communication.
-
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 will be active when RX_DR is high. RX_P_NO in status register will indicate what data pipe the payload has been received in.
-
If auto acknowledgement is enabled, an acknowledgement is sent back.
-
MCU sets the CE pin low to enter Standby-I mode (low current mode).
-
MCU can clock out the payload data at a suitable rate via the SPI interface.
-
The device is now ready for entering TX or RX mode or power down mode.
mtwieg:
If you lower CE to read a packet, does this mean the RX has to warm up for another 130us in order to receive again? This seems like it would drastically lower transmission rates.
You do indeed have to wait the 130 us. The alternative is to do it the way that Sparkfun did and risk flushing just-arrived packets out of your RX buffer when you flush the old one. Either way is a trade-off.
Also, keep this little nugget in mind for the TX unit (p. 21 of the new datasheet):
new 24L01 manual:
The nRF24L01 transmitter PLL operates in open loop when in TX
mode. It is important to never keep the nRF24L01 in TX mode for more than 4ms at a time. If the auto retransmit is enabled, the nRF24L01 is never in TX mode long enough to disobey this rule.
mtwieg:
edit: actually it mentions something on page 65. It says to bring CE low to bring it to standby1, then clock out the payload, but it never says anything about the payload ever being cleared automatically. In fact the only mention I can find about clearing the RX FIFO is with the flush command. What you said seems logical though; one should expect it to automatically clear data after a read, just like the PTX clears the TX fifo after a TX (and ack, if necessary).
If you read on p. 46 of the datasheet, this is described for the R_RX_PAYLOAD command:
new 24L01 manual:
Read RX-payload: 1 – 32 bytes. A read operation always starts at byte 0. Payload is deleted from FIFO after it is read. Used in RX mode.
mtwieg:
So if you’re correct and it’s not necessary to manually clear the RX FIFO with the flush command, then wouldn’t this still be faster than allowing it to do it automatically by bringing it to standby? 130us is a lot in certain applications, and doing a simple flush command would take far less time.
It goes back to whether you can miss packets as I described above. Also, I'm guessing the RX unit is running in open loop during RX (as the TX does during TX, as noted above), so you probably shouldn't run it continuously.
mtwieg:
Also, I saw this in [this thread
brennen:
Keep in mind that with auto-ack, the RX will act as a TX briefly when it acknowledges a packet. It does not appear that you have changed the TX address of your RX unit in your code, which would make sense for the TX unit not getting the acknowledgement back.
I don’t see anything like this in the datasheet either. As I understood it the PRX doesn’t need to know the PTX’s address beforehand, since you should have configured the PTX’s pipe 0 address to be the same as its PTX address (which will also be the same as the PRX’s pipe address). Therefore to send an ACK the PRX simply has to send a packet to the address of the pipe it received the packet on, which will be the pipe 0 address of the PTX. Does this make sense?[/quote]
According to the new datasheet on p. 37,
new 24L01 manual:
To ensure that the ACK packet from the PRX is transmitted to the correct PTX, the PRX takes the data pipe address where it received the packet and uses it as the TX address when transmitting the ACK packet.
To clarify, there is no data in the packet that an RX receives that tells it what the address of the TX was that sent the packet. Therefore, the RX just uses the address of the pipe the data was received on to transmit out the ACK. So in a sense, you do have to have prior knowledge of what the TX’s address actually is. But you can solve that problem like you suggested, by setting the pipe 0 address and the TX address of the TX to the same address as that of the pipe that you’re sending data to on the RX. You are correct that I made a false statement in that quote, however.](http://forum.sparkfun.com/viewtopic.php?t=11402)