Reply by Don Y September 19, 20132013-09-19
> Don, you seem to get very emotional about this stuff. Relax a little > and lets just discuss a few things.
Sorry, I'm actually *not* "emotional" about it. Rather, trying to infuse my sense of priority and commitment to various aspects of the discussion, goals, etc. Old-school, "New England" personality. (Workplace debates have always been "passionate" -- for want of a better word. But, never "emotional". They are *ideas* fighting, not *people*. "If two of us agree, then one of us is UNNECESSARY!")
> My point is that the failure you are describing is *very* unlikely. Push > buttons most often fail open or intermittent rather than shorted, > especially a quality outdoor button as you would surely be using.
Again, you're making assumptions. What *I* would use isn't the issue. What would *you* use if you were a DIYer building something like this (from published schematics)? What would a manufacturer intent on trimming pennies from teh design try to smuggle into the process? E.g., I'm currently looking at using a pneumatic switch, here with the intent of "burying" the mechanism safely and having only a "tube" to expose to the user. I doubt a manufacturer would go to those extremes. Buttons can also fail because of the environment they are in. Getting "gummed up" because tree sap dripped on them. Or, ice formed inside the switch or along the path that the mechanical actuator follows. If *I* am supplying the switch, then *I* can make an assessment as to the likely failure modes of *that* switch. And, play the "expected value" game of offsetting the cost of the "more reliable" switch against the cost of detecting a failure. If I *don't* have control over the parts used, means by which they are assembled, etc. then I have to expect that "CAN'T HAPPEN" *will*, in fact, happen!
> That is my point. You are making a big deal out of one failure mode > while there are many others, much more likely, which result in the same > problem that you can do nothing about. There is little utility to > focusing on this one failure mode rather than looking at the system and > considering what are the mostly likely failures and dealing with those.
How do you decide which failures are "most likely" when you can't control what components are actually used and how well they are assembled? I've never had a solenoid fail. Neither the actual solenoid(s) nor the wiring to them. But, I take great effort when making connections, waterproofing them, routing the cables, *digging* in the yard (to avoid hitting any buried cables), etc. OTOH, I've been called on by friends and neighbors to service varous bits of kit around their homes and found multiple splices in a single cable ("cut out the old component, tie in the new -- but don't bother to remove the old *splice*... just treat it as part of the *wire*!"). I've found 110V electric outlets wired with 220V across them (i.e., the neutral connector wired to the other "hot leg"). Earth grounds tied to live "travelers". 110V devices on 220V services. None of which are *expected* to "happen" -- yet, do!
>>> the system needs to be robust then these other failure mechanisms should >>> be detected. Probably the most important thing would be to just plain >>> detect if water is coming from the spigot or not rather than detect all >>> the individual failures. >> >> There's a difference between "check engine" and OBD functionality. >> The latter has far more value than the former. The more information >> you can provide to a user, the more useful you can be (even if the >> user doesn't have the inclination/skillset to effect the repair, >> he can at least convey the information to a vendor/service provider >> who could then give a more detailed estimate of the cost of the >> repair ("Well, it'll cost you $100 for us to drive to your house. >> Then, whatever else we need to actually fix the problem -- time >> and materials") > > Yeah, like someone is going to give you any sort of quote over the phone > based on the diagnostic of a home built controller. That's not the way > service people work normally.
It's not intended to be "home built". As I've said (here and in other recent threads), I have no desire to be in the manufacturing business. Yet, would enjoy if these designs found a home *with* some manufacturer. So that folks who can't or don't want to recreate these designs can still avail themselves of them -- for a price. If the development has been done for you (as a manufacturer), all you have to do is decide if you can make money at some particular price point *with* that design. [OTOH, if you enjoy playing with electronics, know how to solder, would like to tinker with the code *in* such a device, then you shouldn't be BLOCKED from doing so because a vendor won't expose the device's innards to you!] My garage door opener didn't come with an inbuilt ability to "talk" to anything. It could *listen* to *it's* remote. But, the only way to tell if the door was open, closed, jammed, etc. was to walk out to the garage and *look*. If you, as a manufacturer, could implement a similar opener design replacing the ~900MHz remote with, for example, a BT remote (possibly paired with your cell phone so the cost of the actual transmitter was eliminated) *AND* add the capability of allowing that remote to *query* the state of the door & opener, would you do so if all you had to do was deal with tooling charges? I.e., now the designs are no longer "home built".
> Still, I don't get your point. Why can't you detect details of the > failure? I'm talking about what is ultimately useful to the user, > knowing that he plants are getting water. In fact, he wouldn't know > that unless you also included a flow meter of some sort in case someone > shuts off the faucet handle, etc. So if you aren't doing that, you > really are just pretending to include a useful self diagnostic capability.
You can monitor flow *out* of the valve and still not know that the plants are actually getting water! A pipe downstream from the valve can fail (as happened to next door neighbor). The emitters for a plant can clog and restrict the flow of water (esp true for drip systems -- you might not be able to detect this until *all* the emitters for a particular plant have clogged) I.e., a high resolution flow meter is your best bet (assuming you know -- or can learn -- what the nominal water consumption rates are for your zones). This is the approach I have been pursuing as it also gives you other useful information (e.g., "I am not calling for any water, anywhere. Why do I detect water flowing? Has some pipe broken somewhere??") [It's still possible for certain types of failures to escape detection -- if they resemble nominal usage patterns -- like a broken pipe on a nominally high flow zone]
>>> I would do this with a current driver circuit. It would have a constant >>> current drive allowing the voltage to float depending on the resistance. >>> Sense the voltage out of the driver and you are done. 24 volts is >>> solenoid operating normally, 16 volts is solenoid operating and pressure >>> detected in the output line, 0 volts is button pressed or solenoid >>> shorted. You could use a low level of current to sense the switch when >>> the water if off, or you could pulse the full current briefly, too short >>> to activate the solenoid. >> >> This is essentially the direction I've been pursuing. The problem >> is getting the "data" back across the isolation barrier "cheaply". >> I.e., you don't want to put much on the "exposed" side of the >> barrier as it represents increased propensity for failure. > > You can try to make the "at risk" side as dumb as possible, but that may > be difficult to make flexible so it will work with different resistance
Actually, it isn't hard if you can "measure" current consumption (or, resistance, etc. -- duality). And, you don't have to *know* what the nominal coil's characteristics are. Just that they are in a certain range. You then *learn* what each condition "looks like" (to your electronics/software). (you don't even care if your "measurement units" correspond to any of the SI units!) So, if you replace a solenoid (or valve -- and fail to "rescue" the old solenoid from the old valve) with an identical/similar one, the system sees little or no change. As long as the change isn't enough to make the bare solenoid look like some other detectable condition, all is well. The first time someone presses the button, the results that the controller sees may be slightly different than previous -- due to the different solenoid. So, you now learn that "new normal". If you make a significant change to a solenoid (e.g., a valve from a different manufacturer; replacing a 3/4" valve with a 1" valve; moving the control signal to another "circuit", etc.) then you need to *tell* the system to notice the changes. Otherwise, risk it misinterpretting what it sees. In reality, you would publish a "how to replace a solenoid/valve" guide. It would enumerate the steps to perform -- one of which would be to tell the controller "relearn" (relearn *everything*, not just a specific valve -- that would be requiring more information from the user than the system would need. It can figure out which solenoids have been replaced -- *if* they are "different enough"). This capability also lets you notice more failure conditions. And, adjust how you report those as well as how you continue to operate while they persist.
> coils, etc. A single smart controller watching all the solenoids could > be made very simple and cheap so that it would be inexpensive to replace > if damaged. Of course you can add protection circuitry which will > increase the cost somewhat.
When was the last time you heard of someone replacing their $39 irrigation controller because it "broke"? Or, $139 controller? So, you're advocating a *feature* whereby YOUR controller can be readily replaced? :>
>> My first approach was to use an iso-optilator in its linear region. >> That can provide lots of information -- more detail than you >> really need! But, coming up with a design that can reliably >> ensure you are using *only* the linear region of those devices >> seemed a bit dubious ("select/tweek at test" is not an option; >> esp if Joe Tinkerer opts to substitute some other device that he >> happens to have on hand -- not realizing the "special needs" >> that are imposed on the device in the circuit). > > I don't know so much about using linear optos, but why bother? You > still have a failure mode, the opto.
Repeat that with: "You still have a failure mode: the drive transistor; the field wire connector; the forward-going opto; the voltage/current sensor; the PSU; etc." :> The goal isn't to make things that *can't* fail but, rather, that are *resistant* to casual failures. And, are able to report as many conditions as possible that affect the performance of the device in question. We had a lightning strike in the back yard at a place I lived many years ago. *Toasted* the "electronic" telephone and "magnetized" the TV. But, nothing (aside from the phone) in the house "broke".
> Why not just put a small, > inexpensive controller on the "live" side and live with the small added
Because that sort of device is more fragile than some discretes, etc. And, you don't *need* that, there. OTOH, you *do* need the hammer drivers over there!
> cost? We are talking less than $5 for an MCU and the circuitry. BTW, > remember you need to power this circuit no matter what it is. I suppose > you can power this from the 24 V which I assume is AC. > >> So, I'm now looking at relying solely on operating them as digital >> devices and conveying that information in the time/frequency domain. >> This should keep the actual interface robust, inexpensive and >> easy to build. > > Much easier to just put an MCU on the "live" side and be done with it. > *Any* circuit you put on the "live" side will be susceptible to the > transients from lightning, even passives, even relays! It just depends > on the strength of the jolt. A simple MCU circuit can have some > protection added for the smaller jolts. Keep it inexpensive and > consider it an expendable for the few times you have high voltages > coming in.
Why expose it if you don't have to? Protect things that are less flimsy and that *must* exist on that exposed side. Even if you can price a product so taht you can afford to replace a fair number of them "under warranty", you don't leave your customers with a good feeling about your product if they have to be INCONVENIENCED to replace it!
>> Folks frequently piss and moan that I'm too verbose. Yet, if I >> present a detailed specification, do you think that will be any >> *shorter*? > > Yes, actually. Much of the info you give is not directly relevant. Such > as much of what I just snipped.
Ah, silly boy. :> Here's just a *short* bulleted list. As you suggest, I should *omit* putting all this in context. So, try hard to forget EVERYTHING about that which has been discussed in this thread. Ask yourself *honestly* how many items for which you *crave* justification (it's a spec, I shouldn't have to justify anything, right? :> ) And, how willing you would be to even *think* about a problem presented in such a way? - wired connection(s) - drive a load of < ~20VA, < 36V, < 1A - detect an input signal presented via "volt free" contacts - both simultaneously - tolerate deployment in temps of -40F - 140F, RH 0-100% (though the "sense" and "drive" end can exist in RH 0-80, 0-100F) - not "break" if subjected to conditions beyond these - operate as a two wire circuit - operate alongside other (31?), similar circuits with a "common" - detect a missing load - detect a shorted load - detect a short to any "alongside" circuit - detect an open in any "alongside" circuit - detect inputs as short as 0.2 sec (i.e., < 5Hz) - detect indefinite inputs (i.e., > DC) - survive "nearby" lightning strikes - "minimize" RFI - "immune" to RFI/EMI - 20 yr product life - low cost (e.g., $2-3 per pin) - minimize attack surface presented to a potential adversary - use components and technologies available to tinkerers (cost, low qty) - use components and technologies available to vendors (not "by hand") - use components that will be available for product lifetime (or equiv) - electrically efficient (e.g., 80-90+%) Of course, you can improve on these -- they are just minimums) If written as a *real* spec, this would occupy many pages further clarifying each issue (to answer the questions that the reader would invariably have and to put each requirement into context -- so he understood *why* each was necessary)
>>> But for the most part he is >>> brainstorming and that can be part of what we are seeing. He likely > >> Finally, I consider engineering to be the art of finding the >> LEAST WRONG solution to a given problem (i.e., there are no >> "ideal" solutions in the real world). So, I find *my* best >> and then hope someone else will have a *cleverer* approach. >> Or, see some issue that will eat my lunch that I've neglected. > > That is great if you are really trying for the ultimate solution. But
I'm looking for the *right* solution -- for *today*. Someone can revisit this in the future when MCUs with 100V pin drivers are available. Or, when mixed mode customs are available at the corner grocery store. "Right" doesn't mean "expedient". I've already *got* something that works -- it just doesn't deal with everything I want to do (as well as the other applications to which I would like to apply it) E.g., I use speech as a primary modality for interacting with the system. I'm not going to waste my time trying to design the best speech synthesizer. I don't have expertise, there. So, I'll make a box into which that component fits. And, put a nominal implementation in place that works -- the *right* solution for today. Someone can replace this, later, with better technology (perhaps even proprietary technology -- in the case of a vendor opting to commercialize it!)
> most of us want a practical solution without spending an excessive > amount of time "optimizing" it.
Because you figure you can revisit it, later. I don't know how old you are or what your opinions of your "future life" include. *I* don't want to revisit things, anymore. I want to make my *best* stab at these things (there are a *lot* of them on my list) and move on. Omitting something that is fairly obvious is just plain embarassing... I have *21* designs that I need to complete. I would much prefer leveraging work done on one to eliminate some *other*. And, to increase the quantity of individual designs that I will have to fabricate. I'd love to prune this number down to 4-6. But, will be happy if I can hit 6-8. By the time I'm done, I figure I will have dropped ~10K of recurring dollars into this. It's unlikely I'm going to save another $100 beating it with a stick! [If someone wants to commercialize any of these, they can always elide the components that are not required for a particular *instance* of a design -- instead of relying on differential stuffing as I will] I want to move past "building infrastructure" to developing better algorithms to *use* that infrastructure. Where, by far, the majority of the effort and challenge will lie! It might be fun to *build* a race car; but FAR MORE exciting to actually RACE it! :>
> In fact, I once read a paper on how > optimization is a *bad* idea most of the time. Things should be > optimized when optimization is required, but otherwise it is best to > avoid. Your coil concerns is a perfect example. The design could be > optimized to provide lots of noise immunity by assuming some reasonable > range of the expected coil resistance. But if you use a different coil, > that optimization gets in the way of the circuit working. > > Likewise, if you want to optimize the design to have no active > components on the "live" side of the isolation barrier, then you will > have a design with little flexibility for design issues you find a > month, six months or some longer time down the road.
I've already quantified those "issues". As I said, I don't plan to revisit this. I want to come up with a design that I can produce "a few of", publish and then move onto other aspects of the project. If someone else figures out how to use some technique or device that comes on the market next year to do this better, then *he* can undertake that task -- with my blessing! :>
>>> I like your idea. But I'm not sure that it will do what he wants if you >>> use a common resistor as a sensor. That would require that you >>> periodically turn off all solenoids and poll each switch. In theory you >> >> And, do that fast enough to catch a "quick" button push (or, do you >> burden the user by telling him he has to hold the button pressed for >> 15 seconds to ensure it is "seen" by an ULF polling event?) > > There is no real need to catch a "quick" button. I would expect to > press such a button for a "long" time, possibly until the water started > to flow. This is an easy issue to deal with by directions to the user.
Our clothes dryer requires the power button to be depressed for a full second. The washer (same manufacturer -- "sister" product) responds instantaneously. It annoys the hell out of *both* of us! Why should we have to hold the button IN for so long? It's already recessed so it's not like someone is going to bump into it! And, if such a time is required, then why doesn't the same argument apply to the *other* product sitting beside it?? Same manufacturer. Possibly same developers, code base, etc. You're also thinking only about it "as a button" (because I only described a "button" application). I can use the same hardware interface to talk to the anemometer and/or rain sensor on the roof. Both emit very *brief* pulses. Should I design, layout and fabricate *another* circuit that is largely similar -- but with different constraints? {Again, I didn't mention this in my post as it just would complicate the discussion. It is, however, reflected in the bulleted list I presented above -- as a simple, unqualified "requirement")
> Where did you pull 15 seconds from... no, wait, I don't want to know!
If you have to drop the solenoid to examine the button, then you would want to keep the polling interval relatively long -- so the water isn't "pulsing" through the pipes (which can become audible).
> BTW, I have found that gas pumps do exactly this. If you press the > octane select button quickly, it is not seen by the pump. You have to > press it like you are working a mechanical device, not a quick jab. This > is not unusual on ruggedized equipment.
[Having been involved with gas pumps in the past... :> ] This is often a consequence of a slow polling loop -- the button is just not *examined* very frequently. Some implementations treat the "pump" (what the user interacts with) as a "terminal" of sorts. The switch closure is *reported* to a control algorithm elsewhere. Which, in turn, responds with commands to turn on lamps, engage the pump, etc. And, some switch debounce algorithms are sloppy -- they report the switch only *after* it has been "seen" for some number of observations (instead of reporting it on the *first* observation and just absorbing any bounce thereafter). If this happens before the event is reported to the "controller", then the response is even more slugish! [I've got a paper I wrote on hardware and software debouncing techniques here, somewhere]
>>> could do this fast enough that active solenoids do not drop out, but you >>> would then be sending some moderately fast pulses along long lines >>> potentially generating a lot of RFI. I bet it would mess up AM radio >>> pretty badly. Maybe there would be a way to shape the edges to prevent >>> this. I guess sampling 4 times a second would be adequate, maybe even >>> just once a second. That wouldn't be so bad, so maybe my concerns are >>> not valid. >> >> And this saves, what -- a few resistors? :> >> >> Make the "pin driver" circuit effective; then efficient. As with >> software, don't "prematurely optimize". > > If you think this just saves a few resistors, you don't understand your > own design. Each of those resistors have to be sensed and the sensing > circuitry has to be protected from spikes. Having just *one* sense > element may be the biggest cost saving you can come up with here.
I was being facetious. But, in fact, it doesn't save much. Recall, you have to be able to drive multiple solenoids at the same time. You don't want a failure in one to cause the others to be unusable. So, you want to treat each output/input as a separate circuit. With its own current limiter, isolated *control*, etc. Once you put a current limiter/source in the equation, you've already got a handle on the "sense resistor" -- *in* the current limiter! As I've said, give me credit for having thought about these things *before* posting my question!
Reply by rickman September 19, 20132013-09-19
On 9/19/2013 3:34 PM, Don Y wrote:
> On 9/19/2013 8:50 AM, rickman wrote: >> On 9/19/2013 1:59 AM, ehsjr wrote: >> You make a good point with that. The issue with the failure is not >> really such a big deal. His controller will be able to sense if the >> button is shorted and notify the operator. The button is very unlikely >> to fail shorted, but there are plenty of other failure mechanisms. If > > I've not claimed that I *couldn't* detect a "shorted" button. > Rather, my objection to this approach is that the "short" implicitly > propagates to render the solenoid unusable. As such, the "problem" > has to be fixed *now* (or, "before the solenoid would likely need > to be actuated"). > > This, IMO, is just a crappy design philosophy. Failures should have > *confined* consequences (Would it have been acceptable if that > failure "took down" the ENTIRE irrigation system? If not, then > why is it acceptable to take down that *valve's* functionality > when the button's role is not inherently related to that?) > > Imagine I can *telephone* the user AS SOON AS this condition is > detected. What good does that do him if he's not "at home" to > address the issue? If he *is* home, does he have to hire someone > on "emergency" service to come right out and fix this problem? > Or, can he wait a week/month? *Or*, even decide to live WITHOUT > the ability to "signal for water" with that button -- all else > continuing to work as intended?
Don, you seem to get very emotional about this stuff. Relax a little and lets just discuss a few things. My point is that the failure you are describing is *very* unlikely. Push buttons most often fail open or intermittent rather than shorted, especially a quality outdoor button as you would surely be using. That is my point. You are making a big deal out of one failure mode while there are many others, much more likely, which result in the same problem that you can do nothing about. There is little utility to focusing on this one failure mode rather than looking at the system and considering what are the mostly likely failures and dealing with those.
>> the system needs to be robust then these other failure mechanisms should >> be detected. Probably the most important thing would be to just plain >> detect if water is coming from the spigot or not rather than detect all >> the individual failures. > > There's a difference between "check engine" and OBD functionality. > The latter has far more value than the former. The more information > you can provide to a user, the more useful you can be (even if the > user doesn't have the inclination/skillset to effect the repair, > he can at least convey the information to a vendor/service provider > who could then give a more detailed estimate of the cost of the > repair ("Well, it'll cost you $100 for us to drive to your house. > Then, whatever else we need to actually fix the problem -- time > and materials")
Yeah, like someone is going to give you any sort of quote over the phone based on the diagnostic of a home built controller. That's not the way service people work normally. Still, I don't get your point. Why can't you detect details of the failure? I'm talking about what is ultimately useful to the user, knowing that he plants are getting water. In fact, he wouldn't know that unless you also included a flow meter of some sort in case someone shuts off the faucet handle, etc. So if you aren't doing that, you really are just pretending to include a useful self diagnostic capability.
> Also, the more the system can discern about the consequences of a > failure, the better it can adapt to that failure. > > E.g., if the valve is shorted to another, then it can avoid > "over/under-watering" at least one of those zones whereas acting > as if both valves were still isolated (from each other) would > result in both zones being overwatered. Or, possibly, *neither* > getting watered properly -- depending on the consequences of > trying to "open" those two hydraulic circuits simultaneously > (you may not have enough pressure to cause water to flow as > intended from each circuit) > >> Yes, a pressure switch *after* the valve could >> do that and the pressure switch could be connected to the power wires in >> a similar manner to provide a result back to the controller. The push > > I've approached this by watching water consumption "at the source". > If I open a valve and there is no change in flow rate, then I > know water isn't flowing. Because the valve is mechanically defective, > because a pipe/filter is clogged, etc. > >> button shorts the solenoid, the pressure switch has a resistor in >> series. So now you have three levels of voltage you need to sense to >> detect the button and the pressure switch. > > You actually need more than that to be able to detect all of the > *likely* failures you will encounter. > >> I would do this with a current driver circuit. It would have a constant >> current drive allowing the voltage to float depending on the resistance. >> Sense the voltage out of the driver and you are done. 24 volts is >> solenoid operating normally, 16 volts is solenoid operating and pressure >> detected in the output line, 0 volts is button pressed or solenoid >> shorted. You could use a low level of current to sense the switch when >> the water if off, or you could pulse the full current briefly, too short >> to activate the solenoid. > > This is essentially the direction I've been pursuing. The problem > is getting the "data" back across the isolation barrier "cheaply". > I.e., you don't want to put much on the "exposed" side of the > barrier as it represents increased propensity for failure.
You can try to make the "at risk" side as dumb as possible, but that may be difficult to make flexible so it will work with different resistance coils, etc. A single smart controller watching all the solenoids could be made very simple and cheap so that it would be inexpensive to replace if damaged. Of course you can add protection circuitry which will increase the cost somewhat.
> My first approach was to use an iso-optilator in its linear region. > That can provide lots of information -- more detail than you > really need! But, coming up with a design that can reliably > ensure you are using *only* the linear region of those devices > seemed a bit dubious ("select/tweek at test" is not an option; > esp if Joe Tinkerer opts to substitute some other device that he > happens to have on hand -- not realizing the "special needs" > that are imposed on the device in the circuit).
I don't know so much about using linear optos, but why bother? You still have a failure mode, the opto. Why not just put a small, inexpensive controller on the "live" side and live with the small added cost? We are talking less than $5 for an MCU and the circuitry. BTW, remember you need to power this circuit no matter what it is. I suppose you can power this from the 24 V which I assume is AC.
> So, I'm now looking at relying solely on operating them as digital > devices and conveying that information in the time/frequency domain. > This should keep the actual interface robust, inexpensive and > easy to build.
Much easier to just put an MCU on the "live" side and be done with it. *Any* circuit you put on the "live" side will be susceptible to the transients from lightning, even passives, even relays! It just depends on the strength of the jolt. A simple MCU circuit can have some protection added for the smaller jolts. Keep it inexpensive and consider it an expendable for the few times you have high voltages coming in.
> Folks frequently piss and moan that I'm too verbose. Yet, if I > present a detailed specification, do you think that will be any > *shorter*?
Yes, actually. Much of the info you give is not directly relevant. Such as much of what I just snipped.
>> But for the most part he is >> brainstorming and that can be part of what we are seeing. He likely
> Finally, I consider engineering to be the art of finding the > LEAST WRONG solution to a given problem (i.e., there are no > "ideal" solutions in the real world). So, I find *my* best > and then hope someone else will have a *cleverer* approach. > Or, see some issue that will eat my lunch that I've neglected.
That is great if you are really trying for the ultimate solution. But most of us want a practical solution without spending an excessive amount of time "optimizing" it. In fact, I once read a paper on how optimization is a *bad* idea most of the time. Things should be optimized when optimization is required, but otherwise it is best to avoid. Your coil concerns is a perfect example. The design could be optimized to provide lots of noise immunity by assuming some reasonable range of the expected coil resistance. But if you use a different coil, that optimization gets in the way of the circuit working. Likewise, if you want to optimize the design to have no active components on the "live" side of the isolation barrier, then you will have a design with little flexibility for design issues you find a month, six months or some longer time down the road.
>> I like your idea. But I'm not sure that it will do what he wants if you >> use a common resistor as a sensor. That would require that you >> periodically turn off all solenoids and poll each switch. In theory you > > And, do that fast enough to catch a "quick" button push (or, do you > burden the user by telling him he has to hold the button pressed for > 15 seconds to ensure it is "seen" by an ULF polling event?)
There is no real need to catch a "quick" button. I would expect to press such a button for a "long" time, possibly until the water started to flow. This is an easy issue to deal with by directions to the user. Where did you pull 15 seconds from... no, wait, I don't want to know! BTW, I have found that gas pumps do exactly this. If you press the octane select button quickly, it is not seen by the pump. You have to press it like you are working a mechanical device, not a quick jab. This is not unusual on ruggedized equipment.
>> could do this fast enough that active solenoids do not drop out, but you >> would then be sending some moderately fast pulses along long lines >> potentially generating a lot of RFI. I bet it would mess up AM radio >> pretty badly. Maybe there would be a way to shape the edges to prevent >> this. I guess sampling 4 times a second would be adequate, maybe even >> just once a second. That wouldn't be so bad, so maybe my concerns are >> not valid. > > And this saves, what -- a few resistors? :> > > Make the "pin driver" circuit effective; then efficient. As with > software, don't "prematurely optimize".
If you think this just saves a few resistors, you don't understand your own design. Each of those resistors have to be sensed and the sensing circuitry has to be protected from spikes. Having just *one* sense element may be the biggest cost saving you can come up with here. -- Rick
Reply by Don Y September 19, 20132013-09-19
On 9/19/2013 12:36 PM, bloggs.fredbloggs.fred@gmail.com wrote:
> On Thursday, September 19, 2013 1:19:49 PM UTC-4, Don Y wrote: >> On 9/19/2013 9:37 AM, bloggs.fredbloggs.fred@gmail.com wrote: >> and these are 18-24" diameter specimens!). Oleander is a favorite >> as a hedge/privacy screen. But, it's toxic (think: dogs & fires) >> and pretty boring. > > I saw the Oleander, couldn't believe anyone advocates planting that > poisonous thing, you can't even burn the leaves without risking death.
Exactly. We initially ruled it out because: - it's common - it's boring - it becomes a haven for scads of little birds (a neighbor has a 15 ft tall hedge of this the length of her property -- you can't walk near the house without covering your ears to block the din the birds make!) - it requires constant maintenance (trimming) - poisonous to the dogs (who are likely to eat/taste anything that they can get at) - health hazard in the event of fire A house burned (to the ground!) a few street over a couple of years ago. Firemen *let* it burn (house was full of "stuff" -- owner was one of those folks with "hoarding disorder"). Instead, concentrated on protecting the neighboring houses *and* keeping the ubiquitous oleander from catching fire!
> If you want a privacy screen, maybe a trellis wall with some tough > evergreen vine will work better, those grow in no time.
Anything that "grows well", becomes a pest. We had "cat's claw" years ago. But, it takes over! And, spreads via risomes (?) so it pops up unexpectedly clear across the yard! As it grows so fast, you end up with a thick "clump" in which only the outermost layer is actually alive/flowering. The rest just a fire hazard and haven for "critters". Getting *rid* of it is a multiyear project (as you later "discover" to where the roots have traveled!)
>> Soil here has very high clay content. E.g., dig a hole, fill with >> water. Come back next day and you've ONLY lost water to evaporation >> (no drainage). As such, each of the citrus trees were planted in >> what amounts to as a "large pot" (horticulturist at nursery provided >> that answer when I asked how large a hole I should dig: "Pretend you >> are sculpting a terra cotta pot, *in* the ground, in which the tree >> will *live*..." > > The standard practice of handling that is to plant the tree in a mound > with the root system above the surrounding soil.
Small yard. If you elevate the root ball, you don't have much "real estate" to gradually taper that back to "normal". So, you end up with these pronounced "bumps" in the yard. You also run the risk of the roots growing shallow. We had that problem with one of the mesquites, here. Root system was effective at collecting water and nutrients -- but piss poor for holding a 30 ft tree *in* the ground! In the high winds, the trunk would move almost a foot in each direction as it "rocked" in the soil! [Before opting to remove it, I had tried supporting it in place with steel cables -- terminated on 5/8" diameter "eyelets" anchored in 100lb blocks of concrete buried three feet below grade (!) And *that* wasn't enough!]
>> The point of the electric valve on the hose bibb was so the hose can >> be used to bring water *to* a particular location in the yard without >> having to add or move drip lines/emitters. E.g., the three new citrus >> plantings can't be serviced by the existing irrigation lines -- their >> rootballs don't "reach" the location of the emitters (and won't for >> several years). >> >> Standing outside *holding* a garden hose in 100+ temperatures >> daily is not my idea of retirement! :> > > I use 5-gallon buckets that have been set out for 24 hours in advance > to evaporate the chlorine. Just tip the bucket to pour at the base of > the stem no faster than the water is absorbed into the soil. The > moisture will naturally diffuse into the majority of the root mass. > This process rarely takes more than a minute. By the time any > individual requires more than 5-gallons, it is established enough > to not require supplemental watering. There comes a point where the > plant has to make it on its own.
Possibly true for native plants. Definitely NOT true for the citrus. And, I notice even the native trees (e.g., mesquite) have taken a hit here, lately. There are a LOT of them that are very obviously "dead" in the neighborhood. (It's been a long, hot summer -- we're still touching 100F and expected to be there for at least another week)
>> "Sonoran Desert". Key word is "desert". > > That lack of moisture causes everything to grow extra slowly and
Or, grow very *quickly* and die in short order!
> look lackluster. Water is the catalyst for life in the plant world. > Here in the mid-Atlantic where we have lots of rainfall, almost > anything does well.
Yes. In New England you *never* "watered".
> I'm averaging 30" annual growth with things like Arizona Blue Ice > Cypress that are almost semi-dwarf much farther south, Zone 9 is > its limit.
The Mulberry would grow 10' or more (!) each year. I was having to trim it *twice* a year to keep it at a manageable size. Finally cut it down when I realized how much pollen it was pushing into the air (I am allergic to pollen). It is apparently no longer "legal" to plant them in town. [It was also a PITA when it came to dropped leaves. Each leaf was larger than my hand and very stiff. You would almost have to pick them up one-at-a-time instead of raking them!]
Reply by September 19, 20132013-09-19
On Thursday, September 19, 2013 1:19:49 PM UTC-4, Don Y wrote:
> On 9/19/2013 9:37 AM, bloggs.fredbloggs.fred@gmail.com wrote:
> and these are 18-24" diameter specimens!). Oleander is a favorite >=20 > as a hedge/privacy screen. But, it's toxic (think: dogs & fires) >=20 > and pretty boring. =20
I saw the Oleander, couldn't believe anyone advocates planting that poisono= us thing, you can't even burn the leaves without risking death. If you want a privacy screen, maybe a trellis wall with some tough evergree= n vine will work better, those grow in no time.
>=20 >=20 >=20 > We settled on what we have found to be a good mix of plantings >=20 > that are evergreen, dog-safe, don't encourage too many bees, >=20 > flowering, don't produce too much litter, etc. And, in the >=20 > process, removed all of the original plants as they were >=20 > either inappropriate for the property (tall trees on small lots >=20 > don't offer much of anything!), no longer permitted within the >=20 > city limits (as new plantings... so, "established" is just as >=20 > bad), offered nothing of value to us (peach, pear, almond), etc. >=20 >=20 >=20 > >=20 > We had mostly "semi drawf" specimens, originally. They proved to be >=20 > larger than we expected. We lost three of them (lemon, lime, blood >=20 > orange) in a particularly cold (for here) winter ~2 years back. >=20 > We took that opportunity to replace them with dwarf varieties. >=20 >=20 >=20 > Soil here has very high clay content. E.g., dig a hole, fill with >=20 > water. Come back next day and you've ONLY lost water to evaporation >=20 > (no drainage). As such, each of the citrus trees were planted in >=20 > what amounts to as a "large pot" (horticulturist at nursery provided >=20 > that answer when I asked how large a hole I should dig: "Pretend you >=20 > are sculpting a terra cotta pot, *in* the ground, in which the tree >=20 > will *live*..."
The standard practice of handling that is to plant the tree in a mound with= the root system above the surrounding soil.
> The point of the electric valve on the hose bibb was so the hose can >=20 > be used to bring water *to* a particular location in the yard without >=20 > having to add or move drip lines/emitters. E.g., the three new citrus >=20 > plantings can't be serviced by the existing irrigation lines -- their >=20 > rootballs don't "reach" the location of the emitters (and won't for >=20 > several years). >=20 >=20 >=20 > Standing outside *holding* a garden hose in 100+ temperatures >=20 > daily is not my idea of retirement! :>
I use 5-gallon buckets that have been set out for 24 hours in advance to ev= aporate the chlorine. Just tip the bucket to pour at the base of the stem n= o faster than the water is absorbed into the soil. The moisture will natura= lly diffuse into the majority of the root mass. This process rarely takes m= ore than a minute. By the time any individual requires more than 5-gallons,= it is established enough to not require supplemental watering. There comes= a point where the plant has to make it on its own. =20
>=20 > "Sonoran Desert". Key word is "desert".
That lack of moisture causes everything to grow extra slowly and look lackl= uster. Water is the catalyst for life in the plant world. Here in the mid-A= tlantic where we have lots of rainfall, almost anything does well. I'm aver= aging 30" annual growth with things like Arizona Blue Ice Cypress that are = almost semi-dwarf much farther south, Zone 9 is its limit.
Reply by Don Y September 19, 20132013-09-19
On 9/19/2013 8:50 AM, rickman wrote:
> On 9/19/2013 1:59 AM, ehsjr wrote: > You make a good point with that. The issue with the failure is not > really such a big deal. His controller will be able to sense if the > button is shorted and notify the operator. The button is very unlikely > to fail shorted, but there are plenty of other failure mechanisms. If
I've not claimed that I *couldn't* detect a "shorted" button. Rather, my objection to this approach is that the "short" implicitly propagates to render the solenoid unusable. As such, the "problem" has to be fixed *now* (or, "before the solenoid would likely need to be actuated"). This, IMO, is just a crappy design philosophy. Failures should have *confined* consequences (Would it have been acceptable if that failure "took down" the ENTIRE irrigation system? If not, then why is it acceptable to take down that *valve's* functionality when the button's role is not inherently related to that?) Imagine I can *telephone* the user AS SOON AS this condition is detected. What good does that do him if he's not "at home" to address the issue? If he *is* home, does he have to hire someone on "emergency" service to come right out and fix this problem? Or, can he wait a week/month? *Or*, even decide to live WITHOUT the ability to "signal for water" with that button -- all else continuing to work as intended?
> the system needs to be robust then these other failure mechanisms should > be detected. Probably the most important thing would be to just plain > detect if water is coming from the spigot or not rather than detect all > the individual failures.
There's a difference between "check engine" and OBD functionality. The latter has far more value than the former. The more information you can provide to a user, the more useful you can be (even if the user doesn't have the inclination/skillset to effect the repair, he can at least convey the information to a vendor/service provider who could then give a more detailed estimate of the cost of the repair ("Well, it'll cost you $100 for us to drive to your house. Then, whatever else we need to actually fix the problem -- time and materials") Also, the more the system can discern about the consequences of a failure, the better it can adapt to that failure. E.g., if the valve is shorted to another, then it can avoid "over/under-watering" at least one of those zones whereas acting as if both valves were still isolated (from each other) would result in both zones being overwatered. Or, possibly, *neither* getting watered properly -- depending on the consequences of trying to "open" those two hydraulic circuits simultaneously (you may not have enough pressure to cause water to flow as intended from each circuit)
> Yes, a pressure switch *after* the valve could > do that and the pressure switch could be connected to the power wires in > a similar manner to provide a result back to the controller. The push
I've approached this by watching water consumption "at the source". If I open a valve and there is no change in flow rate, then I know water isn't flowing. Because the valve is mechanically defective, because a pipe/filter is clogged, etc.
> button shorts the solenoid, the pressure switch has a resistor in > series. So now you have three levels of voltage you need to sense to > detect the button and the pressure switch.
You actually need more than that to be able to detect all of the *likely* failures you will encounter.
> I would do this with a current driver circuit. It would have a constant > current drive allowing the voltage to float depending on the resistance. > Sense the voltage out of the driver and you are done. 24 volts is > solenoid operating normally, 16 volts is solenoid operating and pressure > detected in the output line, 0 volts is button pressed or solenoid > shorted. You could use a low level of current to sense the switch when > the water if off, or you could pulse the full current briefly, too short > to activate the solenoid.
This is essentially the direction I've been pursuing. The problem is getting the "data" back across the isolation barrier "cheaply". I.e., you don't want to put much on the "exposed" side of the barrier as it represents increased propensity for failure. My first approach was to use an iso-optilator in its linear region. That can provide lots of information -- more detail than you really need! But, coming up with a design that can reliably ensure you are using *only* the linear region of those devices seemed a bit dubious ("select/tweek at test" is not an option; esp if Joe Tinkerer opts to substitute some other device that he happens to have on hand -- not realizing the "special needs" that are imposed on the device in the circuit). So, I'm now looking at relying solely on operating them as digital devices and conveying that information in the time/frequency domain. This should keep the actual interface robust, inexpensive and easy to build.
> Don is a tough cookie to discuss things with. You offer some help and > he pulls more requirements out of thin air.
We *all* make assumptions. I don't even think twice about whether or not something like this would have to be electrically isolated. "It goes without saying". Similarly, the desire to keep the amount of stuff on that "exposed" side of the isolation barrier "robust" (surely nothing that is going to fry the first time there's an electrical storm, a large inductive kick in the cable, etc.) Likewise, that multiple valves could be active at the same time. Or, that "broken wires", "shorted solenoids", etc. are likely to be encountered in this sort of application (from knowledge of the types of mistakes DIYers make when doing these things). And, the sorts of things that a "system" existing in this sort of environment is likely to encounter -- that you'd not consider if you approached it solely as a technical problem. E.g., a little kid standing there pushing the button, repeatedly or continuously, because he can *see* that each button press is causing the water to stop flowing from the hose -- a consequence of Ed's design (OTOH, if the button is an "independent function" that the controller must *interpret*, then the controller, after seeing several sporadic button presses, can opt to treat the button as "suspect" and disable that functionality -- wildlife? packrat chewing on wires?) [*You* may, OTOH, assume only the left limit switch can possibly be engaged while "moving left" (see below).] Folks frequently piss and moan that I'm too verbose. Yet, if I present a detailed specification, do you think that will be any *shorter*? "Why do you need clause 3.8a?" "Can you eliminate clause 9.6b?" "Why does it have to work in 100% RH? Are you planning on using it UNDERWATER??" Also, the more you specify, the more you close the door on other possibilities. Possibly incorrectly! I had a colleague go through a very detailed analysis to convince himself that a certain observed symptom could *not* possibly be caused by something I was suggesting. Not accepting his decision -- he was actually my boss/client -- I *demonstrated* that this was, indeed, the source of the problem! ("Where is the error in my analysis? Let me check my math, again..." "Why bother? Do you doubt what you are *seeing* in my 'proof'?")
> But for the most part he is > brainstorming and that can be part of what we are seeing. He likely
I think folks don't think "twice" before responding. I.e., this isn't a place where folks come to ask "simple" questions. And, for the most part, it's not "high school kids" with no background trying to get answers to homework problems. Or, equally clueless homeowners tying to fix their own furnace, etc. When I respond to a post, I assume the querant has already thought about the problem. So, any *obvious* solution that I see gets double or triple scrutiny: "Surely he would have thought of this, already. Dig deeper for a solution." (e.g., my comment to Joerg, recently, about using a lawnmower engine as an "air pulser") Note my original post explicitly stated "shorting the coil". So, it should be rather obvious that I'd already considered that as a potential solution -- and moved *past* it (I didn't ask "how do I detect when I deliberately short a coil"). Finally, I consider engineering to be the art of finding the LEAST WRONG solution to a given problem (i.e., there are no "ideal" solutions in the real world). So, I find *my* best and then hope someone else will have a *cleverer* approach. Or, see some issue that will eat my lunch that I've neglected.
> didn't think about the failure detection as an initial requirement, it > occurred to him after he started thinking about how to implement what he > wanted. So it became a requirement because he thinks it will be easy to > include whether it is very valuable or not.
Actually, it's the other way around. I *assumed* everyone would have considered that as it's been an integral part of my design process (and the folks I've worked with) for decades. My favorite example: driving a motorized mechanism. Often, "limit switches" (of some sort) exist to signal the controls when the mechanism has reached end-of-travel in a particular direction. Most folks tasked with driving such a mechanism would write: case (command) { "left" => while (!left_limit) { drive(LEFT); }; "right" => while (!right_limit) { drive(RIGHT); } * => # can't happen } I, OTOH, would build a little state machine that modeled the mechanism: "at left limit", "at right limit", "traveling left", "traveling right". Then, monitor *all* inputs in each context. So, if I think I am "traveling left" and I see the left limit switch activated, I know I have arrived in the "at left limit" state. OTOH, if I see the *right* limit switch activated, I know something is VERY WRONG! I was not *in* the "at right limit" state (so, the right limit switch could not have been active). And, I am driving to the *left*. So, how could the RIGHT limit switch become engaged? Clearly, the software's model of reality no longer corresponds with "reality". Because we are actually *moving* things, there is a real risk that physical damage/injury can occur when the software is out of sync with the real world. So, go immediately to a "safe" condition -- without relying on any of these models! I.e., "CAN'T HAPPEN" *has* happened (because someone miswired the drive signals to the motor, it's drive circuit, or the limit switch sensors, etc.). The failure isn't allowed to propagate (cascade, get worse, etc.). And, the "cost" for this protection is just NOT "assuming" that only the left switch is significant when moving left! [This sort of approach has served me well -- VERY well -- over the years. IME, bugs hide in the "CAN'T HAPPEN" parts of designs.] Similarly, the idea of relying on "dead plants" as an indication of a failure wouldn't even enter into my calculations. "Doctor, the patient in room 205 is dead".
> I like your idea. But I'm not sure that it will do what he wants if you > use a common resistor as a sensor. That would require that you > periodically turn off all solenoids and poll each switch. In theory you
And, do that fast enough to catch a "quick" button push (or, do you burden the user by telling him he has to hold the button pressed for 15 seconds to ensure it is "seen" by an ULF polling event?)
> could do this fast enough that active solenoids do not drop out, but you > would then be sending some moderately fast pulses along long lines > potentially generating a lot of RFI. I bet it would mess up AM radio > pretty badly. Maybe there would be a way to shape the edges to prevent > this. I guess sampling 4 times a second would be adequate, maybe even > just once a second. That wouldn't be so bad, so maybe my concerns are > not valid.
And this saves, what -- a few resistors? :> Make the "pin driver" circuit effective; then efficient. As with software, don't "prematurely optimize".
Reply by Don Y September 19, 20132013-09-19
On 9/19/2013 9:37 AM, bloggs.fredbloggs.fred@gmail.com wrote:
> On Thursday, September 19, 2013 12:34:38 AM UTC-4, Don Y wrote: > >> So AZ. 10-11" precip annually. Think: "desert". Sage brush, creosote, >> cacti, etc. > > There are a bunch of resources on ultra-low water requirement landscape > material there. I found lots of stuff from your state agriculure dept > as well as something called Arizona Municipal Water Users Association. > There are tons of ornamental desert plants that do perfectly well with > little to none supplemental watering.
Yes, we spent the better part of a year researching what to plant. And, tried many different specimens that, ultimately, we opted against using (e.g., "African Sumac" is a popular tree, low water use, etc. But, you end up with a *yard* full of seedlings with tenacious roots.). At the time, we had a pair of dogs so that put a constraint on what we could plant -- many plants are toxic, have spines, etc. And, with such small/close lots, you want to choose specimens to enhance privacy (so you aren't looking at a "wall" each time you glance out the window). E.g., mesquite trees (signature plant for this region) are reasonably low water use, provide filtered shade, etc. But, produce bajillions of 1/4W resistor sized "leaflets" that track into the house, etc. An established pine tree with deep roots out front -- but, didn't yield any usable shade, pine needles everywhere (they trap water when they accumulate on the roof and "rot" the roofing material), AND have a tendency of snapping off at the base in the microbursts we frequently experience here (at least one or two fall each year... and these are 18-24" diameter specimens!). Oleander is a favorite as a hedge/privacy screen. But, it's toxic (think: dogs & fires) and pretty boring. Cactus? <yawn> We settled on what we have found to be a good mix of plantings that are evergreen, dog-safe, don't encourage too many bees, flowering, don't produce too much litter, etc. And, in the process, removed all of the original plants as they were either inappropriate for the property (tall trees on small lots don't offer much of anything!), no longer permitted within the city limits (as new plantings... so, "established" is just as bad), offered nothing of value to us (peach, pear, almond), etc.
>> Pick an orange off the tree and eat it 10 minutes later. Compare >> to *anything* store bought and you will see why we spend the time >> and effort we do to grow them. Along with the *size* of the fruit >> (our limes are as large as store bought oranges; oranges as large >> as grapefruit, etc.) > > Those plants require tons of water, doesn't make any sense to grow > them in a desert climate.
Doesn't make sense to have a back yard that is 60% swimming pool, either! Yet about half of the homes here do. Few of them use "covers" to control evaporation. So, the water they consume just "increases local humidity" (i.e., doesn't produce fruit, greenery, etc.)
> But I suppose you could get away with a small number if you do things > like select grafted root stock dwarf variety, possibly use in-ground > grow bags to mechanically condense root mass, use subterranean drip > irrigation, surface mulch/anti-evaporation measures, and possibly > shading nets for the extra hot months.
We had mostly "semi drawf" specimens, originally. They proved to be larger than we expected. We lost three of them (lemon, lime, blood orange) in a particularly cold (for here) winter ~2 years back. We took that opportunity to replace them with dwarf varieties. Soil here has very high clay content. E.g., dig a hole, fill with water. Come back next day and you've ONLY lost water to evaporation (no drainage). As such, each of the citrus trees were planted in what amounts to as a "large pot" (horticulturist at nursery provided that answer when I asked how large a hole I should dig: "Pretend you are sculpting a terra cotta pot, *in* the ground, in which the tree will *live*..."
>> City lot. 1/3 - 1/2 acre? > > That's so tiny there's no excuse for not just manually turning your > water on and off.
The point of the electric valve on the hose bibb was so the hose can be used to bring water *to* a particular location in the yard without having to add or move drip lines/emitters. E.g., the three new citrus plantings can't be serviced by the existing irrigation lines -- their rootballs don't "reach" the location of the emitters (and won't for several years). Standing outside *holding* a garden hose in 100+ temperatures daily is not my idea of retirement! :>
>> Instead, build a water treatment plant. Tax folks to pay for it. >> Then worry when you will EVENTUALLY run out of water and the >> whole mechanism grinds to a halt. (I think municipalities here >> have to certify a 100 year water supply. Failing to do so >> puts bonds, etc. in jeopardy) > > It's all about job preservation with those people.
Actually, I think they just don't consider it *their* money (in terms of "coming out of THEIR pockets) and, as such, are very comfortable rationalizing the spending of other folks' money. They are putting in a "street car" downtown (or, what passes as "downtown", here). It goes from nowhere to nowhere_else. Has torn up the roads. Cost millions. No one expects it to see any ridership. Heavily subsidized. Etc. "Um, what's the point of this exercise? To cut down on traffic? To add a more 'economical' means of moving people (who don't want to walk those few blocks)? To cut down on exhaust emissions?"
>> Yet, come Monsoon season, everyone drops what they are doing and >> walks outside to watch it rain. ("Hello! Does anyone see the >> inconsistency, here?") > > That 10" is ridiculous, the place is not exactly a garden of Eden.
"Sonoran Desert". Key word is "desert".
Reply by September 19, 20132013-09-19
On Thursday, September 19, 2013 12:34:38 AM UTC-4, Don Y wrote:

>=20 > So AZ. 10-11" precip annually. Think: "desert". Sage brush, creosote, >=20 > cacti, etc.
There are a bunch of resources on ultra-low water requirement landscape mat= erial there. I found lots of stuff from your state agriculure dept as well = as something called Arizona Municipal Water Users Association. There are to= ns of ornamental desert plants that do perfectly well with little to none s= upplemental watering.
> >=20 > Pick an orange off the tree and eat it 10 minutes later. Compare >=20 > to *anything* store bought and you will see why we spend the time >=20 > and effort we do to grow them. Along with the *size* of the fruit >=20 > (our limes are as large as store bought oranges; oranges as large >=20 > as grapefruit, etc.)
Those plants require tons of water, doesn't make any sense to grow them in = a desert climate. But I suppose you could get away with a small number if y= ou do things like select grafted root stock dwarf variety, possibly use in-= ground grow bags to mechanically condense root mass, use subterranean drip = irrigation, surface mulch/anti-evaporation measures, and possibly shading n= ets for the extra hot months.
>=20 > City lot. 1/3 - 1/2 acre?
That's so tiny there's no excuse for not just manually turning your water o= n and off.
>=20 > Instead, build a water treatment plant. Tax folks to pay for it. >=20 > Then worry when you will EVENTUALLY run out of water and the >=20 > whole mechanism grinds to a halt. (I think municipalities here >=20 > have to certify a 100 year water supply. Failing to do so >=20 > puts bonds, etc. in jeopardy)
It's all about job preservation with those people.
>=20 > In the recent past, water from the Central Arizona Project (CAP) has >=20 > been introduced to potable water supply (historically from wells). >=20 > (CAP water flows through a manmade canal from "way up north") >=20 >=20 >=20 > But, past attempts to do this met with some problems (?). To >=20 > address these concerns, the water is pumped *into* the aquifer >=20 > and then drawn *out* of the aquifer (as well water), locally. >=20 > Apparently, the "in" and "out" are within eyeshot of each other. >=20 >=20 >=20 > Until you have reasonable (not heavy-handed) policies in place, >=20 > folks have no incentive to behave "responsibly". I can be fined >=20 > if the "water police" happen to catch irrigation water running onto >=20 > the street *or* across the sidewalk on my property. Yet a business >=20 > can use spray irrigation to keep a green lawn lush during the heat >=20 > of the day? 24/7/365?? Neighbor hand washes their *four* vehicles >=20 > every two weeks. At least if he went to a "car wash", the water >=20 > would be recycled... >=20 >=20 >=20 > I think people (locals) lose track of just how little precip falls >=20 > here, each year. "You get used to it". Coming from a much lusher >=20 > environment ("*God* waters the yard"), the difference is far more >=20 > obvious. You are constantly aware of how much *less* you have >=20 > than you had previously. E.g., none of the "locals" that I know >=20 > would even *consider* rainwater harvesting -- regardless of the >=20 > number of citrus trees on their property, swimming pool, lawn, etc. >=20 >=20 >=20 > Yet, come Monsoon season, everyone drops what they are doing and >=20 > walks outside to watch it rain. ("Hello! Does anyone see the >=20 > inconsistency, here?")
That 10" is ridiculous, the place is not exactly a garden of Eden.=20
Reply by rickman September 19, 20132013-09-19
On 9/19/2013 1:59 AM, ehsjr wrote:
> On 9/18/2013 5:30 AM, Don Y wrote: >> 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. > > Correct. I limited my thinking to a way you can detect a switch > state where the switch is installed near the solenoid location > and connected using the 2 existing wires that go to the solenoid, > _because that is what you asked about_ . > > The rest of the functionality you want is up to *your* circuit.
You make a good point with that. The issue with the failure is not really such a big deal. His controller will be able to sense if the button is shorted and notify the operator. The button is very unlikely to fail shorted, but there are plenty of other failure mechanisms. If the system needs to be robust then these other failure mechanisms should be detected. Probably the most important thing would be to just plain detect if water is coming from the spigot or not rather than detect all the individual failures. Yes, a pressure switch *after* the valve could do that and the pressure switch could be connected to the power wires in a similar manner to provide a result back to the controller. The push button shorts the solenoid, the pressure switch has a resistor in series. So now you have three levels of voltage you need to sense to detect the button and the pressure switch. I would do this with a current driver circuit. It would have a constant current drive allowing the voltage to float depending on the resistance. Sense the voltage out of the driver and you are done. 24 volts is solenoid operating normally, 16 volts is solenoid operating and pressure detected in the output line, 0 volts is button pressed or solenoid shorted. You could use a low level of current to sense the switch when the water if off, or you could pulse the full current briefly, too short to activate the solenoid. Don is a tough cookie to discuss things with. You offer some help and he pulls more requirements out of thin air. But for the most part he is brainstorming and that can be part of what we are seeing. He likely didn't think about the failure detection as an initial requirement, it occurred to him after he started thinking about how to implement what he wanted. So it became a requirement because he thinks it will be easy to include whether it is very valuable or not. I like your idea. But I'm not sure that it will do what he wants if you use a common resistor as a sensor. That would require that you periodically turn off all solenoids and poll each switch. In theory you could do this fast enough that active solenoids do not drop out, but you would then be sending some moderately fast pulses along long lines potentially generating a lot of RFI. I bet it would mess up AM radio pretty badly. Maybe there would be a way to shape the edges to prevent this. I guess sampling 4 times a second would be adequate, maybe even just once a second. That wouldn't be so bad, so maybe my concerns are not valid. -- Rick
Reply by ehsjr September 19, 20132013-09-19
On 9/18/2013 5:30 AM, Don Y wrote:
> 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.
Correct. I limited my thinking to a way you can detect a switch state where the switch is installed near the solenoid location and connected using the 2 existing wires that go to the solenoid, _because that is what you asked about_ . The rest of the functionality you want is up to *your* circuit. Ed <snip>
Reply by Don Y September 19, 20132013-09-19
On 9/18/2013 8:05 PM, bloggs.fredbloggs.fred@gmail.com wrote:
> On Wednesday, September 18, 2013 10:41:14 PM UTC-4, Don Y wrote: > >> But, you'll find truly "native" landscapes (here) are very boring, >> lack color, etc. And, you'll find things like blood oranges very >> expensive (and having to be *shipped* here) instead of growing them >> yourself (ignore the difference in the *quality*, lack of pesticides, >> freshness, etc.) > > Where are you?
So AZ. 10-11" precip annually. Think: "desert". Sage brush, creosote, cacti, etc.
>> Oranges grown in California/Florida also require water. The difference >> is the amount available to them as a consequence of local environmental >> conditions. And, "subsidies" from other water sources. If each >> locality was required to survive with their own precipitation, lots >> of crops would just disappear. Or become vastly more expensive. >> E.g., trade diesel fuel (shipping products) for water. > > The imported citrus, mostly coming from underdeveloped countries, > actually costs less than the domestic produce.
... picked a week ago -- so, either ripened in the hold of a ship *or*, overripe, by now. Pick an orange off the tree and eat it 10 minutes later. Compare to *anything* store bought and you will see why we spend the time and effort we do to grow them. Along with the *size* of the fruit (our limes are as large as store bought oranges; oranges as large as grapefruit, etc.)
> Practices like the jackasses in California growing rice and cotton > should be abolished, but the idiots are waiting for an ecological > disaster first.
I am told cotton is grown "just up the road". (Did I mention 10" annual precipitation??) Along with a fair bit of other "farming".
>> We offset our "excessive" water needs with rainwater harvesting and >> general water conservation. Not letting water *leave* the property >> easily. E.g., using *all* of the precipitation that falls on the >> property instead of relying on "municipal water" to attend to those >> needs. Amending the soil to retain moisture instead of letting it >> seep through directly to the aquifer. > > You must have a small lot.
City lot. 1/3 - 1/2 acre?
>> We *surely* aren't wasteful enough to fill a swimming pool/spa and >> watch hundreds of gallons evaporate *daily*. Or, have a *lawn* watered >> with "sprinklers". Or a "mister" that cools *outdoor* air (OUTSIDE!) >> around a patio by blindly pushing water into the air. Koi pond, "water >> feature", fountain, etc. > > Yeah, no end to the ways people waste resource.
Because policies don't encourage (reward/punish) better stewardship. E.g., we are now approaching the "treated effluent" stage of demand for potable water. One would think "conservation" would be a big deal! *Stressed* by "policy", pricing, etc. If not for "moral" grounds, then for the economic reason of AVOIDING the need for a new treatment plant, etc. Ah, but that means new development (mindless way to stimulate the local economy by borrowing/stealing? from the future) would be hard to support by policy. So, can't come out and say that! And, if you *do* conserve, city complains they need to raise rates because not enough water is being used (to offset their existing cost structure!). Install gray water recycling and they complain not enough water is flowing through the sewers to keep them clear. Instead, build a water treatment plant. Tax folks to pay for it. Then worry when you will EVENTUALLY run out of water and the whole mechanism grinds to a halt. (I think municipalities here have to certify a 100 year water supply. Failing to do so puts bonds, etc. in jeopardy)
> My area is investing in a $250M augmented river flow reservoir to meet > projected demands of the future, but that water was just going into the > Atlantic anyway.
In the recent past, water from the Central Arizona Project (CAP) has been introduced to potable water supply (historically from wells). (CAP water flows through a manmade canal from "way up north") But, past attempts to do this met with some problems (?). To address these concerns, the water is pumped *into* the aquifer and then drawn *out* of the aquifer (as well water), locally. Apparently, the "in" and "out" are within eyeshot of each other. Until you have reasonable (not heavy-handed) policies in place, folks have no incentive to behave "responsibly". I can be fined if the "water police" happen to catch irrigation water running onto the street *or* across the sidewalk on my property. Yet a business can use spray irrigation to keep a green lawn lush during the heat of the day? 24/7/365?? Neighbor hand washes their *four* vehicles every two weeks. At least if he went to a "car wash", the water would be recycled... I think people (locals) lose track of just how little precip falls here, each year. "You get used to it". Coming from a much lusher environment ("*God* waters the yard"), the difference is far more obvious. You are constantly aware of how much *less* you have than you had previously. E.g., none of the "locals" that I know would even *consider* rainwater harvesting -- regardless of the number of citrus trees on their property, swimming pool, lawn, etc. Yet, come Monsoon season, everyone drops what they are doing and walks outside to watch it rain. ("Hello! Does anyone see the inconsistency, here?")