Sara Damiano

There’s a known bug from Digi that any of the XBee3’s with revision “B” of the primary processor, where it will become unresponsive even with very short dips or irregularities in voltage: https://www.digi.com/resources/documentation/Digidocs/90002258/#Troubleshooting/ts_brownout.htm%3FTocPath%3DTroubleshooting%7C_____7

I don’t know about the…[Read more]

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.

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…[Read more]

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…[Read more]

Shannon designed the board well!

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.

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…[Read more]

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…[Read more]

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…[Read more]

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

@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…[Read more]

If you’re curious, I’m working on the objectInitialization branch for this.

The “base” (master) branch of the SDI12 library should claim all possible on change interrupts so you don’t need to mess with calling them yourself. You only need to define the interrupts if you work off the ExtInts branch or if you compile with a build flag to set SDI12_EXTERNAL_PCINT. I think the latter is only possible in PlatformIO. If you’re…[Read more]

Ugh. I’m sorry. I can definitely reproduce this, but I haven’t solved it yet. I’m fairly certain it’s because I’m linking object together in the constructors, but they’re not being created in the right order. This is causing important things (like the whole variable array) to be recreated.

I’m working to solve it.

Sorry!

With AltSoftSerial, data in to the Mayfly goes on pin 6, out from Mayfly on pin 5. It’s kind-of a pain because the Tx and Rx are broken into different Grove ports, but for something like the Maxbotix that you only need Rx for, it’s fine.

I’m starting to look at the calculated variables.

Have you read the threads on the LTE-M XBee? I’ve gotten it to work; hopefully you can too! https://github.com/EnviroDIY/ModularSensors/issues/162#issuecomment-459879699

Oh dear. I’ll get on this ASAP and let you know how it’s going.

A warning on the ublox shield:the native baud rate is 112500, which is to fast for the Mayfly. Look at the gitgub issue on the sodaq uBee for how we worked around it. There’s code in the soon-to-be released as master atlas branch for it.

Oops. Sorry. I’d typed that and didn’t see your response. But yes, slowing down the ESP8266 is the way to go if you want to make sure everything is heard correctly.

Yes, I’ve had problems with the Mayfly receiving data at 115200. The Mayfly is only running at 8MHz and Atmel says the error rate at that baud and crystal combination is 8.5%. The error is a much bigger problem on the receiving end than the sending end. So the serial port monitor and the ESP8266 understand what the Mayfly is saying at 115200,…[Read more]