The Microchip errata sheet for the above says not to use BRGH=1 because
of possible receive errors.

For the faster standard baud rates, you don't have a choice however. I
need to use a baud rate of 57,600 - which is only available with BRGH=1.

I can stand the occasional non-consecutive error (or up to a handful in
a row) by sending a NACK and getting the packet repeated - but not for a
lot of corruption - does anyone know what the nature of the corruption
is, how long it lasts for and what causes it?

Another point - using a clock rate of 16MHz with BRGH=1, the % error in
the book is 1.6%. What error could be tolerated??

>The Microchip errata sheet for the above says not to use BRGH=1 because
>of possible receive errors.
>
>For the faster standard baud rates, you don't have a choice however. I
>need to use a baud rate of 57,600 - which is only available with BRGH=1.
>
>I can stand the occasional non-consecutive error (or up to a handful in
>a row) by sending a NACK and getting the packet repeated - but not for a
>lot of corruption - does anyone know what the nature of the corruption
>is, how long it lasts for and what causes it?
>
>Another point - using a clock rate of 16MHz with BRGH=1, the % error in
>the book is 1.6%. What error could be tolerated??
>

I suspect this is a deep subject, but let me first just skim the surface
with a few observation from my own experience.

The microchip errata is not very specific, it simply says you
**MAY** have problems with errors when BRGH=1.

I have been using BRGH=1 on the 16c74 at 156250 bps without problems.
however I am transmitting short packets with error recovery, so if I
get an ocassional error the transaction is retried. This is not fatal.

Another issue, is that I am communicating with a mitsubishi M37450 and
consequently have complete control over matching baud rates etc. This
is something that might be a problem if your application requires you
to talk to a PC.

Just in the last few weeks I ran some trials with BRGH=0 and BRGH=1
and over millions of packets I could not pick any difference in the
error rate. (This was with short RS485 cabling). If anything the error
rate was slightly higher with BGRH=0. The trials were carried out at
38.4k.

The drop in sampling from x64 to x16, is probably going to make
the system more sensitive to slightly mismatched baudrates. This
is possibly the reason for the reported problems.

At this conditions PIC receive with errors (mostly on bit7).
Errors is depended from settings bit SREN, which is defined "don't care".
If bit SREN=1, for codes from 40h to 7Fh, bit7 frequently sets to 1.
for codes with bit0 set to 1, bit7 also sets to 1.
If bit SREN=0, random errors occurs.
Errors is also depended from SPBRG settings.
If decrease SPBRG value - 30 instead of 31 desired, error probability
decreases and errors from bit0 disappears. Other errors remains.

Work-around:
At the same circuit we change BRGH=1 to BRGH=0.
Calculated value for SPBRG at this settings is 7.
All works fine.
We check also at 19200 bps (SPBRG=3) and at 38400 bps (SPBRG=1). No errors.

>> PIC16C74/JW 9607 SAT alse working.
>> I have a project with 115.2 bps.
>
> Without any errors at all??

Yes, but in my project PIC most time transmitt data,
and receive a command.
This device is a hart rate monitor system (Holter monitoring)
that have 8Mbyte memory to storage 2 ch. ECG. And then all
memory transmitt into PC.
This work! And one problem - the power supply. Now I use 4 AA
rechargable and 2 MAXims DC-DC converter. And now I try to do
this with 2 AA battaries.