Forums

"Input" on an "output"

Started by Don Y September 15, 2013
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.
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!]
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
> 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!