Post by thread:[PIC]: Error correction for RF transmission

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_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

On Thu, 16 Nov 2000 16:04:36 +0000, you wrote: {Quote hidden}>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 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 .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

{Quote hidden}> 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) 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.brownKILLspam.....clear.net.nz -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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 listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

> 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.brownKILLspamclear.net.nz -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

>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 RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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 spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

>>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 TakeThisOuTrayEraseMEspam_OUTdsp.com.au mail from: dsp systems -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> 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.brownEraseME.....clear.net.nz -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservmitvma.mit.edu with SET PICList DIGEST in the body

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_OUTKILLspammitvma.mit.edu

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}>* 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-requestTakeThisOuTspammitvma.mit.edu

>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-requestspamspamBeGonemitvma.mit.edu