Ensuring byte-alignment for ASYNC over RF please dont rip this site Ensuring byte-alignment for ASYNC over RF

Ensuring byte-alignment for ASYNC over RF

When using ASYNC communications over an RF link it is often difficult to ensure that the receiver is properly syncronized at the byte level. If the receiver isn't syncronized you will see framing errors, invalid characters, or both.

Note: this discussion is based on the following constraints and asssumptions.

First, we want to transmit a continuous alternating sequence of 0's and 1's to condition the receiver and set up the bit-level syncronization. We can do so by repeatedly transmitting the byte value 0x55 as a preamble. This works because we send:

bit 0 (1)
bit 1 (0)
bit 6 (1)
bit 7 (0)

The receiving UART will nicely sync on this, but of course it could be misaligned byte wise. There are 5 possible conditions:

Now we have to come up with a way to convert the unaligned cases to the aligned case by taking advantage of the way the UART detects framing errors. We do this by transmitting a 0 data bit where the UART expects a stop bit (a 1). We carefully pick values to send so that the framing errors that we cause results in the UART translating the cases B, C, D and E to case A, sometimes through several steps.

So, in summary, the transmitter could send:

And now we know we have the correct byte syncronization!



Scott Lee Says:

Great idea in general. But why not just use a single byte that will correct all four byte alignment problems? 0xF0 seems to work great for me. In addition, 0xF0 is balanced unlike the four bytes you propose. Also if the data that follows is manchester encoded then the receive routine can assume a sync (reset the receive buffer) in the event of a FERR or a 0xF0 (or a single byte that is not valid manchester if you prefer).

See also:

file: /Techref/microchip/ammermansync.htm, 5KB, , updated: 2004/5/5 15:49, local time: 2021/10/21 10:37, owner: RVA-RAm-R00a,

 ©2021 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://www.piclist.com/techref/microchip/ammermansync.htm"> microchip ammermansync</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.

Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2021 contributors:
o List host: MIT, Site host massmind.org, Top posters @20211021 Neil, Harold Hallikainen, Alan Pearce, RussellMc, Bob Blick, Allen Mulvey, Dwayne Reid, madscientistatlarge, Sean Breheny, Justin Richards,
* Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.

Welcome to www.piclist.com!