Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

USART/UART data receiving problem

Status
Not open for further replies.
If the PIC only needs to read data from that particular GPS receiver, you can try adjusting the PIC baud rate generator up and down to find the hi/lo baudrate limits where you start to get errors.

Then pick the baud generator value right in the middle giving you the best possible reliability with that GPS device.

This is because it is likely the GPS device uses a non-perfect baudrate as well.
 
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.
 
Last edited:
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.
 
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.
 
Last edited:
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.
 
Last edited:
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:

**broken link removed**

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:

**broken link removed**

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:

**broken link removed**

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:

**broken link removed** 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:

**broken link removed**

The red shaded areas are the safe areas.
 
Last edited:
It's late here and so I can't work that out. Can you give us a percentage value? My initial view is 0.5 in 9.5.

Mike.
 
For the transmission baud rate of 38400, the receiver rate should be between -5% and +5.5% of 38400. as you mentioned before.
 
Whoo hoo, (best homer voice) right again.:D:D

BTW, well done on your analysis of the problem. Most people just accept given knowledge. You worked it out for yourself and will have a much better understanding of it because of that. You'll go far.

Mike.
 
As for my baud settings to receive GPS fix data, I will probably end up choosing SPBRG=d'31' instead of SPBRG=d'32'.
With SPBRG=d'32', I get -1.36% error, meaning a slower baud rate than my GPS. With SPBRG=d'31', I get +1.70% error, but faster, meaning there can be absolutely no problem since +1.7% < +5%, but depending on how the receiver circuitry works, even slightest of negative baud rate errors can cause corrupt data. I think this is where the datasheet with its pre-defined SPBRG values comes short of showing the optimal settings for this specific scenario.
After further testing, I might save those few bucks on purchasing a different crystal =]
 
That's what I was trying to get at mbarren. Design for 0 baud error and you don't have to worry what %baud error someone else designed for. If the absolute limit is 5% then the absolute limit you should design for is 2.5% and pray everyone else did the same, if someone else designed for 5% and you were off by even .1% the wrong way..
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top