Searching \ for '[EE] RF encoding' 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/io/serials.htm?key=rf
Search entire site for: 'RF encoding'.

Exact match. Not showing close matches.
PICList Thread
'[EE] RF encoding'
2005\04\28@103647 by Michael Rigby-Jones

picon face
I've been thinking about the design of a fairly simple wireless (RF)
telemetry system, and would appreciate some guidance on encoding methods
and error correction.

Essentialy I will have multiple transmitters and one receiver.  The plan
is to have transmitters transmit a small packet of data at a period
determined by both the transmitters address and a PRBS generator, to try
to prevent transmitters being synchoronised to each other and
continuously colliding.  By keeping the packets as short as possible
relative to the transmission period this will help further.  I'm
planning on using the small license free RF modules available cheaply,
most likely the FM ones running at approximately 2000bps.

Initialy I was planning on using Manchester encoding to get a DC
balanced bit stream and include a CRC to detect bit errors.  However,
the way I see it, manchester encoding is effectively transmitting the
data twice, with one set inverted and interleaved with the original
simply to maintain DC balance.  I'm thinking that there has to be a
better use for the extra 50% bandwidth that manchester uses. Could these
bits contain some kind of Forward Error Correction (like a hamming code)
which also maintains DC balance (within reason, dosen't have to be
perfect)?  Would a scrambling system be usefull for DC balancing?

Thanks for any pointers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\28@122108 by Scott Dattalo

face
flavicon
face
On Thu, 2005-04-28 at 15:36 +0100, Michael Rigby-Jones wrote:

> Initialy I was planning on using Manchester encoding to get a DC
> balanced bit stream and include a CRC to detect bit errors.  However,
> the way I see it, manchester encoding is effectively transmitting the
> data twice, with one set inverted and interleaved with the original
> simply to maintain DC balance.  I'm thinking that there has to be a
> better use for the extra 50% bandwidth that manchester uses. Could these
> bits contain some kind of Forward Error Correction (like a hamming code)
> which also maintains DC balance (within reason, dosen't have to be
> perfect)?  Would a scrambling system be usefull for DC balancing?


Mike,

There are additional benefits you gain with Manchester encoding other than
a negligible DC offset. One is self-timing. If there is any variation in
your transmitters' clocks your receiver can easily compensate for it.
Second, since there are essentially 'rules' that describe how the
Manchester data stream is to be coded, the receiver can verify that none
of the rules are broken. And a rule can be broken by noise corrupting the
data. (If you view the Manchester encoding as a sequence of narrow/wide
and high/low pulses there are combinations that are invalid.) Thus, you
get some error checking by virtue of the fact that the stream is
Manchester encoded.

To address your concern that it appears Manchester encoding sends the data
twice, I'd just suggest trying to imagine any other encoding that can send
clocked data. One example is a pulse width scheme. If you divide the bit
slice in half, then a '0' can be sent with a pulse that is narrower than
half a bit slice and a '1' is wider. You'll need some margin, so you may
choose 1/3 width for 0's and 2/3 width for 1's. But, you'll notice that
there are two edges transmitted for *every* bit. On average, Manchester
encoding has fewer than two edges.

As far as CRC versus Hamming, I'd say the choice depends on the number of
bits in your data. If there are only a few bytes, then I'd use a hamming
code.

Scott

2005\04\29@084432 by Michael Rigby-Jones

picon face


{Quote hidden}

Scott,

Thanks for the comments.  I appreciate the benefits of manchester for
clock extraction, however I think I forgot to mention a fairly important
point!  I was intending to use the PIC's USART for sending and receiving
data, and sending a string of balanced, but illegal manchester codes as
a preamble to stabilise the data slicer in the receiver, and using the
code sequence shown on Piclist.com (originaly by Bob Ammerman I think??)
to ensure the USART is byte aligned.

Under these circumstances, the edges aren't used for clock recovery
apart from the start bit at the beginning of an asynch byte.  Looking at
(e.g.) an (8,4) hamming code, an 8 bit code can represent 16 discrete
values (same as manchester) but with the advantage of being able to
correct 2 bit errors.  The downside is that 2 of the 16 resulting codes
are totally unbalanced (i.e. 0x00 and 0xFF).  I could just ignore those
codes, using the other 14 and only geting ~3.8 bits encoded per octet,
and this would actualy be ok as 4 encoded bytes would hold a ~15bit
value which is plenty for my application.  However, if there is a
reasonably simple scheme that would allow the full range of codes to be
used it would be usefull.

Regards

Mike



=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\29@101633 by olin_piclist

face picon face
Michael Rigby-Jones wrote:
> Looking at
> (e.g.) an (8,4) hamming code, an 8 bit code can represent 16 discrete
> values (same as manchester) but with the advantage of being able to
> correct 2 bit errors.

