Encrypted Audio Comms with XIAO 52840 Sense

Encrypted Audio Comms with XIAO 52840 Sense

The beginnings of wireless audio comms

I've been playing around with the NRF52840 boards I have, and now that I have basic audio functionality working via PDM microphone and PWM audio output, the next thing to do is test out an encrypted wireless communication scenario, so that's what I've done.

The devices use the AutoAnalogAudio and nrf_to_nrf libraries created by me to communicate wirelessly. I've also enabled encryption at the nrf_to_nrf layer, and the related code is an example of implementation, with the device randomly generating a new key and re-keying every 30 seconds. This will prevent others from decrypting the payloads or performing replay attacks outside the 30-second windows. 

This means that users would need to start the devices at the same time (within a 30-second window), so they start-up using the same key. After 30-seconds, a new key is generated and configured, so both devices will then use the same new key. The receiving device ensures that the old key matches before accepting the new key, so unauthorized users can't simply send a new key or replay an old key. Any power down of either device will result in lost communication unless the other device is restarted within the same 30-second window.

To use the sketches (posted lower down), users would need a XIAO 52840 Sense board and both of the aforementioned libraries installed, then just run the code. No wires to connect, no power supply issues to worry about, no counterfeit nrf24 devices to worry about, just a straightforward device that works.

There are still a few issues with synchronization of the audio vs how the device handles PWM data. Essentially, you can have the PWM pin default to a LOW or HIGH state when the current PWM sequence ends, which happens during radio communication when packets are lost or slow to transmit. Compared to other devices I've worked with, which maintain the current state of the pin when PWM or DAC data ends, this device will revert the pin to either HIGH or LOW which causes a popping or clicking sound. 

I'm not sure how to work around this currently, but will continue to experiment to try and achieve better results. In the mean-time users can try out the prototype code by downloading the sketches here: https://github.com/TMRh20/Sketches/tree/master/XIAO-EncryptedAudio

Recording and Playback of Audio on the XIAO NRF52840 Sense - Auto Analog Audio

 Recording and Playback of Audio on the XIAO NRF52840 Sense

Auto Analog Audio Library

So I've been struggling with the I2S interface of the NRF52 devices, and have given up for the time-being trying to get it to work properly. In the meantime I've made some decent headway with the PWM interface and reproducing audio that way. This is similar to the TMRpcm library for AVR devices, which also uses Pulse-Width-Modulation to reproduce audio. 

So far the AutoAnalogAudio library is in a very basic but functional state with an included example to demonstrate how to record and playback audio on the XIAO 52840 Sense. It is designed to input audio from the PDM microphone directly and output using Pin5 of the XIAO board via PWM. The audio signal is 16-bit, 16kHz audio, so of reasonable quality, and cannot currently be modified. The code is still in its infancy.

This makes it easy to record and transmit audio over radio link, since with the nrf_to_nrf radio library, users can broadcast the audio to another device very easily. 

There are still a few problems with it, mainly some synchronization issues, which result in a clicking sound when audio is fed directly from the microphone into the PWM output (Amp & Speaker). I'm not quite sure how to resolve it currently, so will leave things as-is. Update: Adjusting the timers slightly to make the PWM a bit slower than PDM input results in a smooth output signal.

A new release will not be made for a little while, so to try it out, just install the AAAudio library directly from ZIP. See GitHub at  https://github.com/TMRh20/AutoAnalogAudio 

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:

nrf_to_nrf layer: Set the maximum payload size. Up to 127 with CRC disabled or 123 with 16-bit CRC. Use radio.setPayloadSize(125); 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.