Manchester Encoding/Decoding
Like I said in the previous post, the RF receiver will pick up junk data when the transmitter isn’t transmitting anything. This means that you need some sort of encoding or decoding method of the data to differentiate from junk in the air and actual data. This can be easily done through Manchester Encoding, which was used in Ethernet until 100Base-TX came along.
Manchester Encoding actually halves the data rate. The encoding is extremely simple, though. If you have a 1 in your data, it will be followed by a 0, if you have a 0 in your data, it will be followed by a 1. So the ASCII letter ‘A’, or 0100 0001 in binary, would be encoded as 01 10 01 01 01 01 01 10.
This allows for easy error checking- if a bit in the received data is not followed by its inverse, you know that the data is invalid. In other words, there are an equal number of ones and zeroes in the Manchester encoded data. Of course, there is that small chance that one byte of the random junk floating around is actually properly encoded, but these bytes can be avoided with a basic protocol on top of the encoding (possibly with a checksum).
Tonight I coded an implementation of manchester encoding/decoding to be encapsulated by a hardware UART from scratch. It was actually really easy, but it could probably be heavily optimized with some clever bitwise operations. I made direct calls to UART send and receive routines from the Manchester Encoding and Decoding functions so I wouldn’t have to pass around variables in main() or wherever I’m calling it from. For some reason, I wanted to write my own soft bit bang’d UART implementation, so I ended up doing that too. With the exception of optimization of the delay system, it works great.
I tested the code with a wired serial connection, and it works perfectly. Tomorrow I’ll hook up the whole wireless setup and confirm it’s working there. Other than that, I can start working on the I2C code for the digital temperature sensor that will be on my robot. After that–servo motor control (PWM stuff).
Note: my application of Manchester Encoding isn’t exactly what it officially should be used for. I’m just using it to encode/decode data blocks in order to distinguish junk data from real data, which doesn’t exactly fulfill the entire purpose of Manchester Encoding. I might also write a CRC sort-of implementation and use that instead if it takes up less bandwith (which I think it should).
One of the more important aspects of Manchester Encoding is that the clock can be extracted from Manchester encoded data from every other bit. Every bit in Manchester encoding is followed by its inverse, but in the electronics side of this, this means that there is a voltage level transition after every bit (1 -> 0 or 0 -> 1). One of the issues with digital communication over a wireless connection or a long distance connection is that the clock will often lose synchronization due to the lack of voltage level transitions (data might stay 1 or 0 for a prolonged period of time). Having a voltage level transition after every bit of data, however, means that the receiving end can precisely distinguish between each data bit and easily maintain synchronization during the data transfer.
USART, on the other hand, only synchronizes on every start bit of the packet frame. The trade-off with the implementation that I wrote is that I can use the built-in hardware UART, instead of bothering with bit banging my own serial interface with the wireless transmitters/receivers. I’ll see how this works out and whether or not it is reliable enough to stick with. Or maybe I should just enable parity in my UART connections instead of cutting my bandwith in half with Manchester encoding?, there are a few options.
Anyway, here is the code that should work for most AVR devices (with a USART): AVR Pseudo-Manchester-Encoding with Hardware UART
