ucontrollers (AVR/ATMega) and radio transceiver modules

On 25 Jan, 10:22, Tim Watts wrote: I fancy having a play with some radio datalinks (with a view to home automation) - but there seem to be a million modules and a fair number of frequencies and standards. I'm just after some pointers based off some simple requirements:

How bothered are you about power consumption? Can you use mains signalling or just lay cable?

If you decide to go for basic modules without complex modulation methods and software stacks, then there are three main types to consider:

1) On-off (amplitude) keying

2) Frequency shift keying - wideband

3) Frequency shift keying - narrowband

The range and cost increase in the order 1 -> 3.

For the same transmitter power, receiver sensitivity and receiver bandwidth lower frequencies will generally give longer range than higher, mostly because the lower frequency receiver antenna (of equivalent directivity) will capture more of the incident power . However, higher frequencies will make it easier to use directional antennae as they will be smaller. High frequencies diffract round corners better, while low frequencies go through walls better.

I have successfully used the GT1 25mW transmitter and GR1 superhet receiver modules available from several UK suppliers over a range of about 2km in open air with a well-matched dipole antenna at each end. I picked a frequency of 434.225 MHz because it is relatively quiet in my area.

Another approach to getting long range is to take advantage of the UK

0.5W band at around 868 MHz, but the modules are more expensive than the lower power ones.

There are some very easy-to-use single-chip Manchester coder/decoders available for use with FSK modules - RF600 and RF800.

Have a look at Radiometrix, Low Power Radio Solutions, MK Consultants web sites. And of course the Ofcom website for frequency allocations and other rules such as permitted power levels and duty cycle limits. In particular, look for frequencies which are allowed in the UK but not in the rest of Europe. These will generally be much quieter than those which can be used in any European country.

If you do decide to go for Zigbee, Farnell sell reasonably priced Zigbee modules, but the development tools are quite expensive.

John

On Mon, 25 Jan 2010 03:17:50 -0800, John Walliker wibbled:

Hi John,

Thanks for the reply.

Cabling: Well, I will have a wired DC SELV supply to avoid falling foul of the IEE Wiring Regulations if I want to deploy any of these in "Special Locations" like bathrooms. So current consumption will not an issue there, but obviously, this rules out mains signalling.

I had considered dropping cables round and using a bastardised CAN bus or RS485 drops or something, but radio would be cool for a number of reasons, including the education factor. If it's cheap enough it may be cost comparable with a cabled method (bearing in mind cables, terminations, junction boxes etc). Also means I can extend the system to outside use.

I've never been any good with analogue stuff, but I do understand those terms.

OK.

That seems very impressive for the power (thinking how many milliwatts my WIFI runs at)

Ah - thanks - I didn't know powers like 0.5W were permissable.

Very interesting - just scanned the datasheet.

Just for starters, I really like the look of this one:

(easy-Radio 433-4MHz FM transceiver)

Probably about the level I'm looking for.

Good idea. Most manufacturers will be going for common frequencies in a common market - makes sense to try for a quieter band.

I'll have a look there next.

Many thanks John, lots of excellent pointers :)

Cheers

Tim

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

On Mon, 25 Jan 2010 12:52:11 +0000, Tim Watts wibbled:

Incidently, please excuse my ignorance: what would be a sufficient antenna for one of these? Bit of straight open ended wire, 1/4 wavelength (so 17cm or so for 433MHZ)? Or is it better to go for 1/2 wavelength if possible, or some sort of loop? Does it need to be precise for resonance purposes?

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

Looks nice and easy to use, but less transmitter power than some of the others.

The antennae on the page you posted a link to would be a good starting point. Remember that they need a ground plane or counterpoise of at least similar dimensions.

You could just use a 1/4-wave length of wire. Tuning is not terribly critical for a 1/4-wave monopole, but you could monitor the RSSI output of the receiver while adjusting the wire length by about +/-

20% in an uncluttered environment (such as outdoors). Loops need to be tuned quite carefully. Helical antennae are shorter, but tend to be less efficient and need more accurate tuning.

For the long range link I was experimenting with, I used home-made resonant sleeve dipoles at each end, made by applying adhesive copper tape to plastic conduit with the coax down the middle. The tuning was done with the help of a vector network analyzer and the antenna was about 3m above ground at one end and about 2m above ground at the other. I'll check my GPS data later to see what the maximum range was.

As a general rule, unless you need to make a directional antenna, a

1/4-wave monopole or a properly balanced 1/2-wave dipole will give the best and most consistent results compared with most other structures. If you need smaller size there is always a compromise between efficiency, size and bandwidth (the narrower the bandwidth the harder it is to keep the antenna optimally tuned in a varying environment).

John

