18F25K80 Timer/RS-232 off by factors of four

[OldGuy]

Thanks Ttelmah.

I found that example, used it in my program, and seems to work well.

But it shares the same problem as I was having when using receive_buffer, I was hoping it would clear up the problem.

I'm receiving an 18 character string from RS232. Another receiver device gets the string reliably, so I think transmission is OK. But for some reason, the last two or three characters seem to arrive corrupted about half the time, the rest are all correct.

Ever seen anything like that?

[gaugeguy]

What is the exact baud rate of each device? A slight difference between the two can show up at the end of long strings of back to back characters.
You will need a scope or logic analyzer to measure the exact baud of each when they are transmitting.

[OldGuy]

Gaugeguy -

I did the best I could measuring baud on both sides with my scope, and they were very close, both 104uS plus or minus a tick. With the UESART allowing up to 3% correction, should be good on that count. Both sides are resonator-driven.

The intermittent characters always happen after the 16th one of the stream, the earlier ones are always fine. I've put a 2mS delay between the byte sends, so baud errors shouldn't be cumulative, and my buffer size is 32, plenty big.

It's a real head scratcher. I could just shorten the strings, but I know it will come back to haunt me if I don't find the real problem.

[PCM programmer]

What does your PIC program do after it has transmitted these 18 bytes ?

[Ttelmah]

The key thing with this type of problem is to 'narrow things down', and try
to work out where it actually appears.
Now, it sounds as if you control both parts of this?.
Can you setup the transmitter to just send the 18bytes?. No pauses.
Then stop for perhaps half a second. Do you have something like a USB
serial port as well?. Or have you got the USB connection made to your
PIC?. If so, then I'd suggest getting rid of all 'processing' in the PIC, and
just run with a basic routine, that receives the 18 characters, and then
prints these directly out to the USB (or to the USB serial port). It really
is the first basic test, to verify that the corruption is or isn't there with
nothing else being done.
Remember the '3%' figure, is the sum of the errors at both ends. Just a
1.5% error at each end, if in the opposite directions, can give problems,
however this sounds more as if perhaps something you are doing is
disabling interrupts after the 16th byte.
Worth just trying with the #USE changed to:

#use rs232 (stream=XBEE, baud=2400, xmit=PIN_B6, rcv=PIN_B7, PARITY=N, BITS=8, BRGH1OK, ERRORS)

This ensures the BRGH bit can be set, and allows a slightly more accurate
baud rate setup.

You say 'resonator', If I remember correctly, quite a few resonators do
not 'like' the HSH mode. This specifies high drive current for crystals,
but in some cases can result in resonators being overdriven. Try with
HSM. It may be that you are getting a harmonic problem with the
resonator at this high drive.

[OldGuy]

I think I'm on to something.

I've got these two PCBs communicating via RS232 going through XBEE transceivers, different PICs on each side. The XBEE modules which should be transparent. The RS232 data going into one of them should come out of the other one looking like the same data. In this configuration I get the errors.

However, I tried unplugging these modules from both boards, and ran the signals directly from the two PICs together via some wires, so the PICs are directly talking to each other.

Works perfectly in this configuration, so must be something related to the XBEE modules.

One step closer!

[Ttelmah]

Double check your XBEE modules are the same version.
and that they are genuine Digi modules.

There are issues with some firmware versions that sound like this....

[OldGuy]

I removed the the S2 Digi XBEE modules and replaced them with S2C DigiMesh modules, and it works perfectly!

Many thanks to your help in getting to this point. I've learned a lot!

- Brian

[Ttelmah]

'Narrowing things down', is a critical programming 'tool'.