Combining the Zephyr RTOS, Digital Signal Processing, and bare metal programming techniques.
April 3, 2024
Eli Hughes
Introduction
The Zephyr RTOS offers high level microcontroller peripheral driver abstractions to simplify application development and enable portability across vendors and architectures. However, there are times when one must get “to the metal” to achieve the highest performance metrics such as power consumption. This article will show an acoustic machine monitoring application that uses Zephyr with the Nordic NRF9160 cellular System-In-Package (SIP) combined with high-performance vibration and temperature sensors.
While Zephyr is a very rich embedded development framework, it does not mean that you have to give up any of the advantages of “bare metal” for high performance applications. In fact, you can get the best of all worlds while having a development framework that scales across projects. Specifically, we will cover how to:
Access peripherals directly for minimal overhead
Have direct access to IRQ handlers to weave peripherals together in ways not supported by the Zephyr driver model.
Use the Zephyr build system to bring in DSP libraries to implement acoustics & vibration processing algorithms such as a power spectrum computation.
Apply direct peripheral access techniques to achieve the lowest sleep currents for industrial IoT / battery powered applications.
Cellular System in Package (SIP) Technologies, such as the Nordic nRF9160, offer a high level of integration enabling densely packaged sensor solutions. In addition to enabling point connectivity, the nRF offers sufficient processing power to handle complex sensor fusion and data reduction tasks.
Prior to Nordic nRF9160 and open source RTOS solutions such as Zephyr, cellular based industrial IOT development could be consuming and difficult. A typical method for connecting sensors is to use an intermediate wireless network. It is common to network sensors via a local wireless connection. Raw sensor data is collected into a “bridge”. The bridge which may have more significant processing capabilities and high-level operating system such as Linux to deal with intricacies of modern, secure connectivity. With Zephyr and the nRF9160, it is possible to do all precision measurements and data processing in-situ and securely connect to a backend without an intermediate bridge. This point of measurement connectivity approach can greatly simplify deployment of sensors for predictive maintenance and conditioned based maintenance applications.
The nRF9160 can be battery powered using ruggedized chemistries such as lithium thionyl chloride (Li-SoCl2) for years of operation in the most demanding environments. An example of a point of measurement industrial IOT sensor is the MachineMailbox.
The MachineMailbox : An Acoustic Machine Monitoring Sensor using the Nordic nRF9160 and Zephyr.
One of the best methods of implementing machine health on critical, high value equipment is to analyze the vibration of the machine in real-time. Using high bandwidth accelerometers, it is possible to ascertain the health and possible future failures of a critical asset over time. Combining frequency domain analysis with typical sensing modalities, such as temperature, one can perform complicated sensor fusion and data reduction at the point of measurement. Data fusion and reduction at the “extreme edge” reduces the amount of data needed to be transmitted to a backend improving both transmission costs and battery life. Cloud based machine learning and trending algorithms can have access to just the right amount of data to balance complexity in the sensing node and the backend processing.
An Acoustic Machine Condition Monitoring Sensor using the ADXL355, ADT7420 and nRF9160.
Two important considerations when selecting an accelerometer for machine condition monitoring are bandwidth and noise spectral density. The majority of MEMS accelerometers used for orientation and motion control are optimized for low frequency / DC operation but exhibit significant spectral noise in the regions of interest for structural vibration analysis. The ADXL355 operates in the sweet spot of structural acoustics with a 2KHz usable bandwidth and 22ug/ √Hz noise spectral density.
Noise spectral density is an important and often overlooked metric when selecting an acoustic sensor. Often the magnitude of vibration of interest is extremely small. Acoustic analysis for machine health and trending is performed in the frequency domain. A power spectral density computation is often the best choice for understanding energy in a vibrating system. The low noise spectral density properties of the ADXL355 combined with processing gain of a Fourier transform based algorithm means one can resolve the smallest of characteristics in a vibration system.
For the MachineMailbox design, the ADXL355 was connected to the nRF9160 via its SPI interface. The ADXL355 implements a sigma-delta ADC inside of the device package. Streaming vibration data is converted and placed in a FIFO which can be read via SPI transactions.
The ADXL355 Functional Interface
An important point to consider is that once the data stream is started, measurements are pumped into the FIFO continuously. The FIFO is 96 words deep, so it is important to read out data fast enough so there are no discontinuities in the data. The MachineMailbox used the ADXL355 with a 4KHz output data rate (ODR). New sample data is ready every 250uS.
It would be possible to continuously poll the FIFO over the SPI bus. However, this approach is inefficient in terms of CPU activity and energy usage. The DRDY line can be used to efficient trigger read operations. Acquiring a large capture buffer, say 16384 samples, can be done completely in the background with minimum CPU intervention. With 4KHz ODR, SPI transactions need to occur withing the 250uS sample period.
ADXL355 DRDY –> SPI Data Read
With the nRF9160, we can use a combination of GPIO interrupts and SPI DMA to achieve data capture in a background operation while the CPU spends most of its time sleeping. This approach also frees up time for the code to be accessing the ADT7420 temperature sensor. The ADT7420 is accessed via an I2C connection. It should be read no faster than four times a second. Reads of the ADT7420 can be overlapped with the SPI transactions to ensure the CPU is minimally involved and can be put to sleep when idle. In the MachineMailbox firmware, the ADT7420 is read at a 4Hz sample rate while the ADXL is read at a 4KHz sample rate. Both operations are done with minimal CPU interaction to maximize sleep time.
Direct Peripheral Access Approach
Zephyr has a common driver API for the most common access patterns to typical microcontroller IO (UART, SPI, I2C, etc.). However, when one needs to overlap several IO operations and trigger DMA actions from specific interrupts, it can be simpler to directly program the underlying peripherals using “1st principles” thinking. In a Zephyr system, there is no requirement to use the device driver model. Peripherals can be accessed directly just as in a bare metal system with the understanding that the programmer is responsible for all interactions between bare metal code and the RTOS.
The SPI (called SPIM) and I2C (called TWIM) peripherals in the NRF9160 are simple to use via direct register access. They have been designed to handle the most common access patterns. The SPIM module has “EasyDMA” functionality. EasyDMA enables simple configuration of a single DMA transfer to/from a SPI peripheral. I have found that fewer number lines of code are needed to directly program Nordic peripherals than using a high-level driver API.
For this application, we need to trigger a 10-byte SPI operation whenever the ADXL355 flags new data is ready.
NRF9160 SPIM w/ EasyDMA
The ADXL355 use case requires smaller transactions to be triggered from an external pin. We can use the NRF GPIOTE module to trigger an interrupt on the rising edge of DRDY. The SPI transmit buffer is fixed in length and content when requesting new sample. It will contain control/address bytes and does not need to change between samples keeps IRQ handling and restarting DMA operations simple.
Note: The NRF9160 does have a specialized Distributed Programmable peripheral Interface (DPPI) mechanism that can link events between peripherals to reduce interrupt handling. However, I specifically did not use it as I needed to perform some ancillary operations when new sample data is ready and wanted to show a direct IRQ example in Zephyr.
In the MachineMailbox application, the capture buffer for vibration data is 16384 samples in length. The process for capturing a vibration generally followed these steps:
Receive GPIOTE IRQ triggered by the rising edge of ADXL355 DRDY.
Format / store data from the last SPI DMA transfer, except on the 1st interrupt.
Assert the ADXL355 Chip Select
Start the next SPIM EasyDMA transfer if the capture buffer is not full.
Use SPIM ENDRX IRQ to de-assert CS and flag that capture is complete if the capture buffer is full.
