Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
02/11/03 20:32
Read: times


 
#38816 - RE: Manchester Encoding on 89C51 UART
Responding to: ???'s previous message
A few days ago we were discussing (here) 4B/5B NRZI as a more bandwidth-efficient means of encoding onto an RF channel (compared to Manchester) if you have more direct control of the emitted bit stream. 4B/5B could be thought of as 8B/10B when looking at 8 bits of data.

Here's an idea I just came up with for using a UART to source/sink data on to/from an RF physical channel. It's probably a lame idea, so feel free to shoot in down in flames.

Since you are using a UART, I'm assuming that the reason you want to use Manchester is for DC-balancing and not necessarily clock recovery. If you wanted clocking you'd be using a synchronous port. If you are not looking at an external hardware assist like Michael discussed, I think you can still achieve DC-balancing using the UART only. By using a UART you've already committed yourself to a minimum of two bits of overhead for the start and stop bits (asynch is sort of an 8B/10B code). Manchester itself cuts the data bandwidth in half, being considered an 8B/16B coding scheme. If you were able to Manchester-ize the UART's START and STOP bits too, you'd have an 8B/20B coding scheme.

Now, here's my half-baked scheme to achieve DC-balancing with the same 8B/20B efficiency using a UART, but without using Manchester or external hardware...

If you use a 4B/6B code and spread 1 byte (2 nibbles) to transmit out over 2 bytes through the UART, I think you can achieve DC-balancing. UART's transmit LSBit-first -- START bit (0), data bits 0-7 (in that order), and a STOP bit (1). The START and STOP bits are already balanced, so move inward from each end and have two more bits of balance by following the START bit with a 1-bit and preceding the STOP bit with a 0-bit. This leaves 6 bits in between.

<tt>S 01234567 S</tt>
<tt>0 -------- 1</tt>

Becomes:

<tt>S0 123456 7S</tt>
<tt>01 ------ 01</tt>

Expand one nibble of your data byte into a DC-balanced 6B symbol according to the following taken from RF Monolithics, Inc. Appnote #43:
<tt>
Nibble = 0 --> 010101
Nibble = 1 --> 110001
Nibble = 2 --> 110010
Nibble = 3 --> 100011
Nibble = 4 --> 110100
Nibble = 5 --> 100110
Nibble = 6 --> 100110
Nibble = 7 --> 010110
Nibble = 8 --> 011010
Nibble = 9 --> 101001
Nibble = A --> 101010
Nibble = B --> 001011
Nibble = C --> 101100
Nibble = D --> 001101
Nibble = E --> 001110
Nibble = F --> 011100

SBUF = (table[nibble] << 1) | 0x01;
</tt>
Then, likewise expand the other nibble of your data byte and transmit that. You would want to ensure that you transmit back-to-back so there is no idle (marking) time between UART bytes.

Do the reverse for the receiver, looking up a nibble value in a (sparsely populated) 64-byte 6B symbol table.

Sending a few 'A' nibbles will emit alternating 1's and 0's for a receiver-conditioning preamble.


List of 10 messages in thread
TopicAuthorDate
Manchester Encoding on 89C51 UART            01/01/70 00:00      
   RE: Manchester Encoding on 89C51 UART            01/01/70 00:00      
   RE: Manchester Encoding on 89C51 UART            01/01/70 00:00      
   RE: Manchester Encoding on 89C51 UART            01/01/70 00:00      
   RE: Manchester Encoding on 89C51 UART            01/01/70 00:00      
      RE: Manchester Encoding on 89C51 UART            01/01/70 00:00      
      RE: RFM Appnote #43 contains an error            01/01/70 00:00      
   RE: error control??            01/01/70 00:00      
      RE: error control??            01/01/70 00:00      
         RE: error control??            01/01/70 00:00      

Back to Subject List