Radio Days

Some Thoughts about Low Cost Wireless Networks

This is the first of a few posts looking at short range wireless devices. I've experimented with these for a few years and believe that there is a requirement for a really low cost transceiver which allows smart sensors to communicate with each other. In the first of these posts I will look at simple super-regenerative receivers which I have encountered already by pulling apart devices such as wireless doorbells. These can be quickly re-purposed by adding your own microcontroller, which is what I did with the Lidl remote control socket.

Compared to WiFi and other 2.4GHz systems the 433MHz link is cheap and tacky, but it serves its purpose adequately. It offers a very low cost means for devices to get small amounts of data across a wireless link. It is used often in wireless doorbells, remote control systems and burglar alarm systems.

The Lidl remote socket used an example of a super-regenerative receiver and my transmitter pcb uses a SAW stabilised single transistor amplitude modulated (On/Off keyed) transmitter from Telecontrolli. The link runs at a pedestrian 1200 baud - it's best to always pick a standard baudrate to make it easy to debug with hyperterminal. 1200 baud is perfectly adequate for sending a few relay commands and temperature readings around the house.

Super-regenerative receivers are designed to be very cheap - but they can lack in sensitivity. They use a technique discovered in the 1920s by Edwin Armstrong, when manufacturers wanted a cheap wireless that only used one valve. Here's some Wikipedia info for those interested in early super-regenerative sets

http://en.wikipedia.org/wiki/Regenerative_circuit

Today this has translated into one active RF transistor but the principle is the same. A super-regenerative receiver is small and cheap to make often using less than 30 components.

The transistor is configured to be a 433MHz RF oscillator and is biassed up so that it is just on the point of oscillation. It is swept through this oscillation point using a lower frequency of a few tens of kHz. Any incoming RF signal will add to the RF transistors desire to oscillate, and this appears as a change in collector current. An op amp or a chain of 3 cascaded transistors is usually used to detect this change in current, and turn it into a logic level pulse which follows the detected signal exactly. The result is a signal that you can feed into a micros input pin and begin to decode the serial bits.

The super-regenerative receiver has at its heart an RF oscillator. In the 1920s super regen receivers could re-radiate and produce a lot of interference picked up by neighbouring sets. This might be seen as a disadvantage - but its not a million miles from what you need to automatically transmit a packet of serial data. In fact some cheap super-regens emit so much RF carrier that they can cause other signals to be blocked. When not receiving, this RF oscillator could be re-purposed to be a low power transmitter. In theory you could have a whole 433MHz transceiver costing about $1 to implement. This would be a really scungy transciever with only about 10m of range - but if you are using it in a network with other sensors which can retransmit messages, then in theory you could bounce your packet across a series of nodes and thus get to the gateway as a series of short range hops.

Super-regen designs are compact. With only one or two active components and 25 or so passives, they can fit onto a board the size of a postage stamp. They can also work at very low power - just a few microamps. There's a great patent for a super-regen by Thomas E. McEwan for a receiver that works down to 1 volt supply and 1uA of current

http://www.freepatentsonline.com/5630216.html

This makes it ideal for battery powered sensors which have to work for years from a single cell - or power harvest, from mechanical vibrations for example.

I had a go at copying the McEwan design - it worked to a point and had a range of about 3m when using a standard doorbell push as the transmitter. I suspect that it was working more as a crystal set than a super-regen though.

There is an renaissance in Super-regen designs as they can be implemented in silicon within the actual chip. This makes them ideal for say 2.4GHz bands where the antennas a much smaller. Such devices could be used as RF transponders for RF ID devices. They could possibly even harvest their operating power from the RF energy they receive - stored in a super-capacitor.

Super regenerative receivers are used in wireless doorbells, thermometers, remote control toys and other short range wireless gadgets. The photos show a commercial Laipac super-regenerative module and two doorbells - one in discrete through-hole components and the other in surface mount. These discrete designs will work at currents down to about 300uA.

The Laipac design is documented on the web and uses 2 transistors and an LM358 op-amp comparator device. The older doorbell achieves the receiver in just 3 transistors, and the newer doorbell does it with four. All low cost super-regens generally use a fixed capacitor and slugcore-tuneable inductor to get close to the required frequency. The inductor is clearly visible as the red plastic component on the back of the Laipac design.

Super regenerative receivers are also very easy to hack - in fact I first hacked one from a wireless doorbell I bought in Wilkinsons for under a fiver. You just have to find the serial output data - which is easy if you have a scope, or at a pinch a logic probe. Just connect this to your micro and start coding.

