"Input" on an "output"

All of the plantings in the yard have "drip" irrigation available at each rootball. The size of the rootball varies with the age of the planting. E.g., a freshly plated tree might have a rootball

12" dia. A *mature* tree wants to be watered farther out from the trunk (watering at the trunk is a bad idea as it weakens the tree's support in the ground and the water isn't taken up into the plant, effectively). E.g., a tree with a 20 ft crown wants to be watered ~6-8 ft away from the trunk.

So, you make a new planting and now have to ensure it gets watered. Where do you locate the "emitters"? A few inches from the "trunk" so the water will seep into the gound where it can be accessed by the roots in that 12" dia rootball? Or, several *feet* away in anticipation of where the roots will *ultimately* be located? If you choose the former, then you will have to move the emitters farther out as the plant matures. If you choose the latter, the plant will die from dehydration before it's roots ever reach the locations of the emitters!

[I am not keen about doing the same thing twice, needlessly. Esp if that thing involves digging in the yard! :> ]

My solution is to have "adjustable" emitters -- in the form of garden hoses that can be placed *exactly* where a new planting can get at it's water supply. And, a "flow control" (manual valve) that ensures the water doesn't drown the plant each time the faucet is opened!

In use: run the end of a garden hose to a spot near the base of a new planting; manually adjust the flow rate to something that "looks about right"; tell the irrigation controller to actuate the valve associated with that garden hose for X minutes every day (for the first weeks) then Y minutes every *other* day (for the next week) then Z minutes... And, each week, move the hose a bit farther away from the "trunk" as the root systems grow outward.

Once the root systems are established enough that the "final" emitter placement can satisfy their needs, roll the hose up and cancel the "program" for that "zone" on the controller.

E.g., we lost three citrus trees last year (or the year before... I forget). The citrus trees are fed water at a high flow rate (because they *use* a lot of water!). You don't want "standing water" against the trunk of a citrus tree because it leads to gumiosis (sp?). So, the "emitters" ("shrubblers", in this case) are located a few feet away from the trunk. They fill a "mote" that surrounds each tree. This is filled to a depth of about 3", allowed to seep into the soil, refilled, allowed to seep, and refilled (again). This ensures adequate water for good fruit development as well as helping to flush the salts present in the water and soil down *below* the roots.

The *four* (i.e., one of which has no "previous location" that it can occupy) new plantings are tiny: "1 gallon" pots (about 6" dia). So, the root systems haven't a chance in hell of ever reaching that "mote" located several feet away from the trunk! Solution: run garden hose to each new planting and let the hose provide the water needs until the plant is "established".

Similarly, if you discover a plant is NOT getting watered enough, you can hack together a kludge to provide supplemental water to *just* that plant -- without providing EXTRA water to all of the other plants fed by that irrigation "zone". Then, when you have the time to do so, you can replace the emitters on that particular plant with something having a larger flow rate (which gives *that* plant more water per unit time without affecting the water supplied to the other plants on that zone)

The current limiter is to prevent a shorted coil from pulling down the power supply and crippling the other valves in the system. I.e., solenoid should draw 0.3A inrush, 0.2A holding. If it ever draws 0.5A then something is broken! If it tries to draw many

*amps*, something is SHORTED!

You don't want to have to replace a drive transistor because it tried to pass the full output current available through a short. Nor do you want to add fuses.

Instead, let the supply go into limit. That protects the output driver as well as ensuring that one driver doesn't render the entire output system unusable (because you may want to operate several valves concurrently and don't want valve 1 to pull down Vcc to a point where valve 13 won't actuate!)

It has to do both -- but, how finely it measures is debatable. All it has to do is be able to differentiate among different types of load conditions (shorted coil, opened coil, button pressed, button pressed while coil energized, coil shorted to ANOTHER coil, etc.)

That's the easy part. Tough part is getting the information I need across the isolation barrier without using anything precious or "fragile" on the field side of that barrier (cuz you have to expect a very hostile environment, there).

Hmmm... never heard that one! I've always used a lightweight rag and never added more than one fitting at a time before fishing it

*through* the newly attached fitting.

I'll keep this approach in mind as I have to install a pressure reducing valve on the supply, here. And, of course, the gate valve that the city installs at the meter ain't worth squat 30+ years later (i.e., so it won't close off the flow to the house completely while I am working).

Not real anxious to get started on this as any screwup leaves us without water until its resolved! :<

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.

You'll need to provide power to the solenoid at all times for the switch idea to work. 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]---+----+ -------- | | ||

R is high wattage low resistance, chosen to allow reliable operation of the solenoid with your existing supply. V is the voltage developed across R, which will be higher when the push button switch is pressed than when the solenoid is not shorted by the switch.

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.

Ed

You used some thousand words describing your plants and how you want to water them and I don't think you have really explained the problem well. I don't need to know the details of how you water your plants, I just need to know the relevant details.

Of course all power supplies should limit the output power to the load to prevent catastrophic failures. My point is you don't need to draw this full current when you press the switch. If you did that, you would be drawing the PSU down and all other solenoids on the same PSU would deactivate. Another issue in using the switch with the full current limit of the PSU depends on the current and the rating of the switch, but it may well run excessive current though the switch.

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.

I don't recall you mentioning an "isolation" barrier before. Where in the system is that currently? Is that in your controller? Where do you expect to add your electronics? How will the power to the solenoid be controlled by the switch? I don't mean the switch sensing, I mean the control. Once you sense the switch, how does the solenoid get controlled?

You haven't told me enough information to help you.

BTW, this is *not* a difficult design task. I don't think there will be a "tough" part once I understand fully the issues involved.

--

Rick

Nice goal!

Actually, if the solenoid is "off", I can "poll" the circuit instead of leaving power on all the time...

You are sensing V *behind* the solenoid's resistance -- O(120 ohms).

If the switch fails shorted, then the solenoid doesn't work. 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)

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").

I.e., this approach has the switch dominating the "control" output.

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.

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.

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.)

- 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)

