Soil Humidity - any ideas how to fix the values?

Posted on
  • I've done a garduino project last year, not connected to the internet, and @Gordon posted in one of the forums that he created a Xively DHT11 (temp/air humidity) tutorial.

    So I extended that idea with another sensor, a soil humidity sensor. It is just two pins connected to teh soil - one is put HIGH to send 5V and the other reads the analog value - between 0,1 on the espruino.

    It works pretty well - unless I connect it to a 5V/1A power supply via the socket. That really means: if the espruino is connected to my battery-powered Google Pixel, or powered via a USB battery, it works very well - I read always around the same value (which is already averaged over 20 samples).

    But once I connect it to the power supply - a phone charger / USB, connected to teh wall socket, it gives me crazy values - each measurement differs wildly from the last one.

    I am really scratching my head what causes that? Any ideas are welcome :-)

  • hansamann,
    Do you have any sort of series scaling resistor in the circuit? My guess is that the current limited USB supply acts a bit like a constant current source. If the wall supply is not as well regulated and has a much lower source impedance the reading would be jumpy. A series resistor would calm that down considerably and a capacitor across the two pins would provide some hardware averaging. The other type of soil moisture gauge that is common uses two different metal pins, such as copper and iron, with no excitation voltage. The electrochemical potential between the two drives a current through the soil. You would need a high-value resistor, ie 1M, at the espruino end to convert the current to a voltage. I think your two pins with a series resistor and parallel capacitor would actually work better; it has the advantage you can shut it off when not in use.
    Chris Z

  • Hi Chris, many thx for your comments. Meanwhile, I added a LDR for sensing the light intesity and I worked a bit on the WiFi stability - e.g. I disconnect from CC3000 and reconnect every 60 sec. It is not perfect, but runs a few hours at some point.

    I uploaded my code here for everybody to see:
    http://snipt.org/LgFh0

    The readSoilSync() function is doing this:

    • choose randomly which pin is in/output - this is done to reduce corrosion which was an issue in my last years project
    • turn on the out pin, read from the in pin - 20 times
    • average the values
    • turn off the out pin

    Changing the direction of in/out is mainly due to my last years experiences. I also sent a constant current through the soil last year, which I fixed in this project.

    Now, is your idea with resistors and capacitor still valid with this setup? I admit I've not tried it out yet, as I first would like to understand why it makes a differnce if I power it via the power supply compared to the battery. I am planning to do this tonight and before I'll try a few other 5V power supplies (from different phones).

    Thx!
    Sven

  • I have a few pics online, in case this helps to figure out the project:
    https://plus.google.com/1116211951748696­91859/posts/jV83MpZTzDh

  • OK, I'm a bit lost here. It does work constantly with similar results as via the battery with a different power supply. I used a supply from a samsung phone now, connected via micro USB.

    So... that's good. There must be something with the other charger.

  • Sven;
    Thanks for the pics and the code snippet. I have a few more questions for clarity. Is there any kind of R-C network on your measurement pins now; either to ground or between the pins? It appears that you have a clean signal when operating from a "floating" battery supply and a noisy one when using a supply plugged into the wall outlet (referenced to local earth). Is that true? From your expanded comments my original comment about the USB source being the current limiter does not apply; your excitation pin is connected to the regulated 3.3 of the Espruino through the port pin (that is my reading). Is that a correct reading of the setup?
    Cheers,
    Chris

  • It could be that the USB wall adaptor was particularly 'noisy'... I guess cheap ones are probably designed to output a lot of power (1-2A) at 5v, and when Espruino a plugged in and draws 10mA, the signal is probably pretty noisy.

    The other thing you could do is to call E.getAnalogVRef() - this tells you what voltage Espruino thinks it is running off. It should be ~3.3v, but maybe the wall supply goes into some kind of power saving mode and the output voltage drops below what Espruino needs?

  • The power supply used was for an Asus Nexus 7 - a USB charger. I think it's supposed to supply 1A at 5V - but the power saving mode you mentioned sounds like a interesting reason for the issue. It's gone now with a Samsung charger :-) But just for fun I am also reporting the getAnalogVRef to Xively, so when I swap the charger again I would see it in the logs.

  • HI @Gordon, might have found the issue. I was just refactoring the code a but, throwing out the useless vref value, etc. and then noticed that it was running really nicely when connected to my mac, debugging to the web ide.

    When I prepared the espruino for running off the usb power supply, I would typically do
    debug=false to turn off all debug statements and then
    save()

    Now, I cannot understand why, but when I keep the debug statements (console.log) turned on, it works. It not running for hours how, but it seems to fix something.

    I've uploaded the latest code - I have only a few console.log in there. Could it be that one has to "consume" or touch the data variables, e.g. response data at least once so it is freeing memory or not blocking? That's happening when debugging in my code is on for example.

    https://gist.github.com/anonymous/957214­1

    If you have time, please take another look - I am now trying to understand why it works if console.log turned on :-)

  • Hi;
    I will talk about a couple of hardware issues as I cannot provide any substantial help with the programming. Some USB power sources have internal current sensing that will cause them to sleep if no load current is detected. As a concrete example I have a rechargeable battery back that has two USB outlets (Ativa MobilIT 2400 mAh). When connected to the F3 Discovery board will all the bells and whistles it runs just fine. When I connect it to an Espruino with the HC05 Bluetooth module it runs fine for about 30 seconds and then shuts itself off. When I connect the same battery to an MSP430 Launchpad with a Bluetooth module I get the same shutdown behavior. In both the instances the battery pack decides it does not have a load. Given the amount of press from TI about the MSP430 being the lowest power processor on earth it is very entertaining that the Espruino gives it a run for the money!!
    For the soil resistance sensing there is a standard technique of reversing the current several times during one reading sequence. Set one pin high and the other as the analog input and accumulate the result. Reverse the roles of the pins and do it again; repeat this an even number of times so you have accumulated an equal number reads in each direction. Alternating like this will improve noise immunity against stray earth current and against surface differences in your pins by averaging it toward zero. There is also a concern that the nominal 40k pull down resistor at the inputs are not all equal; this scales your soil current into a voltage. I expect this would be equal on a given chip but vary from chip-to-chip. Alternating would average out pin-to-pin variations on a given chip but the repeatability from one chip to the next could be a problem. If you truly want to calibrate these it may be worthwhile to run a fixed resistor to ground from each pin and not use the internal one; for a one-off I would not bother.
    Cheers,
    Chris Z

  • Thx for the great comments. Especially for the tipps on how to read the soil values. Will change my code soon - right now I randomly choose a directly for each reading session and then stick with it.

    My main problem though is still the connectivity. Today I was lucky to reset in the morning and according to xively it was running till 14:00 - but that was real luck. It still seems to hang at some point and then I need to manually reset.

  • Thanks - I'll try and look into the CC3000 again. Keeping the WiFi connection open actually seems to be relatively reliable now but I'll see if I can figure out why it's crashing.

    A quick fix might just be to enable the watchdog timer that now exists? http://www.espruino.com/Reference#l_E_en­ableWatchdog

    If you set it for something like 20 seconds it'll probably be enough to handle most cases...

  • Hi Gordon - I have tried the enableWatchdog method out - but it does not quite work. I also don't quite understand: a reset does not load the saved program, right?

    Reset the interpreter - clear program memory, and do not load a saved program from flash. This does NOT reset the underlying hardware (which allows you to reset the device without it disconnecting from USB).

    Right now I am calling the watchdog timer in onInit with 10 seconds.

  • The watchdog hard resets (much like hitting the RST button), which will load data from flash - I think you're looking at the docs for the reset() function?

    What doesn't work? it should reset the device if any command takes longer than 10 secs to complete (which some of the CC3000 commands do unfortunately :( )

  • Ah, ok - I guess I was confused as from the watchdog function the reset function is referenced... but nothing states it is a hard reset. Might be obvious for people used to microconrtoller watchdog functions (not me :-)

    I'll give it another try tomorrow. Last time it stopped after a few hours...

  • All right, it seems the watchdog does not really work for me. I've got the final code up here:

    https://gist.github.com/anonymous/970613­7

    I had to reset the device manually twice this morning and it just stopped again.

    Here is the procedure so we can rule out all other issues:

    • transfer the code
    • save() -> init is called and it all starts
    • it is then in debug=true mode - I watch it a few times and then do
    • debug=false and save() again
    • I then disconnect from the mac/pixel and reconnect to the USB power supply. It works nicely for sometimes a few hours, but the secodn time it just stopped just after half an hour...

    How could I get more info and data if it's connected to a power source?

  • Hmm... Thanks - mind if I give your code a try?

    My guess is that somehow the intervals get removed - so Espruino is still working and responsive, but is just not doing anything. Does it not crash if it is left connected to the Mac?

  • Hi Gordon, feel free to take the code and massage it in any way you feel it makes sense. I can also send you the xively api key if that helps .All I connected is DHT11, LDR and the soil sensor- I think you could just mock LDR and soil sensor, simple analog reading, but the DHT11 might be interesting to really connect as it might be the reason for the issue. (e.g. it also uses a callback etc and it's a sensor that's a bit more complicated compared to the analog reading).

    Thx
    Sven

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Soil Humidity - any ideas how to fix the values?

Posted by Avatar for hansamann @hansamann

Actions