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
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
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 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.
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.
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
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.
Encrypted Audio Comms with XIAO 52840 Sense The beginnings of wireless audio comms I've been playing around with the NRF52840 boards I h...
Arduino: Using the full potential of NRF24L01 radio modules A New, Optimized Fork of the RF24 Radio Library: High speed data transfers an...
Automation/IoT with Arduino, RPi, NRF24L01+ and MQTT Control and monitor Arduino remotely with mobile devices Overview: Please se...
Arduino Radio/Intercom/Wireless Audio : Streaming Audio in Real Time using Arduino and NRF24L01 In my last blog post, I talked a...