Logging to EnviroDIY... suspected timing issues

[fisherba]

Hi @SRGDamia1,

I have a set of deployments at https://github.com/LimnoTech/EnviroDIY_deployments/ (I believe you have access to this repo) that contain several sensors: 3 Yosemitech DO 2 Yosemitech conductivity 1 MaxSonar 1 5TM

When I run the tests individually for MaxSonar and 5TM, they work fine from this directory: https://github.com/LimnoTech/EnviroDIY_deployments/tree/master/deploy-BAF/testsketches with lib_deps = EnviroDIY_ModularSensors@>=0.9.0

When I run a sketch with the whole group together, such as: https://github.com/LimnoTech/EnviroDIY_deployments/tree/master/deploy-BAF/CMP01 also lib_deps = EnviroDIY_ModularSensors@>=0.9.0 I have two problems:

1) the MaxSonar reports -9999 but everything else works. 2) the RTC set at the beginning of the sketch. Modem signals are usually in the 20-40% range, so not awesome, but @aufdenkampe suggested that this might be a timing issue (maybe that's the case for both issues?).

Thanks for any advice you can give!

[SRGDamia1]

I can try to look into the issue with the Maxbotix. Could you please open the MaxbotixSonar.h file and uncomment the line for debugging and recompile and post the output?

Does the modem give a stronger signal when you're running some other program? I don't think a timing issue is likely, except if maybe the signal strength is variable or the sim800 chip registers better signal the longer it's connected to the internet. Again, open the loggermodem.h file and uncomment the line for both debugging and deep debugging and post the output. I have no 2G signal at all in my office and very poor signal at home, so I'd be very happy to see numbers that high.

[SRGDamia1]

Is this now working?

[fisherba]

http://data.envirodiy.org/sites/NLP01/ is my current logging instance of this. It is spottier than I expected, but probably not much different than the 5TM. (I hadn't checked for a while.)

Now that we have the logger timing settled, I need to go back to these stations and upload new sketches.

[SRGDamia1]

Okay, let me know. Please close the issue if you think it's fixed.

[SRGDamia1]

I guess it depends on what you mean by "spotty." It doesn't look like there are missing points to me; at least not in places where everything isn't missing.

As for the spikes in the data... It's really, really hard for me to say if that's the library or the sensor itself. It is possible that the communication isn't perfect which is causing occasional slightly-garbled data that shows up as spikes instead of being outright rejected (and given as -9999).

We've frequently seen spikes in the sonar data. If they get condensation on them they'll sit at 300 or 500 (the blanking range). Because of that (and because the sonar is fast) the code already forces up to 25 re-measurements if it gets a 0, 300, 500, 4999, or 9999 (ie, blanking or max range values). I'd try averaging 3-5 readings from the sonar (and each of those 3-5 will actually take up to 25 attempts if it gets a known bad) to try to smooth the data a bit. You can also try NeoSWSerial instead of SoftwareSerial_ExternalInts if you think it's a communication problem. SoftwareSerial_ExternalInts is definitely NOT a good serial implementation.

As for the spikes in the 5TM... I don't know. Again, it's possible that it's a communication issue. Or it could just be the sensor. I can put code in that would automatically throw away excessively high temperatures and EA/VWC values that result in >100% water, but that will just give you a -9999 instead of a spike unless you average. (If I force those numbers to -9999 and you average, then the averaging routine automatically skips the -9999 and keeps the "good" so it might actually only "average" 1 reading instead of however many you told it to, but it will give you back that one good value.)

[SRGDamia1]

I added the "reality-check" filters to the 5TM.

[SRGDamia1]

@fisherba - do you know if you're still seeing problems like this?

[SRGDamia1]

Is this still an issue?