Synchronizing USART Asynchronous Communication

Thread Starter


Joined Jan 18, 2008
I am sending 16-bit data (2 bytes) from one enhanced mid-range PIC to another using the EUSART module in each. I am asking for ideas to ensure that the two bytes are received and/or recognized in the proper order. I could establish two-way communication but want to avoid doing that for the present. Baud is 9600.

Some possibilities I have considered are:

1) Send one byte in duplicate;
2) Require that both bytes be received within a limited period (say 2.2 mS) with a delay between transmission of each pair (say 1 mS); and
3) Gate the transmission (say once every 5 mS) and require a period with no data (say 1 mS) to initiate a "true" read (very similar to #2 above).

Any other approaches? I am currently favoring approach #1.

Thank you.



Joined Jul 18, 2013
One method used in Modbus is to send a CRC (record check) Byte at the end, but it would need to be calculated for each TX.
Why would you suspect that they would not be received in the proper order?
The pic Pgm decides the data sequence/order.


Joined Dec 15, 2009

Roman Black have an interesting page about 433MHz RF transmission. I know this is not quite what you are looking for but he says this:

System to receive a byte;
This is a little bit more complex and depends how you want to handle detecting a preamble and packet size. As a general system to receive a 10 byte packet, it could be done like this;

1. must first detect a valid start pulse >200uS, then can try to record 8 bits
2. record 8 bits. If any is >200uS, is some error (static) so start again
3. if we had a good start pulse, and 8 good bits, record it as a received byte!
4. after a full packet of 10 contiguous bytes is received, all done!

Basically this C function below will wait until 10 contiguous (sequential) "good" bytes are received. A "good" byte must have a good start bit followed by 8 good data bits. If static or noise is received the function will just keep resetting itself until 10 good contiguous bytes occur.

But, I could be way off... :rolleyes:


Joined Apr 16, 2011
4) Convert the 16 bit word to ASCII (either decimal or Hex) and send with CR and/or LF, or 0 as delimiter
5) Send four nibbles, where each nibble is contained in the lower 4 bits of each transmitted byte, and the nibble number is contained in the top 2 bits of each transmitted byte
6) Send four nibbles, where MSB set indicates first nibble
7) as option 5, but 3 sets of 6 bits
8) use the 9-bit option available on some USARTs and use bit 9 to identify high or low byte

Thread Starter


Joined Jan 18, 2008
@MaxHeadRoom: Sampling rate is many times (>100 ) that of sending rate. The transmitter is doing little else presently than sampling and sending pairs of bytes. I could slow it down (e.g., like in options 2 and 3, but in theory (at least in my mind), if a byte is voided at the reception end, say from one of the error flags, the next byte received without error might be the second byte of the pair. Your are probably right that it is unlike.y. I have done this type of async. communication before in which the MSB was characteristically different from the second byte. I flashed an LED on error and have yet to see one. However, the sampling rate in that device was slower (only 100 Hz) than the sending rate. CRC is an option I had not considered. Not faster, but maybe more elegant.
@nerdegutta That is an interesting approach and faster than duplicate sending or waiting millisecond(s), but it would require a bit-banged USART. I have used one kindly provided by K8LH (Mike), but the hardware version is so easy to use.

I should add that differences of a few milliseconds won't make a difference in the application. I still don't like to waste time unless needed.


Thread Starter


Joined Jan 18, 2008
Probably true, but realistically all I need to identify is whether a received byte is high or low. Sampling and transmitting are so quick compared to what I need that having the low byte from one transmission and a high byte from a close, but latter transmission won't make a real difference.

I was looking it as a 16-bit problem. As it turns out, my data are really 14 significant bits, not 16 bit. They come from an AS5048 magnetic encoder. Sorry for my loose description in the problem statement. The two MSB from that encoder are error and parity bits that can be removed once they are received by the transmitting MCU.

A simple sequence of rotates will clear the top bit of two, 7-bit nibbles of data. Then using that bit, I can identify the high byte. In other words, do what hexreader suggested with 9-bits but using only using the 8-bit EUSART. I have not had a chance to read up on the 9-bit mode, so that may actually be easier. In any case, I have a simple way to identify the high byte without sending it twice.