Prev: Low Rds(on) tempco
Next: Termination of AC coupled 100MHz clok to generate low jitter 50MHz clock?
From: Tim Watts on 25 Jan 2010 19:34
On Mon, 25 Jan 2010 16:47:50 -0700, D Yuniskis <not.going.to.be(a)seen.com>
wibbled:

> Hi Tim,


> I start looking at these things with the big criteria being: - power
> consumption
> - range
> - data rate + duty cycle
> Cost tends to fall out based on the above.
>
> First, think about how you are going to power these devices. The MCU's
> you reference are *relatively* low power. But, the choice of radio can
> quickly aggravate your power budget. E.g., if you intend to battery
> operate the devices, then you have a very strict power budget. If you
> can tolerate having a real "(mains) power supply", then power is less of
> an issue (though this will affect where you site the devices and can
> also be a cosmetic problem). However, you have to ensure that you don't
> *need* power to be available at all times. E.g., a mains powered HVAC
> controller can make sense -- if the power is out, the controller is dead
> but so is the HVAC plant, typically. OTOH, a mains powered alarm system
> leaves you vulnerable to someone turning off the power (or, a normal
> outage) -- sure, you may have a battery backup on your alarm/siren, but
> if the sensors suddenly go "off-line"... :-/

This is true.

> The same sorts of arguments apply to the reliability of the data link.
> Can you tolerate short and/or long term losses of connectivity? Will
> your HVAC system cease to operate if it loses contact with the
> "temperature sensor"? (etc.)

Good point. I was going to use the "repeated-call-for-demand" strategy -
ie rather than the thermostat sending one request for heat (even if it is
ACK'd) then staying silent for 6 hours, it will send a call for heat
(say) every 10 minutes when heat is required. That way a missed
transmission (or a power cycle where state may be forgotton) doesn't
break the system for long.

> If you need to push lots of bits lots of time (e.g., continuous duty),
> then this will conflict with a low power solution.

I think it will be a small packet (+ return ACK) every 10 minutes or so,
unless remote programming or data dump operations are in progress (from a
PC), in which case the channel will get very bursty for short periods.

>
> For things like home automation, most data channels can be *very* low
> bandwidth -- watching for door/window closures, monitoring temperature,
> etc. With these low data rates, ZigBee can be a win *if* you can't
> afford a wall wart or other AC power source nearby.
>
> Of course, a wireless solution leaves you vulnerable to interference
> from outside sources (unintentional as well as deliberate). And, it
> "leaks" information to outside eavesdroppers (unless you emply an
> encryption protocol in the data stream and authentication).

I'm not too worried about encryption, but I might consider a very simple
challenge-response mechanism to authenticate the end points (never ceases
to amaze me that one can set off a neighbour's radio doorbell so easily
in this day and age).

> I opted to deploy a wired system, here, to meet my needs. This allows me
> to remove the unsightly wall warts/power cords that would accompany each
> device (power comes down the data cable). It also lets me decide which
> devices need to be "backed up" during a power failure and lets me
> centralize that backup power source (instead of having to backup each
> individual node *at* the node). And, it provides considerably more
> security against eavesdropping and tampering than a wireless approach
> would have (imagine someone accidentally/intentionally commanding your
> thermostat to 30C in the Summer; or, turning on the heater for your
> outdoor jacuzzi in the dead of winter)
>
> The problem with any wired approach is, of course, the *wires*! <grin>
> We had been remodeling at the time so installing the extra cabling only
> carried the cost of the cable itself (plus the terminations thereto).

And the expense. Ideally, I'd slap ethernet+TCP/IP on everything and
shove it all through a seperate VLAN to my main network. But ethernet+TCP/
IP is rather heavy (doable but heavy) on a poor AVR and it seems for the
same or maybe less money, I can dispense with the wires.

Those Xbee modules look very cute - been reading the data sheets some
more. Basic collision avoidence and retransmit, packet framing and simple
addressing if my skim reading is correct. Just the ticket. Can soon pop a
simple protocol on top of that.

As it's advantageous to keep the user touchable parts on SELV DC (no
mains or earth references), power isn't a problem. One advantage is that
certain actuators are cheaper in the mains powered version (eg motorised
water valves for radiators) so it would now be possible to stick a direct
from mains powered Xbee next to a water valve with nothing more than a
suitably fused loop in loop out 240V supply, but keep the user interfaces
on DC.

