Problem with wireless serial transmisson

[betwixt]

Hi Davids.

Reset the UART as quickly as possible when a false sync byte is detected. The information is a continuous stream of bytes so the sooner you start looking again, the faster the correct sync will be found. In PIC language, I clear the USART twice because it uses a FIFO and it is possible one byte is still in the queue, I'm not sure if AVR is the same.

Brian.

 

[david_0607]

hi Brian,

thanks

I will try it soon

best regard

davids

 

[Ehtisham adil]

Very good discussion, quite lengthy but prety informative.

Brian, i learned a lot from your experiences. Specially the coding scheme you suggested ( i will experiment it soon ).

I am interested to work on the wireless transmission as this is also part of my project. Here in my city, available module are pt2272 and pt 2262. Had anyone worked on it? I would need help.

Ehtisham

 

[gaurav_sharma132]

Betwixt really thanks for all this information. :smile: I posted this problem long time before. And reading it now again. Its very refreshing. :smile:
I will experiment with this coding scheme because due to shortage of time I developed Spy robot Using encoder/decoder and LabVIEW.

 

[matg0d]

Hello to everyone, i read all the thread, but still have some questions about how these UART encoding system works...

1. I didnt fully undestand the UART system, and there isnt much material about how exactly the bits are sended, soo the main question is, the Start bit is a 0-1 transition, and the stop bit is...? It is an extra bit just to have a 1-0 transition?


2. I made the look-up table for the encoded numbers from 0 to F. It end up like this:
55h, 56h, 59h, 65h, 66h, 69h, 6Ah, 95h, 96h, 99h, 9Ah, A5h, A6h, A9h, AAh.
Is that right?


3.There is just those combinations of bits that are DC balanced(equal number of 0's and 1's), soo the sync and start bytes needs to be one of those in the look-up table?


4. Brian said that using 55h or AAh as a sync byte instead of A6h would not work soo well cuz when you switch to the data packages it would lost sync, but isnt both of them an encoded number? (assuming that my look-up table is right...)


5. Now to see if i understood what as been said here, to successfully send one byte of data from one point to other, using an RF link and the UART, i should make a data package like this : {Sync byte, Sync byte, Sync byte, Start byte, MSB-encoded, LSB-encoded}
Is that right?


Thank you for sharing you knowledge :-D

 

[betwixt]

I got the PM matg0d.

1. not quite, in standard serial transmission it isn't the transistion that indicates the start or stop, it's the length of the bit itself. In a standard UART, the input is continuously sampled at a higher than baud rate, typically between 3 and 16 times the baud rate is used, depending on the way the UART circuit is designed. A majority sampling decision is made to decide if the input is high or low, this gives good immunity against noise and 'false starts'. When the start bit has been verified this way, the remainder of bits are also majority sampled but at a time which would ensure the sampling took place near to the middle of the bit length. It's a bit difficult to explain in words but I'll try: Imagine 16 times oversampling is used and the baud rate is 1200. The sampling would take place at 16 x 1200 = 19,200 times per second. The UART hardware would look for a continuous stream of samples which were at start bit level and if it found 8 consecutive bits it would assume it was in the middle of the start bit. From then on, it would make a majority decision near the middle of the following data bits. If the sample counter was set to zero at the expected start of each data bit it would look at samples 7, 8 and 9 and if 2 out of three were the same polarity it would assume that to be the level of the bit.

2. your numbers are correct but the sync byte is 0x66 and the start byte is 0xA6.

3. the start and stop bits are already opposite polarity so there is no need to worry about them. You might get two consecutive zero bits or two consecutive one bits but over the whole byte the number will balance.

4. the problem with 0xAA and 0x55 is that when the continuous stream of bits is received, it doesn't have any obvious indication of where one byte ends and the next starts . When the data steam has no gaps in it, the start and stop bits look just like data and it isn't possible to find the boundary between the bytes. By using 0x66 a framing error will result in either 0x69 or 0x99 being seen so whenever these appear at the start of a block of data all you do is reset the UART and check again. That's why several sync bytes are sent, it give it chance to try to find the 0x66 again. If you write down a line of the 1's and 0's of AA and 55, including the start and stop bits between them, you will see there is no way to 'frame' a byte, in fact almost any 10 bit block (start+data+stop) looks like all the others. If you do the same with 0x66 you will see it is much more obvious.

5. Correct! First adapt the UART to see the 66 sync byte by reseting it if it sees 69 or 99, then start ignoring the 66 until you find a byte of A6. you are now synchronized and ready to decode the data.
You can send either the MSB encoded or LSB encoded first, it doesn't matter which as long as the receiver knows which way to put the bits back together. Do it wrong and the top 4 bits and bottom 4 bits of the data will appear swapped over.

You might need to use more than three sync bytes, I would suggest at least 8. It's a trade-off between how long it takes to send the block and how likely it is to fail sync. You might have to experiment to find the optimim number in your situation.

Brian.

 

[matg0d]

A really big THANKS to you Brian, with that i feel ready to build my project without any doubts on the UART through RF transmission. Another thanks to FvM and to everyone that helps making thing thread soo useful.
Lucky i find this forum, hope i can contribute and learn much more here