There's a well informed article about super regenerative receivers by Dr. Eddy Insam - well worth a read if you want to pursue them further

http://www.eix.co.uk/Articles/Radio/Welcome.htm

Eddie Insam talks about combining a super regen detector with a SAW stabilised transmitter device to make a cheap transponder or transceiver, but gives no detail away. He also mentions hacking a SAW stabilised transmitter module to make it into the heart of a super-regenerative receiver - tricky, but do-able, he says - I wish he would share some of that detail.

Over the next couple of posts I will share some of my recent findings.

Take Control

For some time I've wanted to tinker around with using the internet as a means of monitoring and control.

There's an appreciation that the growth in internet applications will likely be for internet connected devices - The Internet of Things, Web 2.0, or in sci-fi speak "The Rise of the Machines". Whilst not quite in Terminator league, I thought I'd get an internet dev board from Microchip and see what I could cook up.

The first step was to connect it up to a low power wireless transmitter, so that it could extend the scope of its control, beyond the confines of its own pcb.

I'm fascinated by minimalist solutions, and also hacking old gadgets to improve their performance or functionality. I like the idea of a network of very low cost wireless sensors scattered around the house, such as temperature sensors in every room linked to motorised radiator valves - all of which can be monitored and controlled remotely via the internet.

The key thing is that the sensors can talk to each other - regardless of the type of microcontroller make or model. So they need a standard serial communications protocol that they all can generate and decode. This protocol needs to have a low overhead to run on the smallest of micros with limited on chip resources and simple to hack and debug - more on this later.

I've coined the term "CheaperNet" to describe this network of low cost sensors, and so to get me started, I first needed a low cost candidate to be the first CheaperNet application.

There's a Homecamp Christmas party coming up soon, with talk of internet connected Chrismas lights - so I thought I'd hack together an internet controlled mains switch by way of a demo for a "show and tell" session to illustrate some of the virtues of CheaperNet.

This involves several stages of connectivity. Firstly using the PIC dev board which hosts a micro web server, using the free Microchip TCP/IP stack and the HTTP2 sever application that comes with it. This board acts as a kind of hub/gateway device onto the CheaperNet, and then radiating out from this hub is a a 433MHz wireless link to individual sensors. The first of these being the remote controlled mains socket. Plenty opportunities for a good hardware and firmware hack.

As stated, the PICDEM.Net dev board acts as a micro webserver. This is an almost "out of the box" solution requiring very little configuration to get you connected. The harder step would be to hack it to control a wireless link to a remote control socket which turns the electrical load on using a relay. Fortunately the PICDEM board has some LED outputs which can be turned on and off from the net, so if I could sense one of these I/O pins changing state and generate a wireless message to turn the remote relay on, it would be a simple enough hack.

The PICDEM board is a stupidly big board for what it does. All you really need is the £5 PIC in the middle and the ethernet connector. The little board below could also be dumped if you drive the 433MHz wireless transmitter straight off the I/O of the larger PIC.

The idea being that I can display my live electricity consumption in one browser window, and at the same time click on a button in another browser window that activates the Internet Socket turning something on - so that you can see almost immediately the effect on the live power trace.


A bit geekish perhaps - but worth a challenge. Good way to turn the Christmas lights on at the forthcoming Homecamp party.

The first thing to do was to salvage the old unreliable remote control socket that I purchased as a set of 4 from Lidls a few years ago.

These consist of a 433MHz super-regenerative receiver, a microcontroller and a mains relay all packaged in a plug in plastic case. Unfortunately, these suffer from any old 433MHz interference will cause them to turn on, or off, because of a very poor wireless protocol, which is readily confused by any other wireless devices nearby.

The solution was to implement a simple wireless protocol called SNAP at each end of the wireless link, and bodge a new microcontroller into the spare space in the plastic case. Probably the closest thing this cheapo Lidl switch has had to a brain transplant!

The existing Lidl microcontroller is dumped and replaced with one a little less stupid. The Lidl decoder was very prone to falsely switching when some other 433MHz transmissions - like the neighbours door bell started transmitting. I'm using a PIC16F88, solely because a have a few of them lying around the workroom and I have the beginnings of the SNAP wireless protocol already used on a past project


So after a few hours on Friday, I got the wireless protocol to work, and a few hours today got the unit together with new brain and a suitable wireless interface on my micro webserver dev board and voila I now have a desk lamp that can turned on and off from anywhere on the planet - or perhaps beyond.

This is a SnapRat board - just a PIC16F88 with a 433MHz wireless transmitter. I designed these a few years ago to make a solar powered wireless compost heap temperature monitor - definitely a world's first.