Not quite the same.  The UART sends an additional start bit and stop bit, so
you are sending 4 bits of data for each 10 slice times.  With manchester you
get 4 bits per 8 slice times.

> The downside is that 2 of the 16 resulting codes
> are totally unbalanced (i.e. 0x00 and 0xFF).  I could just ignore those
> codes, using the other 14 and only geting ~3.8 bits encoded per octet,
> and this would actualy be ok as 4 encoded bytes would hold a ~15bit
> value which is plenty for my application.  However, if there is a
> reasonably simple scheme that would allow the full range of codes to be
> used it would be usefull.

How about using the synchronous serial port to send the manchester data.
This gets you 1 free bit for every 4 compared to using the UART.  Then use
those extra bits separately for a CRC checksum or error correcting codes.  I
doubt you'd need an extra 25% more bits to reasonable protection, so this
probably takes less bit slice times and has better DC average over shorter
intervals, and is reasonably tolerant of clock inaccuracies.  There is a
reason manchester is used a lot in low cost RF data transmission.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\29@104117 by Michael Rigby-Jones

picon face


{Quote hidden}

Olin,

The reason I was considering the USART was for ease of reception rather
than transmission.  The (increasingly vain) hope was that by
synchronising the USART with a preamble etc. that the rest of the data
would slot into place without too many problems, and I wouldn't need the
overhead of a timer interrupt at a multiple of the bit rate etc.  I'm
beginning to think that the USART might not be a great idea though.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\29@114806 by Dave Tweed

face
flavicon
face
Michael Rigby-Jones <EraseMEMichael.Rigby-Jonesspam_OUTspamTakeThisOuTbookham.com> wrote:
> (e.g.) an (8,4) hamming code, an 8 bit code can represent 16 discrete
> values (same as manchester) but with the advantage of being able to
> correct 2 bit errors.

Not quite. As I explained before, an (8,4) code is a SECDED code -- it can
correct single-bit errors and detect all double-bit errors.

And I also explained how to avoid using 0x00 and 0xFF as valid code words.

-- Dave Tweed

2005\04\29@125858 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu]
>Sent: 29 April 2005 16:48
>To: KILLspampiclistKILLspamspammit.edu
>Subject: RE: [EE] RF encoding
>
>
>Michael Rigby-Jones <RemoveMEMichael.Rigby-JonesTakeThisOuTspambookham.com> wrote:
>> (e.g.) an (8,4) hamming code, an 8 bit code can represent 16
>discrete
>> values (same as manchester) but with the advantage of being able to
>> correct 2 bit errors.
>
>Not quite. As I explained before, an (8,4) code is a SECDED
>code -- it can correct single-bit errors and detect all
>double-bit errors.
>
>And I also explained how to avoid using 0x00 and 0xFF as valid
>code words.

Dave,

Thanks, I must have missed your post. I'll have a hunt through the
archives in a bit.  You are correct of course, a Hamming distance of
2d+1 is required where d is the number of correctable bits.  I hope I'm
correct in saying that an (8,4) code can detect up to 3 bit errors
though?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\29@133913 by Glenn Jones

picon face
I recently found this App Note from Nordic Semi about using a UART for
transmitting over RF. It looked useful to me, perhaps it can help you.
http://www.nordicsemi.no/files/Product/applications/nAN400-07rev1_2.pdf

Glenn

On 4/29/05, Michael Rigby-Jones <spamBeGoneMichael.Rigby-JonesspamBeGonespambookham.com> wrote:
>
>
> >{Original Message removed}

2005\04\29@134432 by Dave Tweed
face
flavicon
face
Michael Rigby-Jones <TakeThisOuTMichael.Rigby-JonesEraseMEspamspam_OUTbookham.com> wrote:
> Thanks, I must have missed your post. I'll have a hunt through the
> archives in a bit.

Look for this subject line:
  [PIC] Hamming ECC again... In C, this time

> You are correct of course, a Hamming distance of 2d+1 is required where d
> is the number of correctable bits.  I hope I'm correct in saying that an
> (8,4) code can detect up to 3 bit errors though?

Some -- perhaps most -- but not all.

-- Dave Tweed

2005\04\29@203713 by Howard Winter

face
flavicon
picon face
Mike,

On Thu, 28 Apr 2005 15:36:11 +0100, Michael Rigby-Jones wrote:

>...<
> Initialy I was planning on using Manchester encoding to get a DC
> balanced bit stream and include a CRC to detect bit errors.

