Choosing 'Manchester-like' binary strings for wireless Rx-Tx

[Rohit de Sa]

This is with reference to this thread in the code library: http://www.ccsinfo.com/forum/viewtopic.php?t=22525&start=0&postdays=0&postorder=asc&highlight= I've created a new thread here since the Code Library Sticky explicitly says that my queries may not be answered .

I'm trying to write a driver for cheap 433MHz wireless modules, not too different from the ones shown here:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8949

I've had success transmitting data, but now I'm looking for a more robust protocol. Using the PIC's built in UART seems like a good idea. Since I need to send Manchester-like data to prevent saturating the RX, I thought of using a similar scheme as presented by Jmann in the first post.

Jmann's method (I'll explain very quickly so that others need not go through the whole thread) involves encoding a nibble using a DC-balanced 8 bit number, though a data-table approach. This DC-balanced number is then dumped out through the UART 'fooling' the RX module into thinking that its receiving Manchester-encoded data).

I wrote a simple QBasic program to generate all 8-bit 'Manchester numbers', ie numbers with equal numbers of 1s and 0s, and each number having no more than two consecutive 1s or 0s. I also kept in mind that the UART start bit is a low (0), and the stop bit is high (1), thus ignoring numbers with LSbits as 00 or MSbits as 11 (UART data is sent LSB first). This gave me a list of 44 numbers, which I've appended to the post for your convenience.

Now my question: which 16 binary strings should I choose to encode my data? Should I prefer certain binary numbers over others?

[Ttelmah]

The values you post, don't look 'manchester like' to me. Many have imbalanced numbers of 1's and 0's....

However ignoring this, the key to an ability to recover if something is missed, is the 'distance' between values selected. Ignoring the balancing aspect for a moment, if you have a code using two values like:

01010101
and
01010111

It only takes a one bit change to select the wrong value with a large error.

What I'd suggest you do, is do a search for 'gray codes', which are binary numbers arranged in a sequence with the _least_ change between successive values, then go through these, and pick the entries which meet the balanced 1's and 0's criteria. Then from this sequence, space your selections as far apart as possible.
Then on receipt you can choose the 'closest fit' from the table, when an entry is wrong and have a reasonable probability that this will be the 'right' value.

Best Wishes

[FvM]

Following the specification of simple AM modules, that are said to work with 30% to 70% duty cycle of the input bit stream, the suggested method should work. I wonder however, why you don't use true manchester coding? For the low bit rates of usual RF modules, it can be done in software rather easily.

The other point, that usually causes difficulties is synchronization on receive. For reliable operation, a preamble pattern and bit exact sync detection at the receiver are strongly recommended. The latter can't be achieved by a UART anyway.

[Rohit de Sa]

Thanks Ttelmah and FvM.

[Ttelmah]

Gray codes, are just normal binary numbers, 're-ordered'. Just re-order your table, in the order the entries appear in a gray code list of binary numbers (use the default one starting at zero).

Best Wishes

[Rohit de Sa]

[nina]

Rohit

Could you explain me what is the advantage use manchester protocol or instead of whatever other protocol?
How select diferent kind of protocol to different applications?

Many thanks

Nina

[Rohit de Sa]

Manchester is not really a 'protocol'; its an encoding scheme. Most simple ASK type RF modules require a 'DC balanced' stream of data. Put simply, this means that over a time interval the number of 1s should be equal to the number of 0s. If there are more 1s in the data than 0s the receiver will get 'saturated'. If there are more 0s than 1s, the receiver will get biased towards 0. Once this happens, data transmission gets severely impaired.

Think of this situation as data being sent serially through a capacitor. More 1s would cause the capacitor to slowly get polarized in one way. More 0s causes it to slowly polarize in the opposite orientation.

Do a wiki search for 'Manchester encoding'.

Also do a forum search for the terms 'Manchester encoding' and select 'Search for all terms'. You will find several links that will be of help.

This link is good http://www.ccsinfo.com/forum/viewtopic.php?t=23886&highlight=manchester+balanced

Rohit

[Rohit de Sa]

In continuation, here is the list of numbers arranged in Gray-code-like sequence, just in case it will be useful to others :

[Rohit de Sa]

There's already been much talk about this, but I felt that I too must add my experience. I was going through the process of looking for appropriate start sequences and LAM (look-at-me) strings. I tried using a variety of characters; I varied sequence and string lengths, tried everything possible, but my data validity was not too good, varying between 30% and 70%.

The main problem was the start sequence. It seemed to me that the UART couldn't get a proper 'lock' (I was cautioned about this by FvM). I tried using different combinations of the binary strings posted earlier, but to no avail. Finally, I used the *unbalanced* sequence 0xba 0xbe 0xfa 0xce.

Pleased to say that upto now I have obtained 100% UART lock, and total data integrity. I'm still doing range tests and other stuff; but hey! BABE FACE is brilliant!

Rohit