Electronics > Projects, Designs, and Technical Stuff
Setting Up the nRF24L01 for Transmitting, and Receiving
Kalcifer:
--- Quote from: janoc on May 12, 2021, 06:01:52 pm ---If you need low power (which is likely why you were looking at the nRF24L01+ in the first place), then nRF52 or nRF53 series could be a good fit - ARM Cortex core, radio that can handle Bluetooth Low Energy, Zigbee, ANT, Shockburst (the nRF24L01+ protocol) and many other things and still very low power consumption. E.g. the recently released Apple AirTags use nRF52 SoCs.
--- End quote ---
Is the nRF24L01 obsolete? I took a look on nordic's website, and in the nRF24 section, it says "not recommended for new designs" and then lists the nRF52 series chips as alternatives. Would the nRF52 series chips have improvements in range? They use Bluetooth 5.2 bluetooth low energy. Not sure how that stacks up to the performance of the nRF24 series.
sleemanj:
--- Quote from: MarkF on May 13, 2021, 12:39:29 am ---My guess is you can go 20 meters, but 30+ meters is probably pushing their range for the PCB antenna.
--- End quote ---
The PCB antenna is limited as a transmitter, but as a receiver it's pretty decent.
It's all about the antenna really you can do some very long distances if there's nothing in the way...
https://www.youtube.com/c/iforce2d/search?query=NRF24L01%2B
janoc:
--- Quote from: Kalcifer on May 13, 2021, 04:05:39 am ---Is the nRF24L01 obsolete? I took a look on nordic's website, and in the nRF24 section, it says "not recommended for new designs" and then lists the nRF52 series chips as alternatives. Would the nRF52 series chips have improvements in range? They use Bluetooth 5.2 bluetooth low energy. Not sure how that stacks up to the performance of the nRF24 series.
--- End quote ---
nRF24 is not really obsolete (as in end of life/not made anymore) but they would want you to phase it out. It is likely going to be around for a long time, though, a lot of products use these radios.
nRF52 does not use BLE. nRF52 is capable of running BLE but not only - it is a multiprotocol radio and with the exception of Bluetooth Classic and Wifi it can probably handle every common wireless protocol.
Not sure what you mean by "performance of the nRF24 series". Bitrate? That's a function of the protocol, both SoCs have 2Mbps capable radios. Shockburst on nrf24L01+ is 250kbps-2Mbps (AFAIK). That's the same on nRF52.
Power consumption? I had nRF52832 take about 6mA while running the full Bluetooth Low Energy/Bluetooth Mesh stack and actively advertising. When sleeping it is down in uA territory. nRF24L01+ takes about 12mA when transmitting. So that's comparable (the different protocol I have used prevents 1:1 comparison here).
Plus nRF52x is has an ARM core with built-in flash you can run your own programs on, nRF24L01+ requires another micro to act as a host because the SoC isn't user programmable.
janoc:
--- Quote from: SiliconWizard on May 12, 2021, 09:30:04 pm ---Agreed, those ICs are actually pretty good. Sure they are barebones - that's what they are meant to be. But yes they draw little power. The protocol is pretty raw. But you can implement your own protocol on top of that. I've seen a project implementing simple BLE with them. AFAIR, Nordic also provides a protocol that you can use with them: Gazell.
--- End quote ---
You can run the same Shockburst protocol even on the nRF52, it is compatible and officially supported.
nRF24 can't run BLE, the radio is "hardwired" and is unable to broadcast/receive data in the required format. It was only "abused" to send BLE advertisement packets with a bit of hackery, so it can act as e.g. the iBeacon style tag. Not much else.
nRF52 can run the following (but not all models - the ones with smaller flash can't run everything due to the size of some of the sw stacks):
- Bluetooth Low Energy
- Bluetooth Mesh (based on BLE but not compatibile with it)
- ZigBee
- Thread (IPv6 based mesh network)
- ANT (very low power protocol used mostly in fitness equipment)
- IEEE 802.15.4 (low level protocol, basis for ZigBee, Thread, 6LoWPAN, SNAP, MiWi ...)
- Shockburst and Enhanced Shockburst (same as nRF24L01+)
- Gazell (proprietary Nordic thing)
- NFC (has a separate antenna for it)
Possibly more, because there are some other protocols that are built on top of Shockburst or IEEE 802.15.4 that can run on these SoCs. Some parts have also USB, so if you need to build a dongle to interface e.g. a mesh network to a PC, these are ideal parts for it (and, in fact, many BLE dongles contain them for this reason).
If someone wants to mess with this, I would strongly recommend looking at the Zephyr project first instead of trying to work with the Nordic SDKs. It is much easier because you don't have to deal with the Nordic RTOS blob ("softdevice"). Zephyr is completely open source so if anything goes haywire (and it will, especially when implementing complex stuff like BLE or some mesh) it is much easier to debug than getting a hard fault from the softdevice and then wondering where in that binary blob it faulted and why.
https://www.zephyrproject.org/
tonytruong:
Hello ...
My name is Tony Truong. I am a beginner and trying to make 2 x nrf24L01+ to communicate with 2 UNO R3.
I follow the code sequence of MarkF (in this forum) to set them up. They don't really work as I expected.
Note: I write code in assembly and using SPInterface with CE on PORTD bit 7, CSN on PORTB bit 0
On receiver side ...
With CE = 0
I set up all parameter and then cfg_reg to 0x0B and delay ms
Then CE = 1
Looping on fifo_status (reg 0x17) .. checking bit 0 if RX is NOT empty ...
Upload code to receiving UNO
On transmitter side ...
With CE = 0 ...
I set up all parameters and the cfg_reg to 0x0A ... delay ms
Writing W_TX_PAYLOAD ... then CE=1 ... delay ms then CE=0
Upload code to transmitting UNO
I saw the data is received by the receiver once.
I did several experiments and observed these strange things:
- Intended data sent to receiver EVEN I put a break before/in front CE=1 ... looks like nrf was in standby-2 mode but data was sent even before CSN de-asserted (W_TX_PAYLOAD writing sequence not completed yet)
- Status reg (addr = 0x07) = 0x1F ... Max num transmit Interrupt ... TXFifo FULL ...
- Fifo_status reg (addr - 0x17) = 0x21 ... TXFifo Full ... RXFifo Empty
- On receiver side .. received all intended data that were sent from transmitter ... code read all received data out and print on terminal
- Status reg content (addr 0x07) = 0x4E .. RX_DR=1
- CE=0
- Code write 1 to reset RX_DR .... but can not get reset to 0x0E
- Receiver can not receive afterward as this bit is SET
Please help. I can copy and paste assembly code if needed.
Thanks a lot and have a good day.
Tony Truong
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version