Develop wrapper for Meter Teros 11 Soil Moisture Sensors #276
Comments
|
Regarding the SDI-12 timing issue: The sensor that gets called first responds normal, the sensor called second only reads error values (or maybe doesn't respond at all?). I partially fixed this by calling modem RSSI and other values in the array between 1. and 2. sensor. This curiously works for one of my stations but not for another! I also tried to increase the sensor delays and timings in the 5TM.h file without any luck |
|
I probably need to add documentation to Wiki to fully close. |
|
@Volk3rJ, as you might have noticed above, I have this working with two Teros 11 sensors. I made a couple of timing tweaks relative to what you did, so I'm not sure what solved it. Also, my station with two Teros 11 sensors does not also have a MaxSonar (but it does have a BME280), so that is also worth testing. |
|
Note that the timing issues here popped up again for @shepardb when he updated the ModularSensors library on a station deployed with 2 Teros 11 sensors that had been working fine for a year. |
|
Reopening and looping @GArrigotti-cws into this issue, so we can fix this issue that has returned since Modular Sensors versions >0.25ish (@shepardb noticed it summer of 2020). |
|
The changes I just made with v0.28.4 might help this. I made the time between the SDI-12 break and the actual command settable per sensor. I discovered with the newest Meter sensor we got, it was not responding properly with even the 10ms delay I'd added for the RDO. I set the delay for the Teros (and 5TM) back to 0, which is what it was back in 2019. If it doesn't fix the problem, it at least gives one other aspect of the timing that you can try to tweak to see what works. For any sensor that reports back a manufacturer of "METER" I also added code to turn off the DDI serial output string. If the sensor isn't at the factory default address of 0, it shouldn't be putting out the string anyway, but it seem safer to turn it off just in case it was causing extra garbage on the SDI-12 line. |
|
@SRGDamia1 I did tweak a couple of those and still had some issues, I'll see if that change in modular sensors partially rectifies. |
|
@GArrigotti-cws - it's a bit of a long-shot, but maybe it changes something. In the 'tools' section of the SDI12 library there are a few scripts that I made to test sensor timing - basically repeating everything over and over with slight changes to the warm-up, wake delay, etc. They might help. |
|
@SRGDamia1 Okay, I'll give it a try. Thank you. |
|
@SRGDamia1, thank you so much for describing these issues and making the new release! As @GArrigotti-cws, mentioned, a couple of weeks ago the two of us modified the Teros 11 timing settings in /// @brief Sensor::_warmUpTime_ms; the Teros 11 warm-up time in SDI-12 mode:
/// 245ms typical
#define TEROS11_WARM_UP_TIME_MS 250
/// @brief Sensor::_stabilizationTime_ms; the Teros 11 is stable after 50ms.
#define TEROS11_STABILIZATION_TIME_MS 50
/// @brief Sensor::_measurementTime_ms; the Teros 11 takes25 ms to 50 ms to
/// complete a measurement.
#define TEROS11_MEASUREMENT_TIME_MS 50I think we increased the warm time to seconds, but it didn't make a difference. If I understand correctly, with this commit a6eee75#diff-c2718078e9b993d65131fd0cc535a573e7e2d2130591c9a77021d3f7519ae383 /// @brief Extra wake time required for an SDI-12 sensor between the "break"
/// and the time the command is sent. The Terros-11 requires no extra time.
#define TEROS11_EXTRA_WAKE_TIME_MS 0and that we might want to try increasing it from 0 to 10 ms or maybe higher. Is that right? |
|
@GArrigotti-cws, the other thing we'll try is to power the Teros 11 with 5V. I just learned from @SRGDamia1 that the Mayfly's ATmega1284p microprocessor can actually handle up to 6V. To protect the Mayfly, we've always powered Meter sensors at 3.3V to match the Mayfly's voltage. Although most Meter sensors say they need a minimum power of 3.6 V to 4.0 V, we have found that they operate fine at 3.3. However, maybe the Teros 11 is more sensitive at low voltage. Also, it's stated minimum is 4.0 V, unlike many of the others that list 3.6V. See http://publications.metergroup.com/Integrator%20Guide/18224%20TEROS%2011-12%20Integrator%20Guide.pdf |
|
Yes, you could try increasing the extra wake time. For a long time it was zero, then I bumped it up to 10ms for the RDO. I found the newest Meter sensors did not respond consistently with the delay so I made it an argument so it could be set back to 0 for the Meter sensors. The extra wire time applies to every SDI12 command sent to the device. Since the whole SDI12 is designed for environmental sensors; the sensors are required to go to sleep any time except when they are being addressed or measuring. The sensors are required to be ready to listen for a new command within 100 ms of a "break" and "marking" on the SDI12 line. The Meter sensors don't need any of that 100ms, they're ready within the space of the break and marking. The newest CTD we got actually was a little flaky when given the extra time. I think some of the Campbell sensors need the full 100ms. So, for a Meter sensor, I suspect the right amount of time is 0, but you can try increasing it. It should never be over 100. Also, the maximum voltage on a pin for the 1284p is dependent on the voltage it's powered at; it should be no more than 0.5V higher than the power voltage. The Mayfly powers it with 3.3V, so the pin max is 3.8V. It's as much voltage differential as absolute voltage. The very maximum power voltage it can handle is 6V, but that's not what the Mayfly has. So, while I really don't think short pulses like SDI12 at over voltage are really likely to be problematic, I definitely would not recommend regularly subjecting the Mayfly pins to 5V for long periods of time. |
|
@SRGDamia1, that's a very helpful explanation! Thanks. I just looked again at the Meter Teros 11-12 Integrators Guide, and it says that output voltage is typically 3.6V! I had thought the SDI-12 specification was 5V for SDI-12 sensors, and presumed the Teros 11 followed that. So for the Meter Teros 11 or 12 sensors, even if they are powered at ~12V, their digital high signals should still be ~3.6V. The Meter Hydros 21/CTD Integrators Guide shows the digital output voltage of ~ 3.6V. So, it seems we should be powering these Meter sensors at 5V. |
|
(EDIT oops just reading on and Sara said the same thing) Hello I'm wondering where the info on the mega1284 handling up to 6V (on a input pin from SDI-12?) came from. In the data sheet I've been using from the BOM ATMEGA1284P_VQFN44 or ATMEGA1284P-MU it says the Absolute maximum ratings, Voltage on any pin except RESET is to Vcc+0.5V. |
|
Reading the Meter Teros 11 spec, it does fit with what SDI-12 spec. |
|
@neilh10, just be clear, I had misunderstood the comment from @SRGDamia1 about the Mayfly's 1284p being able to handle 6V. She clarified in #276 (comment) that the 1284p is only specified for that voltage if it is also powered near that voltage, and that the plus/minus 0.5V is still the spec. Thanks also for noticing that extra info about SDI-12 voltage ranges. It's clear that I should try powering these sensors with 5V. |
|
@GArrigotti-cws and I are testing right now. Seems like 5V help a bit. We now have both sensors working in Sensor Testing Mode, but only one works in regular logging mode. |
|
Update from testing this afternoon:
Here's the example of it working with both debug statements defined: |
|
Oddly enough, in if you put it into sensor testing mode now both sensors will work. We increased our wake time to five to ten seconds, but it will fail in normal logging interval. But will will allow the normal interval to work if you enable the variable array debug in the .ini file. @aufdenkampe will post my output- Still really odd. |
|
@SRGDamia1, we've found a bug where we can only read 1 of 2 Teros11 sensors unless we have defined Any ideas on what might be causing this bug? I plan on working on this tomorrow (thanks @GArrigotti-cws for sending me two Teros11 sensors), so I could do specific testing. |
|
No, scanning all the debugging prints, I don't see anything in the variable array debug that would lead to that. It's particularly odd because if it was an error there, I'd guess we'd have seen it much earlier. Do you have your SDI-12 addresses set one after the other or are they spaced out? I find sometimes the sensors get confused if I use "1" and "2" but putting space between them (ie "1" and "4") helps. I suspect that has something to do with the not-quite-exactly-perfect timing in the SDI-12 library due to bit-banging and interrupt hand-offs. Could you please post turn on debugging for SDI-12 and the Terros and then post the full log from a couple of readings with and without the variable array debug? Obviously the output from the latter will be much longer than the former, but I should be able to line them up and see more of what's going on. ie, first use and post output from : then use and post output from: |
|
@SRGDamia1 Here should be the information, I have the address one and six. I also placed sensor one at the top of the variable array and moved the other one to the bottom. @aufdenkampe and I did play with some of the timing issues also in varying configurations. const char* teros11SDI12address = "1";
const int8_t terosPower = sensorPowerPin;
const int8_t terosData = 7;
const uint8_t teros11NumberReadings = 3;
MeterTeros11 teros11(*teros11SDI12address, terosPower, terosData, teros11NumberReadings);
const char* teros11_2SDI12address = "6";
MeterTeros11 teros11_2(*teros11_2SDI12address, terosPower, terosData, teros11NumberReadings); |
|
@SRGDamia1 The other file you requested. build_flags =
-DSDI12_EXTERNAL_PCINT
-DNEOSWSERIAL_EXTERNAL_PCINT
-DMQTT_MAX_PACKET_SIZE=240
-DTINY_GSM_RX_BUFFER=64
-DTINY_GSM_YIELD_MS=2
-D MS_SDI12SENSORS_DEBUG
-DMS_SDI12SENSORS_DEBUG_DEEP
-DMS_METERTEROS11_DEBUG
-DMS_VARIABLEARRAY_DEBUGYeah, I noticed that. Not entirely sure why though, the same code is having very different outputs. |
|
The problem isn't with the sensors not responding, it's with the volumetric water content. |
|
@SRGDamia1 But if I disable the debugging libraries then output is very, very different for the results saved to the SD Card. Same everything, 2000-06-06 05:39:00,1.25123,23.10,0.000,23.63,44.978,101405.84,4.882,24.75,-9999.00000,-9999.00,0.000 |
|
@GArrigotti-cws and @SRGDamia1, thanks for working on this! Greg, Sara is asking for you to share with her the debug output when it fails. That's what she needs to see to figure out what is wrong. Run it once with your build_flags =
-D SDI12_EXTERNAL_PCINT
-D NEOSWSERIAL_EXTERNAL_PCINT
-D TINY_GSM_RX_BUFFER=64
-D TINY_GSM_YIELD_MS=2
-D MQTT_MAX_PACKET_SIZE=240
-DMS_METERTEROS11_DEBUG
-DMS_SDI12SENSORS_DEBUG
-DMS_SDI12SENSORS_DEBUG_DEEP
-DMS_VARIABLEARRAY_DEBUGThen run it again with the last line commented out, and save output to a text file called build_flags =
-D SDI12_EXTERNAL_PCINT
-D NEOSWSERIAL_EXTERNAL_PCINT
-D TINY_GSM_RX_BUFFER=64
-D TINY_GSM_YIELD_MS=2
-D MQTT_MAX_PACKET_SIZE=240
-DMS_METERTEROS11_DEBUG
-DMS_SDI12SENSORS_DEBUG
-DMS_SDI12SENSORS_DEBUG_DEEP
; -DMS_VARIABLEARRAY_DEBUG |
|
Ok, I have some suspicions about what might be causing the failures. I think it's probably something in the VWC calculation that's throwing everything else off. To narrow down the issue, I'm going to modify the Teros to output 4 variables - keeping the "calibratedCountsVWC" that is currently being ditched and I'm going to separate out the calculations a little. I'll try to get something ready for you to test tonight. |
|
@SRGDamia1, thank you! I'm on the phone with Greg right now, and he says that enabling So it makes it hard to see what is going on to cause the failures. Sara, do you need more info about when these fail? |
|
@SRGDamia1 @aufdenkampe I can reproduce a failure by doing the following: [build]
build_flags =
-DSDI12_EXTERNAL_PCINT
-DNEOSWSERIAL_EXTERNAL_PCINT
-DMQTT_MAX_PACKET_SIZE=240
-DTINY_GSM_RX_BUFFER=64
-DTINY_GSM_YIELD_MS=2
-D MS_SDI12SENSORS_DEBUG |
|
@SRGDamia1, Greg says the test sensors are in the air, so volumetric water content should be zero. That might not be the problem. |
|
@SRGDamia1, I just noticed that you released Modular Sensors v0.28.5 two weeks ago. Greg and I have been using v0.28.4. Any chance that might be a factor? |
|
@aufdenkampe Looks like the latest modular sensors still did not rectify the problem, ironically it inverted which sensor had -9999. My .ino file: [external:libraries]
lib_deps =
EnviroDIY_ModularSensors@=0.28.5
https://github.com/PaulStoffregen/AltSoftSerial.git
https://github.com/SRGDamia1/NeoSWSerial.git
https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.git
https://github.com/vshymanskyy/StreamDebugger.git
[build]
build_flags =
-DSDI12_EXTERNAL_PCINT
-DNEOSWSERIAL_EXTERNAL_PCINT
-DMQTT_MAX_PACKET_SIZE=240
-DTINY_GSM_RX_BUFFER=64
-DTINY_GSM_YIELD_MS=2
-D MS_SDI12SENSORS_DEBUG The .cpp file is as follows: const char* teros11SDI12address = "1";
const int8_t terosPower = sensorPowerPin;
const int8_t terosData = 7;
const uint8_t teros11NumberReadings = 3;
MeterTeros11 teros11(*teros11SDI12address, terosPower, terosData, teros11NumberReadings);
const char* teros11_2SDI12address = "6";
MeterTeros11 teros11_2(*teros11_2SDI12address, terosPower, terosData, teros11NumberReadings);These are the timings I tried with the new modular sensors: #define TEROS11_WARM_UP_TIME_MS 250
#define TEROS11_STABILIZATION_TIME_MS 50
#define TEROS11_MEASUREMENT_TIME_MS 50
#define TEROS11_EXTRA_WAKE_TIME_MS 0#define TEROS11_WARM_UP_TIME_MS 1550
#define TEROS11_STABILIZATION_TIME_MS 50
#define TEROS11_MEASUREMENT_TIME_MS 50
#define TEROS11_EXTRA_WAKE_TIME_MS 0I verified against the new modular sensors, same results. |
|
Can you try the new sensor_calc branch: https://github.com/EnviroDIY/ModularSensors/tree/sensor_calc? I added an internal parameter for sensors referring to the number of variables that are calculated internally and then split out the calculations for the Teros some. I also added some debugging. Can you post results with no debugging and with all the SDI-12 debugging? |
|
you should be able to pull the new branch with: lib_deps =
https://github.com/EnviroDIY/ModularSensors.git#sensor_calc |
|
@SRGDamia1 Would you like the deep debugging enabled? Or the normal SDI12? |
|
@SRGDamia1 After some troubleshooting, the following output log was produced: [external:libraries]
lib_deps =
https://github.com/EnviroDIY/ModularSensors.git#sensor_calc
https://github.com/PaulStoffregen/AltSoftSerial.git
https://github.com/SRGDamia1/NeoSWSerial.git
https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.git
https://github.com/vshymanskyy/StreamDebugger.git
[build]
build_flags =
-DSDI12_EXTERNAL_PCINT
-DNEOSWSERIAL_EXTERNAL_PCINT
-DMQTT_MAX_PACKET_SIZE=240
-DTINY_GSM_RX_BUFFER=64
-DTINY_GSM_YIELD_MS=2
-D MS_SDI12SENSORS_DEBUG
-DMS_SDI12SENSORS_DEBUG_DEEP Based on several outputs they both appear to be working with the above configuration. However, if I turn off the debugging: -D MS_SDI12SENSORS_DEBUG
-DMS_SDI12SENSORS_DEBUG_DEEP Then I receive this output though I'm on the same branch: |
|
Okay. I'm flat-out stumped. I made some tiny changes, which you should be able to get with a Get another Mayfly and program it with this freshly-written SDI-12 spy program: https://github.com/EnviroDIY/Arduino-SDI-12/blob/master/tools/SDI12_spy/SDI12_spy.ino Connect the ground and sdi-12 data (7) pins, keeping your wires as short as possible. Post the output from the spy along with the output from running with and without the debugging flags. There probably will be some garbage in the output from the spy, especially if your grounds aren't perfect, but it should at least give us some idea of what's going on. |
|
There's definitely going to be garbage in the spy line, because it will parse the controlling line changes as garbage characters. I'll think about fixing that. But, anyway, even with garbage, it might help. |
|
@SRGDamia1 I've got to buy some additional cables, but I'll do that tonight and attempt in the morning. |
|
@SRGDamia1 I'm hoping to get those cables to provide the information, I apologize for the delay. Had to shift priorities temporarily. |
|
@SRGDamia1, we're back at this issue, and now I have two Teros11 sensors for testing. For some reason, I'm seeing the error even when the relevant debug statements are turned on! What I see is that within an action cycle, the first of the two SDI-12 sensors does not respond on the first try, but does on the second. We see this during setup with This is the specific output sections I'm referring to: Then later... DETAILS: The output below is compiled with: build_flags =
-D MS_SDI12SENSORS_DEBUG
-D MS_SDI12SENSORS_DEBUG_DEEP
-D MS_METERTEROS11_DEBUG
-D MS_VARIABLEARRAY_DEBUG
lib_deps =
https://github.com/EnviroDIY/ModularSensors.git#sensor_calc |
|
I found the fix. build_flags =
-D MS_SDI12_NON_CONCURRENTEvidently the Teros 11 sensors do not like concurrent SDI-12 measurements. Both of my sensors are supposedly This works with or without the debugging statements turned on. |
|
... but defining I'm beginning to think that the solution will require modification of the while (!didAcknowledge && ntries < 5) {
_SDI12Internal.sendCommand(myCommand, _extraWakeTime);This is slightly complicated, however, because there is already a while loop there, which I don't want to mess up, nor the stream buffer for those subsequent functions. |
Based on simple logging, with no other sensors nor a radio. For testing issue #276 (comment) Presently working on this `sensor_calc` branch with `MS_SDI12_NON_CONCURRENT` defined, but this is a temporary fix as described in the issue.
|
@SRGDamia1, thanks for merging From my comment above, I may need your help in implementing the fix. I'll let you know when I'm ready for testing again. |
|
@aufdenkampe - do let me know, but I'm really, really behind on pretty much everything right now. Before I left in July, I was starting to pick through the SDI-12 library to see if I could optionally use a different (10 or 16 bit) timer where possible instead of the 8bit timer to be able to have a little more buffer in reading the SDI-12 bits in before the timer rolls over. I was thinking that might improve the back and forth just a touch. But I haven't picked it up since then and I don't know when I'll get a chance to think about it again. I've also dropped my hours just a little to better manage 4 kids at home. |
|
@SRGDamia1, thank you so much for issuing release v0.32.2! It looks like you addressed many if not all the issues I raised here! Thank you! I understand that your time is limited. I will let you know when I am able to test it all out. |
|
The Teros 11 sensors are working well as far as I know. I should have closed this a while ago! |
|
It's possible that there is still a bug in this implementation. See: |
The Meter Group purchased Decagon about a year ago, and just recently stopped selling the 5TM soil moisture sensor, replacing it with the Teros 11 Soil Moisture + Temperature sensor, which uses a more robust construction design that Decagon had been piloting.
Unfortunately @Volk3rJ discovered that the SDI-12 commands are no longer the same. These differences include:
@Volk3rJ partially solved #2 by placing the sensor-variables as far apart as possible in the variables array. He also noticed some hints of these differences in the TEROS 11/12 INTEGRATOR GUIDE and the TEROS 11/12 USER MANUAL.
The text was updated successfully, but these errors were encountered: