Possible Baud Rate Tolerance Issue

[MotoDan]

Thanks PCM for the terrific detective work on finding a high tolerance internal osc part! It looks like the PIC16F1717 will drop right in. I was not aware that higher precision parts were offered by Microchip. Given the amount of trouble a wider tolerance oscillator can cause, I would think Microchip would make all of their parts using higher tolerance internal oscillators. What good is an MCU with built-in UART and 16 MHZ oscillator if it won't perform within it's specifications?

Well, lesson learned! Now I just need to figure out the best way to fix the 2,000 units that have been built and shipped! Replacing the PIC for these units (4,000 PICs) is not a very viable solution. Looks like the best I can do is come up with a way to compensate for the inaccuracies of the internal osc.

Thanks again to every one who offered their expertise!

[newguy]

Our existing product line was designed starting in 1998. Over the years, needs were identified and things were added to address the issues that needed to be addressed.

One of the issues that was tagged as a shortcoming of our system was a way of measuring position (angle) as one of our components moved. My predecessor found a company that makes nothing but inclinometers and selected a model which he then "shoe-horned" (literally) into our system.

These particular inclinometers run $300 each and they do work well most of the time. However, they lack a crystal.

Once my predecessor was let go, it fell to me to figure out why we kept losing angles. And it didn't take long.

We have a generic processor board, with a crystal, getting serial data from this inclinometer module, which lacks a crystal. And our equipment runs at ambient temperatures that range from -40C to +120C (ish). Since the inclinometers lack a crystal, they don't have a reliable clock, particularly at the upper end of the temperature range. Temperatures change, the clock drifts, and we "lose" angles.

I designed a drop-in replacement with a crystal that we had manufactured for about $22 each delivered. We have no problem with missing/dropped angles with our version.

Long story short: when it comes to communication between distinct modules, do your best to demonstrate or iterate to your higher ups that it's well worth the extra $.50 per unit to assure reliable data links. Another thing I've learned is never to trust anyone that tells you that "don't worry about temperature, we're never going to run these outside." They will. They won't think of you when the product works. They will, however, think of you if it fails. ...Not favourably.

[MotoDan]

Well said newguy. Reminds me of that old adage: “One 'aw, sh*t' wipes out a thousand 'attaboys'!

[Ttelmah]

I think on the low accuracy internal oscillators the thought is that as a designer you make the decision to have the cheap oscillator and work with it's problems (you can in most cases for instance trim the master clock to synchronise to an incoming signal), or you add an external oscillator. Things like laser trimming add cost. It's noticeable though that the automated systems are getting so good, that this cost is getting ever lower.

[ckielstra]

[RF_Developer]

[asmboy]

To add to an earlier post by pcm_programmer:
specific to the UART based error independent of any master clock frequency error.

[SuperDave]

Here's a piece that I didn't see in the discussion.

I've learned the hard way to "wire it right". You talk about 1 wire but there must be two, one of which is obviously ground and so obvious we forget about it. Is ground ground everywhere? Current pulled thru a ground connection causes ground at one end to be a different potential from the other and can cause really crazy looking problems especially if the current drawn varies significantly over time. So that's one thing to check. Put your scope ground on the power supply output ground and probe all the other 'ground' connections.

Also I would suggest, again assuming you have only one supply that wired to both units, that the wire from one unit to the other be either a twisted pair or shielded single with the ground side connected on only one end. This should get rid of potential radiated interference. (It might work on your bench but not some other place with a clear channel AM station nearby.)

[SuperDave]

Another thought. Fix it in firmware.

At start up have one unit output a "known" but perhaps inaccurate frequency on the line and have the other unit measure that frequency and adjust the use delay statement so the devices agree. Both baud rates might then be WAY out of tolerance but they would agree with each other quite closely.

Perhaps this happens at start up only if "switch A" is held or a temporary jumper is installed as part of the production test protocol with the new use delay value stored in eeprom.

Firmware updates on existing units are usually simpler than hardware updates.

[MotoDan]

Thanks for your reply Super Dave. I implemented an Autobaud procedure that is run every time the remote Slave device is plugged in. The Master is always sending the same size packet which is terminated with a LF. My routine sweeps across a range of baud rate settings until the valid packet is received. It then bumps the baud rate slightly to put it close to the center of that being transmitted by the Master. This only takes a couple of seconds and so far seems to be very reliable. Just as you suggest, the baud rates are no longer standard (19.2kb in my case) due to the wide tolerance of the int osc, but they are the same between Master and Slave.

[Ttelmah]

Well done.

This is actually a variation of the approach suggested by Microchip. They suggest modifying the OSCTUNE value, rather than the BRG, since this gives finer adjustments.

[MotoDan]

I originally thought about trimming the int osc, but could not find a way to do it. The datasheet refers to using OSCTUNE for this, but there is no other mention of the register. It doesn't look like it exists in the PIC16F1517.

[asmboy]

caution: when sweeping,
the value you select may still be at or close to a marginal error point since in reality you could STILL be off by 3%
and with internal osc we have the chance of thermal frequency drift.

[PCM programmer]