I have adapted my RF73/RFM73 library for the NRF24L01. These chips are almost identical, except that the RFM73 has a second bank of registers that must be initialized with some magical values. The RFM73 has a special command to switch between the banks, and a bit in the status register that indicates the current bank. This provides a good mechanism to test for the presence of the chip (switch the the other bank and check that the bit in the status register toggles), without disturbing any settings or transmitting anything.

Has anyone found a feature of the NRF24L01 that can be used in a similar way to test for the presence of this chip?

  • \$\begingroup\$ Do you mean the nRF24L01+? No one uses the nRF24L01 any more, AFAIK. \$\endgroup\$ Jun 19, 2013 at 18:30
  • 2
    \$\begingroup\$ Then I guess my name is no one. I use some dx.com modules, maybe the chip in those is in reality a 24L01+ or 24L01B, I'll check. If anyone wants to answer the question for one of those related modules feel free!+ \$\endgroup\$ Jun 19, 2013 at 18:34
  • \$\begingroup\$ @WoutervanOoijen One of the nRF24 modules I purchased from eBay was an L01 not L01+, but the seller was nice enough to replace it free of cost when I pointed this out. Would you want to try that? When I checked just now, the cheaper modules are L01, while the slightly pricier ones are all L01+ apparently. \$\endgroup\$ Jun 20, 2013 at 18:22
  • \$\begingroup\$ No need to try, I have both in stock. But my questions is still: is there a convenient way for the application to check if the chip is present? (For extra points: how to distinguish an L01 from an L01+) \$\endgroup\$ Jun 20, 2013 at 18:37
  • 2
    \$\begingroup\$ You can use the Status byte to check for presence. Every first byte you send to the chip, it answers back with the Status byte. So you can send a dummy and read the Status. \$\endgroup\$ Jun 25, 2013 at 14:58

2 Answers 2


This library distinguishes the NRF24L01 from the NRF24L01+ by trying to set the 250Kbps data rate. If it succeeds then the chip is of the + variety. You might also try just powering the chip on and off. It seems unlikely that you would disturb other driver software? by setting and re-setting these settings. https://github.com/jpbarraca/pynrf24/blob/master/nrf24.py#L671


I don't know all your constraints, i.e. how many bytes you dare send if you're worried about some other SPI device being present instead or whatnot, but assuming you're willing to do some communication [SPI, not necessarily RF] and that you are exclusive user of that selected SPI device, seems there's plenty of ways to approach this:

  • if you know the radio will have been power-cycled to its defaults, check that RX_ADDR_P0 is 0xE7E7E7E7E7. Doesn't completely rule out noise, and a few more bytes than checking e.g. RF_SETUP byte, but seems a decent bet.
  • if you're fine writing to the device, set RX_ADDR_P0 to some hardcoded unlikely or random signal value, and see if it reads back correctly. Likewise with any of the other config (SETUP_RETR seems a nice candidate for a single-byte value).

None of these will confirm other pins have been hooked up…for that you'd probably need to attempt an ACK'ed send where it will likely fail (and thus your CE pin if connected should cause MAX_RT status bit to be set and IRQ pin signalled). Nor might they distinguish from a potentially similar device or whatnot. But just for basic SPI wiring check the bulleted items above should suffice IMO.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.