Category Archives: 16F1509

PIC talks UART on RF – 434 MHz

 

PIC talks RF – 434MHz Modules

Photo Sep 01, 12 52 05 PM

Overview

Occasionally you’ll run into a project that requires a remote control. Our last article on IR might suit the bill, but what if you don’t have direct line of sight, or you’re like me and wished all remote controls worked like your PS3 and were RF-based?! No more pointing a remote! Don’t let me get your hopes up though. The 434 MHz modules (or often called 433 MHz) are more like garage door openers than a PS3 remote control. Their short range and poor bandwidth limit their ability to simple controls. No “Hello World!” this time around although it’s definitely possible, this just isn’t the application. Francesco was determined to shut me down on my decision on dropping the “Hello World” to the LCD and declared there was absolutely no problem in using the Mikroelektronika code in previous articles to send our standard “Hello World” to the LCD; this is what I love about Francesco. These RF modules can be found on eBay for a couple bucks as well as the normal places such as SparkFun, etc.

So lets get down to it; is this product right for your application?

Pros:

Cheap
Drop-In module for UART applications
Easy interface
No licensing

In some applications you can have a small amount of unpaired communication that will out perform bluetooth because of the lower frequency.

Cons:

Noisy
Limited distance, 500 ft direct line of sight
Questionable legality in the US (see below for more details)
Low data bandwidth


 

The communication

The 434MHz modules work by shifting the output level of their carrier frequency based on a digital input. If the input to the transmitter is a binary level “0”, the RF output is reduced if the input is a level “1” the RF output is increased. This is called Amplitude Shift Keying. While we are using the modules with a carrier frequency of 434MHz (433.92 MHz) you can also find these in 315MHz and 915MHz flavors. Further discussion about how the data is transmitted and received within the module is beyond the scope of this article.

Modulation Techniques

 

Lets discuss legality: It should be known Francesco lives in ITU Region 1 and Charles lives in ITU Region 2. The ITU region is a boundary created by treaty that dictates the RF band plan. The band plan is a guide outlining what segments of the RF spectrum are used for what purposes. For instance: Aircraft radio-navigation follows directly after the FM broadcast bands in the US. Google is your friend if you want to learn more. In ITU region 1 these 434 MHz modules fall into an ISM (industrial, scientific, and medical) band which is basically a free-for-all zone for all sorts of wireless devices despite it’s named intention. It’s an under-regulated, noisy cesspool of small electronic devices that can transmit license free. In ITU region 2 these 434MHz modules sit in a 70cm amateur radio band. What does this mean for legality? Well in the US you have the FCC and Part 15 rules. I did some reading on the TI Application Report SWRA048–May 2005. According to this document if you keep your transmissions under -49.2 dBm you should be safe, however if you read further in this document it suggests in a control application you can radiate at about -25dBm EIRP and even sneak some more power if account for your duty cycle. That’s up to interpretation of the document and I would probably strongly recommend actually reading 47 CFR Part 15. Regardless of your output power you still can not cause interference with the band user! That means you can not interfere with any amateur radio uses. I have a ham license so in my test I’ll use my license because I do not know my EIRP and good luck finding it in the specs (even with no external antenna connected). Will you get in trouble if you live in the Americas using these modules? Probably not. I wouldn’t produce a product to be sold outside ITU Region 1 with these modules though.


 

The circuit

433-sch

 

In the first version of the 16F1509 application PORTB.7 was connected through directly to the “Data” pin of the transmitter; the Vcc is connected to a 5VDC power supply and ground to the negative side of the supply. Through testing I found that if I transmitted the data inverted I had better data reliability.

In the XC8 compiler that is accomplished by setting the SCKP bit in the BAUDCON register.


    BAUDCONbits.SCKP = 1;   //inverted TX

