Does anyone know what sort of performance I can expect from these things? I'm making a modular motion capture system where you have an arbitrary number of sensor nodes each with their own battery and transceiver, and the master loops through and pings each one for its data. Master calls openWritingPipe with the target slave's address, sends a 16 byte data packet, and the slave returns its sensor data via the AckPayload mechanism.
But now that I have it working, the transmission frequecy seems too low to be useful. With a single slave, I'm getting about 5 successful transmissions per second out of ~100 attempts at 250kbps, and up to 10 successful out of ~200 attempts per second at 2mpbs. I've tried various channels and it makes no difference, and having the slave on battery power makes no difference. I haven't tried master on battery power since I need the serial output to see what's happening. I have it set at 1 retry with 5ms delay. Below that and nothing gets through, above that results in lower attempts per second due to more time spent waiting, but successful transmissions per second is unchanged.
My particular application only needs 6 slaves, and the 16 byte packet from the master is not essential, so I could rework it to one-way communication where the master listens and the slaves each send their data on different pipes. But if my low success rate for AckPayload transmissions is not typical, then I'll continue debugging this system.
It very much depends on the local interference - leakage from a microwave oven on the same channel can knock it out pretty effectively, since they share the 2.4GHz band. I've certainly seen high reliability operation at any of the baud rates with suitable antennas at modest ranges - don't expect a large range at 2.4GHz with a low power transmitter, especially if there are obstacles in the way.
Have you tried the version with PA+LNA?
What range are you testing at? (BTW there will be both an upper and lower range limit for reliable operation).
No, mine have the little zigzag antenna on the PCB.
There doesn't appear to be any lower limit. I can get up to about 10 feet with no obstruction and the success rate remains unchanged. 20 feet with a plywood wall in the way reduces the success rate a bit, and 25 feet with a thick wall results in near zero success.
Microwave is not running, and as far as I know the closest thing broadcasting on the 2.4GHz band is the router, but its signal is very weak in my room due to distance and walls.
I need at least 90 transmissions per second for 6 nodes at 15Hz update rate, but I'd like to get at least twice that.
Ah, it is a bug in my code. It occurred to me to try compiling the AckPayload example I'm working from and modify it to transmit as fast as possible and report the success rate. It's getting 100% success with 610 transmissions per second at 250kpbs, or 573 transmissions per second if I add a call to openWritingPipe before each one like I'll be doing in my program. I'll report back once I track down what I did wrong.
Update: The problem turned out to be insufficient processor speed. It looks like the sensor library is configured to fully utilize a 16MHz Atmega328P, but I'm running on 8MHz so I don't need a voltage booster for the 3.7V battery and because the sensor and RF24 are 3.3V. So the sensor library always has 15 updates queued up, and processes them all at once, which blocks the AckPayload from being refilled for ~200ms, resulting in my ~5 transmissions per second. If I discard every other sensor update, then the queue stays empty and I get about 40 transmissions per second.
I'm still getting some confusing behaviod from the RF24 setRetries function. Delay set below 5ms fails like it did before, but count set to 0 still gets through. But even if the master does suffer a 5ms delay for each sensor node, I should be able to get 30Hz or close to it with my 6 nodes.
Thanks for listening, and hopefully my measured transmission rates will be helpful for someone else in the future.
Yes, that matches my experience - the range isn't large without a proper antenna and the LNA/PA, and even then isn't huge.
The 2.4GHz band is used for many purposes including microwave ovens, industrial uses and WiFi, so often there is a lot of bandground present on the band. WiFi uses spread-spectrum techniques and tends to look like a high noise floor while its active. Trying to pick a carrier frequency between the WiFi channels may help.
The topology you've described, where the master pings each sensor node, does not sound optimal for battery operation. At least not over an extended period. The sensor nodes would have to be active the whole time to respond to any contact from the master. That would mean a power consumption of around 20mA (for the basic NRF24L01 without PA and LNA).
Thanks for the heads-up. I figured power consumption when listening would be negligible compared to the arduino churning away on the sensor data, but checking the datasheet it looks like the NRF consumes even more power when listening than it does actively transmitting (how is that even possible?). The datasheet I'm looking at says 11-12mA, not 20, but the arduino and IMU sensor are only about 3.5mA each, so it may indeed be worthwhile to rework it so the master is the listener. My 400mAh batteries should provide plenty of runtime regardless, but it would be nice not having to recharge as often.
Yes, The current consumption of these modules in receive mode is surprisingly high. With some NRF24L01+ clones/fakes it can be worse. However, even with 400mAh batteries, and the lower figure from the data sheet, you are still looking at recharging every two days or less.
If your application allows it, it would be better to organise a cycle where the MCU sleeps for a period, wakes, switches on the sensor , switches on the radio and transmits, then shuts everything down and resumes sleep. Naturally, that means that the receiver should really be powered via mains.
I published a project, actually a mailbox monitor, which uses this structure. The battery on the transmitter lasts well over 2 years. Arduino NRF24L01 Mailbox Monitor/Notifier
Because you need headroom for the 1st stage mixer to prevent overload when other nearby signals are present at high level. The RF signal you want may easily be millions of times less powerful than an interfering signal, and unless you handle that interfering signal linearly it will intermodulate all over your wanted signal and completely swamp it. This typically means that front-end circuitry has to run at a high enough power to handle the unwanted signals from nearby sources of interference.