Implemented real calculated variables #153
Conversation
Totally untested
Needed for the calculated variables in arrays
This will always be dependent on the user implementing the -9999 return in their calculation function.
|
The headers for the calculated variables will be in their proper place with all of the others, and the calculated results will even appear in testing mode. |
Not sure why I thought this could not be done.
|
@SRGDamia1, this is awesome. Thank you for taking the initiative to do this. I think it will significantly simplify some near-future work and open up many doors for new features. Thank you. I'll try to test soon. |
|
Awesome! I will have a station with me this week and will take some time to test it. Maybe you can take a peek at the TP Downhole sensor if we are able to stop by. It's pretty cool. |
but instead contains a variable array object as an internal member Also made the former init function into a constructor
|
TP Downhole sensor? |
I like the logger info better at the top, even if we create the logger at the bottom.
Kill init
|
I just added a bunch of restructuring to this. THIS DESTROYS BACKWARDS COMPATIBILITY!! I've updated the examples, please update your code. |
|
So far I can't get the sketch to proceed at all. It stalls out as below. Since it's not even proceeding to measurements, I don't know what debugging would be useful to you. |
|
I'm sorry. I'll try to check it out once my kids are healthy again. (Hopefully tomorrow.) |
|
The sketch seems to be working fine for me. Are you sure you have everything up-to-date? You need to be at a84934e for the library and the example sketch. I made changes that broke backwards compatibility, so anything you have based on an example from earlier than that will fail. |
Pointer ref
Except for XBee's, which do not return a signal strength until after a full TCP connection is made. Other modems can ask for CSQ even without being registered to the network. Need to verify this for ESP8266's.
|
I am finally able to test this and deployed stations using the new calculated variables sketch yesterday. It worked for me (using EnviroDIY_ModularSensors@>=0.11.6) with one interesting caveat. I need to have the I2C pin on the Mayfly always on (as 3v3, not "3v3 switched") when MS5803 sensors are connected for the sketch to proceed past: If just the BME280 is attached to I2C, the sketch proceeds just fine. Maybe the sketch is trying to talk to the I2C devices before their power is switch on? At any rate, if I2C power is set to always on, then the calculated variables sketch works. ....And that glitch isn't exactly related to this pull request, but I figured I would tell you my observations.... |
|
I just did some testing, and this ModularSensors calcVar branch as of June 4, 2018 fixes the weird issues that we've been noticing with Maxbotix sonar, as described in https://www.envirodiy.org/topic/minor-glitch-reading-maxbotix-mb7389-with-mayfly/#post-12346 This may confirm that the Sonar issue described in #128 was also fixed. |
There was a problem hiding this comment.
I've now successfully tested this branch on a number of stations. The new calculated variables approaches works (see https://github.com/LimnoTech/EnviroDIY_deployments/commit/3b15b3c0c78e2cd0e9409370bc760168ac01fff1), and the included fixes to the Sonar buffer issue fixes instabilities in those results.
Let's try to move this to Master and a new release!
Wahoo! Closes #127
@aufdenkampe and @fisherba please test out the baro_rho_correction example now. You no longer have to do any messing with the text strings and can use the basic "log()" function.