[Sara Damiano]

You can completely ignore the error “override controls (override/final) only available with -std=c++1 or -std=gnu++11” I’m not sure why it always comes up. I can’t imagine your compiler version isn’t high enough to support it.

[Sara Damiano]

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.

[Sara Damiano]

You definitely want to update for calculated variables. There’s a big bug in 0.19.6 in the “completeUpdate” function in run inside the “logData” function that will make any calculated variables crash.

After you update, adding the compass as a “calculated” variable should work just as you described. That is, you could call the begin and update to return a float in the calcFxn – and you would not be able to get averages or multiple readings without writing it yourself in the function. The calculated variable function are not called until after all the sensors have completed all measurements and gone to sleep.

You could look at the BME’s code if you want to try and write it as a new sensor. I need to write up better documentation on how to create a new sensor.

[Sara Damiano]

Shannon designed the board well!

[Sara Damiano]

Hopefully @aufdenkampe will confirm but I think he went the USB route mainly to avoid power losses in the step down. If you go that way you probably need a relatively expensive 12V to USB to make sure you are getting less loss than the built in step down.

[Sara Damiano]

Oops, yes, sorry, the modem would have power without the battery, just not enough. The naked u-blox SARA R410 cellular chip uses just barely under half an amp at peak. (Assuming you’re using the LTE model.) Add the Digi processor and it’s too much. I’ve never had any luck getting it to connect without a battery. It browns out and stops responding. Often it needs to be completely powered off (or yanked from the board) before it will be happy again.

I think @acgold might have gotten the Sodaq SARA R410 uBee working with the Mayfly without the solder jumper: https://github.com/EnviroDIY/ModularSensors/issues/228

[Sara Damiano]

I’m sure the LSM303 could be integrated into ModularSensors. You should also be able to use it along with ModularSensors without actually integrating it. You might not be able to use the “logData” function though – you might have to break it up some.

So, do you have your program somewhere I could look at? Are you turning off the power to the sensor between reading? (Is your I2C port set to switched power?) Are you sure the sensor is powered when you’re trying to read it? Did you try putting a begin() for the LSM303 right before it’s read? In that library it looks like the begin() function sends an activate command which it may need after every power up (or even after every time I2C is disconnected).

[Sara Damiano]

Depending on the version of the Mayfly you have, there’s a 12V power input that you can step down and use. If I remember correctly, though, @aufdenkampe once told me he’d had smoother power and less loss using a separate 12V to USB step down and powering the Mayfly via the USB port.

Unfortunately, though, with either option you would still need a LiPo to supply the modem. The Digi cellular modems require more amperage than the Mayfly can provide on its own so the only option is to power them directly off the battery by way of SJ13. If you don’t have a battery plugged into one of the Mayfly’s battery jacks, the modem wouldn’t be powered at all.

[Sara Damiano]

I haven’t encountered those sensors yet. Hmmm..

[Sara Damiano]

@gregcutrell – The _numReturnedVars isn’t a “user set” variable in the typical way you might be thinking of it. It is *not* intended to be set by a user in a program. It’s intended to be set in the header file for a specific sensor. When creating it, the writer of the header file should know exactly how many values the sensor can and will return. Those lines are commented out because they really are only for debugging to confirm the sensor code works as it should.

But your code looks like it should be good. Can you put in a pull request?

[Author]

Posts