-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect and support SDI12 sensors that cannot use concurrent measurements #115
Comments
@aufdenkampe, it turns out that this has been the problem the whole time with SDI-12 for me. It was just that until I really started optimizing the timing of the sensors in the timing branch, there wasn't any noise on the line to confuse the sensors. |
Ugh! What a bummer. I'm also really glad that you figured it out! So those SDI12 sensors <v1.2 will need to bypass your awesome new timing stuff. Bummer, but I'm guessing you'll figure out a fix for it. |
Well, they won't so much bypass it as just slow everyone down. Essentially, they will have to be set up so the "StartSingleMeasurement" function does nothing, and the "addSingleMeasurementResult" function will both start a measurement and wait for a return. The MaxBotix and all the sensors off of the ADS1115 already operate that way. These will just be a little slower. Fortunately, the only sensor I'm having trouble with right now is a Decagon CTD that was made in 2012. The vintage 2016 version that I just grabbed isn't having any trouble. Those sensors seem to have very short lifetimes anyway (<2 years...), so I doubt it's going to be worth digging around and figuring out exactly which version of the CTD the implementation was fixed on and writing something special to deal with it. |
The current code will not detect whether the sensor can support concurrent measurements, but you can now manually disable them with the build flag |
Nearly any sensor with SDI12 version 1.2 or earlier will not support concurrent measurements. I've also found that (at least the older) Decagon CTD's are not actually compliant with concurrent measurements. They will take a measurement after a concurrent reading is begun, but they abort the reading if there are any breaks/marks/requests to other sensors sent on the line and only return their address in response to a data request. After being requested, a concurrent measurement (per specs >=1.3) should only be aborted by the sensor if it receives another valid command addressed to it.
The text was updated successfully, but these errors were encountered: