Vegetal Studies

First, thanks to everyone for sharing this conversation because it affords a substantial comment.

Actually, Adrian's comments about thresholding and hysteresis are both deep and big issues, and, as Morgan pointed out, relevant to PLSS or any sensing problem :)   As Morgan pointed out, it is sufficient to leave a continuous map from water sensor to LED intensity. 

(1) So many assumptions are made converting from the analog world to a discrete representation that it  becomes meaningless to talk about "linear" relation between soil humidity to LED intensity.

(2) Linearity itself is meaningless because 

2.1  The relation between concentration of water to soil, or osmotic pressure to plant health is nonlinear and unknown (to the beholder in the TML);

2.2  The relation between electrical signal from sensor to cinput value in a piece of microprocessor code is nonlinear and unknown (to the programmer);

2.3  The relationship between chip output current and LED intensity as measured by a photometer at the eye of the beholder is nonlinear and unknown (to the programmer and to the beholder);

2.4  The relationship between LED intensity as measured by a photometer and the apparent intensity to the eye of the beholder is nonlinear and unknown to the beholder;

2.5  The relationship between one beholder and another beholder's sensitivity to LED intensity is nonlinear and unknown to the programmer.

The ONLY qualities that we should try to guarantee is that, for each given sensor in each given location:

1.  Reproducibility: same soil humidity yields the same LED intensity.

2.  Monotonicity:  soil humidity h1 > h2 => LED intensity[h1] > LED intensity[h2]

or vice versa if you wish: soil humidity h1 > h2 => LED intensity[h1] < LED intensity[h2]

This should be MUCH easier to implement, MUCH less work.

Given some average adjustments to accommodate for coarse limits like soil humidity ranges, and visibility of the LED's in the room under daylight conditions, leave it to us humans to each individually learn how to interpret the LED intensities.

Minimax: Least engineering for Maximum experiential impact.

Use analog first.   Digital only when you must, and understand what reductions you are incurring.

Regards,

Xin Wei

On 2011-03-17, at 12:10 PM, Morgan Sutherland wrote:

Hi Michal, (cc'ing Xin Wei by Jane's request),

My take is that the benefit doesn't justify the cost – 5-wires per node is a lot of wiring. But let's be more precise. Here's how I see it:

AFAIK the relationship between voltage-out from the sensor and soil humidity is reasonably linear. So the question is, does it make sense for the LED to vary linearly with soil humidity times some scalar (controlled by potentiometer), or should the response be non-linear, i.e. on-off, exponential, etc.?

My reading was that linear would be fine because we don't care about intermediate states. We don't need to exclude the middle because the human does it automatically. Approaching the LED, you will ask "is it bright, or not?" How likely is it that you will mistake an intermediate state for a higher or lower intermediate state?

I agree that adding something like an exponential curve for instance will make the readings clearer, but I'm not sure if it will be a problem. Maybe we should try it and see?

Another option would be to put a comparator on each sensor with a tunable threshold so that the LED just turns on when the plants need watering. I'd rather avoid this though for reasons that Adrian detailed recently (I'll forward the email if you're curious) – suffice it to say it's not in line with the TML Way.

A bigger problem that just occurred to me now is that the 'signal out' from the sensor might not vary current linearly with voltage (since the signal is carried on the voltage), which means that the LED might not dim if it's hooked up to the signal out as we suspected. In that case we might need to add an op-amp and some circuits to do the conversion: http://www.allaboutcircuits.com/vol_3/chpt_8/7.html – this would be best worked out with an analog guru like Martin.

So, my opinion is that it would definitely be better to control the LED's with the microcontroller, but only if it justifies the extra cabling and implementation complexity. My gut feeling is that an LED linearly coupled with the sensor reading (multiplied by a hand-tuned scalar) is sufficient for the task, but I could be wrong. (Another advantage to using the microcontroller is that we could easily swap the LED for another kind of feedback device (say, a speaker) later on.)

Morgan

P.S. Sometimes I worry that I take "worse is better" a bit too far...

On Thu, Mar 17, 2011 at 10:09 AM, Michal Seta <djiamnot@gmail.com> wrote:

Hi all,

Regardless of the microcontrollers/hardware and connectivity issue, I
too have some thoughts about what we discussed yesterday.  Going back
to the design of electronic circuit that includes indicators (LED) for
the plants, I think that the original idea of having a LED controlled
by the program/firmware, is in fact more appropriate one.  This is
because the plants need to be watered not only according to the
moisture level of the soil but also according to their needs (desert
plants can last a long time in dry soil).  This aspect should be
controlled either by the microcontroller or, preferably, a computer
program, which would be adjusted according to what kind of plants are
hooked up into the system.  In that case, a LED will go on only after
a certain time interval that the soil would have been dry.  I am not
sure about the analog dial (pot) for the circuit.  For a standalone
solution (microcontroller only) it would make sense to have some
relative control.  If this is going to be hooked up to a a computer
anyways, we could foresee programming a user interface which will
allow for specifying some kind of conditions per plant (I suppose this
would be preferred solution).

I hope I am making sense, please let me know if I am off the track
(wrt PLSS philosophy) or if something is unclear.

Best

Michal

On Wed, Mar 16, 2011 at 11:51 PM, Morgan Sutherland

<skiptracer@gmail.com> wrote:
> Hello Jane,
> If we want to use Ethernet rather than USB, I recommend using this WIZnet
> module which has an associated Arduino library so development is
> trivial: http://arduino.cc/en/Reference/Ethernet
> If you want to trade money for time, you can get the Arduino Ethernet shield
> (yes, it's compatible with the Seeeduino Mega), which is the same Wiznet
> chip: http://www.sparkfun.com/products/9026
> There are four advantages to ethernet that I can think of:
> (1) the cables are cheaper and you can make them to the exact length you
> need
> (2) there is no cable length limit
> (3) if the cable is accidentally unplugged, you don't need to restart your
> software in order to re-establish a connection, it's just always pushing the
> data onto the network without any "hand-shaking" required and
> (4) if we connect it to a switch (like the one on Michael's desk) the data
> is available to any computer in the lab – that would be useful for a day in
> the future when my computer is not located near the box.
> The downsides:
> (1) more development time
> (2) $30 extra
> I'd be curious as to why you were recommended another ethernet solution
> since this one is proven to work well and has an easy to use library.
> Morgan
> On Wed, Mar 16, 2011 at 6:21 PM, Morgan Sutherland <skiptracer@gmail.com>
> wrote:
>>
>> Hi Jane,
>> Silicone conformal coating for protecting circuits from water:
>>
>> http://www.abra-electronics.com/products/422B%252dP-MG-Silicone-Conformal-Coating.html
>> The microcontroller we have + will use:
>>
>> http://www.seeedstudio.com/depot/seeeduino-mega-p-717.html?cPath=80&zenid=22b1d4d04f39a87446605e3c6bf360ef
>> Morgan
>