bgamari / data-logger

An autonomous data logging firmware for the MC HCK development board

data-logger

This is a set of firmware for autonomously logging sensor measurements (e.g. for environmental monitoring purposes) on the MC HCK.

This firmware takes advantage of the low power consumption of the MC HCK to allow sensor values to be logged for months on end.

building

Simply clone the respository into the mchck/examples directory and run make flash,

 $ git clone https://github.com/bgamari/mchck
 $ cd mchck
 $ git checkout temp-gather
 $ cd examples
 $ git clone https://github.com/bgamari/data-logger
 $ cd data-logger
 $ make
 $ ./data-logger start --sample-period=60

using

The data-logger program in this repository provides an easy-to-use interface to the functions of the device. The info subcommand provides various details of the device and its status. After plugging in a new device, its output will look something like this,

$ ./data-logger info
firmware version: c84529f15f3d0d38f643bdc7b891655678370129
device ID: 24404e45-280011-ffff0054-ffffffff
samples collected: 30977
flash: mfg=bf memtype=25 capacity=8e
RTC time: 2014-02-20T19:20:00 = 1392924000
sample period: 30 seconds
acquisition: stopped

sensors:
1 	onboard-temperature 
    0 	temperature         	Kelvin              

2 	external temperature
    0 	temperature         	Kelvin              

5 	gps                 
    0 	latitude            	degrees             
    1 	longitude           	degrees             
    2 	altitude            	meters              
    3 	n-satellites        	count               

To begin data acquisition use the start command,

$ ./data-logger start --sample-period=90
The device time doesn't look valid. I've updated it for you.
Acquisition started sampling every 90 seconds

Here we see that data-logger has noticed that the device's time isn't set. It has set the clock to the current UTC time. The device is now taking data.

Finally, the collected data can be downloaded with the fetch command,

$ ./data-logger fetch
# time         sensor    value
1389105233     1         16.0150
1389105233     3         304.0020
1389105233     2         294.0020
1389140502     1         16.2590
...

We described a subset of the functions of data-logger. data-logger --help for a more thorough description.

core concepts

data-logger is intended for long-term, periodic recording of sensor data. Each sensor (e.g. a thermometer, accelerometer sensor, or GPS) may report one or more measurements. In the case of, e.g., a GPS module these may be the reported latitude, longitude, and altitude. These measurements (or samples) are stored in FLASH memory for later retrieval.

internal command set

The device exposes a CDC-ACM device over its USB interface. There is a very primitive command set for communicating with the device. Running make console in this directory will start picocom as a convenient way of exploring these commands. One can exit with Ctrl-A Ctrl-X.

• a=[bool]: Start or stop acquisition
• f: Force taking a sample
• v=[bool]: Enable/disable verbose mode. In verbose mode the device outputs each sample taken to the console.
• Fi: Print identity of FLASH device
• Fs: Print status of FLASH device
• g [start] [count]: Print sample numbers start to start+count
• t=[time]: Set RTC time in seconds
• t: Print RTC time in seconds
• T=[time]: Set time between samples in milliseconds (sample period)
• T: Print sample period in milliseconds
• l: Print last acquired sample
• n: Print number of samples taken
• n!: Erase all samples
• S: Print whether acquired samples are stored to FLASH
• S=[bool]: Set whether acquired samples are stored to FLASH
• s: List configured sensors
• m [sensor id]: List measurables of given sensor
• V: Print firmware version (commit id)
• I: Print device ID
• p!: Enter power-saving mode immediately
• Operations acting on non-volatile configuration
  • NB: Get acquire-on-boot flag
  • NB=[bool]: Set acquire-on-boot flag
  • NN: Print friendly name of device
  • NN=[string]: Set friendly name of device
  • NS: Save non-volatile configuration
  • NR: Reload non-volatile configuration

bool is either 0 or 1.

Stored samples

The primary function of the device is to store sensor samples to the MC HCK's on-board FLASH memory for later retreival. If the device loses power, it will lose track of the location of the last sample it wrote. For this reason, it is necessary for the device to scan the FLASH to recover this location. This is done with the R command.

Low-power mode

Note: This isn't completely implemented yet.

This is the mode the device should be in while in the field taking measurements. Here most of the functions of the device are disabled.

Note that the microcontroller unfortunately does not have the ability to wake itself up when plugged in to a USB port without external circuitry (namely pin PTD6 connected to the USB +5V rail through the appropriate voltage divider, see power.c). Without this circuitry it is necessary to wake up the device with the "wake up" button before the USB interface can be used.

data-logger's Issues

radio support is broken

This appears to be an upstream issue in mchck.

Fix `t=TIME` command

Currently acquisition isn't rescheduled if running.

Core temp sensor acquisition seems to be broken

Configuring multiple mchcks using the both the datalogger-web and console methods seems to record only "444.2390" for the onboard temp measurement.

Fix radio mode

Some samples are inexplicably dropped.

BMP085 is broken

This appears to be an upstream mchck issue.

Fix `a=0`

Currently acquisition doesn't stop.

USB interface stalls after several commands

Currently running, e.g., data-logger stop several times in fast succession will result in the USB interface being unable to accept more commands. Strangely, a simple test case like,

#!/usr/bin/python
from data_logger import DataLogger
for i in range(50):
    logger = DataLogger('/dev/ttyACM0')
    hi = [(i, logger.set_acquisition_state(False)) for i in range(5)]
    print '.',
    logger._dev.close()

fails to reproduce the stall.

Change sampling rate remotely via radio?

E.g. 'live' data feed from remote nodes might indicate that an interesting event happens every Tuesday; one could then reconfigure remote nodes to sample at a greater frequency on Tuesdays.

Add instructions re: using the 'console' program in the README

The internal command set is nicely documented, but maybe a line can be added in the README, right above the "internal command set" heading, re: running "make console" in order to interactively use / test the command set ...