When you click on the 8th LED button on the web page, the micro on PICDEM board raises on of it's I/O pins (to light a real LED) I use the SnapRat board to monitor this and send a "relay-on" message to the receiver and PIC inside the remote socket. This turns the relay on - at a distance of about 20m indoors.

Some of the detail.

The PIC micro web server uses the Microchip TCP/IP stack. There are several dev boards which run this stack - such as those from Olimex or Celeritous.

I use a PIC16F88 to run the wireless protocol at both ends. The protocol is called SNAP (Scaleable Network Address Protocol) and details can be found on the High Tech Horizons site www.hth.com/snap/

I use a PIC implementation that is based on the published code by CASTRICINI & MARINANGELI - originally written for a PIC16F84. (See the HTH site). The whole protocol fits into about 850 words of ROM including the serial transmit and receive bit banging routines, error handling etc.

SNAP was designed to be a minimalist protocol to run on small micros. There are versions of it for BASIC Stamps and AVRs. Someone has bound to have hacked it onto an Arduino - if not - please would someone rise to this challenge.

If you want to see my firmware - leave me a comment.

Using an Arduino to monitor gas consumption

Energy monitoring is something I have been involved in for ten years - both professionally and "socially".

First a Historical Note - this formed the basis of my "off the cuff" talk, "Gas c.1999" at Homecamp 09.

Back in 1998, whilst working for a telecommunications equipment company we needed to develop a low cost gas datalogger for automatic meter reading (AMR) applications. It needed to read gas meter pulse counts from a Schlumberger meter and transfer them via short range wireless and good old fashioned PSTN telephone modem to a remote PC based server.

The wireless transmitter had to have a battery life of 10 years, running from an AA sized lithium thionyl chloride cell, and the low data-rate modem had to be self powered from the telephone line. That, plus the need to store gas meter readings every 6 minutes for 16 months made it quite a design challenge. Oh - and it has to be intrinsically safe to use in the hazardous zone around gas meter installations.

A two part product that featured a short range radio, a telephone network connection and had to meet the requirements of Ex intrinsically safe equipment meant that dealing with the various approval bodies was a major part of this product and not the actual engineering itself.

Technically the project was a success. Fine resolution gas meter data automatically retrieved from a number of trial sites. But at £40 a unit, it wasn't the low cost the utilities wanted - when they were only paying £5 a year for their small contract army of meter readers. The project was shelved in late 1999 - conveniently on my workshop shelf.

So now we have "Gas c. 2009" - the subject of a possible future Homecamp off the cuff presentation.

In the intervening decade, things have changed somewhat. Low power radio gadgets are now commonplace, and low cost energy monitors have been available for a few years now. (Electrisave, Owl, Wattson, CurrentCost etc). PSTN modems are well and truly a thing of the past, as broadband has all but taken over as the means of getting data out from low cost sensors.

In addition to these technical changes, several cultural changes have occurred in the last decade. Thanks to the efforts of a group of pioneering computer scientists working for IBM, Hursley - it's now cool to monitor your home energy usage , and the Homecamp unconferences have shown that I'm not the only one with an interest in energy monitoring - (and I thought that I was the only geek in the village. Of course it is a global village now - with a lot more residents).

Counting pulses from a gas meter became a whole lot easier when some meter manufacturers started to provide an opto-reflective silvered zero on the least significant digit of the register. Prior to this, there was a little red rotary pointer which was almost impossible to detect reliably via optical means - unless you were lucky enough to have a Schlumberger meter which came already fitted with an RJ11 connector and a reed-switch providing a "volts free" pulse output.

Technically, Transco, the gas transport company own everything up to and including your meter. If you want to measure the pulse output, they would provide a "Chatterbox" - a Ex certified relay box, which echoed the pulsed on to your own equipment. It was powered by 4 alkaline D cells. Transco would charge you a fixed cost of about £500 to come and install this unit. This proved an obvious deterrent for all but the most determined energy monitoring enthusiasts. This issue needs to be addressed if we are to make much headway in monitoring gas consumption. Nobody wants to pay £500 for a clunky old relay box that cost £20 to make. What is needed is a low cost, Ex certified, universal pulsecounter, which anyone can fit and geta pulse count from. Wireless seems the obvious choice - an opto sensor that sticks to the front face of the register and a self contained 433MHz transmitter running of a lithium cell. Essentially fit and forget.