You wanted to know why I needed an electric valve. Would you have been happy had I replied, "Because."? I find understanding an *application* ends up saving questions later.

"Why do you need to do that?"

I didn't claim that the switch would cause the supply to hit its current limit. Rather, that the supply *was* current limited as part of any reasonable such application.

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: "Hi, could you please tell me what the pull-in voltage is for the solenoid used on your model ABC irrigation valve? And, while you're at it, could you please tell me what the drop-out voltage is? What's that -- yes, these are running off a 24V system as indicated on the box that they came in... So, why do I need these numbers, you ask...?" Speak the language appropriate for the application domain you're working in. :>

Currently, the controller just drives the 15 irrigation valves with a darlington and flyback. No isolation at all -- the controller is just an SBC from a design I did for a client many years ago that I had repurposed for this role, temporarily.

*New* design will be expressly for irrigation controller. As such, outputs will need to be isolated from the "logic", communication network, power for those electronics, etc. You can expect to encounter large voltage spikes (lightning strikes) as well as deliberate attempts to subvert the electronics "inside" that isolation barrier.

The user will see a network connection to the controller (which powers the "smarts"), a connection for "valve power", and wires running off to the individual solenoids (15+master -- though that would probably increase as the electronics for an individual valves represent a small cost). Additionally, connections to a flow meter and water treatment appliances (basically, just more isolated DIO's).

The button is just a button. I *choose* to use it to signal actions for that particular electric valve. I could just as easily use it to open the garage door... it just happens to use the same "conductor" as the solenoid valve.

(e.g., I will eventually use this to control portions of the laundry, the hot water heater and the garage door opener -- as these are all just "isolated DIO applications")

I think I've already got a flexible solution that should give me everything I need. I just have to consider each likely failure (in the field wiring) to verify that I can detect each such condition. I.e., so I can report problems before they affect actual operations. (you'd like to know a valve wasn't operational/controllable BEFORE the plants serviced by it dried up and died; you'd also like to know that your connection to the garage door opener was ineffective before you tried to open it!)

Thx!

--don

My point was that I only needed to know that you wanted to control it from an automatic timer to water plants. That's all I need to know to understand the technical issues. It would be better to explain the requirements in more detail.

Then why bother to mention it at all? I find this confusing.

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.

The trouble is that you might not power them from a 24 V supply. It sounds like you are going to add other electronics which may affect that supply voltage. But then this comes back to the lack of complete information supplied so far. It would be very helpful if you can explain more of what you have and what you intend.

So this is not a commercial unit, but a home built one.. that is important.

Ok, then good luck!

--

Rick

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

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

I guess *my* problem is that I assume folks have read the other posts in a *live* thread before commenting. As I had already tried to explain why TWO valves were needed (manual and electric), I assumed my response to that wasn't clear and endeavored to be more specific.

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"!

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.

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.

They write their specs and literature from the standpoint of the irrigation controller market. 24V is the standard power supply voltage available for valves. If you want to drive them with a current source, that's your problem. If you want to drive them with a couple of alkaline cells, also your problem.

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.)

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)

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).

And, that doesn't require an engineer to deploy.

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 :<

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:

[And *now* I can go "do my thing"...]

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)

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...

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.

But you *are*. You need to know how the coil will work in your circuit. But this spec should be enough info.

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.

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?

???

--

Rick

See below -- things aren't always as obvious as they appear!

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.

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!

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?

Correct.

Note that even "some duration" is poorly defined. "Dem's da brakes".

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...

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).

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! "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?"

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.

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.

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.

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.)

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 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.

You didn't ask for a failure detection feature.

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.

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.

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.

You don't need an ADC, and it doesn't have to be remote from the controller in any event.

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.

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

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]

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!

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!

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??")

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")

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*.

As above, there may not *be* an "after that"!

How do I activate 1, 5 and 9 while *monitoring* the buttons on 1, 2, 3, 4, 5, 6, 7, 8, 9, ...?

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.

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..."

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!)

That's not how irrigation is controlled.

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.