Why are you worrying about DC balancing a radio system?  I can see why you'd want to with cable linked comms,
but radio (especially if it's FM) really doesn't care about it, as far as I know...

I'd say a Hamming code is your best bet for error detection/correction, since I believe that Manchester coding
can only detect that there is an error, but not tell you what it is (a simple Hamming code should be able to
detect and correct all 1-bit errors, and detect all 2-bit errors in a byte).

Cheers,



2005\04\29@205805 by olin_piclist

face picon face
Howard Winter wrote:
> Why are you worrying about DC balancing a radio system?

It simplifies the data slicer.  With a little more sophistication
determining the high/low threshold, all you need is to encounter a high and
low "often enough", like every few bits.  The signal from a UART would be
sufficient as long as there were a steady stream of characters.

> I can see why
> you'd want to with cable linked comms,

I don't.  Many cable systems don't require this at all because there you
have an absolute 0 voltage reference.

> but radio (especially if it's
> FM) really doesn't care about it, as far as I know...

FM doesn't, but many low cost systems are carrier keyed AM where it does
matter.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com


'[EE] RF encoding'
2005\05\02@122417 by Alvaro Deibe Diaz
picon face
> Howard Winter wrote:
> > Why are you worrying about DC balancing a radio system?
>
> It simplifies the data slicer.  With a little more
> sophistication determining the high/low threshold, all you
> need is to encounter a high and low "often enough", like
> every few bits.  The signal from a UART would be sufficient
> as long as there were a steady stream of characters.

First of all, sorry if this is not the goal of the thread. I've lost the
beginning of it, so I can be a little biased from my own problems.

As Michael, in my case using the UART in the receiver part of the RF link
was a must.

As Olin says, more UART speed would be good to make the data slicer and the
AGC in the receiver work better without the need of DC balancing, in a
steady characters stream. But speeds over 57600bps in an RF link between PIC
and a PC would be troublesome  

In my case, a simple RF datalink, where the importance of losing single
packets now and then is not crucial, i just used only those bytes in the
0-255 range that better suited the RF link needs. I sorted the binnary
numbers from 0 to 255, including start and stop bits added by the USART,
attending several criteria: number of transitions in each code, DC balancing
(number of 1's and 0's), number of consecutive equal bits (0's or 1's).

There are 70 numbers with 0 DC level (same number of 0's and 1's), and 112
with 1 DC level. I chosen this 70+112=182 bytes, and sorted them by maximum
number of consecutive equal bits. Choosing 3 bits maximum, there are 125
bytes. So I got this 125 and added 3 more bytes with 4 consecutive equal
bits, but with the most possible transitions 0-1 and 1-0. There would be, of
course, other criteria based on the expected noise, range, and error
handling.

This way I discarded the "worse" 128 values from each byte (losing 1 bit),
and ended up with a much more convenient code set to get through the RF
link. My first objective was data speed, and this may not be the target of
Michael, but this can easily be changed as suited...

I made an Excel sheet to make this calculations, but don't know if it is
allowed to attach it in a mail in this list, so here goes a link to it:

ftp://anonymous@193.144.52.77/pub/Codification.xls

Regards,

Alvaro Deibe Diaz.


2005\05\03@043107 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: Howard Winter [RemoveMEpiclist-bouncesspamTakeThisOuTmit.edu]
>Sent: 30 April 2005 01:37
>To: Microcontroller discussion list - Public.
>Subject: Re: [EE] RF encoding
>
>
>Mike,
>
>On Thu, 28 Apr 2005 15:36:11 +0100, Michael Rigby-Jones wrote:
>
>>...<
>> Initialy I was planning on using Manchester encoding to get a DC  
>>balanced bit stream and include a CRC to detect bit errors.
>
>Why are you worrying about DC balancing a radio system?  I can
>see why you'd want to with cable linked comms,
>but radio (especially if it's FM) really doesn't care about
>it, as far as I know...

Howard,

The decision threshold of the data slicer is based on the average DC
value of the output data (imagine a comparator, one input connects
directly to the receiver output, the other connects to the receiver
output via a low pass filter).  A run of 0's or 1's will move the
decision threshold up or down and can cause large error bursts.  This is
true for both the cheap AM receivers and also many of the FM receivers
that use the demodulated output in the same manner.  One of the
functions of the preamble is to center the data slicer ready for the
real data.


{Quote hidden}

Thank you very much for sharing your work.  I guess you used a simple
lookup table to decode your symbols into 7 bit values?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\05\03@063645 by Alvaro Deibe Diaz

picon face
> >I made an Excel sheet to make this calculations, but don't
> know if it
> >is allowed to attach it in a mail in this list, so here goes
> a link to
> >it:
> >
> >ftp://anonymous@193.144.52.77/pub/Codification.xls
> >
> >Regards,
> >
> >Alvaro Deibe Diaz.
> >
>
> Thank you very much for sharing your work.  I guess you used
> a simple lookup table to decode your symbols into 7 bit values?

Yes. The selected values are randomly distributed over the 0-255 range, so
it was very difficult to find an explicit function to do the work, and I
ended up with lookup tables.


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