Exact match. Not showing close matches.
'[OT] Need help with RF Solutions AM RF modules'
Happy New Year Piclisters,
I hope someone can help me out here. Sorry for the long post, but I wanted
to provide as much info as possible.
I am attempting to communicate between a PC and a PIC using RF Solutions
418Mhz AM modules.
On the PC side I am sending data via RS232 at 1200 baud to a MAX220. The
output of the MAX220 is connected to the input (pin 6) of a AM-RT5-418
module. Per RF Solutions' Antenna Design Notes I am using a piece of wire
17cm long as the antenna.
On the PIC side I am receiving with a AM-HRR1-418 module (again using a
17cm wire as the antenna). I have all of the Vcc's (pins 1,10,12,15)
hooked up to the same supply and all of the grounds (pins 2,7,11) hooked up
to a common ground. Data out (pin 14) of course goes to a PIC pin.
I know that the RS232 send to a PIC works as I have hardwired the
connection between the PC and the PIC and have that working flawlessly. I
thought it should be a simple matter to replace the wires with the RF
Solutions modules, but something isn't working right.
The transmit (PC) side of things seem to be working okay. If I transfer a
file via Windows Terminal, I can see the voltage changing on the output pin
of the MAX220 (as expected), and I can see the voltage changing on the
antenna pin of the AM-RT5 module.
On the receive side I don't at all see what I expect on the data out pin.
So my questions are:
1. Do I have the receiver wired up right?
2. Should the RF +Vcc and RF Gnd lines from the datasheet be connected
somehow differently from the lines designated AF +Vcc and AF Gnd? (Do I
need separate/isolated supplies for these?).
3. Is 17cm really the correct length for antennas for both sides?
4. I am using thin copper telephone wire for the antennas, should I use
5. Is 1200 baud too fast?
Any help would be greatly appreciated.
You are using AM RF moduls, with on-off keying. The AM moduls while your
circuit not sending signals introduce noise.
This noise scrambling your valid signal. To able to receive You need signal
conditioning on the receive side.
The 17 cm antenna sounds right.
At 08:54 05/01/99 -0700, you wrote:
>module. Per RF Solutions' Antenna Design Notes I am using a piece of wire
>17cm long as the antenna.
Where is that note? For earlier transmitters, to comply with MPT1340, you
had to keep the antenna length for the transmitter below 1/8 wavelength
(9cm), though you could use a 1/4 wavelength (18cm) receive antenna. I
couldn't see anything on the transmitter data sheet for the 4-pin version
about antenna design, so I just used a 9cm piece of wire (my transmitter
box is small anyway, and waterproof, so I wanted the antenna to fit inside it)
>On the receive side I don't at all see what I expect on the data out pin.
>So my questions are:
>1. Do I have the receiver wired up right?
Be _very_ diligent with the grounds- is it all in a star, and wires as
short as possible? Looking at the data out pin should show you if it's got
lots of noise on it or not.
>2. Should the RF +Vcc and RF Gnd lines from the datasheet be connected
>somehow differently from the lines designated AF +Vcc and AF Gnd? (Do I
>need separate/isolated supplies for these?).
Nope- my wireless doorbell has them all together, with one connection from
5V to AF Vcc and one to RF Vcc, then spidered out from these to the other
connections, similarly for the grounds.
>3. Is 17cm really the correct length for antennas for both sides?
418MHz, wavelength is 72cm, so 18cm is quarter wavelength- I believe that's
a good length, though I'm not an RF person really ;-)
One problem I sometimes found on the receiver was that the antenna was
_too_ good (picking up noise), and I seemed to get more reliable
communications with a less than optimal one- have a look at the data out
pin and see if you get lots of noise on it (could also be due to supply and
grounding connections being bad)
>4. I am using thin copper telephone wire for the antennas, should I use
Should be fine
>5. Is 1200 baud too fast?
Nope- that's what I used.
>Any help would be greatly appreciated.
I presume you're trying this at short ranges? If not, get the 2 less than
1m apart for starters to lose any RF effects. Then look at the data
received pin and see if it's very noisy (I presume you've got code in the
PIC to react to OERR and FERR USART errors?- there will definitely be some
Other 'gotchas' that got me...
The output from my receiver was _not_ enough to give a reliable TTL input,
so I needed a transistor stage to get a full 5V (the data sheet said it
would be higher than it was)
Then I realised that the output from the receiver was normally low (when no
carrier was detected) and the PIC USART needs normally high, so I replaced
my transistor stage with a PNP stage... and suddenly it worked ;-)
Hope that helps- please let me know how you get on...
Nigel Orr Research Associate O ______
Underwater Acoustics Group, o / o \_/(
Dept of Electrical and Electronic Engineering (_ < _ (
University of Newcastle Upon Tyne \______/ \(
'[OT] Need help with RF Solutions AM RF modules'
> I am attempting to communicate between a PC and a PIC using RF Solutions
> 418Mhz AM modules.
I have done experiments with similar modules, but with FM. The major signal
quality problems were
a) very low range with just a 17cm wire (barely 2 rooms). Using real antennas
doubled the price, but quadrupled the range.
b) inversion of the signal. Could be handled in software, because I was not
using a HW UART.
c) inside the receiver module, the analog signal (after demodulation) doesn't
have sharp edges. It is re-shaped by a treshold device. The treshold was
off in my module. When transmitting a high and a low pulse of _same_ length,
the low pulse was about 20% _longer_ (at my baudrate) than the high one at
the receiver module output. This is a problem when synchronizing to
the edge of a bit to sample its middle.
d) as expected with wireless transmission, some bits were just bad. Usually
several neighbor bits.
I did have a dedicated sender, and a dedicated receiver. The receiver could
therefore not re-request corrupt data.
The solution I made was:
1) No UART. A bit error can strike anywhere. When using a normal UART, an
erraneous STARTBIT renders the whole byte useless. Worse: when a block
of several bytes are sent with no gap in between, their DATA bits might
be misinterpreted as STARTBITS. In the worst case, the whole block will
be corrupt due to a _single_ bit error.
I prefered a DPLL and sync word detector. It samples the radio channel
continously at 15x bit clock. The DPLL moves the sample point towards
the bit middle. To accomplish that it looks for edges in the incoming
signal. Each message begins with a preamble (sequence of 0101010101)
to train the DPLL. The data coding (see 2) ensures lots of edges in
the body of a message.
The resulting data stream is continously compared to a sync word (and
its inverted version, to allow drop in replacement of RF modules by
inverting types). A syncword match is accepted when less than N bits
differ (XOR data with sync word, count remaining 1's).
2) The following N bits are the message. Those are encoded with a
convolutional error correction code. It adds a parity bit for every
data bit (doubles the number of bits). The parity is based upon _two_
data bits, both of which are spaced apart from the parity, and from
The typical radio error hits a burst of bits, so it will hit _either_
the parity, _or_ _one_ of the data bits that were used to form it. As
long as this holds true, recovering the error is possible.
Calculating a new parity and seeing a mismatch to the received parity
indicates a bit error. "Fortunately" each of the two data bits were
involved in forming one of parity each. Checking those reveals whether
the error stroke the parity bit (ignore), or the data bit (invert).
AA BB CC DD EE FF GG HH II JJ Bitpairs A-J
DP DP DP DP DP DP DP DP DP DP D= Data bit P= Parity bit
A ^-------^--------^ Data bits that formed Parity part of pai
B ^-------^--------^ Data bits that formed Parity part of pai
C ^-------^--------^ Data bits that formed Parity part of pai
D ^-------^--------^ Data bits that formed Parity part of pai
A false DATA bit G will result in false Parity at pair A _and_ at pair D.
In contrast, a fals PARITY at G results in false Parity at G and _nowhere_ el
As a result of 1) and 2), a single bit error or burst of length < spread
of parity vs first data bit can be recovered completly. Several burst
errors can be recovered if they are spaced apart far enough (parity
vs second data bit).
With proper chosen syncword size and max differences for the match detector,
this robustness applies to _all_ parts of the message. There are no particula
vulnerable points for an error to cause more damage than at any other point.
(A chain is as strong as its weakest link)
3) I used traditional checksums to detect long error bursts, or those that
happen to match the error correction bit spacing. Those packets I had to
ignore (data loss).
Hint: Don't chose a baudrate/spacing to separate the data/parity at 50/60Hz
or similar :-)
The application allowed to add redundancy by keeping a "history" in the
messages. When some of the messages come through, system integrity is
guaranteed. The more messages can be decoded, the better the (time) resolutio
(which was desired to be the best possible).
You might ask what all this has to do with PICs. Well, nothing at all - I have
implemented this on an AVR S1200 :-)
I hope you enjoyed reading it anyway. (at least you've made it here)
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...