Networking and communication with Nordic NRF52 devices, NRF24L01 & Arduino

Networking and communication with Nordic NRF52 devices, NRF24L01 & Arduino

Opening up new possibilities

So I recently created a new library (nrf_to_nrf) to communicate with NRF24L01 devices with the new NRF52x devices like the XIAO BLE SENSE 52840 sent to me by Seeed Studio. These devices open up some new possibilities as far as networking go and can be put to use in many different applications. 

For example, the XIAO Sense 52840 has an on-board Gyro & Accelerometer making it useful for things like simple quadcopters, drones etc, and if used in combination with a high power NRF24-based transmitter, long distance control can be achieved with this tiny device. It is also very much suitable for Audio transmission and reception, allowing full-duplex audio transmission and reception at 1Mbps (using the ACK-Payload functionality) of the radio devices. 

In contrast to the NRF24L01 which has 6 addressable pipes and can transmit up to 32-byte payloads, the NRF52x devices have 8 addressable pipes and can transmit up to 127-byte payloads. This opens up things quite a bit when it comes to networking these devices, allowing mixed NRF24L01 and NRF52 networks, and when NRF52x devices are solely used, expands the number of devices in RF24Network and RF24Mesh networks and the maximum transmission sizes. The NRF52x devices also have on-board encryption capabilities, enabled in nrf_to_nrf, so users can now create encrypted networks and communications scenarios.

I really like the NRF52x devices, specifically this little XIAO board, there are no pins to connect to the radio, and no issues with power supplies etc. I recently also updated the Auto Analog Audio library I created to support recording on these devices as well, making it possible to transmit audio over radio link using that library in combination with the nrf_to_nrf library. The code is still in its initial phases, without full functionality yet.

Modifications required to use the full capabilities of NRF52 only networks:

RF24 layer: Set the maximum payload size. Up to 125 with CRC disabled or 123 with 16-bit CRC. Use radio.setPayloadSize(123); or radio.enableDynamicPayloads(123);

RF24Network: Open RF24Network.h and set MAX_FRAME_SIZE to 111, Open RF24Network_config.h and set NUM_PIPES to 8

RF24Mesh: Open RF24Mesh_config.h and set MESH_MAX_CHILDREN to 6

See https://github.com/TMRh20 and https://github.com/nRF24 for all related libraries and documentation.

NRF52840 and Arduino: Encrypted and Authenticated Radio Mesh Networks

 NRF52840 and Arduino: 

Encrypted and Authenticated Radio Mesh Networks

In a recent post, I mentioned using the on-board encryption module of the NRF52840, and I've made some decent headway so far! I've finally gotten my encrypted driver working with RF24Network and RF24Mesh and am pretty happy with the results. 

One of the nicest parts of this is it doesn't add any overhead to RF24Network or RF24Mesh itself, since the encryption is incorporated at OSI layer 2. This means that when we transmit a 32-byte payload with RF24Network or RF24Mesh, all those layers see is the unencrypted data. The radio at layer 2 will add some data onto each payload and encrypt it, then decrypt it and present the unencrypted data to the higher layers.

For example, the current overhead of this implementation for encryption is 12-bytes. A 5-byte Initialization Vector (IV), a 4-byte Message Authentication Code (MAC) and a 3-byte packet counter. The radio driver adds this data on in the background, so if you have a 24-byte payload to send, RF24Network adds on its 8-byte header and the 32-bytes of data is sent to the radio driver. The radio driver will then encrypt the data, send an actual 44 bytes of data over-the-air, then decrypt it and present 32-bytes of data back to the RF24Network layer.

Tip: If using this library with the RF24Network or RF24Mesh layers, open RF24Network.h and set the MAX_FRAME_SIZE to 111. Then, per the included examples, the higher layers will handle the larger packet sizes that the NRF52840 is capable of. Make sure to set it back to 32 for communication with nrf24 devices.

There are still a number of questions I have regarding this implementation, but in any case, the library is functional, but don't quite expect full security just yet. There are a number of things to be investigated and worked out regarding how exactly this CCM module is supposed to be driven.

