Forums

"Input" on an "output"

Started by Don Y September 15, 2013
Hi Jasen,

On 9/17/2013 2:50 AM, Jasen Betts wrote:
> On 2013-09-17, Don Y <this@isnotme.com> wrote: >
> put a resistor in series with the switch > -=- > +----o o--[470]------+ > | | > 24V ---------------------------+---[Solenoid]-------+ > (120) | > 0V -----[1.0]--------------------------------------+ > B > > sense voltage at point B above about 210mV is switch pressed, > you many want to use a trimpot for the comparison voltage > to allow use of different coils > > how to sense the button when the coil is off? > > -=- > +----o o--[470]------+ > A | | > 24V ---11K-----------------------------+---[Solenoid]-------+ > (120) | > 0V -----[1.0]--------------------------------------+ > > > measure the voltage at point A less than 1V is switch pressed. > same deal you'll need a pot to adjist the set point to > compensate for coil resistance. > > ( LM339 36V comparitor circa 30c a piece ) > > or perhaps wire it to a DAC input with 100K in series
Yes, sense a voltage, sense a current... two sides of the same coin (duality). This is *easy* to do when the solenoid, switch, etc. are on the same circuit board as your electronics (i.e., in a nice benign environment). It gets more difficult when the solenoid and switch are at the end of 100 ft of cable that acts like a giant_antenna/lightning_rod/opportunity_for_vandalism. Everything "exposed" (to the outside world) has to be consider as vulnerable. You don't want a nearby lightning strike to take out the electronics, there (hence my desire to use simple passives "out beyond the fence"). E.g., you wouldn't like it if your TV died each time you touched it with static charge on your person (because the case wasn't designed to dissipate this charge away from the electronics). You also have to contend with the sorts of things that happen to these installations over the years. E.g., people cut or break wires connecting solenoids to the controller, valves get replaced "unprofessionally" (cut old wires, twist wires for new valve onto old wires, FORGET to weatherproof connections), critters chew on wiring (possibly even removing segments and carrying it away -- e.g., pack rats), etc. At the very least, you want these sorts of EXPECTED problems to not cause your device to fail irreparably. And, as a value-added feature, it's nice if you can detect their consequences so they can be reported to the user ("The valve for zone 4 seems to be missing -- or has gone open circuit", "The valve for zone 8 appears to be shorted to the valve for zone 13", etc.). And, have some rational way of dealing with these problems *before* the user has been able to remedy them. For example, if the controller continues treating zones 8 & 13 (see above) as if they were NOT shorted, then several possible outcomes are likely: - if a single driver can not source enough current to engage the two solenoids coincidentally, then it is possible that NEITHER solenoid is engaged when zone 8 is driven, nor zone 13. So, the plants on those two zones don't get watered - if a single driver *can* source enough current to engage both solenoids, then both zones get surplus water equal to the watering *durations* of zones 8 & 13. This could kill the plants in either (or both) zones or just "waste water". - a smart controller could determine the safest approach if both valves engage simultaneously: -- replace the 8 & 13 "programs" with one that provides the minimum required for either (assumes one zone is a bit more drought tolerant than the other while the other is intolerant of overwatering) -- replace the 8 & 13 programs with one that provides the maximum required for either (assumes one can tolerate overwatering while the other can not tolerate drought) -- some compromise [In my case, the controller happens to know what's fed by each zone, what the microclimate in each of these locations is like, etc. So, the latter solution is very feasible. A generic homeowner might be satisfied with the first or second alternatives. A commercial nursery would probably be more keen on *my* approach -- so nothing dies or is unduly stressed before staff returns to work monday morning to fix the system!] [[why design two different controllers -- one for homeowners and one for businesses -- when the designs are so similar. Just omit the deployment details that the customer isn't willing to address!]] ----- Off to do some volunteer work (despite the heat!)... Sheesh, still 100 degrees and Fall is just around the corner :<
[Grrrr... in my rush to get out the door, I failed to proofread
this entirely]

On 9/17/2013 7:20 AM, Don Y wrote:

> For example, if the controller continues treating zones 8 & 13 > (see above) as if they were NOT shorted, then several possible > outcomes are likely: > > - if a single driver can not source enough current to engage > the two solenoids coincidentally, then it is possible that > NEITHER solenoid is engaged when zone 8 is driven, nor zone 13. > So, the plants on those two zones don't get watered > - if a single driver *can* source enough current to engage > both solenoids, then both zones get surplus water equal to > the watering *durations* of zones 8 & 13. This could kill > the plants in either (or both) zones or just "waste water".
A smart controller would drive the outputs for BOTH 8 & 13 simultaneously (as they are already known to be shorted, this at least ensures there is enough current sourced to engage both solenoids) whenever the program would call for *either* of these valves to be engaged. It could, then:
> -- replace the 8 & 13 "programs" with one that provides the > minimum required for either (assumes one zone is a bit > more drought tolerant than the other while the other is > intolerant of overwatering) > -- replace the 8 & 13 programs with one that provides the > maximum required for either (assumes one can tolerate > overwatering while the other can not tolerate drought) > -- some compromise
[And *now* I can go "do my thing"...]
On Mon, 16 Sep 2013 17:30:35 -0700, Don Y wrote:

> On 9/16/2013 12:19 PM, Charlie E. wrote: > >> The joys of plumbing! > > You've been inhaling too many solder fumes, Charlie. As I recall it, it's > _The Joy of *SEX*_! :>
Same thing, surely. There was a young plumber named Lee. Was plumbing a girl by the sea. Said she, "Stop plumbing, there's somebody coming". "I know", said the plumber, "it's me!" -- "Design is the reverse of analysis" (R.D. Middlebrook)
On 9/17/2013 9:54 AM, Don Y wrote:
> > FWIW, notice how often people reply to a post with a question > like: "Why would you need to do *that*?" instead of accepting > that the OP *wants* to "do that"!
Yes, because it is hard to think in the dark. If an obvious simple solution is visible, it begs the question, why is this a problem? Now I know, you want to water plants automatically using a controller and an electric on/off valve and setting the flow rate with the standard outside faucet. See, one sentence gives all the needed info...
>>>> BTW, coils are not specified for "inrush" and "holding". They are >>>> specified for pull in and drop out. These are typically voltages and >>>> specify the level at which the solenoid is guaranteed to pull in or >>>> drop >>>> out. Coils don't have "inrush" current, that would be a capacitor. >>>> Coils resist changes in current, so when you apply a voltage the >>>> current >>>> goes up gradually (even if gradually is quick). It doesn't spike up and >>>> then drop back. >>> >>> Excuse me, but the solenoids (coils) used in irrigation systems >>> *are* rated as "inrush" and "holding" current. That's what you >>> will find on their "datasheets" when you go hunting for specifics. >>> You can always be pedantic -- and your end user will end up >>> calling the solenoid vendor: >> >> I was trying to help in an area where I thought you didn't understand >> something. Obviously I am the one needing to understand somthing. What >> is the meaning of the "inrush" current? Does "inrush" refer to the >> water or the actual current? As I said, inductors resist change in >> current and do not have an inrush. > > Current. Note it's not just an inductor but actually a solenoid. > This is "just how its done" in that industry. The COTS controllers > apparently have really wimpy power supplies. And, can potentially > be interfaced to other ancillary equipment (e.g., you may need > to start a *pump* if your irrigation system is fed from well water; > the power to engage that "contactor" for the pump comes out of the > power budget of the controller. > > When "programming" such a controller, you can potentially have > multiple "zones" (valves/solenoids) engaged concurrently. So, > the homeowner (who often does this without hiring an installer) > needs some EASY way of knowing if his "program" can be supported > with the power available from the controller for the valves. > > E.g., I have 15 zone valves, here. Plus a "master valve" that > must be engaged for any of the other valves to "see water" > (it gates the water supply to the other valves). The zone > valves that I use are rated 0.3A inrush, 0.19A holding. > > Said another way, I need at least 3A to be able to have all > of the zones active concurrently (assuming I stagger their > turn-on times). If I want to be able to engage all of them > with a single control signal (i.e., coincidentally), then I need > closer to 5A.
Again, a lot of information, but you didn't answer the question. For me to understand how to use these solenoids, I need to understand the spec. What is "inrush current" and "holding" current? Do these solenoids behave differently from other relays and solenoids? I did some searching and this is not indicating the I/V characteristics of the solenoid. They are indicating the requirement for activation. Inrush is required for some duration for initial activation of the coil. Holding is the current required for continued operation. This is specified so that the PSU can be sized with an overdraw capability for some 10's or 100's of ms. This impacts the switch and resistor arrangement.
>> The trouble is that you might not power them from a 24 V supply. It > > The irrigation valve suppliers aren't aware of that. Just like > the automobile manufacturers are not aware that you might want > to install that big V8 in a *boat*. Or, use it to power a > genset.
But you *are*. You need to know how the coil will work in your circuit. But this spec should be enough info.
> What I'm pursuing, currently, is a "one bit" high voltage, high > current digital I/O driver that is current limited (i.e., so I > can put N of these on a power supply that is able to deliver > N * current_limit and not worry about the supply EVER being > dragged down). Isolated so conditions encountered on the field > wiring don't affect the controls (and beyond). Capable of > handling individual loads in the ~0.5A ballpark (overkill but > probably doesn't add anything to the cost) with open circuit > voltages in the ~50V range (though it will probably see 24V > max). The input will be a volt-free contact closure -- easy > to conceptualize (i.e., a switch -- whether that's a pushbutton > or a limit switch in a garage door opener or a reed switch > mounted on the garage door track, etc.)
When you say "isolated", can you put numbers on that? How do you plan to isolate the PSU? Are you going to use an isolated PSU? b Are you trying to protect the electronics as well? Lightning can be very hard to deal with, even indirect strikes. The induced voltage and current can be *huge*. Try to use twisted wires as much as possible.
> Said another way, I should be able to gut a pinball machine > (electromechanical or electronic) and use this as an interface > to emulate the original controls (though it would be horrible > overkill)
I don't think a pin ball machine will be a great source, but that is your call. What in a pin ball machine is isolated?
> It will eventually be offered for others to copy. Whether someone > wants to commercialize it or not isn't my concern. It's just one > component in a larger system. But, one that needs to be designed > in a way that would make it suitable for others' needs beyond just > my own -- including other applications (e.g., the pinball example).
??? -- Rick
On 9/17/2013 1:29 PM, rickman wrote:
> On 9/17/2013 9:54 AM, Don Y wrote: >> >> FWIW, notice how often people reply to a post with a question >> like: "Why would you need to do *that*?" instead of accepting >> that the OP *wants* to "do that"! > > Yes, because it is hard to think in the dark. If an obvious simple > solution is visible, it begs the question, why is this a problem?
See below -- things aren't always as obvious as they appear!
> Now I know, you want to water plants automatically using a controller > and an electric on/off valve and setting the flow rate with the standard > outside faucet. > > See, one sentence gives all the needed info...
First paragraph of my original post reproduced here: I've added four hose bibbs around the yard, each behind an electric solenoid (24V). The intent is for supplemental irrigation for new plantings, etc. (attach hose to hose bibb; run hose out to be proximate to the new planting; "program" irrigation system to dispense water via this particular "hose circuit" I believe this contains everything in your above "one sentence". Granted, it doesn't EXPLICITLY say, "The controller uses the electric valve to gate the flow of water on/off; the *user* uses the manual valve to adjust the flow rate accordingly (for the supplemental irrigation required by the "new planting" -- I would think it fairly obvious that you wouldn't want "full water pressure" coming from that hose! And, fairly common sense to anyone who has used a "faucet" of any kind that the faucet not only turns flow OFF but ADJUSTS the flow rate, over a continuum. Second paragraph of my original post: I'd like to be able to *manually* signal the irrigation system that I would like the electric valve engaged (and, later, possibly disengaged!). But, I don't really have a spare conductor to dedicate to that purpose. :< This says that I need a digital input. And, that I don't have a spare conductor to set aside for it's use. Furthermore, it indicates *why* I want it (for those folks who need a reason for every query). Together, they indicate the environment and problem to be solved.
>>>>> BTW, coils are not specified for "inrush" and "holding". They are >>>>> specified for pull in and drop out. These are typically voltages and >>>>> specify the level at which the solenoid is guaranteed to pull in or >>>>> drop >>>>> out. Coils don't have "inrush" current, that would be a capacitor. >>>>> Coils resist changes in current, so when you apply a voltage the >>>>> current >>>>> goes up gradually (even if gradually is quick). It doesn't spike up >>>>> and >>>>> then drop back. >>>> >>>> Excuse me, but the solenoids (coils) used in irrigation systems >>>> *are* rated as "inrush" and "holding" current. That's what you >>>> will find on their "datasheets" when you go hunting for specifics. >>>> You can always be pedantic -- and your end user will end up >>>> calling the solenoid vendor: >>> >>> I was trying to help in an area where I thought you didn't understand >>> something. Obviously I am the one needing to understand somthing. What >>> is the meaning of the "inrush" current? Does "inrush" refer to the >>> water or the actual current? As I said, inductors resist change in >>> current and do not have an inrush. >> >> Current. Note it's not just an inductor but actually a solenoid. >> This is "just how its done" in that industry. The COTS controllers >> apparently have really wimpy power supplies. And, can potentially >> be interfaced to other ancillary equipment (e.g., you may need >> to start a *pump* if your irrigation system is fed from well water; >> the power to engage that "contactor" for the pump comes out of the >> power budget of the controller. >> >> When "programming" such a controller, you can potentially have >> multiple "zones" (valves/solenoids) engaged concurrently. So, >> the homeowner (who often does this without hiring an installer) >> needs some EASY way of knowing if his "program" can be supported >> with the power available from the controller for the valves. >> >> E.g., I have 15 zone valves, here. Plus a "master valve" that >> must be engaged for any of the other valves to "see water" >> (it gates the water supply to the other valves). The zone >> valves that I use are rated 0.3A inrush, 0.19A holding. >> >> Said another way, I need at least 3A to be able to have all >> of the zones active concurrently (assuming I stagger their >> turn-on times). If I want to be able to engage all of them >> with a single control signal (i.e., coincidentally), then I need >> closer to 5A. > > Again, a lot of information, but you didn't answer the question. For me > to understand how to use these solenoids, I need to understand the spec.
If you can *find* a formal spec, I would be delighted to see it! :> All the consumer sees is *numbers* with these "titles". But, this is all the consumer *needs* in order to be able to determine if the valve will meet his needs and *how* to use it!
> What is "inrush current" and "holding" current? Do these solenoids > behave differently from other relays and solenoids?
You are welcome to contact the manufacturer! :> As I suggested in a previous comment, I suspect they will just recite the same information that they publish. Because that's how they specify their products for *that* market. Your automobile probably has a "maximum payload" rating, somewhere. What if you wanted to exceed this -- but were willing to use "better tires" and overinflate them? And, maybe concede to never exceeding a particular speed? Chances are, you *could* do this. Do you think there is anyone in Detroit who will give you a clear answer as to how much you could push this limit? Or, will they, instead, just recite the published "maximum payload" rating?
> I did some searching and this is not indicating the I/V characteristics > of the solenoid. They are indicating the requirement for activation.
Correct.
> Inrush is required for some duration for initial activation of the coil.
Note that even "some duration" is poorly defined. "Dem's da brakes".
> Holding is the current required for continued operation. This is > specified so that the PSU can be sized with an overdraw capability for > some 10's or 100's of ms.
Exactly. So, Joe HighSchoolDiploma can configure and install irrigation systems without special instruction. For one zone at a time activation: Enter number of valves/zones on line 6 Subtract 1 from line 6 (if less than zero, enter '0') Multiply by holding current Add inrush current If result is less than MAX_PSU_CAPABILITY, OK Otherwise, consider purchasing our high power model XYZ! For multiple simultaneous zone activation: Enter maximum number of zones simultaneously activated on line 19 Multiply line 19 by inrush current Enter maximum number of other zones also active on line 83 Multiply line 83 by holding current Sum these two products If result is less than...
> This impacts the switch and resistor arrangement.
No, it doesn't have to. In practical terms, if I push 1mA through the coil, it's just going to look like a resistor. I'll see roughly 100mV across the coil (they are nominally ~100-125 ohms), If I shunt this with 1K conditional on the button being pressed, then I'll see slightly less potential across the coil. (assuming I am looking at it in voltage mode). The difference may well fall within the tolerance of the coil's resistance! So, if I turn the controller on and the button is *shorted*, I may not be able to determine that vs. a "slightly lower resistance coil" than nominal. OTOH, if the user had been pressing the button when the system was turned on, *eventually* he will release it. I will then see an *increased* potential across the coil. Modeling the system's behavior as a simple state machine, I can now deduce that we are *currently* in the "button released" state -- regardless of whichever state we *thought* we were in a second earlier. Likewise, if I suddenly see a decrease in the potential across the coil, then I know the button has just been pressed, that we *were* in the "button released" state, and that we are now moving into the button pressed state. Of course, the actual magnitudes of these changes depend on the *DC* characteristics of the coil along with the choice of shunt resistance (assuming an ideal switch).
>>> The trouble is that you might not power them from a 24 V supply. It >> >> The irrigation valve suppliers aren't aware of that. Just like >> the automobile manufacturers are not aware that you might want >> to install that big V8 in a *boat*. Or, use it to power a >> genset. > > But you *are*. You need to know how the coil will work in your circuit. > But this spec should be enough info.
I'm not foolish enough to think solenoid vendors are going to characterize coils *just* for my needs. Nor do I want to be in the business of characterizing coils for other folks! So, I consider the sort of data that these vendors provide to be the *only* data that I will have available. And, consider this constraint as one imposed on the design of a solution! There are *countless* holes in the specifications of most MCU's. Many specs never see anything more than a "PRELIMINARY" release (even after the product is mature!) You can either fight with the vendors of these devices to get things quantified as you would like -- or, design against what is available. (E.g., I love exploiting the reset behavior of most processors and other "controllers" to trick them into providing some functionality that they don't intentionally provide. But, reset is usually one of the least well defined aspects of these components' behaviors! <shrug> "Deal with it") Japanese suppliers are incredibly accommodating when it comes to specification changes. So much so that you wonder if they are just paying lip service to those changes and not actually doing anything to their process (incl enhanced testing!) As a result, I stopped asking for clarification of "missing or 'typ' data" long ago: "What would you LIKE it to be?" <shudder>
>> What I'm pursuing, currently, is a "one bit" high voltage, high >> current digital I/O driver that is current limited (i.e., so I >> can put N of these on a power supply that is able to deliver >> N * current_limit and not worry about the supply EVER being >> dragged down). Isolated so conditions encountered on the field >> wiring don't affect the controls (and beyond). Capable of >> handling individual loads in the ~0.5A ballpark (overkill but >> probably doesn't add anything to the cost) with open circuit >> voltages in the ~50V range (though it will probably see 24V >> max). The input will be a volt-free contact closure -- easy >> to conceptualize (i.e., a switch -- whether that's a pushbutton >> or a limit switch in a garage door opener or a reed switch >> mounted on the garage door track, etc.) > > When you say "isolated", can you put numbers on that? How do you plan > to isolate the PSU? Are you going to use an isolated PSU? b
The PSU that powers the valves will be a generic wall wart sort of thing. No need for fancy regulation. Two wires that enter the "isolated" side of the controller. Fused or PTC protected (consider what would happen if someone shorted line voltage to the "field connections") Data/status will probably be optically coupled across this barrier. MOVs, etc. on the actual "field wiring" to guard against big induced voltages. Ferrites to keep RF out/in.
> Are you trying to protect the electronics as well? Lightning can be
My goal is to have nothing "sensitive" on the isolated (exposed) side of the barrier. E.g., I surely wouldn't want an ADC sitting over there waiting to get clobbered (consider even the "benign" case where an installer is "handling" the conductors during installation). Everything "precious" (microcontroller, network interface, etc.) sits on the "protected" side of the isolation barrier.
> very hard to deal with, even indirect strikes. The induced voltage and > current can be *huge*. Try to use twisted wires as much as possible.
You can never protect 100%. A direct strike will toast damn near anything you put in the path to protect yourself. And, you can't protect against foolhardy installations. The guy who wants to run the field wiring up a mast to control an UNGROUNDED antenna rotor is SoL. OTOH, most typical installations have field wiring buried or run in some innocuous location (e.g., close to the ground). *Expect* that and design with that in mind -- instead of expecting folks to run the cables through EMT, etc.
>> Said another way, I should be able to gut a pinball machine >> (electromechanical or electronic) and use this as an interface >> to emulate the original controls (though it would be horrible >> overkill) > > I don't think a pin ball machine will be a great source, but that is > your call. What in a pin ball machine is isolated?
Everything in a pinball machine would want to be isolated from your (my) electronics! Too easy for nasty voltages and BIG currents to get into an unisolated design. E.g., the lamp circuit would easily cook anything attached to *any* rail and never bat an eyelash (one accepted way to test for shorts in a lighting circuit is to bridge the lighting fuse with a NAIL and watch for smoke!) The point of the example was this provides an electrical interface that could be fitted to these sorts of problems (you wouldn't wire an I/O port on an MCU *directly* to the contacts and coils on a pinball machine; nor to 100 ft of cable driving a solenoid, etc.)
On 9/17/2013 2:29 AM, Don Y wrote:
> Hi Ed, > > On 9/16/2013 10:17 PM, ehsjr wrote: >> On 9/15/2013 3:31 PM, Don Y wrote: > >>> So, I figure I could *share* the "solenoid drive" function with >>> the "button sense" function. >>> >>> (remember, this is outdoors in the weather so I'm not keen on >>> putting any electronics out there that won't appreciate the >>> heat, cold, water, sun, etc.) >>> >>> I figure I can wire a NO button across the valve solenoid (either >>> directly or with some series resistance). Then, on the driving >>> side, sense this "short" when the solenoid is NOT energized (i.e., >>> please turn ON the valve) as well as when it *is* energized (i.e., >>> please turn OFF the valve). > >> Here's a conceptual description of how you could do it that >> will meet your requirement that there be no electronics (other >> than the switch) at the solenoid locations. > > Nice goal! > >> You'll need to provide power to the solenoid at all times for >> the switch idea to work. > > Actually, if the solenoid is "off", I can "poll" the circuit > instead of leaving power on all the time... > >> For that, you'll need a low voltage >> power supply in addition to your existing power supply to the >> solenoid. (You could derive the low voltage from the existing >> supply if you want.) The low voltage supply will allow you to >> sense the status of the switch without forcing enough current >> through the solenoid to energize it or to cause a lot of heat >> in it. >> >> N/O >> -------- +-----o o-------+ >> | New | | | >> | Power |---+---[Solenoid]---+ >> | Supply | | >> | Low V |-----+---[R]---+----+ >> -------- | | >> |<---V--->| >> >> R is high wattage low resistance, chosen to allow reliable >> operation of the solenoid with your existing supply. V > > You are sensing V *behind* the solenoid's resistance -- O(120 ohms).
I have no idea what you mean by "behind" the solenoid's resistance, nor why it makes a difference in your mind. With a given supply voltage, the voltage across the resistor will be higher when the switch is pressed than when it is not. Detect that higher voltage with your circuit to initiate switching state from on to off or from off to on. The resistor is physically located at the voltage source location, wherever that is. <snip>
> > If the switch fails shorted, then the solenoid doesn't work.
You didn't post failure detection as a requirement. If it fails shorted, you can detect that with your circuit and ring an alarm, blink a light, send up a flare, whatever.
> This is the same sort of problem Spehro's NC approach has -- the > circuit needs immediate attention (because the solenoid can't > perform its normal function -- even though ONLY the button is broken)
You didn't ask for a failure detection feature.
> > Also, the solenoid effectively "turns off" when the button is > pressed. So, if the controller does NOT want to turn it off, > it ends up "pulsing" off (while the switch is pressed) and then > back on (after the switch is released and the controller has > decided to "leave it on").
You can provide whatever functions you want from *your* circuit, once the state of the push button is detected. The concept presented to you will give you 4 different voltages. Do with them what you will.
> > I.e., this approach has the switch dominating the "control" output.
No it doesn't, except for the period of time (a second or two?) that a button is pressed when the associated solenoid is energized. What happens after that is totally up to your circuit design.
> >> You'll get 4 different voltages across R: >> V1 - voltage with low V supply connected, switch not pressed >> V2 - voltage with low V supply connected, switch pressed >> V3 - voltage with high V supply connected, switch not pressed >> V4 - voltage with high V supply connected, switch pressed >> >> V2 and V4 can initiate turning the solenoid on or off: >> V2 detected - turn solenoid on >> 1) disconnect low v 2) connect high v >> V4 detected - turn solenoid off >> 1) disconnect high v 2) connect low v >> >> You'll also need a delay to prevent false switching during >> transitions or if the switch is pressed too long. >> >> All the electronics can be installed at your existing controller >> location, with the switches installed at the solenoid locations. > > I'm currently looking at a design wherein the resistor is colocated > with the switch. Then, monitoring the current drawn in each > "circuit" to characterize the instantaneous load seen by that > circuit.
With the approach I suggested, there is only one R, and it doesn't need to be co-located. Physical diagram: Garage Wherever ------- |Control|-----------------------------------Solenoid1---+ | |-----------------------------------Solenoid2---+ | |-----------------------------------Solenoid3---+ {{ {{ ... | | |-----------------------------------SolenoidN---+ | | | | |--R--------------------------------------------+ ------- Your existing controller may send two wires to each physical solenoid, but one of those wires will be electrically common to all solenoids. The other wire will be switched on or off by the controller.
> > The trick is to see how coarsely I can quantify the current > while still garnering as much information about the load and > what it likely represents. > > E.g., shorted coil, open coil, two coils driven by a single > output (unintentionally), missing Vcc at one or more coils, > etc. And, throw the button into this mix as yet another > variable... > > Wanting all of this to be isolated and "robust" makes it a > bit more challenging -- can't just hang an A/DC out there > and read the sense current.
You don't need an ADC, and it doesn't have to be remote from the controller in any event.
> > But, I think it essential that: > - the drivers not be prone to failure in conditions that you > *expect* to encounter in a deployed scenario (miswired, shorted, > opened, etc.)
Well, then the push button approach is likely ruled out, as they will be more prone to failure than drivers. They are mechanical, after all, and they'll be exposed to the weather.
> - you alert the user to as many problems as possible that could > be impacting the actual delivery of water to the irrigation > zones (cuz there are other zones that may not have buttons; > ideally, treat them all the same!) > - the design not rely on characteristics of some specific solenoid > > Ideally, I'd add a flow rate sensor to the irrigation supply line > but that's not high on the priority list... I am hoping to > ultimately be able to watch the city water meter and compare > its readings with those from my "potable water reading" to > deduce what must be flowing outside the house (e.g., there is > one hose bibb that I have no control over) > >
Ok. Based on your post, you really don't want to figure out how to sense a turn on or turn off command from a hose bibb location - you want a complete, hardened, solution. I guess you need to interface your controller to the internet, and get an app for your cell phone ... Ed
Hi Ed,

On 9/17/2013 10:29 PM, ehsjr wrote:
> On 9/17/2013 2:29 AM, Don Y wrote:
>>> For that, you'll need a low voltage >>> power supply in addition to your existing power supply to the >>> solenoid. (You could derive the low voltage from the existing >>> supply if you want.) The low voltage supply will allow you to >>> sense the status of the switch without forcing enough current >>> through the solenoid to energize it or to cause a lot of heat >>> in it. >>> >>> N/O >>> -------- +-----o o-------+ >>> | New | | | >>> | Power |---+---[Solenoid]---+ >>> | Supply | | >>> | Low V |-----+---[R]---+----+ >>> -------- | | >>> |<---V--->| >>> >>> R is high wattage low resistance, chosen to allow reliable >>> operation of the solenoid with your existing supply. V >> >> You are sensing V *behind* the solenoid's resistance -- O(120 ohms). > > I have no idea what you mean by "behind" the solenoid's > resistance, nor why it makes a difference in your mind. > > With a given supply voltage, the voltage across the resistor > will be higher when the switch is pressed than when it is > not. Detect that higher voltage with your circuit to > initiate switching state from on to off or from off to on. > > The resistor is physically located at the voltage source > location, wherever that is.
You haven't thought this through, completely. When the coil is "off", you want to impose a low voltage supply "so the coil doesn't engage". If your "voltage detector" is (reasonably) high impedance, then R can be relatively large (even MUCH larger than the coil resistance) without swamping the signal you're looking for. E.g., with R = 10 * Rc (Rc=coil), you still see almost the full supply voltage across R. As long as R doesn't get *too* big, you can even easily detect a missing *or* shorted coil! And, *while* the switch is pressed (or shorted), you'll dissipate much less power in R than you would normally be dissipating in the coil. E.g., if R=10Rc (~1K), then a LOW wattage resistor would be safe, indefinitely (while excited with Vlo!). [Even at Vhi, that big R wouldn't need to be outrageously large... e.g., ~1W would suffice (~24V across ~1K)] But, driving the coil through this large R would be problematic. Your "high voltage" (Vhi) supply would need to be much higher to ensure adequate drive *to* the coil. E.g., if R=10Rc (~1K), then Vhi would need to be ~10x the nominal drive voltage for the coil (~200V). AND, capable of passing the nominal holding current (~0.2A) leading to an exorbitant waste of power (~40W in R). Note that this would be the case regardless of whether the button was pressed or not. But, you knew all that: "R is high wattage low resistance" So, look at the opposite extreme -- making R as small as practical. Try R=Rc/10 for yucks (e.g., ~10 ohms). With the switch open, you'll see ~Vlo/10 across R. This is easy to detect for even small voltages even avoiding the use of "integrated devices" (which would be exposed to the nasty signals present on the field wiring). Distinguishing this from the Vlo that you would see when the switch was closed wouldn't be difficult (just add enough filtering to tamp down the noise). Now, assume the coil *is* engaged. So, the 'R' sits across the supply for the duration of that button press. But, now the supply is no longer Vlo but, Vhi (or thereabouts). So, you have much higher currents (~10X) flowing through the circuit -- including R. And, a similar increase in power dissipation (~100X). I.e., you're back with the exact same problem you had before (10 ohms, 24V, 60W). Note that this happens whenever a coil fails shorted, the *button* fails shorted or if someone (a child?) likes holding the button depressed (e.g., a child fascinated by the fact that the water flowing from the hose STOPS while he holds the button pressed -- regardless of what the controller wants to do!) The "sweet spot" (for R) in this sort of approach is to match the source impedance (R) to the load (Rc). This reduces the worst case power dissipation in R to match the nominal power dissipation in the load (e.g., ~6W). Increasing R above this value results in increased power dissipation in the "coil activated" scenario (regardless of whether the button is pressed, coil shorted or not). Decreasing it below this value results in increased power dissipation in the "button pressed/button shorted/coil shorted" scenarios. Just double Vhi (=48V!) so the voltage available on the load side of the source impedance remains unchanged! [This might cause problems with an inspector as it pushes the envelope regarding what the NEC wants to consider as low voltage and/or power limited circuits. There's already enough ambiguity in the code when it comes to this! OTOH, I doubt any of them would bat an eyelash at a "24V" system!] And, you need this FOR EACH VALVE (despite claims to the contrary, below). So, I would have to design the power supply to be 100% oversized just to handle the losses in these "sense resistors". As well as making the enclosure for the controller capable of dissipating these 25W. If all 15+1+4 of my drivers used this feature, that would be ~120W in the enclosure -- though this is not a problem for the power dissipated in each of the 20 solenoids distributed around the yard (below ground)! Ah, but we've got "smarts" in the box! When you sense the button pressed, you *know* the coil has deenergized (controller has no control over that with this sort of implementation). So, immediately (!!!) switch to Vlo to reduce the power dissipated in R. Then, you can take advantage of the "low resistance" (i.e., R=Rc/10) analysis characteristics. For example, a 10 ohm resistor excited with 2 volts (1/2W). But, you must NEVER FAIL to do this. And, must do so *immediately*! Otherwise, that resistor turns into a "firecracker" (60W in a 1/2W device won't take long to explosively leak magic smoke!). Your software can not crash. The driver circuit can not fail in the "stuck in Vhi mode", etc. [I suspect this would *pass* regulatory agency testing. It would, instead, turn up in litigation, warranty repairs or "customer dissatisfaction": "My irrigation controller burst into flames one day..."] Also, you'll now have to contend with (relatively) large current surges as the button is pressed (i.e., you don't *see* the button press until the ~2.5A current has been flowing through the wire!). Add some chokes?? [If you reread my original post, you'd realize I'd already done this sort of analysis -- e.g., "sense this 'short'". This is what led me to the current control/sense mode I'm now pursuing]
>> If the switch fails shorted, then the solenoid doesn't work. > > You didn't post failure detection as a requirement.
Regardless of "failure detection", the circuit just DOESN'T WORK when this sort of failure occurs! And, the loss of functionality isn't limited to the feature(s) associated with that button (i.e., signalling the controller). "The radio in my car died -- so I lost my power steering!" (WTF?) Note I also didn't mention cost, operating voltages, coil resistance, regulatory agencies, size, etc. -- yet you didn't hesitate to offer a solution in the absence of these details!
> If it fails shorted, > you can detect that with your circuit and ring an > alarm, blink a light, send up a flare, whatever.
You missed the point. The failure needs to be attended to *immediately* (because it has implicitly *propagated* to an unrelated function of the device -- the valve can't perform it's normal duties if the button fails, gets stuck "depressed", etc.). The user has to fix it *now* in order to regain the "button functionality" *and* the "nominal functionality"! What if the user is "away" (vacation)? What if it's a commercial establishment (e.g., nursery, golf course) and not "open" for a long holiday? If *you* assume the system doesn't have to detect failures (your words), then the system won't *report* this failure (email, klaxon, blinking red light, etc.). And, the *normal* functionality of the system has been compromised -- not just an inconvenience to the user who would no longer be able to use that button to call for water!
>> This is the same sort of problem Spehro's NC approach has -- the >> circuit needs immediate attention (because the solenoid can't >> perform its normal function -- even though ONLY the button is broken) > > You didn't ask for a failure detection feature.
And, apparently, you didn't think about the stated application. Or, decided that "wilted/dead plants" was a suitable means of indicating this sort of failure! :> "Bob, the roses have died" "What happened?" "The irrigation system that was keeping them watered broke and no one happened to notice that they were withering and dying." "Ah. Sure would be nice if the irrigation system could TELL us when it is broken!" "Fred, the garage door opener died" "What happened?" "The control system that actuates the opener broke and no one happened to notice that the door was inoperable." "Ah. Sure would be nice if the control system could TELL us when it is broken!" "Doctor, the patient in room 205 has died." "What happened?" "The ventilator that was keeping him alive broke and no one happened to notice the patient was no longer breathing." "Ah. Sure would be nice if the ventilator could TELL us when it is broken!" I guess a lot depends on how you think about problems. In my case, I think about what the user will experience over the life of the product. And, the sorts of things that the user will "blame" the product for -- rightly or wrongly -- that "cost" him, personally. ("I had to replace all the rose bushes because this STUPID irrigation system failed and didn't tell me it that it wasn't watering them! What the heck do these guys expect me to do, stick my finger in the soil by each of the plants in the yard -- not just the roses -- EVERY DAY to verify that their product is functioning AS ADVERTISED??")
>> Also, the solenoid effectively "turns off" when the button is >> pressed. So, if the controller does NOT want to turn it off, >> it ends up "pulsing" off (while the switch is pressed) and then >> back on (after the switch is released and the controller has >> decided to "leave it on"). > > You can provide whatever functions you want from *your* circuit, > once the state of the push button is detected. The concept > presented to you will give you 4 different voltages. Do with > them what you will.
You've missed the point. Your circuit gives the button unconditional influence over how the "system" functions. If the button is pressed, the valve shuts off. If the button is HELD pressed, the valve stays off. If the button FAILS shorted, the valve stays off. REGARDLESS OF WHAT THE CONTROLLER MAY WANT TO DO! (e.g., if I *disable* the "signalling function" for that zone *in* the controller, the button still has an influence on the "flow of water")
>> I.e., this approach has the switch dominating the "control" output. > > No it doesn't, except for the period of time (a second or two?)
For as long as the button is depressed, "stuck closed" (mechanical interference -- no one has specified what sort of button will be used... what if it was a toggle switch?? "ON" to call for water; "OFF" to signal the end of the need for water) or *shorted*.
> that a button is pressed when the associated solenoid is energized. > What happens after that is totally up to your circuit design.
As above, there may not *be* an "after that"!
>>> You'll get 4 different voltages across R: >>> V1 - voltage with low V supply connected, switch not pressed >>> V2 - voltage with low V supply connected, switch pressed >>> V3 - voltage with high V supply connected, switch not pressed >>> V4 - voltage with high V supply connected, switch pressed >>> >>> V2 and V4 can initiate turning the solenoid on or off: >>> V2 detected - turn solenoid on >>> 1) disconnect low v 2) connect high v >>> V4 detected - turn solenoid off >>> 1) disconnect high v 2) connect low v >>> >>> You'll also need a delay to prevent false switching during >>> transitions or if the switch is pressed too long. >>> >>> All the electronics can be installed at your existing controller >>> location, with the switches installed at the solenoid locations. >> >> I'm currently looking at a design wherein the resistor is colocated >> with the switch. Then, monitoring the current drawn in each >> "circuit" to characterize the instantaneous load seen by that >> circuit. > > With the approach I suggested, there is only one R, and it > doesn't need to be co-located. > > Physical diagram: > > Garage Wherever > ------- > |Control|-----------------------------------Solenoid1---+ > | |-----------------------------------Solenoid2---+ > | |-----------------------------------Solenoid3---+ > {{ {{ ... | > | |-----------------------------------SolenoidN---+ > | | | > | |--R--------------------------------------------+ > ------- > > Your existing controller may send two wires to each physical > solenoid, but one of those wires will be electrically common > to all solenoids. The other wire will be switched on or > off by the controller.
How do I activate 1, 5 and 9 while *monitoring* the buttons on 1, 2, 3, 4, 5, 6, 7, 8, 9, ...?
>> The trick is to see how coarsely I can quantify the current >> while still garnering as much information about the load and >> what it likely represents. >> >> E.g., shorted coil, open coil, two coils driven by a single >> output (unintentionally), missing Vcc at one or more coils, >> etc. And, throw the button into this mix as yet another >> variable... >> >> Wanting all of this to be isolated and "robust" makes it a >> bit more challenging -- can't just hang an A/DC out there >> and read the sense current. > > You don't need an ADC, and it doesn't have to be remote > from the controller in any event.
Not remote from the controller but, rather, on the *isolated* ("field") side of the circuit. I.e., exposed to the sorts of disturbances that hundreds of feet of wire running around a yard would encounter.
>> But, I think it essential that: >> - the drivers not be prone to failure in conditions that you >> *expect* to encounter in a deployed scenario (miswired, shorted, >> opened, etc.) > > Well, then the push button approach is likely ruled out, as they > will be more prone to failure than drivers. They are mechanical, > after all, and they'll be exposed to the weather.
There are buttons that are reliable -- it's a question of what you want to spend and where you want to locate them. And, if the circuit isn't *compromised* (as yours is) by a failed button, then there is no reason to "rule them out". E.g., if one *valve* fails (shorted!), you would still expect the remaining valves to remain operational. If one *button* failed, would you expect ALL the buttons to be nonoperational? Would you *expect* that valve to be nonoperational? Would Joe User expect it?? "My power steering doesn't work!" "Check your radio..."
>> - you alert the user to as many problems as possible that could >> be impacting the actual delivery of water to the irrigation >> zones (cuz there are other zones that may not have buttons; >> ideally, treat them all the same!) >> - the design not rely on characteristics of some specific solenoid >> >> Ideally, I'd add a flow rate sensor to the irrigation supply line >> but that's not high on the priority list... I am hoping to >> ultimately be able to watch the city water meter and compare >> its readings with those from my "potable water reading" to >> deduce what must be flowing outside the house (e.g., there is >> one hose bibb that I have no control over) > > Ok. Based on your post, you really don't want to figure out > how to sense a turn on or turn off command from a hose bibb > location - you want a complete, hardened, solution. I guess > you need to interface your controller to the internet, and > get an app for your cell phone ...
No, I've already *got* that -- along with tie-ins to roof mounted rain sensor, solarimeter, etc. (so I can adjust the irrigation schedule based on observed environmental conditions). Eventually, I'll write a script to fetch "online" forecasts to add predictive capabilities (is it likely to rain this afternoon? if so, it may be wise to postpone watering until I know for sure -- I can always change my mind and water later this evening). I just don't want to have to carry a phone, "remote control", etc. with me each time I happen to be in the yard -- just in case I /might/ want to turn a hose on (to wash bird shit off a window, to rinse out a paint bucket, to water a shrub, etc.). Or, have to come back inside to tell "the system" to do it for me. (automation should be intuitive and *enhance* your lifestyle -- not subject you to *its* dictates!)
On Wednesday, September 18, 2013 5:30:48 AM UTC-4, Don Y wrote:

> > No, I've already *got* that -- along with tie-ins to roof mounted > > rain sensor, solarimeter, etc. (so I can adjust the irrigation > > schedule based on observed environmental conditions). Eventually, > > I'll write a script to fetch "online" forecasts to add predictive > > capabilities (is it likely to rain this afternoon? if so, it may > > be wise to postpone watering until I know for sure -- I can always > > change my mind and water later this evening).
That's not how irrigation is controlled.
> I just don't want to > > have to carry a phone, "remote control", etc. with me each time I > > happen to be in the yard -- just in case I /might/ want to turn a > > hose on (to wash bird shit off a window, to rinse out a paint bucket, > > to water a shrub, etc.). Or, have to come back inside to tell > > "the system" to do it for me. (automation should be intuitive > > and *enhance* your lifestyle -- not subject you to *its* dictates!)
I've never seen so much verbiage to describe such a simple system.
On 9/18/2013 5:42 AM, bloggs.fredbloggs.fred@gmail.com wrote:
> On Wednesday, September 18, 2013 5:30:48 AM UTC-4, Don Y wrote: > >> No, I've already *got* that -- along with tie-ins to roof mounted >> rain sensor, solarimeter, etc. (so I can adjust the irrigation >> schedule based on observed environmental conditions). Eventually, >> I'll write a script to fetch "online" forecasts to add predictive >> capabilities (is it likely to rain this afternoon? if so, it may >> be wise to postpone watering until I know for sure -- I can always >> change my mind and water later this evening). > > That's not how irrigation is controlled. > >> I just don't want to >> have to carry a phone, "remote control", etc. with me each time I >> happen to be in the yard -- just in case I /might/ want to turn a >> hose on (to wash bird shit off a window, to rinse out a paint bucket, >> to water a shrub, etc.). Or, have to come back inside to tell >> "the system" to do it for me. (automation should be intuitive >> and *enhance* your lifestyle -- not subject you to *its* dictates!) > > I've never seen so much verbiage to describe such a simple system.
Because it's not "such a simple system"! :> Irrigation controllers come in a variety of different capabilities. The simplest, "dumb" controller (most commonly encountered in residential systems) is purely *time* based. The user (installer) sets an irrigation schedule for each "zone" (valve) as some particular "water flow duration" at some particular "watering frequency". E.g., 10 minutes every other day. Or, 5 minutes *twice* a day. Usually, explicitly specifying the actual *times* of day that each zone is to be engaged (wee hours of the morning, late in the afternoon, etc.). This allows the user to impart his knowledge of how the landscape will be utilized (don't water the golf course while there are golfers using it!) as well as minimizing evaporative losses (here, "sprinklers" lose 40% to evaporation during the daylight hours). Furthermore, ensuring that the total irrigation needs can be addressed without risk of instantaneously overloading the water delivery capacity of the system (plumbing). [This is a weekend project with a PIC in a DIP package, a soldering iron, some darlingtons and a few hours of coding.] Slightly smarter controllers tie in a precipitation sensor with a naive threshold that automatically injects a fixed delay in the watering schedule when a preset amount of precipitation is detected. ("It rained today so we can postpone the irrigation cycle by 24 hours"). [Add half a day to mount the precipitation sensor, tweek your PIC code and verify the conditional delay works] So called "SMART" controllers (evapotranspirational controllers) try to *intelligently* use "weather data" (current conditions, historical records and, in a few cases, data downloaded from special "services") and the knowledge of the individual plantings that are serviced by each zone -- along with the rates of flow to each of those plantings -- to estimate the transpirational and evaporational losses that the plants/soil encounter and the offsetting effects of any precipitation, humidity, etc. These then adjust the irrigation schedule dynamically to ensure the "water needs" of the plants are satisfied -- not the "timer needs of a naive control algorithm". This is, needless to say, considerably harder than a weekend with a PIC! And, also considerably more "involved" to set up! OTOH, once configured, acts as an active "staff member"/agent constantly tweeking the irrigation schedule based on actual observations (closing the loop) instead of running open loop and counting on "someone" (professional gardener? homeowner?) to do the tweeking. E.g., to fully *configure* the system, you need to specify the individual plants (actual species) served in each zone, the types of soil in which they are planted, sun & wind exposure patterns, runoff/drainage patterns, flow rates of emitters associated with the individual plantings, etc. I.e., the same sort of information that you would provide to a horticulturalist tasked with setting a suitable irrigation schedule (*not* Joe HischSchoolDiploma to whom the local Home Improvement store subcontracts irrigation system installations). [Doing all these things doesn't guarantee you a turnkey, optimal solution. But, it brings you much closer and makes fine tweeks easier -- embed the "expert" in the system instead of relying on the "homeowner" to have the desired level of expertise. (he'll just keep increasing watering times to ensure nothing dies from dehydration -- and, probably never back off on those times as the seasonally adjusted needs of his landscape change)] Of course, the only difference between these systems is the *software*. And, if it doesn't have to reside *in* the controller, physically, but can reside *anywhere*, then it doesn't impact the cost of the system! [Chances are, *you* aren't going to ever use this much detail. So, you configure it for a "nominal evergreen" on a zone; or "low water use"; or "seasonal flowering"; or "winter fruit bearing"; or "generic" and all those blanks get filled in with trivial values taht map nicely to the sort of performance you would expect from a *dumb* controller. *Or*, a "weather assisted" controller (if you have precip sensor). OTOH, if you are managing a golf course, nursery, "professional property", etc. then you invest the extra configuration information -- in much the same way that you would have a horticulturist on staff (or on call)] AFAICT, this is the only such system that will (eventually) be able to avail itself of publicly available weather forecasts (instead of relying on a "service"). And, conceptually, be able to *advise* the installer/homeowner/etc. on plumbing configurations that simply won't work: "there simply is no way you can get enough water to the citrus trees on zone 7 with the currently configured flow rates without *swamping* the cacti served by the same valve!" In locations where water use is an issue (here in the desert as well as locations where population growth threatens available resources), "SMART" controllers are the norm. In commercial settings, water savings and the elimination of the need for "professional" staff to tweek irrigation schedules ("What do YOU do for a living, Daddy?") leads to really short payback times! Hardly "simple". But, you *knew* all this already, right? Perhaps you could point me towards some commercially available product offering of your own?? Bye.
On Wednesday, September 18, 2013 2:32:17 PM UTC-4, Don Y wrote:
> On 9/18/2013 5:42 AM, bloggs.fredbloggs.fred@gmail.com wrote: > > > On Wednesday, September 18, 2013 5:30:48 AM UTC-4, Don Y wrote: > > > > > >> No, I've already *got* that -- along with tie-ins to roof mounted > > >> rain sensor, solarimeter, etc. (so I can adjust the irrigation > > >> schedule based on observed environmental conditions). Eventually, > > >> I'll write a script to fetch "online" forecasts to add predictive > > >> capabilities (is it likely to rain this afternoon? if so, it may > > >> be wise to postpone watering until I know for sure -- I can always > > >> change my mind and water later this evening). > > > > > > That's not how irrigation is controlled. > > > > > >> I just don't want to > > >> have to carry a phone, "remote control", etc. with me each time I > > >> happen to be in the yard -- just in case I /might/ want to turn a > > >> hose on (to wash bird shit off a window, to rinse out a paint bucket, > > >> to water a shrub, etc.). Or, have to come back inside to tell > > >> "the system" to do it for me. (automation should be intuitive > > >> and *enhance* your lifestyle -- not subject you to *its* dictates!) > > > > > > I've never seen so much verbiage to describe such a simple system. > > > > Because it's not "such a simple system"! :> > > > > Irrigation controllers come in a variety of different capabilities. > > > > The simplest, "dumb" controller (most commonly encountered in > > residential systems) is purely *time* based. The user (installer) > > sets an irrigation schedule for each "zone" (valve) as some particular > > "water flow duration" at some particular "watering frequency". > > E.g., 10 minutes every other day. Or, 5 minutes *twice* a day. > > Usually, explicitly specifying the actual *times* of day that > > each zone is to be engaged (wee hours of the morning, late in the > > afternoon, etc.). This allows the user to impart his knowledge of > > how the landscape will be utilized (don't water the golf course > > while there are golfers using it!) as well as minimizing evaporative > > losses (here, "sprinklers" lose 40% to evaporation during the > > daylight hours). Furthermore, ensuring that the total irrigation > > needs can be addressed without risk of instantaneously overloading > > the water delivery capacity of the system (plumbing). > > > > [This is a weekend project with a PIC in a DIP package, a soldering > > iron, some darlingtons and a few hours of coding.] > > > > Slightly smarter controllers tie in a precipitation sensor with > > a naive threshold that automatically injects a fixed delay in the > > watering schedule when a preset amount of precipitation is > > detected. ("It rained today so we can postpone the irrigation > > cycle by 24 hours"). > > > > [Add half a day to mount the precipitation sensor, tweek your PIC > > code and verify the conditional delay works] > > > > So called "SMART" controllers (evapotranspirational controllers) > > try to *intelligently* use "weather data" (current conditions, > > historical records and, in a few cases, data downloaded from > > special "services") and the knowledge of the individual plantings > > that are serviced by each zone -- along with the rates of flow > > to each of those plantings -- to estimate the transpirational and > > evaporational losses that the plants/soil encounter and the > > offsetting effects of any precipitation, humidity, etc. These > > then adjust the irrigation schedule dynamically to ensure the > > "water needs" of the plants are satisfied -- not the "timer needs > > of a naive control algorithm". > > > > This is, needless to say, considerably harder than a weekend with > > a PIC! And, also considerably more "involved" to set up! OTOH, > > once configured, acts as an active "staff member"/agent constantly > > tweeking the irrigation schedule based on actual observations > > (closing the loop) instead of running open loop and counting on > > "someone" (professional gardener? homeowner?) to do the tweeking. > > > > E.g., to fully *configure* the system, you need to specify the > > individual plants (actual species) served in each zone, the types > > of soil in which they are planted, sun & wind exposure patterns, > > runoff/drainage patterns, flow rates of emitters associated with > > the individual plantings, etc. I.e., the same sort of information > > that you would provide to a horticulturalist tasked with setting > > a suitable irrigation schedule (*not* Joe HischSchoolDiploma to > > whom the local Home Improvement store subcontracts irrigation system > > installations). > > > > [Doing all these things doesn't guarantee you a turnkey, optimal > > solution. But, it brings you much closer and makes fine tweeks > > easier -- embed the "expert" in the system instead of relying on > > the "homeowner" to have the desired level of expertise. (he'll > > just keep increasing watering times to ensure nothing dies from > > dehydration -- and, probably never back off on those times as > > the seasonally adjusted needs of his landscape change)] > > > > Of course, the only difference between these systems is the > > *software*. And, if it doesn't have to reside *in* the controller, > > physically, but can reside *anywhere*, then it doesn't impact > > the cost of the system! > > > > [Chances are, *you* aren't going to ever use this much detail. > > So, you configure it for a "nominal evergreen" on a zone; or > > "low water use"; or "seasonal flowering"; or "winter fruit bearing"; > > or "generic" and all those blanks get filled in with trivial > > values taht map nicely to the sort of performance you would expect > > from a *dumb* controller. *Or*, a "weather assisted" controller > > (if you have precip sensor). OTOH, if you are managing a golf course, > > nursery, "professional property", etc. then you invest the extra > > configuration information -- in much the same way that you would > > have a horticulturist on staff (or on call)] > > > > AFAICT, this is the only such system that will (eventually) be > > able to avail itself of publicly available weather forecasts > > (instead of relying on a "service"). And, conceptually, be able > > to *advise* the installer/homeowner/etc. on plumbing configurations > > that simply won't work: "there simply is no way you can get enough > > water to the citrus trees on zone 7 with the currently configured > > flow rates without *swamping* the cacti served by the same valve!" > > > > In locations where water use is an issue (here in the desert as well > > as locations where population growth threatens available resources), > > "SMART" controllers are the norm. In commercial settings, water > > savings and the elimination of the need for "professional" staff to > > tweek irrigation schedules ("What do YOU do for a living, Daddy?") > > leads to really short payback times! > > > > Hardly "simple". > > > > But, you *knew* all this already, right? Perhaps you could point me > > towards some commercially available product offering of your own?? > > > > Bye.
I know a tad bit about agricultural irrigation and I'll tellya'- that's the most ridiculous writeup extant. There are more than a few unknowns making your idea /completely/ unworkable, but, since you /know/ so much, I'll let you find out what they are.