Issue 138 January 2002
An RF-Controlled Irrigation System

---

Start • Controller/Receiver • Encoder/Decoder • The Firmware • Time's Up • Sources & PDF

Controller/Receiver

If you’ve read my recent articles, it should come as no surprise that I used an Atmel AVR controller chip, the AT90S8535-8PC (40-pin DIP package), for this project. This device contains four 8-bit ports, eight 10-bit ADC channels, 8 KB of flash memory, and 512 bytes each of data EEPROM and RAM. Like most AVR devices, this one is easily serially programmable in-circuit. You may want to refer to my article, "My fAVRorite Family of Micros" (Circuit Cellar 133) for an overview of this family, along with the details of a free ISP programmer for these chips.

I must admit up front that I probably could have done this project with the smaller AT90S2313 by multiplexing some of the I/O pins and writing the program in assembly language. I decided it was more productive for me to spend the extra $6 (Can $) on the ’8535, whose larger flash memory would allow me to program in BASIC, using the BASCOM AVR compiler.

Figure 1 is a schematic of the controller/receiver. Let’s start by looking at the user interface. The user interface consists of a 4 × 20 LCD and four push buttons. The display is operated in the common 4-bit mode; in this case, because it saved some wiring, not because of a shortage of I/O pins.

(click here to enlarge)

Figure 1—The Atmel 8535 AVR controller is at the center of the action of the irrigation controller. An Abacom QMR1 receiver takes care of the wireless reception functions. The LCD operates in 4-bit mode.

The four push-button switches are individually strobed by port pins PC0–3 and sensed by the INT1 input of the ’8535. I hooked up the switches this way because I originally drove the LCD using the same four port C lines. I had been saving the ADC inputs of port A for future use, but later changed my mind and switched the LCD over to port A, leaving this switch circuit intact.

The four push-button switches operate this unit the same way that many small electronic devices work. There is a Menu button to scroll through several menus as well as a Select/Cursor button. The buttons are used to position the cursor within a time field for adjustment purposes or to select a particular value when finished changing it. Finally, there are plus sign and negative sign buttons used to increment or decrement the current parameter.

I chose to implement the real-time clock in the software. One reason I initially picked the ’8535 over the slightly less expensive ’8515 is because it includes a third timer, which may be driven by a 32,768-Hz watch crystal. I must say that my attempts to implement the RTC using this feature gave me some problems! Atmel’s datasheet for the ’8535 advises you to merely connect the 32,768-Hz watch crystal between the TOSC pins 1 and 2 with no capacitors to ground. [1]

When I did this, I could see a reasonable 32,768-Hz sine wave signal on either crystal pin with my oscilloscope using a 10× probe. I soon discovered, though, that my clock was losing about 1 min./h. After troubleshooting, I found that the crystal oscillator waveform contained serious glitches coinciding with LCD screen refreshes.

At that point, I was using the port pin adjacent to TOSC1 to drive the LCD ENABLE pin. Moving the LCD ENABLE pin over to port A eliminated the glitches, but the clock was still slow. This was odd because I could not see anything wrong with the crystal waveform with my oscilloscope, and the built-in frequency counter in the oscilloscope indicated that the frequency was "bang-on."

So next, I contacted Mark at MCS Electronics to see if he had run into the problem. He mentioned capacitors, which made me think that capacitance to ground was probably needed (contrary to the datasheet). It turns out that my oscilloscope was providing the necessary capacitance, but only when it was hooked up. Adding 22-pF capacitors to ground cured the problem, at least with the particular crystal I was using. However, for this project, I decided to play it safe and implement the RTC using Timer0 of the ’8535 clocked by the 4.194304-MHz crystal of the CPU, which works perfectly. A side effect of this was that I couldn’t use BASCOM’s intrinsic real-time clock function and instead had to write my own routine.

My pump draws about 10 A when running (much more when starting), so I chose a Potter & Brumfield T9AP5D52-12, which is inexpensive and rated for 20-A continuous current. A small 2N3904 transistor is all that is needed to handle the 200 mA that its coil requires. This sealed relay is small. I haven’t used it long enough to know how well it will hold up, so the jury is still out on this component choice.

The controller/receiver is powered by a 9-VDC adapter followed by a 78L05 regulator. The actual output of the adapter is closer to 12-V, and is enough to operate the relay coil. Photo 1 shows the controller in place in my family room.

The wireless part of the controller consists of an Abacom QMR1 receiver followed by a Holtek HT12D decoder chip. This receiver is one of the choices recommended for use with the AT-MT1 AM transmitter that I use. The datasheet that comes with the package (available soon on www.abacom-tech.com) calls the QMR1 a quasi-AM/FM receiver module. The datasheet doesn’t spell out if it also works with FM transmitters, but it sounds like it would.

In any AM transmitter/receiver link, one thing for certain is that the receiver will spit out a stream of noisy data during much of the time when its companion transmitter is not transmitting. The QMR1 is sensitive (RF sensitivity specification is –110 dBm) and it has no squelch circuitry to suppress spurious output signals arising from any RF interference that it might receive. With cell phone towers cropping up all over the countryside, even my rural home is probably not "RF-quiet" anymore. I definitely see lots of noise output from the QRM1 receiver module.

My intention is to emphasize the need for some form of error detection/ data formatting in any AM RF link. What I haven’t mentioned is that the circuitry in the receiver that recovers the data from the RF signal (called the data slicer) is choosy about the form of data modulation that it will accept.

For example, most data slicers work reliably only if there is a roughly even distribution of zeros and ones in the datastream, even within the short-term such as the time taken to send 1 byte of data. This means that you cannot, for example, just feed in the signal from a UART to an AM transmitter, and expect to hook up a UART to the receiver output.

Instead, Manchester encoding is generally used because it guarantees an equal number of zeros and ones in the datastream, regardless of the particular data being sent. Furthermore, it is good practice to send the same data several times and check that it matches when it comes out of the receiver. A final precaution could include some form of checksum or better still, a CRC byte in the data packet to further verify the integrity of the received data.

Another concern is the amount of time it takes the receiver to adjust itself to the strength of the incoming signal or wake up from an idle state if that feature is present in your receiver module. To allow for this, the transmitter must send out a short stream of known data, called a preamble, to allow the receiver to get ready for data reception, so to speak.

This is a lot tougher than your average RS-232 serial data link! There are many books that cover in depth the theory of reliable RF data communication; An Introduction to Low Power Radio by Peter Birnie and John Fairall is a good starting point for those of you starting out in this area. [2]