Another thing that is intriguing here is the break from the OSI model, since encryption is typically defined to be implemented at the presentation layer, way high up on the stack. I don't know why, but it feels like a better opportunity to encrypt as much of the data as possible, publicly transmitting only what absolutely needs to be public information. The design of the RF24 communication stack generally follows the OSI model, so the hope is that this will make up for a lack of presentation layer moving forward. It looks like some tasks can still be left up to the presentation layer, like rekeying and managing timestamps to prevent things like replay attacks.

The library with encryption enabled has now been released, get it via Platform IO, Arduino Library Manager or directly from GitHub for the latest changes. Note that Platform IO will install the proper RF24Network and RF24Mesh dependencies, while Arduino Users would need to install the separate RF24Network and RF24Mesh branches manually for now.

AutoAnalogAudio Arduino Library: Updated with recording support for XIAO Sense via PDM

 AutoAnalogAudio Arduino Library

Updated with recording support for XIAO BLE SENSE - NRF52840 via PDM microphone

Its been a while since I received my first NRF52840 device, and I finally got around to publishing what I have so far with the AAAudio libray. The XIAO Sense board that I have has a built in PDM microphone, so I managed to get it working with AAAudio. The results are pretty good, I tested it as a wireless microphone and it seems to hold up well. This is all kind of preliminary, full functionality isn't quite there yet, but it does function.

I've struggled with getting I2S output to work so far, but eventually I should be able to figure it out. There seems to be some sort of problem with it, I would like to blame the board and say it just won't work properly, but there is probably something I'm missing in the code.

In any case, the library has been updated, but it will probably be a while before I do an official release, so users will have to get the source code directly from GitHub.

https://github.com/TMRh20/AutoAnalogAudio/archive/refs/heads/master.zip

NRF52840 to NRF24L01+ Wireless Communication with Arduino

 NRF52840 to NRF24L01+ Wireless Communication with Arduino

More on development of the nrf_to_nrf radio driver

So I've finally made some more progress on the development of the nrf_to_nrf radio driver that allows communication between NRF52840 and NRF24L01+ devices. The main and latest development is the functionality of using static payloads. I'd been playing around here and there for a few months trying to figure out why the ACKs kept getting rejected when using static payloads, since I had the driver working with dynamic payloads and even ACK payloads. It turns out the NRF24 devices will only send and receive ACK packets that have a payload size of 0 when using static payloads. The driver actually needs to set the payload size to 0 then switch back after sending/receiving ACKs. I should have guessed, but didn't figure it out for quite a while.

It's been quite interesting so far, this radio will handle payloads up to 127-bytes compared to the 32-bytes of the NRF24, and supports 8 'pipes' (for addressing) rather than 6. It still has a similar method of addressing, which many people seem to find confusing. It also can measure the RSSI and return a value rather than the NRF24 functionality of returning on any value better than -64 dBm. 

The main "downfall" is that the radio is software driven, unlike the NRF24, which handles a lot of functionality independent of the MCU, but that downfall on the other hand gives us direct access to the radio and its functionality. This opens things up a bit for what is possible with the radio. In order to achieve functionality similar to the NRF24 however, interrupts need to be used to handle radio events in the background, while the main software runs. This may prove to be something I'm not going to support, but will see how things develop with the Arduino platform and NRF52 board support.

Another interesting capability of this device is encryption. It contains a CCM - AES CCM mode encryption peripheral, that allows us to create encrypted and authenticated networks. I've been playing around with this functionality lately, and it looks like it can be incorporated into the library in a fairly seamless way. More on this later...

The library is currently available via the Arduino Library Manager, PlatformIO or you can grab it at GitHub if you want the latest modifications.

XIAO BLE Sense: More with nrf24L01+ communication

 XIAO BLE Sense: More with nrf24L01+ communication

Emulating the Enhanced Shock-Burst Protocol

So its been a little while since I received a BLE Sense board based on the NRF52840 from https://www.seeedstudio.com/ and man oh man it has taken up a lot of my time. This is one of my favorite hobbies, so creating a library for ESB communication with nrf24 modules has been quite a lot of fun!

The radio works with logical pipes and defined radio addresses, just like the NRF24L01 and interaction with it is not as complicated as it could be. Getting the ESB protocol working has been a bit tougher than I originally thought it would be though.