The turning point for me came in November 2004, when my gas utility replaced my old meter with an Actaris, "pulse ready" meter. This had the opto-reflective silvered zero, ready provisioned to accept a photo reflective sensor. Sometime in Winter 2004, I put one of these together on a small scrap of veroboard, and then wrote a pulse counter routine in PIC assembler. However, come the spring, and a new extension to the house, and the whole project was forgotten and the pulse sensor lost.

So a couple of weeks ago - I decided to make another. I still had some of the photo-reflective IR sensors left. This time the coding would be a whole lot easier. In the intervening 5 years, I had learnt just sufficient C code to be dangerous - prompted by the arrival of the ubiquitous Arduino. The timing was right an announcement of a forthcoming Homecamp in about a month, meant that I had to pull my finger out and get hacking.

Here's the photo-sensor on a small scrap of veroboard - pushed onto a couple of locating pegs conveniently provided by Actaris.

The 4 wires are 5V supply, LED supply, photo transistor output and ground. I use an additional NPN transistor to buffer the voltage output and give me a bit more gain and sensitivity. Connect this into an Arduino ADC input and start sensing digits.

So the first thing I did was write a simple ADC routine which prints the ADC value to the serial port once per second so that I could see what was coming out of the sensor. This I captured in hyperterminal (aargh) and plotted out in XL - shown below. From this I could see that there was a very characteristic voltage pulse produced when the zero went past the sensor - but additionally all of the other digits had their own signature too - so with a bit of coding I could sense to the nearest litre.

A few lines of Arduino code, I had the pulse counter running, outputting the pulse count every second along with an (approximate) H:M:S timestamp. Having let this run overnight and during the time that the boiler fires for the water heating and central heating I had 60,000 readings which could be chopped into manageable chunks and graphed in XL. However this is such a tedious way of processing data so I thought I'd try something a bit more sophisticated.

I'd had recently acquired a CurrentCost CC128, and subsequently had been using Dale Lane's CurrentCost GUI for capturing the output of the CC. Why not write a sketch for the Arduino that mimics the CC XML data format, and then squirt this into Dale's GUI? Excellent idea and about 30 minutes of hacking the XML as a serias of serial print statements (thanks to CurrentCost for making their XML output format freely available on the Web) I soon had the Arduino interloping as a gas monitoring CurrentCost.

Individually, Pulse counts can be unspeakably dull. It's only when you get two of them, which are different, and separated by a suitable time period, that they become remotely interesting. If you take a reading at the same time each day, for example, and subtract them, then you get your daily consumption. If you shorten the sampling period from 24 hours to 1 hour, you can get a much finer resolution of when your boiler fires and how much it uses. You then extend this a bit further and start taking readings every 6 minutes and the picture becomes a lot more interesting. With 6 minute resolution you can see when the gas is being used, and by logging room temperature and external temperatures on other channels, you can start to see how quickly your house warms up, for a given outside temperature as a function of the gas you burn. Every house will have it's own thermal lag characteristic and once you optimise for this you will start to use it to your advantage and make reductions to your gas consumption - well that's the plan.

Real time boiler logging is a useful tool for diagnosing the defects of an existing system. In 2005 I made the poor choice of buying a 24kW condensing boiler. Had I bought a 12kW, it would have been more than adequate for my property and spend less time idling and modulating down to a lower power output. As with over powerful, fuel guzzling V8 cars - big is not always best.

Here's the first plot I got from Dale Lane's GUI showing the boiler modulating down as the return water temperature starts to heat up. The horizontal scale is 20 minutes and the vertical scale is from 8kW to 20kW.

Each pulse on my meter is the passing of 10 litres of gas. Gas is about 39MJ/m3 so by dividing 390,000 by the time between consecutive pulses, you get the instantaneous boiler power in kilowatts. Flat out, it takes about 16 seconds between pulses for my boiler - so I can deduce that it's consuming gas at about 24.4kW

Possible extensions: I have a couple of 10K pipe clip thermistors I got from Rapid Electronics. I'll use some of the spare Arduino ADC inputs to measure these and the internal and external temperatures.

I use a 433MHz Drayton Digistat to control the boiler. Having already cracked the "boiler on " and "boiler off" wireless packets using a PIC, I can get the Arduino to control the boiler.

Write a 3 term PID controller to control the boiler temperature - one that avoids massive overshoot, and consequent waste of gas.

I'm also currently hacking a "cheapernet gateway". This is an attempt at a very low cost ethernet gateway not dissimilar to an Arduino ethernet shield which will allow low cost wireless sensors to connect to the net and provide the means for realtime, live energy monitoring. Real time means once per second data (OPS) with a 2 second delay caused by the interweb thingy.