Framing errors with RS232 in CVI 2009

[haisol]

I'm tying to connect to an embedded serial device (19200, 1-Stop, 0-Parity, No-Fow-Ctrl) and sniff Tickets, which contain about 128 bytes. I'm trying to read them with the viRead(), after having waited until the VI_ATTR_ASRL_AVAIL_NUM are big enough.

1) When I connect  to the COM-Port with a Windows terminal application (e.g HTerm) and try to read the tickets, everthing works fine.

2) When I send the same tickets with that Terminal application through another port and try to receive it with my CVI program everything is fine as well.

3) But when I try to read the tickets with the CVI application directly the first few Bytes leads to a framing error. Afterwards receiving the rest of the bytes works fine, until the next longer pause.

Does anybody have any ideas?

Thanks in advance

haisol

[menchar]

Have you tried flushing the inqueue before attempting the first read?

The only time I've seen framing errors (I use CVI rs232 library with either the NI driver when using NI HW or Windows driver when I'm not, not sure what viRead winds up using) is when trying to read the port on a device that's powering up where the device doesn't guard against the com port pooping out a few bad frames.

Framing errors are rare, I wouldn't know how to cause one without low-level manipulation of the UART on the sending side, unless maybe cabling / noise is a problem.

If you were to use the CVI rs232 library directly you could throw out bad frames, you can configure the library to detect framing errors and handle them in a callback I believe.

Hyperterminal may be seeing the bad frames and silently discarding them.

I like using Terminal instead of HyperTerminal, it's more versatile, it's small, and it's freeware.

http://hw-server.com/software/termv19b.html

One trick to help with a device having frame timing problems is to use an extra stop bit on the sending side.  It's benign to the receiving side, the receiver doesn't really have to know how many stop bits are getting sent.

I'd suspect the sender in your case, you might try using a logic analyzer or scope to get a good look at the frames being emitted by your embedded device.

Another thought is that if you're using a USB to rs232 dongle, many, if not most, of the cheap ones don't really work.  The NI ones work OK, as do three or four others, but it's entirely possible to get a cheap USB-serial port dongle that doesn't work well.  This is an increasingly common problem what with newer PC's having no built in serial ports other than USB.

[haisol · Accepted solution]

Thanks for your fast response!

< Have you tried flushing the inqueue before attempting the first read?

Yes, but normally this should effect the inqueue only, not the receive register flags. They instead are cleared when changing baurate etc.

< ... device that's powering up

No powering up, everything stable and seconds between viOpen() and viRead()

<... maybe cabling / noise is a problem.

I don’t think so, because I use short cables and no special noise sources around. And why then the HTerm has no problem with that? Especially because he uses the same hardware (which normally is responsible for detecting frame errors)

<... library to detect framing errors and handle them in a callback I believe.

But then I will loose the bytes, I have to observe...

< Hyperterminal may be seeing the bad frames and silently discarding them.

All bytes transmitted here. I can see the tickets of the protocol to be complete (header and footer)

< I like using Terminal instead of HyperTerminal...

I tried this one as well. Same observations!

<... use an extra stop bit on the sending side. 

The device I'm observing is a piece of hardware, for which I have code post production test procedures. So no chance to change something - apart from an error report. But I could see, it uses the equivalent of approximately 3 stop bits (seems because of the slow processor used).

< using a USB to rs232 dongle

No dongle, a professional 32-port RS232 card for industrial usage. Here again: HTerm and Terminal, don’t have any problems at all. No bytes discarded. And when I send with them no problems as well.

< ... using a logic analyzer or scope

This what I've done in the meanwhile:

1) 3 stop bits.

2) but a jitter on the begin of the stop bit around 50% of a bit. This is a drift of 5%/Bit which seem to be too high indeed!

[menchar]

Guess I'm wondering how you can trust a frame that has an error - unless you know you're getting the payload correctly despite the framing error.

rs-232 can tolerate a 5% total clock error.  If the jitter at the stop bit is half a bit time, that would seem to be the tipping point.

CVI rs-232 library says a framing error is "stop bit not received when expected".  And a clock error as it accumulates over the frame shows up as stop bit problem as you're seeing.  Extra stop bits help with frame to frame timing but don't help with intra-frame timing.

Have you tried a different bit rate?

[haisol]

This is why I closed the case, as soon as I observed that jitter with the logic analyser. Different bitrate was not the solution, as the observed single bits had the correct period. An additional parity was the the solution (aught to be none)!

Unfortunately, the protocol tags and the length of the standard tickets lead to a 0 in parity, so that these bytes have been transmitted correctly - with the parity treated as stop bit. Within the data-packet, which I'm not able to check so far, there then where some bytes with a 1 parity, leading to the framing errors.

Thanks for your assistance!

[Farmalawi]

I am using labview for a Keithley 6517B Electrometer. I have LabView 2010 and am using RS-232. When I run the VI I get a "an error on the Keithley, ERROR :800 and 1073807339 in LabVIEW program I search about this error due to an RS-233 framing error. Can you help? Please see attached file, my program Thanks. Abdallah

[Wolfgang]

Hi farmalawi,

1) Don't hijack threads - start your own with an appropriate topic - this one was about framing errors with RS232 in CVI!

2) If you have questions on LabVIEW, you should post them in the LabVIEW forum - this one is dedicated to CVI

[Farmalawi]

I am sorry for that but i have some problem subscription options

 Thanks for the alert