[Greg Cutrell]

If your only interested in a month of data and not concerned about a long-term deployment, I would just put the Mayfly/hardware/batteries in a nice IP 67 or 68 enclosure with a voltaic solar panel and strap it to a something like a spare buoy. The picture attached isn’t pretty but would probably work for long-term deployment in small inland lakes.

Attachments:

1. 

   2022-01-26-09.55.39-scaled.jpg
   

[Greg Cutrell]

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 addSingleMeasurementResult and startMeasurement function overrides (something about a version issue). So I just started to edit the SDI12Sensors code just to make sure my routine would work and then put that code in the new sensor .cpp file.

BTW this ATMOS22 would work perfect for the mayfly since it averages internally until you request another measurement. Only issue for us is we need to use the compass to offset a platform direction which is always moving.

[Greg Cutrell]

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 might have had effected this.

I was thinking this might be an easy way to average higher frequency logging to a longer average. For example take a measurement every minute but we really want to save/send out every 10 minutes. Is there a way already in-place to complete a task like this?

[Greg Cutrell]

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 compass offset is applied before saving it to the variable array. Hopefully in the next week I’ll put in a pull request for this new sdi-12 (METER ATMOS22) wind sensor. A great very low power sensor for a relatively low price (~$500 – $600) for an acoustic wind sensor. Thanks again!

[Greg Cutrell]

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 for the ‘float (*calcFxn)()’ calls a function that then gets data from the compass? I’m guessing the downside would be I could not do averages and I would just receive one reading per logging interval?

I have not gotten calculated variable method to work for my compass but I think it is because of an error in my code or maybe a bug in ModularLibrary 19.6 I’m working on. Anytime I add the variable pointer to the variable array (like in https://github.com/EnviroDIY/ModularSensors/blob/master/examples/baro_rho_correction/baro_rho_correction.ino) it makes the MayFly reset going through all the initial checks again and setting up sensors ever sampling interval. I might just need to update to the most recent master version 21.1.

[Greg Cutrell]

@saradamiano – I was going to bring up the _numReturnedVars issue when also doing a pull request for the YSI EXO. There are sensors out there, like the YSI sondes, where users typically set their own sdi-12 output so you can’t really create a header that has variables and variable counts set in there. It really needs to be done in the ino file. I’ve got the header working because I did the variable defines myself but it really needs to done in the ino file and carry over to the header file. I just wasn’t sure how to code it. I’ll tag you in github once I get the code in there for thoughts. Thanks

[Greg Cutrell]

Unless you can make a large enough buffer to accommodate 20-30 values the full proof other option is to have a way a to check if the number of received values equal the number of expected from concurrent result command. If it doesn’t then increase the dataOption value from D0! to D1! and so on. I piggy-backed off your code SDI12Sensors code and simply said if we are beyond the third value and a -9999 is returned, then try increasing the dataOption and send command. This worked for me but isn’t the best method. Ideally the loop would center around the variables the SDI-12 device has, which you called ‘numVariables’ and not the number of variables the user sets ‘_numReturnedVars’. We could follow my logic for checking for more data after finding missing data (-9999) OR parse and count the results from the initial .read(), check if it is equal to ‘numVariables’, if not then ask for more data and append to previous results, and check again and so forth till read variables count equal the ‘numVariables’.

I also had to increase your sdiResponse.substring(4,5) to (4,6) to account for two digit variable counts.

C++

for (uint8_t i = 0; i < _numReturnedVars; i++) { float result = _SDI12Internal.parseFloat(); // The SDI-12 library should return -9999 on timeout if (result == -9999 or isnan(result)) result = -9999; //Check if there are more values than in initial data command if (i > 2 and result == -9999){ // Empty the buffer again _SDI12Internal.clearBuffer(); MS_DBG(getSensorNameAndLocation(), F("Checking for more data:")); String getDataCommand = ""; getDataCommand += _SDI12address; getDataCommand += "D"; getDataCommand += String(dataOption); getDataCommand += "!"; dataOption += 1; _SDI12Internal.sendCommand(getDataCommand); delay(30); // It just needs this little delay MS_DBG(F(" >>>"), getDataCommand); while (_SDI12Internal.available() < 3 && (millis() - startTime) < 1500) {} MS_DBG(F(" Receiving results from"), getSensorNameAndLocation()); _SDI12Internal.read(); // ignore the repeated SDI12 address result = _SDI12Internal.parseFloat(); } MS_DBG(F(" <<< Result #"), i, ':', result); verifyAndAddMeasurementResult(i, result); }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

for (uint8_t i = 0; i < _numReturnedVars; i++)         {             float result = _SDI12Internal.parseFloat();             // The SDI-12 library should return -9999 on timeout             if (result == -9999 or isnan(result)) result = -9999;             //Check if there are more values than in initial data command             if (i > 2 and result == -9999){               // Empty the buffer again               _SDI12Internal.clearBuffer();               MS_DBG(getSensorNameAndLocation(), F("Checking for more data:"));               String getDataCommand = "";               getDataCommand += _SDI12address;               getDataCommand += "D";               getDataCommand += String(dataOption);               getDataCommand += "!";               dataOption += 1;               _SDI12Internal.sendCommand(getDataCommand);               delay(30);  // It just needs this little delay               MS_DBG(F("    >>>"), getDataCommand);                 while (_SDI12Internal.available() < 3 && (millis() - startTime) < 1500) {}               MS_DBG(F("  Receiving results from"), getSensorNameAndLocation());               _SDI12Internal.read();  // ignore the repeated SDI12 address                 result = _SDI12Internal.parseFloat();             }             MS_DBG(F("    <<< Result #"), i, ':', result);             verifyAndAddMeasurementResult(i, result);           }

[Greg Cutrell]

Thanks Shannon! This is a clean way to implement a logic board to power converter! I have finally successfully retrieved and saved 18 values from our YSI EXO2, which itself requires a signal output adapter to transmit SDI-12, using the modular sensors library. This was done without using a logic converter and powering the EXO externally with 12V.

My initial error was not taking into account the pin interrupts for the mayfly (I first used the basic arduino sdi12 code) so I was able to send the message but that is why I was not receiving a message. For reference Arduino-SDI-12#variants-and-branches.

I have a working local header file for the YSI EXO and hope to commit the code and pull request in the next few weeks. I also found some limitations in the sdi12sensors library that need to changed to get more than 3 or 4 measurements from a sdi12 sensor. Once the sdi12sensors code is updated I would think any advanced instrument that produces many measurements via sdi-12 will be able to be used in a similar fashion as the YSI EXO header.

[Greg Cutrell]

Thanks Shannon. Could you share the logic converter you have had success with? I like to give another logic converter a shot.

[Greg Cutrell]

Dave,

Just curious if you ever revisited this issue over the winter? I am having the exact same issue with a Viasala WXT530 and YSI EXO. I did find a post where I guy successfully got his WXT530 to work back in 2017 (https://hankpai.weebly.com/sandbox/arduino-data-logger-vaisala-some-code). We are powering the devices with 9V and able to change the SDI-12 address of the WXT, but can’t get the SDI12_b_address_change program to find the device or get any response from the sensors. I also tried using a sparkfun logic level converter (https://www.sparkfun.com/products/12009), thinking the WXT530 signal is too high since it is powered by 9V, but I couldn’t even change the SDI address with the converter. I am using the 19.3 modular sensors library for my test.

[Author]

Posts