Subversion Repositories manchesterwireless

Manchester Wireless Core

================================= Overview ====================================

This core was created to serve as a decoder for incoming Manchester encoded

data. This project was developed using an ASK A315 transmitter/receiver pair

obtained from Sparkfun.com. The transmitter was driven by an Atmel AVR

microcontroller. The receiver's output was was plugged into a Xilinx Spartan-3

starter board obtained from Digilent.

The ASK equipment is convenient in that when the input of the transmitter is

driven high, the output will also go high, and when the input goes low, the

output goes low. There is a caveat, however. The receiver's input must make

high/low transitions at a certain minimum frequency to prevent the receiver

from outputting random garbage. Furthermore, there is a maximum frequency at

which these transmitter/receiver pair will operate.

In brief, the Manchester encoding is trivial: 0 is converted to 10 and 1 is

converted to 01, where 0 and 1 refer to sending the data line of the ASK

transmitter low (0) or high (1) for one bit length. When programming the

microcontroller it was easiest to shift the bits of the message off to the

right and encode/transmit one bit at a time. Take the binary string 1000, for

example. The first zero is shifted off, and 10 is sent. Likewise, the other two

zeros are shifted off and sent. Finally the 1 is sent as 01. This gives a

transmission of 10101001. Note the encoded bits are are in reverse order of the

original; when the Manchester Wireless Core decodes the bits, it will present

them in the correct order as 1000.

Because of the asynchronous nature of the input, the challenge is in the

receiving side. To send a message, then, this core defines a protocol that must

be adhered to. First, the transmitter sends four high bits. Then the

transmitter sends one low bit. Then the data stream begins. Finally a few "end

transmission" bits are sent. Continuing the example above, the total message

would be :

11110                 10101001             0101

start signal begin    data stream begin    end transmission

Note that the spaces between the 0's and 1's are added for readability.

================================= User's Guide ====================================

The file globals.vhd has the constants which must be configured by the user.

Those constants are

WORD_LENGTH : The number of data bits before encoding. In the overview, above,

the WORD_LENGTH was four bits.

INTERVAL_MIN/MAX_SINGLE, INTERVAL_MIN/MAX_DOUBLE : The number of FGPA clock

cycles that must pass before the algorithm classifies a single/double/quadruple

one/zero. For example if the transmitter bit length is 1 ms and the FPGA clock

is 50 MHz, then the nominal number of FPGA cycles required to classify a bit as

being a single is 1 ms / (1/50E6 cycles/second) = .001/2E-8 cycles = 50000

cycles. The transmission, for whatever reasons, will not be exactly 1 ms, which

is the reason for having a MIN and MAX interval for the single/double and

quadruple constants. Some experimentation may be necessary to get the best

performance from this core. It is recommended that you synthesize the

singleDouble.vhd module, which classifies single/double zeros/ones and see

which windows will provide the best performance.

INTERVAL_QUADRUPLE : The series of ones at the beginning of the transmission

must be at least INTERVAL_QUADRUPLE cycles. To get this constant, multiply the

nominal single bit length by four and add some padding.

Out of the box, the manchesterWireless core will decode one message, then set

the ready_o flag, then stop. The core must be reset to start waiting for the

next message. See synthTest.vhd for an example of how to use this core.

synthTest.vhd is used to create a simple counter which waits for and displays

the digits 0 to 9 on the LEDs of the Spartan-3 board.

================================= Design ====================================

manchesterWireless is composed of three modules which flow from the top down:

1)waitForStart : Waits for the data_i to go high for INTERVAL_QUADRUPLE

cycles then sets ready_o to 1. One process is in wait for start. When data_i

goes high, a counter will measure how long it stays high. If data_i stays high

for longer than INTERVAL_QUADRUPLE clocks then the ready_o flag is set and

remains set until the core is reset; the 'lock' variable keeps the flag set

after the window is reached. If data_i drops to zero before the ready_o flag is

set, then the counter will be set to zero.

2)singleDouble : Once waitForStart is finished, singleDouble classifies

single/double zeros/ones which it outputs on q_o. q_o is a four bit vector

with the following mapping

q_o(0) <= single_one;

q_o(1) <= double_one;

q_o(2) <= single_zero;

q_o(3) <= double_zero;

The constants set in globals.vhd are such that there is never an overlap

between what is classified as a single or a double.

TODO: The transition process infers a clock from transition_i. This should

probably be eliminated by polling transition_i on a clock edge.

3)decode : Takes serial input from singleDouble and provides a decoded parallel

output. The controller process counts how many bits have been decoded and

stops when all of the message has been encoded. The next_state_decode and

output_decode processes keep track of the bits coming from singleDouble and

decodes them. The challenge is that we receive a single_one followed by a

double_zero, that is 100, we will decode a 0 from the 10 and place the last

zero in 100 in the left most place of the insert buffer "0_". At this point,

as can be seen by inspecting the next_state_decode process, only a single

or double one is possible.

TODO: The next_state_decode process will reset when an unexpected next_state

is provided. For example, from the state one_0, the only possible valid

next state is one_1. Any other next_state will send the FSM to reset. It

would be good to reset the entire circuit at this point.