Baud rate and temperature issue

[ginvent]

I have been using the 16x2 serial non-backlit display for a while and have found a few interesting issues. The display version is 1.2

I am connecting the display to a custom microcontroller we designed. It has a serial output which we use to drive the display. It is not SPI, but a 0V - 5V RS-232 type signal. We have had no problems getting the display to work most of the time.

Sometimes when it is cold, the display prints out garbage, and when I heat it up just a little the display starts working again. So I went further and noticed that when we cool the unit down a bit, it will definatly fail. Anything below about 65 F will cause the display to print trash. This happens on all the displays we have.

I thought it might be the crystal circuitry changing frequency on the display, so I thought if I lower or raise the baud rate just a tad, it might fix it... nope.

We don't use any handshaking on the serial line. So, besides incorporating handshaking (which we don't have enough pins on the micro to do) can you suggest any other thing to try?

We are using a direct connection to the data_in pin.

Have you seen this issue before?

[CF Tech]

Thank you for your post.

The 1.3 and 2.0 version displays have a jumper to select 0v to +5v (logic level) or -10v to +10v (RS-232) input signal levels.

On the 1.2 version displays, resistor R9 needs to be changed from a 10 K (marked 103) to a lower value (from 0K minimum to 1K maximum). If R9 on your units is marked "103" then R9 will need to be replaced in order to assure reliable communications.

Can you check the value of R9?

[ginvent]

R9 was 10K like you stated, I changed it to a 470 ohm resistor and BANG ZOOM KAPOW! it works great. No characters get dropped even with cooling. THANK YOU!

Now one other side question, what is the tolerance of the baud rate detector on the display. For example, I usually use it a 4800, what approximate range could it handle? +/- 10%? I ask cause my micro does not use a crystal that will give me a perfect baud rate and with no handshaking, I want to be careful, plus I would like to increase to 9600 bps someday. Is it better to be slower than faster?

Thanks again,
Joseph

[CF Tech]

The closer to nominal you can be the better.

The 632 and 634 use a firmware asynchronous receive routine. In general they sample within the center 1/3 of a bit at the higher baud rates, and the sampling window gets relatively smaller and better centered for slower baud rates, so in general the slower baud rates will be more forgiving.

There is not a systematic creep in the sampling, so being fast or slow will not help.

We use a ceramic resonator which is probably good for about +-1% worst case.

I think the only reasonable way to get a handle on this would be to sweep your processor's frequency while you are continuously transmitting a stream of test characters and see where the data gets corrupted. Be sure transmit 4 total characters, chosen so that the all combinations of the msb and lsb are represented.

The receiver gets re-synchronized on every start bit, so to analyze this stuff, you only need to look at one byte.

Handshaking should not be related to the baud rate accuracy--handshaking would only be an issue if you manage to over-run the display's input buffer--which is pretty hard to do since the display processes commands faster than they can be delivered.

All of this stuff is one notch better in the v2.0 displays. So if you are safe with the v1.2 displays then there will be an extra margin on the v2.0 displays.

[ginvent]

Thanks again for all your help. Not to kiss up, but I am VERY pleased with the technical support I have received from crystalfontz. I am a very happy customer. Even with the delays on the displays, all can be forgiven with GREAT customer service and support. Out of all my semiconductor vendors, your the most responsive. GREAT JOB!

Joseph