I envisage lots of paired timer/thermostats (LCD display, few buttons,
one per room) paired with a valve + a second relay for boiler/pump
demand. The system would work without any PC and failure of any part (bar
the boiler demand interface) would knock out a room, not the house. The
flexibility comes in then being able to remote manage the lot as a whole.

I've been looking at Heatmiser timer/stats. Very nice, RS485 data link
with documented protocol but not radio link. But around 50 pounds. I
winder if I could do something for a fraction less, with more education
value and possibly (after the nth firmware upgrade!) more features :)

Honeywell CM-Zone stuff is also pretty nice and radio based but pricey
and without a documented protocol no fun at all.

Thanks for all your comments!

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buff
From: D Yuniskis on 25 Jan 2010 21:04
Hi Tim,

Tim Watts wrote:
>> I start looking at these things with the big criteria being:
>> - power consumption
>> - range
>> - data rate + duty cycle
>> Cost tends to fall out based on the above.
>>
>> First, think about how you are going to power these devices. The MCU's
>> you reference are *relatively* low power. But, the choice of radio can
>> quickly aggravate your power budget. E.g., if you intend to battery
>> operate the devices, then you have a very strict power budget. If you
>> can tolerate having a real "(mains) power supply", then power is less of
>> an issue (though this will affect where you site the devices and can
>> also be a cosmetic problem). However, you have to ensure that you don't
>> *need* power to be available at all times. E.g., a mains powered HVAC
>> controller can make sense -- if the power is out, the controller is dead
>> but so is the HVAC plant, typically. OTOH, a mains powered alarm system
>> leaves you vulnerable to someone turning off the power (or, a normal
>> outage) -- sure, you may have a battery backup on your alarm/siren, but
>> if the sensors suddenly go "off-line"... :-/
>
> This is true.
>
>> The same sorts of arguments apply to the reliability of the data link.
>> Can you tolerate short and/or long term losses of connectivity? Will
>> your HVAC system cease to operate if it loses contact with the
>> "temperature sensor"? (etc.)
>
> Good point. I was going to use the "repeated-call-for-demand" strategy -
> ie rather than the thermostat sending one request for heat (even if it is
> ACK'd) then staying silent for 6 hours, it will send a call for heat
> (say) every 10 minutes when heat is required. That way a missed
> transmission (or a power cycle where state may be forgotton) doesn't
> break the system for long.

But, if it goes silent, you don't know if the device has "died"
(in which case, you don't know whether the *room* wants heat/cooling
or not) or if it just "doesn't need 'anything'".

What I have done is download small "fail safe" applications into
each node. These allow local intelligence to keep things "safe"
in the event communication with the "server" fails for some
reason. I.e., the "thermostat" knows to maintain temperature
between some absolute limits regardless of whether or not it
has been commanded externally to do so. Likewise, the
irrigation system knows a default watering schedule that it
will enforce if it loses contact with the server.

(you have to consider what might happen if you are away from
the house for an extended period -- weeks? -- when the failure
occurs... no possibility of outside intervention to *fix*
things in your absence)

>> If you need to push lots of bits lots of time (e.g., continuous duty),
>> then this will conflict with a low power solution.
>
> I think it will be a small packet (+ return ACK) every 10 minutes or so,
> unless remote programming or data dump operations are in progress (from a
> PC), in which case the channel will get very bursty for short periods.

ZigBee is good for very low bandwidth operation using very little
power (sleeping most of the time). E.g., it was designed to be
retrofittable in places like hotels, hospitals, etc. where you
may not already have the (network + power) infrastructure in place
to support things like this. So, you want to operate on batteries
yet not have to be replacing 500 batteries every month! :>

>> For things like home automation, most data channels can be *very* low
>> bandwidth -- watching for door/window closures, monitoring temperature,
>> etc. With these low data rates, ZigBee can be a win *if* you can't
>> afford a wall wart or other AC power source nearby.
>>
>> Of course, a wireless solution leaves you vulnerable to interference
>> from outside sources (unintentional as well as deliberate). And, it
>> "leaks" information to outside eavesdroppers (unless you emply an
>> encryption protocol in the data stream and authentication).
>
> I'm not too worried about encryption, but I might consider a very simple
> challenge-response mechanism to authenticate the end points (never ceases
> to amaze me that one can set off a neighbour's radio doorbell so easily
> in this day and age).

Note that this will leave you vulnerable to "session" attacks.
I.e., once you legitimately "open" a connection, someone else
can inject their own "commands" -- until you "close" the
connection. If the attacker can obfuscate your eventual
"close" message, then he can leave the channel open indefinitely
(unless your protocol has built in timeouts)

I only mention this as you need to gauge your own level of
paranoia. Nowadays, it is just too easy for folks to tinker
with stuff like this: "Hey, wanna watch me make Tim's
garage door go up and down nonstop for the next hour??"

>> I opted to deploy a wired system, here, to meet my needs. This allows me
>> to remove the unsightly wall warts/power cords that would accompany each
>> device (power comes down the data cable). It also lets me decide which
>> devices need to be "backed up" during a power failure and lets me
>> centralize that backup power source (instead of having to backup each
>> individual node *at* the node). And, it provides considerably more
>> security against eavesdropping and tampering than a wireless approach
>> would have (imagine someone accidentally/intentionally commanding your
>> thermostat to 30C in the Summer; or, turning on the heater for your
>> outdoor jacuzzi in the dead of winter)
>>
>> The problem with any wired approach is, of course, the *wires*! <grin>
>> We had been remodeling at the time so installing the extra cabling only
>> carried the cost of the cable itself (plus the terminations thereto).
>
> And the expense. Ideally, I'd slap ethernet+TCP/IP on everything and
> shove it all through a seperate VLAN to my main network. But ethernet+TCP/
> IP is rather heavy (doable but heavy) on a poor AVR and it seems for the
> same or maybe less money, I can dispense with the wires.

You needn't go Ethernet to be "wired". I opted for it simply
because I want one network fabric that I can apply to *all*
of my needs (automation, security, telephony, entertainment, etc.)
instead of having to run Cable Type X to these N places and
cable type Y to these other places.

E.g., I can put a "display" anywhere to control any*thing*.
(instead of having the display for the thermostat *at* the
thermostat, etc.)

> Those Xbee modules look very cute - been reading the data sheets some
> more. Basic collision avoidence and retransmit, packet framing and simple
> addressing if my skim reading is correct. Just the ticket. Can soon pop a
> simple protocol on top of that.
>
> As it's advantageous to keep the user touchable parts on SELV DC (no
> mains or earth references), power isn't a problem. One advantage is that
> certain actuators are cheaper in the mains powered version (eg motorised
> water valves for radiators) so it would now be possible to stick a direct
> from mains powered Xbee next to a water valve with nothing more than a
> suitably fused loop in loop out 240V supply, but keep the user interfaces
> on DC.

