PLEASE REMOVE FROM YOUR LIST.
  MER@MiddleEast.org.



Marc wrote:
>
> > 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
>    themselves.
>
>    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 p
air A
>    B      ^-------^--------^            Data bits that formed Parity part of p
air B
>    C         ^-------^--------^         Data bits that formed Parity part of p
air C
>    D            ^-------^--------^      Data bits that formed Parity part of p
air D
>
>    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_
else.
>
>    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 particu
lar
>    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) resolut
ion
>    (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)