Searching \ for '[PIC]: Error correction for RF transmission' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=rf
Search entire site for: 'Error correction for RF transmission'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Error correction for RF transmission'
2000\11\16@110537 by Simon Nield

flavicon
face
Do any of you have any error correction code you would be willing & able to share ?
An encoder and decoder would be lovely. If the code was .asm usable on a 16f877 then I would be over
the moon.

some more information:
I am transmitting data from a 433MHz Radiometrix TX2 module through a 36dBm PI attenuator (for FCC
compliance) with a loop aerial, to a Radiometrix RX2 module. The datarate is currently 38400 baud,
which is about as fast as the modules will go (max baudrate is 40k)

I turn on the transmitter and then send 4 bytes of 0xf0 to allow the receiver's data slicer to bias
up correctly.
I then send a start byte, seven bytes of data and a checksum - this data is not coded in anyway.
I then switch off the transmitter unti TMR2IF goes off again some 13ms later

The data received looks ok and the system works fine up to about 4 feet of seperation. Beyond that
the system becomes sluggish with 'too many' packets being lost due to corruption... some good
packets are still getting through at about 15 feet, but only a few per second. I would like to try
adding 'some' error correction to see how far I can extend this system's 'comfort zone'.
I have tried transmitting the packet twice per TMR2 interval and that made an appreciable
difference, however I do not want to transmit continuously as this would impact on battery life too
heavily (and I think also break FCC rules)

regards,
Simon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@125445 by mike

flavicon
face
On Thu, 16 Nov 2000 16:04:36 +0000, you wrote:

{Quote hidden}

Before looking at error correction you should try to improve the basic
error performance before trying to patch it up afterwards. Using different coding may help a lot, in particular dc-free codes, to
help the data slicer. May also be worth investigating coding schemes
that have good pulse-length jitter tolerance and tolerance of short
glitches around the data edges. Look at the received data on the scope
and you should see the sort of nasties you need to cope with.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@130911 by jamesnewton

face picon face
I've been working on this for a while but have no complete solution to show
for it.

see:
http://www.piclist.com/../method/errors.htm

Please consider making your work public.

There are two CRC routines at
http://www.piclist.com/../microchip/memory.htm

