CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

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

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Rohit de Sa



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

Choosing 'Manchester-like' binary strings for wireless Rx-Tx
PostPosted: Tue Jun 22, 2010 9:37 am     Reply with quote

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 Confused .

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?
Code:

binary decimal  ASCII
---------------------
(list removed since it has some erroneous values. Look below for correct list)

I hope I've been clear enough.

Rohit


Last edited by Rohit de Sa on Thu Jun 24, 2010 12:52 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19496

View user's profile Send private message

PostPosted: Tue Jun 22, 2010 3:07 pm     Reply with quote

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



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Tue Jun 22, 2010 10:36 pm     Reply with quote

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



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

PostPosted: Tue Jun 22, 2010 11:53 pm     Reply with quote

Thanks Ttelmah and FvM.

Ttelmah wrote:
The values you post, don't look 'manchester like' to me. Many have imbalanced numbers of 1's and 0's....
Sorry, foolish coding error on my part. And I was so sleepy that I didn't check the values before posting. Embarassed Here is the proper set of characters.
Code:
00101011
00101101
00110011
00110101
00110110
01001011
01001101
01010011
01010101
01010110
01011001
01011010
01100101
01100110
01101001
01101010
10010011
10010101
10010110
10011001
10011010
10100101
10100110
10101001
10101010
10110010


Ttelmah wrote:
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.
I don't see how I can do this while still achieving a balanced number of 1s and 0s. Since the numbers are Gray code, only 1 bit would/should change. Wouldn't this cause the number of 1s in the character to become more than the number of zeros (or vice-versa)?

FvM wrote:
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.
I've got a bunch of other background tasks that need to be done, so I'm running out of free processor time. I suppose I could squeeze in the 'true' Manchester decoding routines, but that would make my code messy. Having the PIC's hardware handle the dirty work makes my code more 'readable'.

FvM wrote:
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.
Yes, I feared that this problem would crop up. I've read elsewhere on the forum (SherpaDoug, if I'm not mistaken) that the hex stream "BABEFACE" is a nice synchronization string.


So my transmission will be something like this:

LAM-[spam]-synch (6 chars)
Start sequence (2 chars)
Data length (1 char)
Data (n chars - not more than 32)
Checksum



Rohit
Ttelmah



Joined: 11 Mar 2010
Posts: 19496

View user's profile Send private message

PostPosted: Wed Jun 23, 2010 2:01 am     Reply with quote

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



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

PostPosted: Wed Jun 23, 2010 2:12 am     Reply with quote

Quote:
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).
Aah, so what you're saying is arrange the numbers in a 'Gray code-like' sequence. The numbers will obviously not be a traditional Gray sequence (since more than 1 bit changes at a time). Sorry, I couldn't quite get that the first time Razz

Thanks!

Rohit
nina



Joined: 20 Apr 2007
Posts: 111

View user's profile Send private message Send e-mail

manchester
PostPosted: Wed Jun 23, 2010 4:26 pm     Reply with quote

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



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

PostPosted: Wed Jun 23, 2010 8:45 pm     Reply with quote

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



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

PostPosted: Thu Jun 24, 2010 12:50 am     Reply with quote

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

Code:
Binary   Decimal    Hex   ASCII
00110011   51       33      3
00110110   54       36      6
00110101   53       35      5
00101011   43       2B      +
00101101   45       2D      -
01100110   102      66      f
01100101   101      65      e
01101010   106      6A      j
01101001   105      69      i
01010011   83       53      S
01010110   86       56      V
01010101   85       55      U
01011010   90       5A      Z
01011001   89       59      Y
01001011   75       4B      K
01001101   77       4D      M
10100110   166      A6      ¦
10100101   165      A5      ¥
10101010   170      AA      ª
10101001   169      A9      ©
10110010   178      B2      ²
10010011   147      93      “
10010110   150      96      –
10010101   149      95      •
10011010   154      9A      š
10011001   153      99      ™


Rohit
Rohit de Sa



Joined: 09 Nov 2007
Posts: 282
Location: India

View user's profile Send private message Visit poster's website

PostPosted: Sat Jun 26, 2010 10:05 am     Reply with quote

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. Very Happy I'm still doing range tests and other stuff; but hey! BABE FACE is brilliant!

Rohit
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group