Originally Posted by Sceadwian

The sync can't be 100% perfect every time if the baud rate isn't the same, when the error is high enough and the two clocks are at their worst sync point is where the errors occur, once the bit error occurs in a stream synchronization is lost and can't be regained until there's a break in the transmition because it won't be reading the start and stop bits properly anymore.

But you're talking about a baud rate error larger than a single byte, if the baud error is smaller than that, then it can't lose synchronisation, because the stop bit and subsequent start bit resyncronise at every byte.

Not sure how to do the math on that, so what baud error are you saying is required for it to no longer sync?

Okay you stated some numbers Pommie, how'd you come up with them? Cause I've had corrupted data at around 3%

Think about when the signal is sampled. After the (leading edge of the) start bit is received there is a wait of 1½ bits before the first data bit is sampled. Errors will occur if the sample is ½ a bit either way when the 8th bit is received. So, from the start bit to the final sample is 9½ bit lengths. One half in nine and a half is around 5%.

Some software routines don't sample as often and so miss the start of the start bit and thus the acceptable error is smaller.

Mike.

It's more than likely the GPS unit has a baud rate compatible crystal. Mbarren has hopefully already moved on. I've never taken apart a commercial device that doesn't work with a baud rate compatible frequency on the output stage of it's serial devices.

Originally Posted by Pommie

Think about when the signal is sampled. After the (leading edge of the) start bit is received there is a wait of 1½ bits before the first data bit is sampled.

Perhaps a little 'nit-picky', but the way I do it (which I think is pretty universal?), is to resample the start bit half a bit after it's detected, then sample each bit after a one bit time.

The reason for this is so you can abort the read if the start bit isn't still valid after half a bit time, which of course it still should be.

That's good for start bit detection, what happens if it confuses the start bit with a data bit? You'll get garbage out, for at least that byte, and every sequential byte if the next data byte happens to have a data bit set in the receivers perceived start bit spot.

Originally Posted by Sceadwian

That's good for start bit detection, what happens if it confuses the start bit with a data bit? You'll get garbage out, for at least that byte, and every sequential byte if the next data byte happens to have a data bit set in the receivers perceived start bit spot.

That's how RS232 works, and is in no way affected by clock accuracy (within reason) - obviously it shouldn't confuse the start bit with a data bit, because the start bit 'should' come along first.

It's an obvious reason why RS232 commonly uses 'packets' and error checking.

Define 'within reason'
The start bit only comes along first _IF_ the baud rates are perfectly in sync. Desync near the end of a byte and all hell breaks lose. Once the sync is lost the receiver will lock onto the next start bit which may be a data bit, it'll look for 8 bits which it'll get no matter what they are, and look for another stop bit and try to resync which is more than likley goign to be another data bit. It's also why there is an option for 2 stop bits, which is many times a blanket cure for sync issues.

Nigel, seriously, I'm not guessing here, I've actually tested and observed this, just not the threshold of what the baud difference needs to be for it to occur, cause honestly it's UART and clock drive dependant.

Originally Posted by Sceadwian

Define 'within reason'
The start bit only comes along first _IF_ the baud rates are perfectly in sync. Desync near the end of a byte and all hell breaks lose. Once the sync is lost the receiver will lock onto the next start bit which may be a data bit, it'll look for 8 bits which it'll get no matter what they are, and look for another stop bit and try to resync which is more than likley goign to be another data bit. It's also why there is an option for 2 stop bits, which is many times a blanket cure for sync issues.

'Within reason' is within the acceptable baud rate error, which a previous poster calculated as 5% - anything under that 5% error is just as good as 0% error.

The two stop bits is more to give the receiver time to process the previous byte than an error prevention tactic - otherwise it might miss the next start bit because it's not ready in time. It was far more common in the old days, when you had mechanical printers and no buffers.

Found sometime to go over this in details and here're are my findings, which may be not be correct at all, so please hint out the problems.

Let's start with a perfect baud rate match between the transmitter and receiver:



Hopefully the image is self explanatory. I have assumed the receiver can poll the line status/voltage many times faster than the baud rate, to simplify things (I read about programming a PIC to handle 115200 baud rate with 4Mhz clock). That's why there is a solid gray area which shows constant monitoring of the line by the receiver. I've also assumed perfect vertical rising/falling edges.

Now here's where the receiver is running at a faster baud rate than the transmitter. This is what I think the maximum difference between the two baud rates can be:



Note that when receiver polls the line in where it expects the middle of the stop bit to be, it's just after the rising edge of the actual stop bit. If you stretch out the bottom wave any further, the receiver will read in the 8th data bit instead of the stop bit.
However, staying within the range shown in the graph, there will be no errors even in back to back transmission, since the receiver syncs to the start bit for each byte.

In situations where the baud rate of receiver is less than that of the transmitter, I'm not quite sure what would happen. If we assume that the receiver waits for the entire length of stop bit before polling the line for the next start bit, there is no way the receiver can keep in sync in back to back transmissions, unless the baud rates differ only by less than half a bit!
However, if we assume that the receiver will start polling the line for the next start bit right after checking for the stop bit (which is half way through it), then:



Putting the two situations together, I came up with this formula to find out if two different bit rates can work without errors in back to back transmissions:

which simply means, maximum +/- 5.2% of transmitter baud rate

This formula only works for a 8 bit data, 1 stop bit settings.

And here's a graph of it:



The red shaded areas are the safe areas.