I have been moving everything to PoE. Electric Code here (US)
allows this as "low voltage, power limited" wiring.

> I envisage lots of paired timer/thermostats (LCD display, few buttons,
> one per room) paired with a valve + a second relay for boiler/pump

I've opted to do everything "headless". Just black boxes with
suitable field wiring. The user interface being something
decoupled from the "controllers", "sensors" and "actuators".

> demand. The system would work without any PC and failure of any part (bar
> the boiler demand interface) would knock out a room, not the house. The
> flexibility comes in then being able to remote manage the lot as a whole.
>
> I've been looking at Heatmiser timer/stats. Very nice, RS485 data link
> with documented protocol but not radio link. But around 50 pounds. I
> winder if I could do something for a fraction less, with more education
> value and possibly (after the nth firmware upgrade!) more features :)

Pounds = Dollars (regardless of the current exchange rate :> )
So, you should be able to put an EIA485 transceiver on a tiny
AVR and get the same sort of performance. But, then you have
to build the boards yourself...

> Honeywell CM-Zone stuff is also pretty nice and radio based but pricey
> and without a documented protocol no fun at all.

Good Luck!
--don
From: D Yuniskis on 26 Jan 2010 17:42
Hi Tim,

Tim Watts wrote:
>>> Good point. I was going to use the "repeated-call-for-demand" strategy -
>>> ie rather than the thermostat sending one request for heat (even if it is
>>> ACK'd) then staying silent for 6 hours, it will send a call for heat
>>> (say) every 10 minutes when heat is required. That way a missed
>>> transmission (or a power cycle where state may be forgotton) doesn't
>>> break the system for long.
>> But, if it goes silent, you don't know if the device has "died"
>> (in which case, you don't know whether the *room* wants heat/cooling
>> or not) or if it just "doesn't need 'anything'".
>
> True - perhaps a better strategy would be positive on and off signals, but
> repeated every 10 mins. Continued lack of reception would signal an error -
> though there's not much that can be done of the water valve controller has
> died, other than manually override it[1] I suppose if the thermostat died,
> the water valve could default to the last timed pattern it saw.

If you have local intelligence, you can continue to operate the
valve even in the absence of temperature (sense) data. E.g.,
remember the *pattern* that the valve was following (something
akin to duty cycle) and just have the valve continue that
*pattern* of operation in the absence of any "command input".
No, it won't be perfect. But, I suspect it will be better than
"full on" or "full off" :>

> [1] Zone valves are the cheapest motorised valves I can find, but I'm
> considering butchering a standard thermostatic radiator valve head and
> adding an heating resistor to control it by bias. I know of someone who has

Ah, that's clever. Some "setback" thermostats sold here
ages ago worked on a similar principle -- generate some
heat *under* your regular thermostat to trick them into
thinking the house didn't need heat.

> successfully done that (around 5W heating required IIRC) and the parts are
> cheaper. Also allows for full manual override (turn the knob).
>
>> What I have done is download small "fail safe" applications into
>> each node. These allow local intelligence to keep things "safe"
>> in the event communication with the "server" fails for some
>> reason. I.e., the "thermostat" knows to maintain temperature
>> between some absolute limits regardless of whether or not it
>> has been commanded externally to do so. Likewise, the
>> irrigation system knows a default watering schedule that it
>> will enforce if it loses contact with the server.
>
> There won't actually be a server as such - the room stats will be paired
> with a valve controller (likely to be remote where it's convenient to mount
> a valve, prolly in the attic space where the pipes are). If a room stat
> fails, there's not a lot you can do, but I'm allowing mechanical manual
> override as I don't trust computers (!).

<grin> Gee, I wonder why?? :>

>> (you have to consider what might happen if you are away from
>> the house for an extended period -- weeks? -- when the failure
>> occurs... no possibility of outside intervention to *fix*
>> things in your absence)
>
> True. With the paired strategy though, at most one room is likely to fail
> (might have to double up on the boiler receiver to guarantee that) so it
> won;t really affect frost protection.

Understood. It's been so long since I've used steam heat that
I forgot how easy it is to have "multiple zones" :<

> <snip good thoughts>
>
>> Note that this will leave you vulnerable to "session" attacks.
>> I.e., once you legitimately "open" a connection, someone else
>> can inject their own "commands" -- until you "close" the
>> connection. If the attacker can obfuscate your eventual
>> "close" message, then he can leave the channel open indefinitely
>> (unless your protocol has built in timeouts)
>>
>> I only mention this as you need to gauge your own level of
>> paranoia. Nowadays, it is just too easy for folks to tinker
>> with stuff like this: "Hey, wanna watch me make Tim's
>> garage door go up and down nonstop for the next hour??"
>
> No one round here will even be close to hacking at that level and the one's
> who are up to it won't. But I take your point. It would be good to engineer
> a modicum of protection in. Has to be lightweight - don't fancy doing
> polynomials on an AVR... Must do some reading...

Even if you aren't at risk for hacks, consider the effects
"bad data" can have on operation. I.e., what happens if
you erroneously turn the valve on? off? Think about
how each type of error can affect you. (e.g., timeouts
are often used).

Once you've done *that* thinking, consider how *that*
scheme can fail. E.g., what happens if your valve turns
on, then times out and turns off, then (erroneously) turns
on again, etc. I.e., it may be better off if it "fails"
one way or the other -- I'm not saying this is the case
for a steam valve but, rather, consider this when you
think of other automation applications (garage door
set to automatically close after 5 minutes to safeguard
against a faulty "open" command; then opens shortly
after having closed; closes again 5 minutes later and
again reopens, etc.)

> <snip>
>
>> E.g., I can put a "display" anywhere to control any*thing*.
>> (instead of having the display for the thermostat *at* the
>> thermostat, etc.)
>
> I like your approach :)

