It's has been a while since I wrote about the status of the OPQ project. A lot of changes have accumulated, and need to be laid out.
- On the STM32 end the data acquisition has been finished, and is quite stable. While still lacking DMA, I was able to meet the timing constraints imposed by the interrupt driven program.
- SPI communication between the STM32 and PI is stable and working. I was not able to get reliable data transfer from Pi's userland however. When using SPIDEV I was missing about a third of the SPI transfers.
- In order to combat the SPIDEV vows I moved the SPI transfers to the kernel. Now the kernel is responsible for managing the DSP interrupt and performing SPI transfers. The neat thing about this is while SPIDEV is not able to perform transfers via DMA, my kernel module will do just that. This means the CPU is freed to perform more interesting tasks.
- On the userland end, and DAQ/analysis pipeline has been setup, and is working as expected. For the moment a reduced version of the data is stored in a remotely hosted redis server for experimentation.
That mostly covers what has been done. Now lets talk about what is coming:
As shown in the figure above the Raspberry Pi will run a local Redis server in order to store minutes of high resolution measurements. The cloud service, will only see the result of the local analysis, which is a highly reduced version of the data containing RMS voltage, a frequency measurement and a histogram of several grid cycles. Since the expected signal to noise ration we expect to operate in is below 1, data from multiple OPQBoxes is required to ascertain a grid wide power quality event. By looking at the results of the local analysis the cloud service may decide to request full resolution data for a period of time and store it for local analysis. This methodology should save both bandwidth and computational resources while preserving the event detection efficiency.