Goal

To build a general purpose RF receiver module which receives messages from a 433 Mhz wireless link (for example from my self built RF sensor) and forward the received and decoded message to my Linux server via USB, where they are further processed.

Scope

• A AM-RRQ3-433 from RF-solutions is used to receive raw signals from the 433Mhz RF channel
• For the USB interface, I’ll be FTDI’s TTL-to-USB cable, which is a ready-to-use solution for briding 5V TTL signals to RS232 emulation over USB. This enables the microcontroller talk directly to the linux box without any additional components. The linux kernel supports the FTDI chip, so it works out of the box. When this cable is plugged in, the RS232 port is reachable via /dev/ttyUSB0.
• This cable also provides also a 5 Volt power source which will be used to power the entire receiver module.
• For debugging purposes and possible other future features, the receiver module will be able to write to a HD44780 compatible display (I’ll be using the EAW162B-N3LW) which is attached using a 14 channel flat cable
• A potentiometer is used to provide a configurable reference voltage for the purpose of noice filtering.
• For the main processor, a PIC16F690 microcontroller will be used, which has a built-in crystal/clock and enough pins to support all interfaces described above.
• For re-programming the firmware of the microcontroller without needing to remove the chip from the board, I’ll be using ICSP (In-Circuit Serial Programming)

Protocol

All messages which this receiver module should be able to receive are encoded in my own RF protocol. This protocol is a kind of Ethernet protocol, it contains a destination address field, a source address field a message length and a checksum field. This protocol does not say anything about the kind of content which it carries. The syntax looks as follows:

When transmitted over RF; the message is encoded using Manchester encoding which is a self-clocking signal where each bit is actually sent using two bits. The length of a low-level bit is 0.5 ms which means that each logical bit takes 1 ms to transmit. At the beginning of each message, there is a start bit sent with the value of HIGH for 0.5ms.

Understanding the raw RF signal

The hardest part of this project was to translate the raw signal, which the AM-RRQ3-433 provides, to a usable message and disregard any noice and foreign signals.

The main idea here is that the RSSI port of the AM-RRQ3-433 module is used directly as a signal source (instead of the DATA-OUT port). The RSSI port is an analog port which provides both signal strength information and the information in the signal itself, whereas the DATA-OUT port is a digital port and only provides the digital signal received via RF. The DATA-OUT port will raise to HIGH (=5V) on the slightest noice on the RF channel, while the RSSI port will output a voltage which tells us about how strong the receive signal actually is. So by measuring the output voltage of the RSSI port using AD (analog-digital conversion), it is possible to both receive the signal itself and also the strength of this signal.

So when the microcontroller is receiving a signal from the RF module, a configurable reference voltage provides the minimum required voltage (signal strength) which the RSSI port has to output in order for the microcontroller to recognize this as a HIGH (1). Any voltages which the RSSI port outputs which are below this configurable reference voltage are seen as a LOW (0) by the microcontroller.

The next step after this noice filtering is to translate the received HIGH’s and LOW’s into a understandable message. In the attached source code, I’ve implemented a decoder for manchester encoding which is based on the finite-state-machine concept. A state machine is ideal to keep track of the current received bit and to determine which is the next expected next bit. As soon as a mismatch is found, a bit lasts too long (timeout case) or the max message length is exceeded, the state machine goes into error state and further reading is given up.

When the state-machine was able to decode an entire message, the next step is to calculate a CRC16 checksum over the entire message (all fields, except the CRC16 fields) and compare this value to the CRC16 fields in the message (The code I use to calculate the CRC16 checksum is from this website). If the CRC16 values are the same, the next step is to determine whether this messages was intended for this receiver at all. This is done by comparing the destination address in the message against a locally hardcoded address.

In case the destination address matches, the message is then forwarded over the RS232 interface to the linux box. This is done by simply sending the message over a digital output port (port RB5, see below) of the microcontroller which is connected to the TTL-to-USB cable.

The hardware

All components will be placed on a PCB board which is placed in a plastic container with an antenna on top. Here is the schematic of the board:

On the left side is the RF module (AM-RRQ3-433). The R1 is a 10KOhm potentiometer for configuring the RSSI reference voltage. U1 is the PIC16F690 microcontroller. In the right upper corner you find a 7×2 flat cable connector which is the connection to the display. Below is the TTL-to-USB cable connector and in the right bottom corner is the ICSP connector.

Since I wanted to fit the board into a 59mm x 59mm box, I was forced to use a double layered PCB board. The bottom layer looks as follows:

And the upper layer:

