'Decoding 12 bit radio data using PIC'
I've written PIC code to decode a serial 12 bit word received via a radio
My problem is noise - I'm decoding the signal by looking for a start bit
of 2ms high, then sampling in the middle of the data bit, then
re-synchronising on the start of the next data bit by waiting for the
signal to go high
Unfortunately, if there is a noise spike in the middle of all this I see
it as a state change and lose synchronisation.
Anyone got advice on how signals of this sort are best processed - am I
approaching this from the wrong direction - should I be measuring the
length of each pulse and throwing away anything shorter than a data bit?
Your help would be appreciated
ndie Ohtsji 
Please let me know of your findings as I will be implementing this
as well, in the near future. I was thinking of sending packets
of between 10 to 50 bytes. Each packet would have a start bit,
data, crc, and stop bit.
I was thinking of doing a start byte and stop byte instead of only
a bit width to avoid misinterpreting noise as a start. Like you,
I was thinking of syncing up with the start bit/byte and then
sampling in the middle of the next bit. Don't know what to do
about noise - perhaps sampling more than once for each bit and
then determining the level of the bit by choosing the majority level
(e.g. you sample 4x for each bit, and if you sample 3 highs and 1 low,
then chances are the bit is high and the low sample was due to noise).
I guess this would be determined by the speed of your transmission
and the speed of your processor.
I was thinking of using the Linx modules (another thread that just
STRONG, Neil -Syntegra <MITVMA.MIT.EDU> wrote: PICLIST
> I've written PIC code to decode a serial 12 bit word received via a
> radio module.
> My problem is noise
> Unfortunately, if there is a noise spike in the middle of all this I
> see it as a state change and lose synchronisation.
> should I be measuring the length of each pulse and throwing away
> anything shorter than a data bit?
=== Andrew Warren - ix.netcom.comfastfwd
=== Fast Forward Engineering - Vista, California
|On Fri, 6 Mar 1998 14:52:00 PST "STRONG, Neil -Syntegra"
<NEWCASTLE2.SYNTEGRA.AGW.BT.CO.UK> writes: STRONGN
>I've written PIC code to decode a serial 12 bit word received via a
>My problem is noise - I'm decoding the signal by looking for a start
>of 2ms high, then sampling in the middle of the data bit, then
>re-synchronising on the start of the next data bit by waiting for the
>signal to go high
This is not an optimum way to do it. The best receiver "knows"
everything about the transmitted signal beforehand other than the
*content of the message* (the only intentionally random parameter).
Rather than constantly "guessing" and resynchronizing, etc. it should
rely on the transmitter sending a consistently-timed message and examine
the received signal primarlily to determine the data in the message.
How do you approach this ideal? First, send a known sequence before (and
possibly after) the variable data. The receiver analyzes this sequence
to determine (a) if the signal is coming from a legitimate transmitter,
or if it is just noise and (b) the exact timing of the unknown bits to
follow. If most or all of the premble bits are as expected, the reciever
goes on to collect the unknown bits. Obviously a "start bit" is a known
sequence, but better performance can be realized by using more than one
bit. During the preamble sequence, the receiver adjusts its bit timing
to best match the incoming data. Once synchronization is established,
the receiver just clocks in the unknown bits and makes only minor, if
any, timing adjustments. This is how RS-232 over a wire works (with a
single start bit, it starts timing at the leading edge of the bit, and
rejects the sequence if the bit is not still 0 at the center). For
radio, a more thorough method should be used.
Additionally, the message can be made better-"known" to the receiver by
including redundancy. If the same message data is always sent 3 times in
a row for example, the receiver can reject messages that don't have the
same data in all 3 fields or use a majority (2 out of 3) vote to decide
which one is more likely correct. More advanced error-control codes
should be considered if the time required by a simple redundancy scheme
is too much.
Of course, none of this works if the coding used to send the message is
not compatible with the radio hardware. The simple radio modules using a
regenerative receiver by necessity must AC-couple the data. This means
that there is both a minimum pulse length that can be detected (set by
the bandwidth), and a maximum that can be transmitted without distortion.
Codes which guarantee a minimum number of data transistions (such as
Manchester or the pulse-position modulation used by IR remotes) should be
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
|I have been doing this for a few months. My requirement was for
a UHF link over a few metres capable of tramsmitting channels
from a 12bit ADC (temperature actually) along with a 3 bit
I originally had a lot of trouble with noise pickup, but that's
What I did was to use a pulse-width modulation method at 1200 bit/
second with a 5 mSec carrier before the data to settle the data
slicer on the receiver.
The data format is 1 bit-width of carrier (logic 1), followed
by either a data 0 (no carrier) or data 1, finally followed by a
data 0. This gives a data rate of 1200 / 3 = 400.
I use a 32 bit packet, made up of an 8 bit address, 16 bits of data
(as 4 bits of channel number followed by 12 bits of data) and an
8 bit checksum.
So far the noise immunity has been good.
The transmitters and receivers use 16c84's though I have also
implemented the transmitter with a 12c509, using 5 of its pins
as logic inputs (no ADC). For the 12c509 solution, I need only a uP, and
the UHF key-fob transmitter. The uP sleeps most of the time and draws
an average current of < 5uA from 2 AAA cells.
hope this helps
. Never trust a man who, when left alone in ....... Pete Lynch .
. a room with a tea cosy, doesn't try it on ....... Marlow, England .
..........Billy Connolly. ......................... beowulf.demon.co.uk .. pic
On Fri, 6 Mar 1998, Randie Ohtsji  wrote:
|Hi STRONG, (STRONG, Neil -Syntegra), in <guidion1.syntegra.bt.co.uk> on 350085AC
Mar 6 you wrote:
> I've written PIC code to decode a serial 12 bit word received via a radio
> My problem is noise - I'm decoding the signal by looking for a start bit
> of 2ms high, then sampling in the middle of the data bit, then
> re-synchronising on the start of the next data bit by waiting for the
> signal to go high
> Unfortunately, if there is a noise spike in the middle of all this I see
> it as a state change and lose synchronisation.
> Anyone got advice on how signals of this sort are best processed - am I
> approaching this from the wrong direction - should I be measuring the
> length of each pulse and throwing away anything shorter than a data bit?
There's a lot you can do, but it'll take processing power.
You should examine the noise characteristics before selecting a counter
One way is to lowpass filter the incoming data stream. That's actually
quite similar to your idea of measuring pulse length. Always look at
several samples instead of one. If 3 out of the last 5 samples are 1, act
like you've read a 1. If it's 2/5 max you have a 0.
Also, you can implement a PLL. It generates the bit clock (when to sample
each bit), and synchronizes to the senders' bit clock. The PLL expects the
bit to change at a certain point of time, and hunts for actual bit changes
near that point. If the actual signal changes a bit earlier, the PLL is
late and shortens its next bits' period. If the PLL is early, it can relax
during the next bit.
Because the PLL is not "hard" locked, you can determine how fast the PLL
phase shifts towards the input signal phase. A slow shift rate is more
robust against noise.
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...