Maker Pro
Maker Pro

"Input" on an "output"

D

Don Y

Jan 1, 1970
0
I'll tell you why, because you flushed it down the drain on a bunch
of oddball landscaping that required too much water.

"Lawns", golf courses, people using a garden hose to "wash" the
cruft off their driveways instead of dragging out a *broom*,
businesses watering lush lawns during daylight hours, hydraulic
mining, fracking, leaving the water running while brushing teeth,
legacy plumbing fixtures, swimming pools, spas, crops that use
disproportionately high amounts of water, etc.
Modern landscape architecture is getting away from that. People are
learning that they have plenty of options using plants native to their
climate zone and soil conditions. This means watering is only required
during extreme drought conditions, *if that*.. It also means the plants
are immune to attack from the local pests and diseases (no pesticides,
fungicides, microbicides, bactericides), and they supply food to the
local wildlife in one form or another. You will find that the native
plants will do spectacularly well and with very little maintenance.

Our yard is xeriscaped with the exception of the citrus and roses. I
(personally) removed/dug up the "lawn" that was here previously. We
use no chemicals to control weeds, pests, etc. (because our domestic
water comes from wells and we don't want to add more cruft to that
water supply!)

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.)
There are exceptions with some of the chinensis and japonica imports
that have proved hardier than the natives, but you should check with
your state agricultural department for things like invasiveness and
legality first. Things like water intensive roses are out, and it
sounds like the citrus are too if they absolutely have to have three
deep waterings weekly.

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.
Sounds like you have a bunch stuff that needs to pulled up and thrown
on a compost heap.

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.

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


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.

Practices like the jackasses in California growing rice and cotton should be abolished, but the idiots are waiting for an ecological disaster first.

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

Don Y

Jan 1, 1970
0
Where are you?

So AZ. 10-11" precip annually. Think: "desert". Sage brush, creosote,
cacti, etc.
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".
You must have a small lot.

City lot. 1/3 - 1/2 acre?
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?")
 
E

ehsjr

Jan 1, 1970
0
Hi Ed,

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

rickman

Jan 1, 1970
0
Hi Ed,

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

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.

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.


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

That 10" is ridiculous, the place is not exactly a garden of Eden.
 
D

Don Y

Jan 1, 1970
0
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.
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*..."
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! :>
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?"
That 10" is ridiculous, the place is not exactly a garden of Eden.

"Sonoran Desert". Key word is "desert".
 
On 9/19/2013 9:37 AM, [email protected] 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.

If you want a privacy screen, maybe a trellis wall with some tough evergreen vine will work better, those grow in no time.

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.





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

The standard practice of handling that is to plant the tree in a mound withthe root system above the surrounding soil.

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 comesa point where the plant has to make it on its own.


"Sonoran Desert". Key word is "desert".

That lack of moisture causes everything to grow extra slowly and 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. 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.
 
R

rickman

Jan 1, 1970
0
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.

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)


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.


You actually need more than that to be able to detect all of the
*likely* failures you will encounter.


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.

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.

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.

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

Don Y

Jan 1, 1970
0
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!
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]
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? :>
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.


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!
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)
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! :>
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]
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!
 
Top