<shrug> It made sense at the time ;-)

>> I have been moving everything to PoE. Electric Code here (US)
>> allows this as "low voltage, power limited" wiring.
>
> The UK IEE regs define SELV (separate extra low voltage) as less than 60V
> DC, so that does allow PoE too, in dry areas. But there is still a special
> case to do with bathrooms where the limit is 30V DC depending on area and IP
> rating.

Yes. I believe a consequence of the difference between
wet skin "breakdown voltage" vs. dry.

> I've addressed that problem by siting the backbox for the device out in the
> hall and that one will have a remote sensor in the bathroom ceiling, which
> is considered outside the vulnerable zones provided it's high enough.

I think 7 feet, here. (or maybe it's 8?)

>>> I envisage lots of paired timer/thermostats (LCD display, few buttons,
>>> one per room) paired with a valve + a second relay for boiler/pump
>> I've opted to do everything "headless". Just black boxes with
>> suitable field wiring. The user interface being something
>> decoupled from the "controllers", "sensors" and "actuators".
>
> That's a nice idea. If I opt for cheap enough RF transceivers and given AVRs
> are dirt cheap, that would be quite sensible.

The point was to allow the sensors and actuators to be simple,
inexpensive and "pot-able". Once you remove the human user
from the equation, you can more readily achieve these goals.

At the same time, it lets the user interface become much
*richer* than it would otherwise be for any of these
individual devices.

>> Good Luck!
>
> Cheers! Have to fix the rest of the house first :) In the middle of a DIY
> renovation - doing the mains wiring at the mo.

