Maximum Baud Rate error tolerance

[keithdoxey]

Hi All,

Several of the posts here recently have been about problems recieving or transmitting serial data.

I was wondering what the maximum allowable error is to still retain reliable communications. I realise that this is probably a similar question to "how long is a piece of string" but I have been thinking about this quite a bit and playing with Mister_Es superb little utility.

I currently have a project with several pics receiving IR data and forming messages to be sent to the main processor. The IR receiver PICs are 16F88s running at 4Mhz and the main CPU is an 18F452 running at 20MHz. Comms are at 9600 at the moment although I may speed this up once I have everything working OK.

It occurs to me that the actual error is not the overall consideration but the difference between the error rates.

e.g. if both PICs are running with an error of +8.5% then the difference is zero so comms should be perfect but if the two devices have different error rates then the situation could be totally different.

If device A was +8.5% but device B was -1.5% then overall the discrepancy is 10%.

How far out of sync can the two devices be before the error is too great ?

Thanks

[mister_e]

depending of the baudrate i guess. But to me bellow 1-2 % is good.

You could even use a Synchronous serial comm to make it 100% (hum hum) reliable... but the down side is that it use more i/o.

I2C in slave/master is popular now..

Anyways, why don't use the same crystal speed (appart of the PSU current, EMI etc)?

[keithdoxey]

depending of the baudrate i guess. But to me bellow 1-2 % is good.

Thats what I figured.

You could even use a Synchronous serial comm to make it 100% (hum hum) reliable... but the down side is that it use more i/o.

Cant do that because I am already using all the pins on the 452. Some are shared for LCD/Databus. Also the serial port on the 452 is shared amongst several input streams.

Anyways, why don't use the same crystal speed (appart of the PSU current, EMI etc)?

I may well do in this instance for the comms described above but some devices that this will communicate with are already in use and run at 4MHz 9600 baud but messages are very short, typically a single byte.

[BigWumpus]

...in the good old days, a UART (8250) uses a clock of 16-times (?) the baudrate. So ist can sample the signal feg. at the middle of die time.

What is about saying:
1/8 of a bit jitter in 10 bits ? (8N1)
It would be 1,25% error.

I think it belongs to the intelligence (!) of the receiver to take the best samplepoints inside a serial character.

Modern PICs are able to get very close baudrate by using higher frequencies and bigger dividers.

If you are using an PIC-PIC-conversion, you are able to define your own baudrate by using "good" dividers of a standard frequency.

[Luciano]

Hi Keith,

Use a baud rate friendly crystal. (0% baud rate error).

18.432 MHz for the 18F452 and 3.6864 MHz for the 16F88s.
Does your compiler support these oscillator frequencies?

Best regards,

Luciano

* * *

Baud rate friendly crystals:

1.8432 MHz
3.6864 MHz
7.3728 MHz
11.0592 MHz
14.7456 MHz
18.4320 MHz

[keithdoxey]

Use a baud rate friendly crystal. (0% baud rate error).

18.432 MHz for the 18F452 and 3.6864 MHz for the 16F88s.
Does your compiler support these oscillator frequencies?

Baud rate friendly crystals:

1.8432 MHz
3.6864 MHz
7.3728 MHz
11.0592 MHz
14.7456 MHz
18.4320 MHz

Hi Luciano,

According to the PBP manual the only supported frequencies are
Oscillator speed in MHz: 3(3.58) 4 8 10 12 16 20 24 25 32 33 40 so any timing function would be off. I could compensate for this but it would make my IR timing routines more complicated.

As I said at the start, if BOTH PICs are off by the same amount then it wouldnt matter if it was 50% as they would be running at the same speed.

My question was more out of curiosity as to how far out you could get before comms would be unreliable.

Thanks to everyone for the replies