The component at the top is the 2×7 flat cable connector. The long vertical component to the right is the RF module (AM-RRQ3-433). The the PIC is in the middle and below it is the potentiometer. The 6 pin connector in the left bottom corner is the TTL-to-USB cable connector and the 6 pin connector in the right bottom corner is the ICSP connector. All other holes are vias which connect the bottom layer to the upper layer.

I developed the PCB using the same method as explained on my previous blog entry with the additional feature of adding an aligned upper layer. After four attempts, I finally managed to developed a double sided board which works:

More pictures

The antenna which I use is: ANT-433-PW-QW-ND.

Downloads

In case you want to build something like this yourself, here are all my project files, including the source for the program on the microcontroller. I developed this using the Microchip MPLAB IDE.

• The binary executable for the PIC16F690 microcontroller: rf_receiver-v1.hex
• The assembly source code: rf_receiver_source-v1.rar
• The eagle project files: RF_receiver_eagle_files-v1.rar

Can you guess which picture was taken where?

There are many different ways to fabricate you own PCB’s at home, the method I choose was to use photo-resist laminate since that way I could use my inkjet printer and didn’t have to buy a laser printer (for the toner-transfer method). The basic idea is that the board is covered with a thin film of a photosensitive layer, which prevents the etching solution to reach the copper. By exposing this thin film of photosensitive layer with UV light and developing it afterwards, the photoresist layer is removed everywhere where the copper is not supposed to be. I’ll show you how it’s done in more detail now.

Building a UV Lamp

First a UV lamp is needed. Instead of buying a rather expensive professional UV exposure box, I built my own using UV LEDs. I ordered some cheap LEDs from ebay which have a wavelength of about 400nm, a strength of 7000mcd, voltage drop of 3.4V and which require a current of 20mA. I arranged the LEDs is rows of 3 with a 100Ohm resistor such that I can use a 12V DC power supply. After soldering the LEDs in a 3 x 9 x 2 formation onto a prototype board, I mounted the lamp in a box as shown on the following pictures:

Result: a fully functional UV exposure box, which consumes about 0.39A @ 12V.

Printing the art work

Next step is to design and print the PCB layout. I used the wonderful program Eagle to do this. You can download my eagle project files (including all self created library files) at the button of this page. I sized the board in such a manner that it will fit into a plastic case which I have (see below). The final result is:

For the PCB to be a good as possible, it is crucial that your print is of good quality and has nice smooth lines. To achieve this, I exported the board layout from eagle using 1200 DPI and set the print quality to best. Then I used photoshop to actually print the file onto the transparent film (I used Transparency Film from Pelikan for my standard HP inkjet printer) because it provides the possibility to print additional orientation marks. I used those orientation marks to align two prints on top of each other, to create an even thinker layer of black, which is supposed to stop the UV light from getting to the board.

Preparing the laminate

Once the artwork is prepared and taped down onto a glass plate, I prepared the laminate; the actual boards. I measured the pieces and cut them out using my Dremel.

UV exposure

Now the development can begin. To bring the layout onto the  laminate, the blue protection foil is removed from the laminate and the piece is placed under the glass plate with the art worked taped onto. The UV exposure box goes on top such that the UV light hits the art work first and then the photoresist layer on the laminate. Exposure time is about six minutes.

Once done, the exposed board is placed in a chemical solution (a photo resist developer) to remove the photoresist layer at those places where we don’t want any copper to be. The result looks like this.

The darker layer on top of the copper is the photoresist layer which will prevent the etching solution to reach the copper (and thus doesn’t get etched away).

Etching the board

The final step of making our PCB is to etch the copper which we don’t want away. The board is placed in a etching solution (natrium persulfate) at about 40 degrees for about 20 minutes or so. Once done, I drilled the holes using my Dremel and removed the remaining photoresist layer with nail polish remover. The finished PCB result looks like this:

At last, I soldered all components onto the board and fitted the board into a small plastic housing, which it will live in. The temperature and humidity sensor are clued on the outside of the case, such that they are in contact with the air outside. The finished sensor looks like this:

Result

I installed two sensors outside at places where the sun doesn’t reach them both at the same time. Using rrdtool, the following graph was generated by combining the data from the two sensors (assuming the coldest temperature reading is the correct one):

Downloads

• Eagle project files v4

When designing and building this sensor, it was important to me to use cheap components, since I’ll be making at least 10 of them and spread them around the house. Another requirement was that the sensor should consume very little power, so that the battery would last for at least a year or so. A PIC micro-controller will be the brain of the sensor.

Wireless communication

First challenge to overcome was how to implement the wireless communication part. There are many different RF modules out there with different features. High end modules will handle the entire protocol including error correction and even encrypt the communication if you want, all you need is to write your message into the RAM memory of those modules and leave the rest to them. The XBee modules are such high end modules. Unfortunately, those modules are way too expensive for my project, so something cheaper was needed.