Because of the noise I tested this application strictly from microcontroller to PC to start with. I did this to evaluate the amount of noise. I found that these modules shouldn’t be your first choice for sending RS-232 data in a reliable manor. You can do this but I wouldn’t expect high data rates and it should be considered for control applications where handshaking and data integrity is confirmed and can be requested to be resent. A robust protocol would be needed. As shown below this is the output of the data being sent from the microcontroller to the transmitter, through the receiver and then because my terminal client didn’t have an inverted data option I added a 74LS04 inverter before the TTL to RS232 level converter.


The Code

The 16F1509 Transmitting PIC code: uart_xmit_w_parity.c

After successfully exploring the transmission side of the project I decided it wouldn’t be much fun if we didn’t give the readers a building block of a control system. Using a PIC 18F26K22 demo board that came with an LED (ease of troubleshooting) I quickly wrote a program that would first check for framing errors, then UART overruns, then finally confirm parity.


            if (RCSTA1bits.FERR) {  // Frame Error, next read will reset
                uart_data = NULL;
            }

            if (RCSTA1bits.OERR) {  // Overrun Error
                RCSTA1bits.CREN=0;       // receive disabled
                __delay_us(1);
                RCSTA1bits.CREN=1;       // receive enabled
                uart_data = NULL;
            }

            parity = calculateparity(uart_data);
            if (parity_rx == parity) {

The specification declare a framing error will be cleared automatically on the next UART read; you can ignore this but I set the received data to NULL so that I’m certain I won’t do anything else with it below if the parity happens to be correct. The overrun flag on the other hand will not be cleared unless you actually turn off the UART receiver and then it back on by clearing and setting RCSTA1bits.CREN. Finally I calculate the parity of received data and compare it with the received parity bit. If I get a match I consider the data good enough to compare it for a valid command. In the code below I am simply looking for the “a” in my call sign and set the output to the on-board LED for 1 millisecond but this could just as easily be an output to a relay (via transistor driver).. or whatever control you need. To port the code between the 16F and 18F series depends on the actual device you’re using. In these cases the 16F series I drop the “1” out of the TX/RC registries (RCSTAbits versus RCSTA1bits).. other modifications will likely be needed based on the individual product you select. Common changes are the configuration settings, oscillator settings, and BAUD control (SPBRG).

The PIC 18F26K22 Receiving Code: uart_rx_w_parity.c


 

The Results

In the following screenshots you’ll notice a fair amount of noise. It was worse in my initial testing of these modules. This was somewhat remedied by modifying my UART transmit code to 9-bit and using a parity generator to include an EVEN parity bit. I had high success with determining when data was bad due to noise. Either there was a framing error and/or a parity error. Both of these can be easily handled in a microcontroller. In my testing I had the best luck with 1,200 baud and 2,400 baud. I found I missed many more bits with 4,800 baud and at 300 baud I become more susceptible to noise; that surprised me more than anything.

Note the actual characters being transmitter are "__ ac0gd - test. "

Note the actual characters being transmitter are “__ ac0gd – test. “

The output on the logic analyzer on the receiving PIC showed my output when I had a valid “command” compared to the serial stream. Note in the second screen shot I occasionally miss a command because of noise. Any commands you send should be sent in multiples for your best chance of proper communication.

rx_valid rx_invalid

Spectrum Analyzer

Neither of us has a ‘scope that has the bandwidth to show you the ASK in the time domain as shown in the modulation diagram previously in the article. We can however show you this device is fairly narrowband in the frequency domain using a spectrum analyzer. The device is advertised as 433.92Mhz; I trust my SA’s accuracy over the little transmitter in a can.

433.3

 

Look at those harmonics!

Look at those harmonics!

These modules have a bit of harmonics; the 2nd harmonic is at about -30db of the original signal and that is not surprising given the size and cost of the device.


 

Logic analyser

There wasn’t much surprise on the logic analyzer. It goes in looking like regular UART and comes out with some slight timing wiggle but within specification enough for the LA protocol analyzer and terminal emulation client to receive the data. 
tx vs rx LA

Try to push the speed on the module and you just end up with data-mush!

2400inv_noise_LA

Final thoughts

We had a great time playing with these little RF modules. They’re a very affordable way to start getting your PICs to play together when apart and are a great launching point to a lot of fun projects.

When finished with the project we had to do some range testing! I found that in a home environment I got about 100 ft (30m) of range out of this device and it still have the ability to send mostly correct information; 1 out of 4 transmissions. My preambled began to fall off first, and eventually the whole sentence was gone. At about 40ft (12m) I had about 30-50% correct transmissions. My antenna was a 6″ piece of wire on both transmitter and receiver, yes I know not even quarter wavelength.

I’ll wrap this article up with a list of considerations I wrote while writing the code for this article and testing this project…  they follow:

Uses: Remote Control, Wireless Home Automation, Telemetry.

Multiple Devices: Typically I’ve found these transmitters working in a one-to-one or multiple(tx)-to-one(rx) topology.

In one to one situations your overhead is pretty low unless you’re trying to make the transmitting/receiving device pair unique.
There are a number of projects found on the internet where a number remote sensors/transmitters broadcast some bit of telemetry to a receiver; the telemetry data would include a transmitter or sensor number with it’s packet of data.
If you’re considering a multi-to-multi or a mesh network I recommend finding an alternative product such as XBEE.

Simplex vs Half/Full Duplex: If it’s not completely obvious we’ve presented a project that information only flows in one direction (Simplex).

If you wished to have bi-directional data you would want to have a transmitter and receiver at both microcontrollers.

You could get away with using the same style transmitters and receivers if your goal was simple simplex operation. Example: walkie-talkie where one person talks while the other listens. (Unless you have a rude friend)

If you were looking for a full duplex operation you might consider buying a set of 315MHz modules for one path and then 434Mhz modules for the other path. If you attempted to use the same frequency transmitters for bi-directional transmission your receivers would get confused over actual signal and receiver garbage. Separating the frequencies to such a degree will help prevent the receiver getting mixed communication. It’s still possible that the power from one transmitter will overload the front end of the receiver installed near it. I recommend physically separating the transmitter and receiver at each microcontroller as far as reasonably possible.

Security: In uses you’ll note we didn’t mention Security applications. I don’t recommend using these simple modules for some secure application such as unlocking your front door.

If you pair this with some other technology such as Microchip’s KeeLoq or other hardware cipher offerings you can achieve reasonable secure communication.

Voltage Input: Battery Applications

The PIC you use can dictate what voltage you might desire for your system. One additional thing to consider is the voltage supplied to your transmitter. Many of these transmitters can accept up to 9VDC. You will see improved transmission range if you have the ability to run your transmitters on a higher voltage. The make and model of your modules will dictate what you can use.

External Antenna

Determining the legality of your antenna system is also another item that’s beyond the scope of this article. That being said if you are going to use an antenna attempt to make it something such as a half wavelength dipole or 5/8 or full wavelength vertical antenna with ground counterpoise. Having the correct wavelength antenna will minimize your SWR loss and improve your transmitter range.

315MHz vs 434MHz: (I’d use 315 in the US)

This is opinion, I have no articles to reference for proof, take this bit of advice with a grain of salt. If you’re in the US you’re likely better off to receive less interference by using the 315MHz modules. You’re also likely to get better range at these lower frequencies outside. Because of the lower frequency your antenna system will have to look electrically longer for best performance. The 434 modules are well within amateur radio spectrum and you’re likely to get intermittent interference if you live near a city. If this is to be used indoors you’re probably going to see better performance from the 434MHz modules.

Addressing/Protocols

I personally wouldn’t use a heavy protocol on these devices, but you could make your own lightweight TCP-like stack if you have nothing but time and hardware budget was tight.

Regardless you should consider at least sending an address with your data transmissions even in a one to one situation for possible future use. A transmission might look like $$$$$T01,W,203,3.0#.  The $$$$$ is a made up preamble. I’ve noticed more than any other time my first one or two bytes of information are the most noisy. If you have a couple bytes you can throw away in the front your packet the receiver microcontroller can safely ditch any preamble bad bits. I nicely formatted string will also help you determine validity of the reception. I would also recommend you consider using a stop bit (in this case I arbitrarily used “#” ).