Activity

For small orders, we only sell through our Amazon storefront. But since you need a large order, it’s best to contact us directly to see what we can do for you. You can send me an email at mayfly@envirodiy.org and we can continue the discussion there.

The Grove 6-pin screw terminal adapter board is now available on Amazon: https://www.amazon.com/dp/B07PVKQVH8

The OBS sensor comes a with bare-wire cable with 6 leads. Three of them need to be connected to the Mayfly ground (sensor power ground, sensor signal ground, and sensor shield). Then the 3 other sensor wires get connected to the remaining 3 pins of a Grove terminal (note, you have to use one of the two Aux A/D Grove inputs only). Seeedstudio…[Read more]

For each supported sensor in the Modular Library there’s an extensive wiki. I haven’t used that sensor, but the OBS3+ wiki (https://github.com/EnviroDIY/ModularSensors/wiki/Campbell-OBS3) says that it’s an analog communication and here are the wire color details:
“The power supply is connected to the red wire, low range output comes from the blue…[Read more]

Great, thanks for your quick reply. Is there a way to connect the sensor to the board without the screw terminal adapter?

We currently don’t sell the screw terminal adapter, but I’m working on getting them to Amazon this week. I’ll post an update here when they are available.

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.

Thanks! Bummer about not being able to average out samples over a period of time but I understand the power limitations for a normal mayfly system.

The double logger was going to be my fall back so we can at least save some higher frequency data. I was using the Decagon5TM sensor as an example but was getting an warning on the…[Read more]

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]

On the topic of averaging. It seems the averaging parameter takes a number of consecutive measurements. I thought the measurement_time variable might offset each consecutive measurements but it doesn’t seem to work that way, just the initial measurement. Is this correct? I have been playing around in the SDI12Sensors.cpp file and was sure if I…[Read more]

Thanks for the update confirmation and information about when the calculated variable takes place. I’ll see how much time I can spend on the best way to integrate the compass. The best way to is to call it in a custom .cpp file for the wind sensor, which is SDI-12. That way every every time the wind data is requested from the sdi-12 sensor the…[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.

Thanks Sara! My I2C port is not switched and confirmed that it had 3.3V. I didn’t think about looking into what the begin() function is actually doing. It turns out applying the begin() before every compass object creating did the trick!

As for actually saving the compass data could I create a constructor for a calculated variable where the value…[Read more]