<grin> Been there, done that, have the T-shirt to prove it.
Tedious though rewarding experience!

--don
From: Charlie E. on 26 Jan 2010 21:23
On Mon, 25 Jan 2010 14:18:34 +0000 (UTC), Tim Watts <tw(a)dionic.net>
wrote:

>On Mon, 25 Jan 2010 05:49:09 -0800, John Walliker <jrwalliker(a)gmail.com>
>wibbled:
>
>> On 25 Jan, 11:17, John Walliker <jrwalli...(a)gmail.com> wrote:
>>> �High frequencies diffract round corners better,
>>
>> Correction - its the other way round. What I should have said is that
>> high frequencies are better at getting through small apertures, such as
>> the joints between sheets of aluminium foil coated plasterboard.
>>
>> John
>
>
>Ah yes. Fortunately I don't have any shielding issues until I get to the
>roofline (1st floor as it's a bungalow) when the foil lined celotex will
>be an issue.
>
>Re the antennae: thanks for the info regarding monopoles and dipoles.
>Many of these devices (thermostats) if I make them, will be in backboxes
>in the wall. I've laid in lots of plastic conduit, so it has occurred to
>me I could make a 1/2 wave dipole, coax centre fed and insert it up the
>conduit, which gets it clear of the metalwork in the wall and the
>electronics. Downside is there might be a power cable up there too
>(mostly I have a pair of oval conduit drops per box, but a couple have a
>single round 20mm tube). Suck it and see I guess :)

