Reply To: LSM303 Accelerometer + Compass library integration into ModularSensors

If you’re averaging multiple measurements, the first measurement is started stabilizationTime_ms after wake up and the result requested measurementTime_ms later, or as close to that time as the sensor is checked in iterating through all variables. The second measurement is begun in the next loop after the first measurement result is collected, so nearly immediately after the first measurement is completed. The result is requested measurementTime_ms later. Same for all subsequent measurements.

If there was only one sensor with three readings, it would go about like this:

main processsor wakes -> sensor powerUp() -> wait warmUpTime_ms -> sensor wake() -> wait stabilizationTime_ms -> startSingleMeasurement() -> wait measurementTime_ms -> addSingleMeasurementResult() -> startSingleMeasurement() -> wait measurementTime_ms -> addSingleMeasurementResult() -> startSingleMeasurement() -> wait measurementTime_ms -> addSingleMeasurementResult() -> sensor sleep() -> sensor powerDown() -> calculated variables calculated -> data written to SD -> data published to remotes -> mcu goes to sleep.

The reality is a little different if there are multiple sensors because each step takes a non-zero amount of time and the millis() function gets called a lot which in itself wastes processor time, but it shouldn’t be far off the above. If you’re seeing something much different, that’s a problem/bug.

So, right now there’s now way to average readings between multiple wake/sleep sessions. So if you wanted to average 10 readings 1 minute apart, the mcu and sensor would be awake the whole time and murder your battery. You could create two logger instances, one logging at 1 minute and another logging at 10 minutes and only attach a publisher to the longer logging interval, but the data going out would only be from that 1 measurement, not the last 10. You’d want to optimize your loop to do this; DON’T just use logData(). If you look in the definitions for the dataPublishers, there are arguments for a send frequency and offset, but those are just place-holders right now – they’re not actually implemented in any way in the code.

If you’re making a new SDI-12 sensor, you shouldn’t modify the SDI12Sensors.cpp. Create a new cpp/h pair defining a sub-class of SDI-12 sensor. Look at the Decagon5TM as an example – it follows the “normal” SDI12 sensor in everything except “addSingleMeasurementResult” which is defined separately.