nRF24L01+ for a network of low power sensors - Page 1
Forum section: electronics / projects

author: RoGeorge
author_rank: Super Contributor
timestamp: October 05, 2025, 08:44:08 am
content: Would like to log the indoors humidity/temperature with 2-3 wireless sensors powered from batteries. Have already two modules with HTU21D temp/humidity sensors, and two with DHT11 sensors, a few AT89C2051 (8051 MCUs), and nRF24L01+ modules for wireless.Reading the nRF24L01+ datasheet as we speakhttps://docs.nordicsemi.com/bundle/nRF24L01P_PS_v1.0/resource/nRF24L01P_PS_v1.0.pdf, and it doesn't seem to have any low power mode while still listening for incoming packets.The remote temperature+RH sensors will be battery powered, so interrogating them from a central station is not an option, because interrogating the sensors will imply to keep the receiver listening, so powered, in the remote sensors. So, I guess the remote sensors will have to wake up by themselves, transmit T and RH, then go to sleep until the next data send. Though that will make the whole network of sensors unidirectional, the remote sensors will be able to transmit only.The receiver is supposed to stay connected to a PC, so to log the measurements, so for a first version the receiver can be powered from the USB, and can keep its Rx radio on at all times.However, with 4 remote sensors that can only transmit, and can wake by themselves, there can be transmission collisions. How is this usually solved in nRF24 based networks? Is there a way to have bidirectional communication between the sensors and the central receiver, but without heaving to keep the sensors awake (in Rx) all the time?If not, then how is one suppose to choose which radio channels to use? I guess the 2.4GHz is usually crowded, so if the radio channel is at a fixed frequency and can not be negotiated, there might be situations when the nRF network might not be able to work at all without manually changing the radio channel. Or maybe this is not so critical in practice?How these 2 are usually solved in a nRF24L01+ network:- How to have a bidirectional link, yet keep the remote nRF24L01+ in standby for low power (battery powered sensor)?- How to find/choose/change to a radio channel that is not busy?

author: brucehoult
author_rank: Super Contributor
timestamp: October 05, 2025, 08:56:40 am
content: Those were a great chip in 2005, but there are usually better options now. Perhaps BLE on an ESP32 (all models)? Or the newish CH570 with a similar simple 2.4 GHz packet radio to the nRF24L01 (it might even be compatible, I'm not sure), or LoRaWAN.

author: RoGeorge
author_rank: Super Contributor
timestamp: October 05, 2025, 09:27:35 am
content: Fully agree with that, just that this is a hobby project, made with whatever happens to already have at hand, parts sitting unused since many years now: nRF24L01+, HTU21D, DHT11. If you think the radio solution is less than optimal, just wait to hear about the MCU: AT89C2051.That's an MCU from the 90's or so, with an 8051 core, only 128 bytes of RAM and 2kB of flash, has no dedicated I2C/SPI/UART peripherals (only a shift register), yet the nRF24 is SPI, the HTU21D is I2C, and the PC logging is made by a serial port. And the I/O ports are open drain. And to use an I/O bit as input you'll have to set that I/O output to 1 first.There will be a lot of flippin' bits involved, and that's the whole fun of it, to put all together. Doesn't even matter if it will eventually log the temperature or not.

author: FireBird
author_rank: Regular Contributor
timestamp: October 05, 2025, 10:09:20 am
content: The nRF24L01 has the ability to ACK a packet and the transmitter can automatically retransmit several times if it doesn’t receive the ACK from the receiver. There are registers that tell your sensor if the transmission was successful so your software can react accordingly.See the chapter about “Enhanced ShockBurst” and ACK packets.

author: corgon
author_rank: Contributor
timestamp: October 05, 2025, 10:41:58 am
content: That's not a problem at all. I've built several devices using the NRF24 where the receiver draws around 300 µA and has a response time under 100 ms. In your case, it's even simpler. On the receiver side, you can, for example, set a loop where it listens for 50 ms, then sleeps for 500 ms. The transmitter keeps sending data in a loop until it receives an ACK from the receiver – and that's it. Then the transmitter can go to sleep mode.There's a lot of information about this online. Look up something like "NRF24 reducing the receiver power consumption", or check out how the ANT+ protocol works – it's based on a similar principle.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 05, 2025, 02:51:50 pm
content: As FireBird said. This won't be a problem especially with only a few nodes, as it handles retransmission automatically (if you enable it).And yes, each node sending packets periodically (and sleeping the rest of the time) and one listener on at all times is the most common way of doing it for achieving low power for nodes. BLE operates pretty much in the same way.If you don't need nodes to communicate with one another but only to a "gateway", this is rather straightforward. And the nRF24L01+ are great chips for that. Very simple to use with only a few registers to configure.If you can fit node data in a single packet (max payload size is 32 bytes), that greatly simplifies your custom protocol too, as data doesn't need to be sent fragmented.