Rs232 Analyser

[Author Metcalfe]

1The LG outputs data every 2s and I scan it every 2s. Every 20-30s the logger only gets half of the data string, and the next scan gets the other half. This makes it difficult to split the strings consistantly. Any thoughts on how I can overcome this timing problem?

2. Once I have the string (12/10/08, 11:09:00.00, 12.3, 3.99E-04 ...) I split it into its component parts, but I am still left with strings. Is there a way to convert strings to numerics using CRBasic so I can average the data over time?

The instrument is a Los Gatos water vapor isotope analyser which measures water vapor concentration, d18O and d2H. Piccaro also make a similar analyser. I have heard better things about the Piccaro, but we could only afford the LG machine. Our instrument arrived and the main optical bench had not been tightened so we have had to send it back. While it was here (for 2 weeks) I started on the CR1000 - serial comms part.

The output from the analyser is via an ethernet, a USB or a serial connection. The fastest it scans at is 0.5Hz (every 2 seconds) and as far as I can see the output via the serial port is the same. It produces a single sting, comma delineated, containing the data and time, then 7 data values and 3 values for the internal pressure, cell temperature and ring time. I think followed by a CRLF. Some are in engineering format and some straight numerical.I am not sure how to find out the number of bytes so I set my SerialOpen buffer to 10,000 and the InputString length to 100.

Thanks for the offer of assistance. We had to send the analyser back for repairs. A new one is not due until Christmas. In the SH, Christmas combines with summer holidays so it might be mid Jan before I get back to you.

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.

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.

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.

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.

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).

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.

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.

Usually when debugging I have a debug UART spitting out information on my boards. It would be really useful if I could take one of the pins from the analyser and use it to receive ASCII text in a separate terminal like window. Saves me having to plug in another usb device, open another terminal program. Is this possible?

ation on my boards. It would be really useful if I could take one of the pins from the analyser and use it to receive ASCII text in a separate terminal like window. Saves me having to plug in another usb device, open another terminal program. Is this possible?

I want the option to display ASCII uart data like a terminal program. So it displays lines of text, \n\r stuff is processed\ etc. You know when you connect to a the debug port of a linux board for example and you get the full boot messages? It would be nice to be able to use a logic analyser to read that data in whilst doing other stuff as well.

The drawback of this method is, the pipe cannot handle the speed of the data if the frequency of your data is too high, so some data can be lost in between. You must find some custom way to verify the integrity of your data.

Interestingly enough, we also use a named pipe in the application to get data from our analyzers into the terminal. We were considering looking at supporting multiple connections, so outside applications could use the same connection, but I think having an HLA do it us much more flexible, since named pipes are only one possible solution for streaming the data, and they are quite finicky to work with.

The Crouse-Hinds series MTL Z230 zirconia oxygen analyser is ideal for versatility and portability. This benchtop analyser is a fully self-contained, complete unit with integral sensor and optional pump. The carrying handle makes it easily transportable, and the integral flowmeter and valve mean there are no further accessories or consumables to carry around.

The analyser features a bi-directional RS232 port, allowing for remote calibration and data logging. There is a choice of user programmable outputs and alarms. The internal pump option is available if there is insufficient pressure in the sample stream and, for applications where a long sample path is involved, a bypass flow sample system enables faster results.

So I gathered the required equipment (HP/IP, Ext I/O, RS-232) and now I'm trying to get it to work. I have been able to OUTP a program from the 41 to the PC, but I have not been able to transmit it back to the 41 (INP) for a full round trip. I'm using Windows Terminal to receive, and the type command to send. I've found some Linux utilities, is there anything for Windows that automates the process? I can't be the only one to attempt this, or am I?Steve Re: Using the RS-232 HP/IL Interface

Message #2 Posted by andy on 21 Jan 2003, 9:34 a.m.,

in response to message #1 by Steve

You're not the only one. I've attempted it with similar results. I was using HPVEE (a program that allows you to communicate with serial and HPIB ports).I had similar results. I could upload a program easily. I could also download small programs, but I did not have success with larger programs. About that time I got an hpil/isa interface and an old 286 and am now using LINK+ for all my pc-hpcalculator comms.I was thinking that the longer programs wouldn't transfer because the 82164's buffer fills up. The small programs don't fill the buffer so they go through. I think it may be just getting the settings right.I am still interested in getting my 82164 to work though. You might try emailing Tony Duell (sp?). He programmed the linux versions. Please let me know if you learn anything new and I'll do the same.Andy Re: Using the RS-232 HP/IL Interface

Message #3 Posted by Hans Brueggemann [GER] on 21 Jan 2003, 1:22 p.m.,

in response to message #2 by andy

Well, I couldn't resist putting in a public plug for Hans Brueggermann's HPILCOM program!He was kind enough to email it to me to try, and I LIKE it very much! It has a very professional graphical interface which includes a "browser" window from which one can see programs that reside in a particular directory on the PC which are selectable for downloading to the HP41. What is especially nice, though, is that one really controls all of the transfers both to and from the HP41 from the HP41 itself. The HPILCOM program, runnning on the PC, simply facilitates the transfers to and from the HP41 and allows monitoring the progress of the transfer with a progress bar and status "LED's". To send a program to the PC, one types in the name of the program on the HP41 into the alpha register and executes OUTP.That's it! The HPILCOM program receives the program, monitors the progress, displays the received program, and stores it to the PC.To get a program from the PC, one first drags the program to a particular directory on the PC which can be viewed from the HPILCOM's "browser" window and then executes a small program on the HP41 called GETFL. GETFL prompts for the name of the program that is visible in the browser window and then gets it: the HPILCOM program does the "handshaking" with the GETFL program and sends it to the HP41 as initiated by the HP41 via the GETFL program.He also has a routine built into the HPILCOM program that allows the HP41 to initiate getting the PC's time and date and transfering it to the HP41, from which another HP41 program that he provides will set the HP41's time and date to match! The programs on the HP41 are VERY short! You must have an EXTENDED I/O module, however, though it looks like he has done some experimenting with the CCD module. I'm not so familiar with that module, so I may have misunderstood if it could be used as well.He also has built-in "hooks" to the HP41UC.exe program, from within HPILCOM, such that one can translate from RAW to DAT mode by checking "radio" buttons withing HPILCOM. Furthermore, he has "hooks" for future enhancements, including character translations that, I believe, will be done on-the-fly during transfers. Finally, he has radio buttons to allow auto-commenting for alpha characters, XROM numbers, and no-label tags for HP41UC compatibility. VERY NICE!His program makes using the HP82164A to transfer programs to and from the HP41 as seemless as possible.THANK YOU, Hans!-Mike(running HPILCOM on Windows ME) oops... remove 'dumpsam' from my above mail address (n.t.)

Message #8 Posted by Hans Brueggemann [GER] on 21 Jan 2003, 7:58 p.m.,

in response to message #3 by Hans Brueggemann [GER]

3a8082e126