Close

Publishing sensor data with MQTT

A project log for Street Sense

Portable electronic device to measure air and noise pollution

mike-teachmanMike Teachman 04/07/2019 at 18:470 Comments

The next iteration of the prototype involves taking advantage of the built-in WiFi feature of the ESP32 microcontroller to publish sensor to an internet database such as Adafruit IO or Thingspeak.  The MQTT protocol will be used.

Publishing data to a cloud database with WiFi and MQTT protocol is something I've done in other projects.  But, there is an added technical challenge in this project - that is publishing data and simultaneously recording audio to SDCard without creating audio gaps.  If the MQTT task blocks for too long at any point, the DMA buffering used in by the audio recording task will "overrun" leading to gaps in the recorded WAV file.

To overcome this risk I used a non-blocking asyncio version of MQTT written by Peter Hinch.   This version uses a non-blocking sockets implementation and will not block other asyncio co-routines from running (like the microphone recording task) when WiFi goes down or the MQTT broker is unreachable.   An additional pause/resume feature was added by Kevin Köck that allows WiFi to be turned off when the device is not actively publishing.   This turns off the WiFi radio which reduces the power consumed by the ESP32 - the end result is a longer battery life.  There is a discussion on the MicroPython forum describing how this enhancement was realized.  Sensor data will be published every 15 minutes in the final design.  

A 2 hour test was run, publishing sensor data to Adafruit IO.  Below is a plot from Adafruit IO showing 2 hours of PM2.5 particulate data.  This shows a very clean air day on the west coast of Canada!  This publish period was reduced to 2 minutes for this test.  

Some diagnostic information in the microphone task showed that there were two audio gaps in the 2-hour SD Card audio recording.   The was a unwelcome result.  More debugging code will be needed to determine the root cause of the audio interruption.  The audio sample rate in the test was 10kHz.     

Discussions