I decided to go for the 433Mhz band since this band has a large enough range to overcome in-door walls while still providing plenty of bandwidth for my relative small measurements. The transmitter module AM-RT4-433 and the receiver module AM-HRR3-433 from RF Solutions are most suitable for the job. They are relative inexpensive, but lack any kind of data encoding or error correction features. All this does is to either send HIGH or LOW (e.g. send nothing).

In order to be able to transmit any kind of data which is to be understood by the receiver, the bits needed to be encoded somehow (for example, how to transmit the value 11111111 when you only have HIGH and LOW? Send HIGH for x milliseconds?). Since there is only one communication channel (instead of two: one for data and one for the clock) and I didn’t want to worry about clock synchronization between the two end-points, I looked into using a so-called self-clocking signal. Manchester encoding is such an encoding algorithm; it provides both clock and content information at the same time.

But how to ensure reliability and error detection? At first, I wanted to use bi-directional communication in order to be able to send acknowledgements back to the sender, but this approach would also mean that the sender needs to be a receiver at the same time, which would have an unacceptable impact on power consumption (receiving data means you need to listen actively for incoming data). So the final strategy is to make the sensor a transmitter only, which simply sends it’s measurements at regular intervals. For error detected I decided to use CRC16.

The final protocol syntax which I was going to use looks like this. Each message (package) which is sent, consists of:

The receiver module (covered in this article) is able understand the self-clocking signal and check’s the CRC16 for error detection before passing it onwards for further processing. The result is very usable, inexpensive and low power consuming wireless data transmission. The disadvantage with this approach is that it lacks any kind of security. Anyone can capture the signals and even send fake values to the receiver. Once those signals are going to be used to control something like heating or ventilation, a more secure communication channel is needed to prevent anyone in the neighborhood from doing anything nasty.

Measuring temperature

For temperature measurements I decided to simply use a thermistor together with the PIC’s internal 10 bits ADC (analog-to-digital converter). This solution is very cheap and by using a suitable thermistor, it is still possible to achieve a pretty good resolution of more than 0.1 degrees Celcius.

I calculated that a 10KOhm thermistor is suitable for in-door temperatures and a 4.7KOhm thermistor would give me the best resolution for common outside temperatures where I live. I choose for the K164 series from epcos. My approach is that the PIC micro-controller will measure the resistance through the sensor and send this value to the central receiver unit for the actual calculation to degrees Celcuis.

Measuring humidity

Humidity was a different subject. Most sensors available are capacitive based, which means that you need to measure farads of the sensor. This can be done by generating a trial-angle wave signal (with the help of an op-amp) and measure the time it takes for the capacitive sensor to be charged.

A much simpler approach however is to use a resistive based sensor, which has the same approach as the thermistor sensor (measuring the resistance through the sensor). After a long search, I finally found such a sensor which fitted my budget, the H25K5A. The datasheet contains a lookup table to calculate the relative humidity at a given temperature. I decided it would be easiest to just send the raw ADC values (e.g. the measured resistance of the sensor) to the central RF receiver unit and calculate the relative humidity value using this table there.

Schematic

The following image shows the sensor schematic which I’ll be using.

B57164-K164 is the thermistor which I used and R1 is the voltage devider resistor, which has the same value as the thermistor. By letting the PIC control the current flow through the sensor here as well, power can be saved during sleep mode.

H25K5A is the humidity sensor and R3 is the voltage divider resistor for which I found 220KOhm to be most suitable for in-door temperatures. Q1 is a N-channel MOSFET of type 2N7000 which is used to switch the humidity sensor “on” and “off”. Why? Since the goal is to consume as little as possible power, there should be no current flowing through the sensor when the PIC micro-controller is in sleep mode. By using this MOSFET, current flow through the sensor is only enabled when the PIC is taking a measurement. R2 is a 10KOhm pull-down resistor.

C1 is a 100pF filter capacitor, U1 is a PIC16F690 micro controller and RT4-433.9RC is the wireless transmitter module.

Battery & Power consumption

The basic idea is that the PIC micro-controller will sleep for most of the time and only wake for a fraction of a second to take the two measurements and transmit the results via the RF module, before going back to sleep again. The power consumption during the sleep mode turns out to be very low: 1.2 micro Ampere @ 3.2V = 3,84 micro Watt. This allows the usage of a small cell batter of type: CR2032. This battery should last for 20 years if the micro-controller would only be in sleep-mode. However, given the short moment of activity for taking a measurement (and thus more power consumption), the actual life-time will be somewhat shorter. I configured the sleep time to be 16 seconds. This way, three out of four measurements can be missed by the receiver and I still have one measurement per minute.

The software