---
James Newton (PICList Admin #3)
jamesnewtonspamKILLspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\11\16@144147 by Brent Brown

picon face
{Quote hidden}

As Mike said, getting things working as good as possible before
adding error correction is a good idea, then maybe you wont need
it. Maybe you've tried that already, so forgive me if I'm going over
old ground. I'm only passing on these ideas because I've been
there recently, but I don't have any code for data correction.

You could try changing your preamble of 4 bytes of 0xF0. This
could be a little on the short side - I might suggest 10 or 20 bytes,
and try a different byte value. Time is the main issue. For a simple
ON/OFF keyed transmitter, then just switching Tx on for a period of
time (the right period of time) with no data will get the Rx data
splicer back into business quicker. Follow what I'm getting at? The
data splicer likes a nice average 50% mark/space ratio, but its
been dragged down to 0% because you haven't been feeding it for a
while, so you overfeed it with 100% just long enough for the
average to come back up to 50%. This depends of course on the
time constant of the data splicer.

If your 7 bytes of actual Tx data is typically very unbalanced, ie.
lots more one's than zero's, or visa versa, then a quick and easy
way of improving this is to XOR each byte with 0x55 or 0xAA. This
inverts every second bit. To decode at the Rx end just repeat the
XOR instruction.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  .....brent.brownKILLspamspam.....clear.net.nz

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@181312 by David Huisman
flavicon
face
Brent,

How about sending 0x55 to condition the slicer at the correct Baud rate.
Next, you can convert the data into pseudo Manchester Encoded signal in
software.
You spilt the byte into 2 bytes and have a lookup table that generates
almost DC balanced word for each nibble sent.
Finally add a CRC-16 checksum.

In our data radio systems, our simplest packet structure is

Preamble, Preamble, Sync, Num Bytes, Data, CRC-16
Where Preamble = 0x55.
Sync byte = 0x54

We have tested our link at over 500m without problem, though here in
Australia we can transmit 25mW in that band.

Regards
David Huisman
Orbit Communications
http://www.orbitcoms.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@185438 by Brent Brown

picon face
> Brent,
>
> How about sending 0x55 to condition the slicer at the correct Baud rate.
> Next, you can convert the data into pseudo Manchester Encoded signal in
> software.
> You spilt the byte into 2 bytes and have a lookup table that generates
> almost DC balanced word for each nibble sent.
> Finally add a CRC-16 checksum.
>
> In our data radio systems, our simplest packet structure is
>
> Preamble, Preamble, Sync, Num Bytes, Data, CRC-16
> Where Preamble = 0x55.
> Sync byte = 0x54
>
> We have tested our link at over 500m without problem, though here in
> Australia we can transmit 25mW in that band.

OK, makes good sense, but the original poster wanted to minimise
transmission time because of power restraints.

My idea was that the length of preamble could be minimised by
sending 0xFF as the preamble character, for a shorter period of
time. As the Tx has been off for a period of time, the data slicer
has effectively been unbalanced by receiving 0x00 for a while, so a
burst of 0xFF could restore the balance twice as fast as 0x55? As I
said, it would depend very much on the response time of the data
slicer. Does this sound feasible or am I off the mark here?

I like your pseudo-manchester encoding...that way you can still
use the UART to send/receive.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  @spam@brent.brownKILLspamspamclear.net.nz

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@190654 by Alan B. Pearce

face picon face
>You spilt the byte into 2 bytes and have a lookup table that generates
>almost DC balanced word for each nibble sent.

If you are going to do this, then split the byte into 2 bytes, and when sending
a bit, send the next bit as the complement, so it looks like a phase encoded
signal. On receive just use every second bit. Would require a little bit of
software if sending it through standard UART type interface because of the
receive and transmit bits. Would almost be easier to use a software UART with 16
bits between start and stop bits.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@191854 by David Huisman

flavicon
face
Brent,

That may work if the data slicer receives no transitions at all since the
last transmission (including those caused by noise). And also that there has
been enough time for the slicer cap to discharge since last transmission.

In our design, the slicer tracks the DC voltage. If the DC voltage changes
due to temperature/voltage etc, you have no way of knowing what voltage the
data slicer has settled to. By sending 1010101010... you force it to be
around 50% of the level between 1 and 0  + the DC offset. If the slicer
voltage is reasonably high due to noise transitions etc when you send the
0xff, then the slicer will be settled very high and be very susceptable to
noise.

Regards

David Huisman
Orbit Communications
http://www.orbitcoms.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@204113 by Ray Gardiner

flavicon
face
>>You spilt the byte into 2 bytes and have a lookup table that generates
>>almost DC balanced word for each nibble sent.
>
>If you are going to do this, then split the byte into 2 bytes, and when sending
>a bit, send the next bit as the complement, so it looks like a phase encoded
>signal. On receive just use every second bit. Would require a little bit of
>software if sending it through standard UART type interface because of the
>receive and transmit bits. Would almost be easier to use a software UART with 16
>bits between start and stop bits.
>

       We are doing this with the radiometrix modules, basically the
       approach is as follows.

****    Working from the top down. (Transmit)

       1. The data is a modbus packet with 16 bit crc.

       2. The packet is then huffman encoded for forward error correction
       we are currently using 8/12.

       3. The resulting bitstream is then manchester encoded
       and transmitted using software uart.

       The data rate is basically 300 baud which means 600 for
       manchester encoded data.

****    The receive side is as follows.

       1. Digital Filtering centered on 600Hz

       2. Manchester Decode.

       3. Huffman Decode and correct errors.

       4. Validate Packet structure and crc.

Notes:
       The huffman encoding/decoding lowers the noise floor by about 2-3db
       for the tests we have done.

       You can't do manchester encoded bitstreams with the on chip uart.

       Lowering the data rate further might drop out of the range
       of the internal data-slicer in the radiometrix module.

       We get better results with modules' built in data slicer and
       digital filtering in software rather than using the raw audio
       out and hardware bandpass filtering.

       The radio metrix modules are suscepible to interference if
       improperly mounted. I measured receiver sensitivity at 5uV
       with a rough breadboard layout. This improved to 0.3uV with
       a properly contr=ucted "rf sound" layout with good grounding
       and sheilding..







Ray Gardiner TakeThisOuTrayEraseMEspamspam_OUTdsp.com.au
mail from: dsp systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\11\16@221520 by Brent Brown

picon face
> That may work if the data slicer receives no transitions at all since the
> last transmission (including those caused by noise). And also that there has
> been enough time for the slicer cap to discharge since last transmission.
>
> In our design, the slicer tracks the DC voltage. If the DC voltage changes
> due to temperature/voltage etc, you have no way of knowing what voltage the
> data slicer has settled to. By sending 1010101010... you force it to be
> around 50% of the level between 1 and 0  + the DC offset. If the slicer
> voltage is reasonably high due to noise transitions etc when you send the
> 0xff, then the slicer will be settled very high and be very susceptable to
> noise.

Oh, thanks David - I completely overlooked the noise between
transmissions. 0x55 or 0xAA it has to be then. Wish all that noise
wasn't there. OK everyone switch off everything electric - I want to
open my garage door...

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  brent.brownEraseMEspam.....clear.net.nz

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body


2000\11\17@024407 by James Newton

face picon face
Ray, are you saying that you have actually implemented full Huffman decoding
WITH error correction on a PIC? Where did you get the RAM? Where am I being
stupid in thinking that this is not possible without external RAM?

James Newton, PICList Admin #3
RemoveMEjamesnewtonEraseMEspamEraseMEpiclist.com
1-619-652-0593 phone
http://www.piclist.com


{Original Message removed}

2000\11\17@081833 by Simon Nield

flavicon
face
Thankyou all, in order of appearance:
Mike, James, Brent, David, Alan and Ray.

i apologise for any confusion i may have caused by not making clear before that the radiometrix
modules in question are fm modules.

in case you are interested my plans are as follows:
* will stick with 0x0f preamble for the time being - it creates a simple square wave at the
byte-rate (3840Hz), which makes triggering my software receiver a little easier... the receiver
appears to be biased to somewhere usable after 1 to 3 bytes of preamble. increasing the number of
bytes is probably a good idea to give more noise margin. will have to find out how many is optimal
by experimentation. Will try adding a few bytes of 0x55 into the mix too - trouble is they are
impossible to sync to as they have no break in the pattern. prehaps 0xaa would be a better choice.

* am currently working on a tidy hack to convert the transmit side code (which uses the HW uart) to
pseudo manchester code the data (great suggestion btw). once that is done i will customise the
software receiver to only grab the bits i want.

* will look into error correction (prior to the pseudo manchester coding) if the above doesn't
improve things enough.


Regards,
Simon

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu


2000\11\17@105150 by mike

flavicon
face
On Fri, 17 Nov 2000 13:19:08 +0000, you wrote:

>Thankyou all, in order of appearance:
>Mike, James, Brent, David, Alan and Ray.
>
>i apologise for any confusion i may have caused by not making clear before that the radiometrix
>modules in question are fm modules.
>
>in case you are interested my plans are as follows:
>* will stick with 0x0f preamble for the time being - it creates a simple square wave at the
>byte-rate (3840Hz), which makes triggering my software receiver a little easier... the receiver
>appears to be biased to somewhere usable after 1 to 3 bytes of preamble. increasing the number of
>bytes is probably a good idea to give more noise margin. will have to find out how many is optimal
>by experimentation. Will try adding a few bytes of 0x55 into the mix too - trouble is they are
>impossible to sync to as they have no break in the pattern. prehaps 0xaa would be a better choice.
..or do it the other way - start with 55's and then a 0f or whatever
for sync.
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2000\11\17@161959 by Peter L. Peres

picon face
>slicer training

fyi most slicers worth more than a dime or so use peak detection for the
signal strength followed by a filter so the slice level is set at 50% (or
more, to account for noise) of the peak level. This makes the training
sequence immaterial, however it makes the total duration of the 1's in it
important, to achieve the receiver's minimum training period. In other
words, send 0xff to train a better receiver. HOWEVER the manufacturer of
said receiver should tell you how to do this !

Peter

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...