nRF24L01 fast TX

Discussion about wireless devices

nRF24L01 fast TX

Postby SteveD » Mon Nov 24, 2008 8:21 pm

Hi,

I would like to transmit consecutive packets as quickly as possible with the nRF24L01. Is there a way to keep the radio actively transmitting for more than 1 packet at a time? Or is it just about limiting the delay time between transmissions?

Thank you,

Steve
SteveD
 
Posts: 3
Joined: Mon Nov 24, 2008 7:13 pm

Re: nRF24L01 fast TX

Postby brennen » Mon Nov 24, 2008 8:46 pm

You can certainly do this. Basically, you hold CE active and make sure that you always have at least one payload in the TX FIFO. If you're using my library, you would call nrf24l01_write_tx_payload() to load up your payloads, but you would leave the second parameter (bool transmit) set to "false". Once you got your payload(s) loaded, you would call the nrf24l01_set_ce() function to keep CE set. Whenever you get a TX_DS interrupt, you would load the TX FIFO with a new payload.

Keep in mind you need to *always* have at least one payload in the FIFO *in addition to* the one that is being transmitted. That way, the 24L01 will not have to wait on you to load a new payload up to transmit it once it finishes sending the current payload.

There are two things to keep in mind, though. Proper operation of the RX unit requires that you take it into standby mode to read the RX payload, which then requires a 130 uS delay to return to active RX mode. Also, the datasheet recommends on p. 21 that you shouldn't keep the TX in active mode for more than 4 mS at a time.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24L01 fast TX

Postby SteveD » Tue Nov 25, 2008 8:57 pm

Thanks a lot Brennan,

It's working nicely now. It wasn't working for a while and it just turned out I needed to turn my processor speed from 8 MHz to 16 MHz to keep up. Otherwise it would send the first 3 packets together, and then one packet at a time from then on. I suppose I'm using a non-proper method of receiving the packets by not going into the standby mode, but it's getting all the packets so I'm happy. Do you know the reason for not exceeding 4 mS of active transmission?

Best,
Steve
SteveD
 
Posts: 3
Joined: Mon Nov 24, 2008 7:13 pm

Re: nRF24L01 fast TX

Postby brennen » Mon Dec 01, 2008 12:52 pm

According to the datasheet, the reason for that is that the PLL runs in open-loop mode while you are in active TX mode. Therefore, it has no feedback to ensure that it is keeping the proper clock time, so you could get out of sync if you go longer than 4 ms. I really wish they would fix this, personally. :x
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24L01 fast TX - how fast can you get?

Postby domen » Mon Dec 22, 2008 1:09 pm

Hello!

How fast do you manage to communicate between two chips?
With nRF24L01+ I managed about 2100 packets/second with acknowledgements (~60kB/s), and ~6350 p/s (~200kB/s) without (and static payload lengths of 32B, 5 byte addr, 1 byte CRC).

ACK way seems a bit slow, even thought I understand it needs to switch from tx to rx and reversed.

I also have problems with noACK way. I seem to miss a few packets (<1%), but OK, that's low, and I need to implement some retransmittion protocol on top in any case for larger distances, obstructions.
What's really bugging me is that I get duplicate packets at rate of >2%.

I was thinking maybe something is wrong with my RX procedure (polling), but I tried multiple ways:
1)
if ((reg_read(STATUS) & REG_STATUS_RX_P_NO_MASK) == REG_STATUS_RX_P_NO_MASK)
retry
otherwise
read payload
optionally ack RX_DR, no difference if i do or not

2)
ff ((reg_read(REG_FIFO_STATUS) & REG_FIFO_STATUS_RX_EMPTY) != 0)
retry
otherwise
read payload
optionally ack RX_DR

3)
if ((nordic->status & REG_STATUS_RX_DR) == 0)
retry
otherwise
read payload
ack RX_DR
/* this one makes it miss about 2/3 of the packets */

CPU is 72 MHz arm cortex-m3, fwiw.
So, anyone managed to transmit data at full speed? Can you share (pseudo)code?
Ideas, tips?
domen
 
Posts: 7
Joined: Mon Dec 22, 2008 12:49 pm

Re: nRF24L01 fast TX

Postby brennen » Mon Dec 22, 2008 4:43 pm

The fastest way I was able to get the chip to send data was with no ack, 3 byte address, no CRC, 32 byte payload, 2 Mbps mode, and constantly transmitting (this breaks the rules in the datasheet). By doing this, I think I was able to get around 1.74 Mbps of actual data throughput over the link. Obviously, this is not the type of settings you would want to see in a real world application, but it does give an upper bound on what you can do with the chip.

With my code, I can't say I've ever had any issues with getting duplicate transmissions. My guess would be that it is likely a bug somewhere in your code. You are correct that using auto-ack will definitely bring down your data throughput, but it is really the fastest way to ensure throughput, since you rule out the delays inherent with using your own acknowledge/retransmit algorithm. Plus, it ensures that all of the proper timings are adhered to. You can always take a look at my main()function in my tutorials to see how I do my polling routines (all of my tutorials use polling).
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24L01 fast TX

Postby domen » Tue Dec 23, 2008 2:17 pm

And you were able to receive that data clocked at 1.74 Mbit? With the code from tutorials?
Because checking RX_DR works too slow here.

My current theory is not that duplicates are transmitted, but "received" (ie. R_RX_PAYLOAD not deleting payload from FIFO right after it's received).
domen
 
Posts: 7
Joined: Mon Dec 22, 2008 12:49 pm

Re: nRF24L01 fast TX

Postby brennen » Tue Dec 23, 2008 5:26 pm

I assumed that when I got an interrupt that I was receiving data, so I did receive data, but I didn't read it out (I don't think I deleted the stuff out of the FIFO, either). I used the tutorial code, but obviously modified it to work with this configuration, and also didn't check for the RX_DR interrupt ove SPI. This code is overall pretty useless from an application standpoint, but like I said, it was just there to be a proof of concept.

Are you sure you're clearing CE on the RX side when you receive a packet, before you read it out? If so, the hardware automatically deletes the packet. If you don't, the R_RX_PAYLOAD command *won't* delete the packet and you have to do so manually.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24L01 fast TX

Postby domen » Tue Dec 23, 2008 6:39 pm

I'm not clearing CE on RX. Why should I? And won't that make it miss packets? And more importantly: delay for 130us for each packet?
My datasheet says for R_RX_PAYLOAD: "Payload is deleted from FIFO after it is read"

http://www.nordicsemi.no/files/Product/ ... on_1_0.pdf
domen
 
Posts: 7
Joined: Mon Dec 22, 2008 12:49 pm

Re: nRF24L01 fast TX

Postby brennen » Wed Dec 24, 2008 3:05 pm

It's one of those things that really isn't documented properly. All I can point you to is p. 66 where it tells you the proper sequence for RX mode. I will say that in all of my experiences with the 24l01, if you don't clear CE before you read a packet out of the RX FIFO, it will not be deleted by hardware. In that case, you have to delete it yourself by using the FLUSH_RX command. It will only make you miss packets if you haven't implemented your TX to take the delay at the RX into consideration.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Next

Return to Wireless

Who is online

Users browsing this forum: No registered users and 2 guests

cron