Tim,
When you say power, are you talking 24VAC for powering the thermostat,
or full 120VAC. If the latter, it is a big code no-no to put ANYTHING
low voltage in there!

Even if it is the 24VAC, you are going to couple to it with any
antenna you put in there, and get very 'interesting' results!

Charlie
From: D Yuniskis on 27 Jan 2010 00:54
Hi Tim,

Tim Watts wrote:
>> If you have local intelligence, you can continue to operate the
>> valve even in the absence of temperature (sense) data. E.g.,
>> remember the *pattern* that the valve was following (something
>> akin to duty cycle) and just have the valve continue that
>> *pattern* of operation in the absence of any "command input".
>> No, it won't be perfect. But, I suspect it will be better than
>> "full on" or "full off" :>
>
> Agreed. The only thing the valve doesn't have is the current room
> temperature, so it would have to replay the operation timings - or an
> approximation of them (like x% duty cycle from 1pm to 2pm etc). But yes,

I wouldn't even bother trying to track time of day, etc.
Pick some period -- "the last 24 hours" (?) -- and have it track
(and continuously update) the average duty cycle that it was
*commanded* to use over that period. Then, in the absence
of "commands" (for some "significant period"), just have it
reproduce that duty cycle in some <mumblemumble> period
(I don't know the time constants involved in steam heat so
you'd be better at guessing that!)

You aren't trying to work perfectly. Rather, you are
trying to come up with something better than "all on",
"all off" or "whatever I was commanded to do most
recently". If things break while you are "available",
you will *fix* it! (you've heard of the Master-Slave
principle? Well, in this case, *it* is the Master and
*you* are its Slave! :> ) You just want to cover your *ss
in case you *aren't* available.

> that would probably give a sensible performance for constant weather
> conditions and at least means it goes off at night and on in the day.
>
>> Ah, that's clever. Some "setback" thermostats sold here
>> ages ago worked on a similar principle -- generate some
>> heat *under* your regular thermostat to trick them into
>> thinking the house didn't need heat.
>
> I think all the mechanical stats I've ever seen here have had that -
> provided the person remembered to take a neutral there(!).
>
> I went through loads of sources of random valves. The motorised "standard"
> valves are fairly ubiquitous, but not so cheap and are usually 240V
> operation. 24V exists, but being aimed at the fancy boat market cost far
> more than they're worth.

Yup. With steam, you're kinda stuck on your choices.
E.g., if it was hot water heat, you might have a wider
variety to chose from.

> I found one neat little valve that was pulse operated at 12V (bistable,
> needed no power to maintain either state) but it both severely restricted
> flow and had some bloody awful *plastic* 1/2" BSP threads on it. Having had
> experience of some plastic threads on a small water heater where varying
> amounts of PTFE tape (tried water grade and the thicker gas grade) failed to
> seal it and had to resort to a product that's basically a thick Loctite for
> plumbing[1], I never want to see one again!

Plastic and metal don't usually mix well. E.g., always plastic
*into* metal and not the other way around. Even that is no guarantee.

> [1] Rocol Threadseal XS - suitable for hot, cold and drinking plumbing and
> methane-gas plumbing, on any taper thread joint - don't know if you have it
> or something like it, but it is superb stuff.
>
>> Understood. It's been so long since I've used steam heat that
>> I forgot how easy it is to have "multiple zones" :<
>
> We think it's the state of the art here ;->

Yeah, well... we also have INDOOR PLUMBING on this side of the
pond! Fantastic invention! Makes going to the loo on a cold
winter day much more comfortable!

> Seriously - last house I lived in had one timer and stat in the hall for the
> whole house and that was only 15 years old. Building regulations now require
> I think 2 zones and thermostatic rad valves. hmm. advanced...

Here, I would wager most homes have single zone HVAC. Things
like forced air and hot water are expensive to route into
multiple zones. I don't think I have seen steam heat used
in many modern homes.

>> Even if you aren't at risk for hacks, consider the effects
>> "bad data" can have on operation.
>
> I was planning on lobbing a CRC in at least :) And framing the data. SLIP is
> quite a nice way, simple and reasonably bomb proof - used that a lot at my
> last job for binary data transmission over radio (well, the electronics
> geniuses did, I just had to understand it when it fell out of a TCP stream
> and process it on a linux box...)
>
>> I.e., what happens if
>> you erroneously turn the valve on? off? Think about
>> how each type of error can affect you. (e.g., timeouts
>> are often used).
>
> Indeed. I'm rather used to programming larger computers (PC vs embedded),
> but I find a lot of wisdom in higher level protocols can be borrowed,
> simplified and put to good use...

