can nRF24L01 really upto 2M bps? &what is your prj's ba

Hello, Sparkfun community. I have successfully drived the nRF24L01, but it only can stream data upto 220K bps. i compute the baud by the steps below:

step1: the transmitter transfers 60 x 32 bytes (60 pcs payload, 32bytes per payload);

step2:on the same time, the other side, the receiver starts timer when it get the first active IRQ. During the receiving payload, the receiver count how many payload it have received.

step3:After receiving all the payload, the receiver stops the timer. by now, i know the count of received payload and the time. according to these two factor, i get the baud.

My questions are, is my test method wrong? if not, why the baud is only 220k bps not at least 1M bps?

I now feel very confused, Can anyboby help me? Does anyboby run nRF24L01 at a higher baud?

Thanks for reading.

Keep in mind that your packet has a substantial amount of packaging. It’s like sending a fragile item in the mail. It may only weigh 10 grams, but by the time you get done protecting it, it may weigh 100 grams. Between the preamble, address bits and CRC you are adding a substantial amount to your payload. If you send it with less “protection”, it will substantially increase throughput, but the chance of loss goes up considerably. Also auto ack will increase transmit time dramatically. For transmission of a couple of meters, you may not need all that extra padding. Try experimenting, but try to stay with a two byte CRC.

Hope this helps,

Ron

I have done some testing, and if you strip off everything you possibly can, you can actually reach (or get extremely close to) the theoretical maximum data throughput. This requires a 3 byte address and no CRC, however. You also have to send 32 byte packets constantly, with no ACK or anything like that. The theoretical maximum is somewhere around 1.75 Mbps.

This setup is only good for streaming applications that do not need guaranteed packet delivery, as it provides no acknowledgement. You will also likely see a lot of noise packets at the receiver as the CRC is turned off. Also, the new datasheet that came out said that you should only leave a unit in TX mode for at most 4 ms, and every time you go from into standby back into TX mode you have to wait around 130 uS for the 24L01 to get sync’ed up.

If you are not using auto-acknowledgement, you can calculate your theoretical maximum relatively easily. The preamble is always present and is always 1 byte. You can choose 0, 1, or 2 CRC bytes. You can also choose 3, 4, or 5 address bytes. On top of that, each packet may contain anywhere from 1 to 32 payload bytes. Therefore, the number of bytes you have to send in a given packet can vary from 1 + 0 + 3 + 1 = 5 bytes anywhere up to 1 + 2 + 5 + 32 = 40 bytes. Then your utilization would be the number of payload bytes you sent (the 1 to 32 byte part) divided by the total number of bytes in the packet. Finally, your overall data throughput would be the selected bit rate (1 or 2 Mbps) multiplied by the utilization.

Take for example the settings for maximum data throughput I described above. The settings were 0 CRC bytes, 32 data bytes, and 3 address bytes. We will also use a bit rate of 2 Mbps. Then, if we can constantly transmit data and never drop a single packet (which doesn’t happen in real life), we get a utilization that looks like this:

Througput = 2 Mbps * (32 / [1 + 0 + 3 + 32]) = 1.78 Mbps

Given different settings, YMMV.

Now i know how '1.78 Mbps ’ comes. Thanks so much for all replies. i will keep on trying after my vacation. if i cann’t make my prj speed up to 600kps, i will drop my prj. it is a cruel thing to me. Can anyboby share how high the baud your nRF24L01 speeds up to?

Thanks for reading.

Well if maximum without CRC is 1.78Mbps, maximum with 32 bytes packet, 3 bytes of address and 2 byte CRC is 1.68Mbps, a bit lower, but you won’t pick up noise. Try with auto-acknowledgement activated, speed will drop, but 600Kbps may be possible. Use a good antenna, since it reduces the number of packet lost and increase speed.