nrf24l01+ Real Data Rate

Wireless & IoT
1

Hi. I’ts my first post here, and english is not my primary language so…

I have purchased two transceivers nrfl2401+, and I was searching around the forums, and the web about the real speed transfert of usable DATA.

Since I have found nothing about that, I have made my own tests, and here I write the results to all of you, for a quick reference.

Setup:

Atmega168 clocked at 16 mhz, with SPI speed set at 8 MHZ (Max settings)

The nrf24 chip programmed with 5 bytes Address, 16 bit CRC, and Auto ACK using Enhanced shockburst.

The calculation was made by calculating the time to transfert a DUMMY 1 meg of data (1 024 000 bytes)

Take note that the rate here is with 0% packet loss

32 Bytes Payload:

1-At 250 kbit speed:

66 seconds for 1 meg of data=15.5kbyte/s (124 kbit/s)

2-At 1 mbit speed:

26 seconds for 1 meg of data=39.4kbyte/s (315 kbit/s)

3-At 2 mbit speed:

19 seconds for 1 meg of data=46.5kbyte/s (372 kbit/s)

In theory, the speed at 2 mbit is supposed to be twice the speed of the 1 mbit right? So, why it’s not the case? It’s simply due to the SPI transfer.

The air rate increase, but the SPI rate remain the same, but is quite acceptable.

I have also tried the same test, but this time with a payload of 5 bytes.

at 250kbit, I can reach only 4.5k sec
at 1mbit, 10.8k sec.

So, if you need an high amount of data, pay attention to your payload setting. It have a big influence on the real Usable data rate.

Also, the packet loss at 32 byte payload and 5 bytes payload seems to be about the same.

I hope this information will help you with your designs concerning real Data speed rate.

Mast3rbug.

http://www.innovativedevice.com

2

Thanks for posting your test results! Very handy.

3

Good info,

I always wondered what the real data rate was with those chips.

4

I was interested in using those chips in a project of my own, do you have any data with auto-ack off?

5

Unfortunately, I have not made any other test than these one…

You want to send data without any notification? So Auto ack off, and auto retry off, no CRC?

Also, note that I think you can go faster than that if you enter the 3 fifo buffer before starting the RF radio. I will have to make some test with this.

Mast3rbug, www.innovativedevice.com

6

I was thinking of putting together a wireless solar powered camera. But I’m not sure this chip will handle the bandwidth required if you add more than one cam.

7

Humm… Did you do the math?

Okey, lets take just the poorest resolution that we can get on a camera so QVGA (Quarter VGA) 160x120, suppose we have the poorest color depth, RGB 8 bit, and we use a really slow frame rate, 10 frames/second.

total bytes to transfer: 160x120=19.2kbyte for 1 frame

At 10 frame/second: 19.2kx10=192kbyte/second.

The nrf24L01+ will do the best with no error correction and really to the limit, 70kbytes/second

So, If you does not have some kind of high compression algorithm, you definitively have not enough bandwidth on this IC.

I listen to my own TV on my cell phone, at about 80kbyte/second, full quality, but the signal is compressed at the other side by a core Duo :shock:

But if you want to pass some still image, it’s ok.

A good solution can be purchase an tcp/IP camera, run it on solar, put a small wifi router and a Yagi antenna at each side, and you will do up to 10 miles in line of sight easily.

If you are interested in more details, just check my web site, I have all that you need.

Cedric, www.innovativedevice.com

8

great to see practical data !

Can you share with us what was the distance between the transceivers?

And what hex address did you use?

And the dummy data, was it like all 0x00 or all 0xFF ?

And where there any active wifi / bluetooth devices in the neighbourhood?

I did tests with nrf2401 (without auto-ack but with crc) and I saw that the link was less reliable for certain addresses containing many 0’s or 1’s like 0x0000 or 0xff00. Also the packet contents did matter. This effect is also mentioned in the data sheet.

9

Maybe next time I’ll set a timer to count how long it will take to transmit a packet until the ACK singal is reseived.

But I’ve done the test that transmit a 32byte packet with ACK, twice , in 1ms. The data rate is at least 2100032*8 = 512Kbps. The data is ADC data of an acclerometer, the address is set 0xC5 5C C5 5C C5.

:roll:

10

Don’t forget the 130us of delay switching from RX to TX and vice versa, as well as the ACK packet. Assuming 32 byte packets, and ACK packets without payload and 2 byte CRC, the total bits per round-trip are 68 + 9 + 328 + 28 = 329 bits for the TX and 68 + 9 + 28 = 73 bits for the ACK for a total of 402 bits per packet. At a data rate of 2 Mbps, that is 201us. The two TX/RX switching times add up to 260us however, so we spend more time switching than transmitting. In the absolute best case, assuming a perfect PHY, no interference and 100% channel utilization, it would take 461us to transmit a packet, so the maximum number of packets per second is 1,000,000 / 461 = 2169, and the maximum useful data rate is thus 216932*8 = 555 kBps or 69.4kB/sec for an efficiency of almost 28% of the raw data rate. I’m curious how close anyone has gotten to this.

More interesting might be the maximum data rate without ACK/retransmission. I’d guess that in most cases it is far more efficient to do less frequent higher level retransmissions. So, let’s just use 3 bytes for the address and 1 byte CRC. Total bits per packet now is 4*8 + 9 + 32 * 8 + 8 = 305 bits, or 152.5us. More importantly, there are no more switching delays, so the theoretical maximum packet rate is 6557 packets per second, or 1679 kBps, or 209.8 kB/s. This is an efficiency of about 84%, so removing the automatic ACK/retransmission may triple throughput.

Say we’d want to transmit 1MB of data, and an error rate of 0.1% per 32-byte packet, we’d expect about 3 packets with errors. If each 256-bit packet includes a 1-bit sequence number (alternating between 0 and 1) and 1 bit of CRC data, then every 32 packets (1kB) we’d be able to determine which packet, if any, was corrupt, and also have a high degree of confidence in the correctness of the entire 1kB packet transmitted if it matches the 32-bit CRC. So, including the retransmission of 3 packets taking 4 * 461us (1 retransmission requests plus 3 responses, all with ACKs), or about 2 ms, the total transmission time would be (102410248/254) * 152.5us + 2ms = 5.04s. This compares with 15.1s for the automatic ACK variant.

11

How did you make this test? I don’t know why i have some problems about speed. I send and receive data then count the number of 32 bytes packets. After 1 second passed, i stoped and print how much pakets’ve been sent. It is just 10 or 11 packets which means about 320 bytes.

ACK is on.

I tried in different datarates and output powers and also changed spi’s prescelar.