You can download my assembly code for the pic micro controller here:

• rf_sensor v0.1

config.inc contains some configuration settings. crc16.asm contains the sub routine for calculating the CRC16 checksum. rf_protocol_tx.asm contains the code to transmit a message wireless. display.asm and math.asm are included but not used; they can be used to display measurements on a HD44780 compatible display connected to the PIC. A compiled binary rf_sensor.hex is included in the archive. To compile the code yourself, I recommend using Microchip MPLAB IDE.

The sensor on action

The sensor components placed on a breadboard for testing:

The green item on the left is the RF transmitter module. The white plastic sensor between the RF module and the battery is the humidity sensor. The temperature sensor is the gray component which sticks out above the black PIC micro-controller.

The receiver unit (covered in this article) is connected to my home server where a small perl script converts the raw values into degrees Celcius and relative humidity and stores those values into a database using rrdtool. The first image shows the humidity in the bath room (watch the humidity raise as someone is using the shower):

What’s next

The next step is to design a neat PCB and select a small enclosure and fabricate 10 of those sensors, which I can place around the house and outside. But this will have to wait for the next blog post.

Instead of buying a finished product, you might be interested in building your own IR Thermometer instead. This way, you can learn how it works and you are able to design it exactly the way you want it to be. For example, how about building wireless sensors which transmit data to a central receiver unit?

In this article, I’ll show you the basics. Components which I’ll be using for this are:

• IR temperature sensor: I’ll be using the MLX90614 (this version to be precise). It has a range from -70 up to +380 C and a resolution of 0.02 C.
• Microcontroller: I’ll be using a 8-bit microcontroller from Microchip: PIC16F690, but the program included in this article can easily be ported to any other 8bit microcontroller.
• Display: You can use any HD44780 compatible display; I’ll be using the EAW162B-N3LW

You will also need a programmer (I recommend using the PICKit2) to write your program into the micro-controller and an oscilloscope might came in handy for analyzing and debugging. For source code development, I used the Microchip MPLAB IDE, which you only need if you want to compile your own binary.

The test setup

To test the sensor and the assembly code, I use the following setup. A 9V battery is used for the power supply and the 78L05 voltage regulator converts this to a 5V power rail. If you rather want to use a 5V supply directly, you can of course skip the regulator. For the pull-up resistors R1 and R2 I choose 10KOhm. R3 is a 10KOhm potentiometer which is used to regulate the display contrast. R4 is needed for the LED background light built into the LCD display planet. You should check the datasheet of your display for the correct value. C1 and C2 are for filtering and have a value of 100nF.

(Please note that the display module shown in the drawing is not the same one which I used for my setup)

Reading the temperature from the sensor

The IR sensor, which is a digital sensor with it’s own microcontroller on board, provides two temperature readings: A) the sensors own (body) temperature and B) the object-in-sight temperature, measured using infra-red. For this project, I’ll be reading and showing both values.

The sensor (when not in sleep mode) will constantly measure the current temperature and store the result into it’s own internal memory. The already calibrated and ready to use temperature measurements can then be fetched from the sensor’s memory using the SMBus protocol. Using the sensor’s documentation and my oscilloscope, I developed the assembly code needed to read the measurements from the sensor. The source-code for this is provided below and is located in the smbus.asm module.

Converting the data to degrees Celcius

In order to convert the temperature values received from the sensor to degrees celcius, the raw value has to be multiplied by 0.02 according to the documentation. The result is the temperature in degrees Kelvin with two decimal precision. Substract 273.15 from that and you have the temperature in degrees celcius. To do this calculation on the microcontroller, I first subtract 27315 (273.15 x 100) from the raw value and then divided the result by 100. This way, I don’t have to worry about the comma until the very last step. The code for this conversion can be found in main.asm. The code makes use of this excellent assembly math library.

Showing the result

I first sent the readings via the serial port (using rs232) to my PC, but I quickly realized that using this method doesn’t really promote the idea of making a portable thermometer. So I replaced the rs232 output with an LCD display (HD44780 based) instead. Both the rs232 code and the LCD code is included in the source-code package though and can be found in the rs232.asm and display.asm modules.

Main loop

Now, to see the thermometer in action, I created a tiny main loop in main.asm which clues together the above mentioned modules. It basically configures the microcontroller after power-on-reset and then goes into an infinitive loop performing: A) 1 second delay, B) read latest temperature from the sensor using the smbus.asm module, C) convert to degrees celcius and finally D) show the value on the display using display.asm module.

The source & binary

Download the source code and the binary hex file (compiled for the PIC16F690) here:

• ir_sensor-0.2.zip

Sensor in action:

www.youtube.com/watch?v=kinmQh4vWxQ