| ??? 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. |
| Topic | Author | Date |
| 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 |