Yup. The problems most folks face when moving into an embedded
world are lack of resources (memory, MIPS, etc.), 24/7 operation
(rebooting is not an option) and "Gee, that CAN'T HAPPEN!?"

>> Once you've done *that* thinking, consider how *that*
>> scheme can fail. E.g., what happens if your valve turns
>> on, then times out and turns off, then (erroneously) turns
>> on again, etc. I.e., it may be better off if it "fails"
>> one way or the other -- I'm not saying this is the case
>> for a steam valve but, rather, consider this when you
>> think of other automation applications (garage door
>> set to automatically close after 5 minutes to safeguard
>> against a faulty "open" command; then opens shortly
>> after having closed; closes again 5 minutes later and
>> again reopens, etc.)
>
> Agreed. Even the boiler control can be fail safe - cycle it at a reasonable
> periodicity and duty cycle. If all the valves are closed, boiler's internal
> stat will cut out (safely) and the water will just get pumped around the
> mandatory bypass loop so nothing lost.

But, *you* have to figure out what those times and duty
cycles are. Can't turn to a chart on page 47 for the answer.

>> The point was to allow the sensors and actuators to be simple,
>> inexpensive and "pot-able". Once you remove the human user
>> from the equation, you can more readily achieve these goals.
>
> Simple and modular is good. It's likely that the human bit will have a
> 240x128 or similar LCD dotmatrix display (cheap and usable) and a few
> buttons, or a touch panel. Running that *and* doing comms *and* doing
> control logic is probably inviting bugs. Of course it's doable, but making
> everything basically one IO blob on one side and a comms link on the other
> is probably more rational.

I'm looking into repurposing some "digital photo frames" for
wall mounted displays (they tend to use far less power than
regular LCD monitors -- also much more appropriate sizes!).

Even there, I plan them to just be simple "display devices".
I.e., all the smarts reside in the server and this is just
a "terminal" -- much the same way that the sensor nodes are
just "input devices" and the actuator nodes are "output devices".

This helps keep the displays inexpensive, lets me power them
down when not being used, makes support for multiple "user
interfaces" an inherent part of the design, etc.

> The one *must have* would be the ability to reload the firmware over the
> comms link, be it radio or wire. If the code is small enough that I can have
> 2 code bases in flash and an invariant boot section that should be possible
> and fairly bullet proof.

That's reasonably easy to do with today's parts.

>> <grin> Been there, done that, have the T-shirt to prove it.
>> Tedious though rewarding experience!
>
> Fun when something works and/or doesn't blow up/fall off ;->

Yeah, as Buckaroo Bonzai would say: "Don't tug on that -- you
don't know what it's connected to!"
First  |  Prev  | 
Pages: 1 2 3
Prev: Low Rds(on) tempco
Next: Termination of AC coupled 100MHz clok to generate low jitter 50MHz clock?