The guys over at comp.arch.embedded may also have some thoughts. I added that group as a cross-post, with follow-ups directed to the original group at s.e.d.

Have a look over at

and for an idea of what's available. For one-off, the simplicity of throwing on an XBee module is hard to beat (and it meets your price point) but there are several other choices.

Cost increases with data rate and complexity, so you'll have to make the decision as to where your comfort zone is.

--
Rich Webb     Norfolk, VA

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

On Mon, 25 Jan 2010 08:42:14 -0500, Rich Webb wibbled:

Thanks - I'll check that group out too :)

Wow - some of those Xbee modules look exceedingly cool.

Indeed. Data rate per device isn't likely to be high, but given many devices, the net bandwidth and wasted bandwidth due to collisions is a consideration...

Many thanks for your pointers Rich :)

Cheers

Tim

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

On Mon, 25 Jan 2010 05:49:09 -0800, John Walliker wibbled:

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 Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

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

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

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

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 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*! We had been remodeling at the time so installing the extra cabling only carried the cost of the cable itself (plus the terminations thereto).

On Mon, 25 Jan 2010 16:47:50 -0700, D Yuniskis wibbled:

This is true.

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.

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.

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

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

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)

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

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

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

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

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

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

Good Luck!

--don

D Yuniskis wibbled on Tuesday 26 January 2010 02:04

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.

[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 successfully done that (around 5W heating required IIRC) and the parts are cheaper. Also allows for full manual override (turn the knob).

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

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.

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

I like your approach :)

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.

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.

That's a nice idea. If I opt for cheap enough RF transceivers and given AVRs are dirt cheap, that would be quite sensible.

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

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

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

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.

Gee, I wonder why?? :>

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

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

It made sense at the time ;-)

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

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

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.

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

--don

D Yuniskis wibbled on Tuesday 26 January 2010 22:42

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

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.

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!

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

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

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

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.

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.

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.

Fun when something works and/or doesn't blow up/fall off ;->

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

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

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

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.

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.

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!

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.

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

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.

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.

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

Yeah, as Buckaroo Bonzai would say: "Don't tug on that -- you don't know what it's connected to!"

Charlie E. wibbled on Wednesday 27 January 2010 02:23

240V mate, in Blighty here...

I know (unless the ELV ( Even if it is the 24VAC, you are going to couple to it with any

Accepted. Most of my backbox drops (this is plaster on solid brick walls, no sheetrock except upstairs) have 2 x 16mm uPVC oval conduit, so at least the antenna can go up the other one and be > 1" away.

One or two ended up with 1x 20mm round uPVC tube for logistical reasons (too much random wood in the ceiling area over the box) - just have to suck that and see...

If I got desperate enough, I could always score a fine channel in the plaster and bury a couple of antenna wires in the wall surface next to the unit - not sure how well that would work...

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

D Yuniskis wibbled on Wednesday 27 January 2010 05:54

Wise words - I like that principle.

There is some confusion. I never said steam - someone else did ;->

No-one uses steam here expect as a primary distribution round a large site (eg Hospital, University) and even then it's converted down to HW by local calorifiers.

Nope - just plain old water at around 160F. My Building Inspector just about accepted I would be testing my own electrical work with the correct instrument and filling in the correct forms for him; he had a mild stroke when he saw I'd declared gas work on the Building (works) Notice (he agreed it *was* legal for me to do my own (but illegal for me to do it for others for pay - need to be registered for that), but they'd never had anyone ever bother to tell them before). I'd imagine he'd have a full on coronary if I mentioned steam heating ;->

Hope you saw that as tongue in cheek ;->

;->

My great aunt had an outside bog. It was grim in winter...

Some use air here. I'd have a problem - so much wood under the floor upstairs due to a previous roof room conversion, it's very hard for me to even route one 4" extract duct for the bathroom...

That's a very cool idea - I like that.

And when you have 5 identical copper pipes coming up from the boiler, be sure you know which one is gas before wielding the pipe cutter ;->

--
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

Ah, my apologies!

Wow! And you have individual control over each (baseboard) radiator? Someone spent a wee bit extra on all that bypass pipe! Usually, all radiators are in a single loop (you have a "loop per room"?)

Yeah, that sort of thing is *almost* fine when you're a kid "away at camp". I can recall experiences on a *frozen* lake! But, I much prefer to be 25C when I crap! :>

Many houses here don't employ return ducts. Just supply. (wonky system).

I like X Terminals. The idea grew out of that. The software lets me draw on displays (from the server) wherever they may be.

Yikes! Gas in copper? We use "black pipe" (similar to galvanized pipe) for gas. Copper *prefered* for potable water (though I have see PVC and other wonky things used -- poorly!