As shown in the image above, pipe or logical address 0 can have a unique address, but pipes 1 through 7 must share a base address, very similar to the 24l01.

It seems that the radio must be disabled when switching between TX and RX states, it took me a while to figure this out programmatically, until I noticed this in the datasheet. 

Interestingly enough, the new, enhanced RF52840 does not implement any internal protocols, ESB must be entirely handled via software.

I have my nrf_to_nrf radio driver up and working now with many radio features. It allows users to use the API from the RF24 library to interact with the radio. I am having problems getting static payloads to transfer correctly, but simply enabling the dynamic payload feature enables the RF24 examples to function correctly, and it works with the rest of the RF24 communication stack, the different layers will need to be updated to accept the new library.

The nrf_to_nrf library only has a single-layer buffer at the moment, but it shouldn't be too difficult to implement a 3 layer FIFO like the nrf24s have. It would be helpful if I could drive the radio via IRQs but so far I haven't had any luck with IRQ handling. My cohort in RF24 programming is working on an alternative layer that uses code from the NRF52 SDK, but we might need to have IRQ handling running for that to be a viable option. We will see, the NRF24Network and higher layers have had adjustments made to allow the new library to work. Users can manually install from source until a new release is made to the libraries, which will update via the Arduino Library Manager.

Thanks again to Seeed Studio for sending me this device, new hardware is always fun to play with!

XIAO BLE SENSE: nrf52840 radio communication with nrf24L01+

XIAO BLE SENSE: nrf52840 radio communication with nrf24L01+

Establishing a communication layer using the RF24 API 

I recently received an XIAO BLE Sense board from https://www.seeedstudio.com/ based on the nrf52840 and have been playing around with it for a few days now. In that time I have been able to get audio recording working with my AutoAnalogAudio library, as well as establish basic radio communication with the nrf24l01+ modules. This thing is pretty sweet! It is very small, so I've been leaving it connected to the USB cable so I don't lose it, but its definitely a benefit.

One of the first things to know about this board is that it has a DFU functionality, so it switches ports while uploading, and goes back to the original port after uploading. This means that if you upload some code that crashes the device, you need to press the reset button twice quickly, and it will reaload into DFU mode on a different port, so you can re-upload some working code.

Secondly, if you get an error 'Property 'upload.tool.' is undefined' then you just need to select the correct upload port.

It also uses a USB-C connector, so make sure to have the correct cable handy.

Radio Communication:

To get radio communication working, I've written an Arduino library for the nrf52840 which can be found here: https://github.com/TMRh20/nrf_to_nrf It can be installed just like any other Arduino library.

The library includes one example for now, gettingStarted. To get this example working with the Arduino example from the RF24 library, the following parameters need to be set in the RF24 example:

1. Call radio.enableDynamicPayloads();

As of this writing, the library only supports reception, and there is no Auto-Ack functionality yet. This is just a preliminary draft of the API.

So far I am very intrigued with this device and its capabilities. Hopefully it isn't too much to get transmission and auto-ack working, but we will see I guess.

New Raspberry Pi + nRF24L01+ shields

 New Raspberry Pi + nRF24L01+ shields

Connect PA+LNA modules to your Raspberry Pi

I recently had some circuit boards made, as I have had enough experience working with nrf24l01 radio modules that I've encountered numerous issues regarding power supplies and the need for additional capacitors soldered to the radios. 

These boards connect to the 5v pins of the Raspberry Pi, which can supply plenty of current for the radios, and converts it down to 3.3v. I've designed two boards, one that fits inside the case, and the other that fits outside the case, so they should work with most cases, though some cases may need modifications. The designs both use a 26-pin header, so they are compatible with earlier versions of Raspberry Pi as well.

Raspberry Pi - nRF24L01+ adapters

These adapters will support even the PA+LNA versions of the radios, so you can extend the range of your wireless networks considerably over the standard modules. They include extra capacitance, with capacitors placed right beside the VCC and GND pins of the radios, so there is no need to solder on additional capacitors.

Shields are available at https://tmrautomation.myshopify.com/