Am having troubles using sourceforge's zmeter program to read output from a RadioShack 22-812 voltmeter in RS232 mode on Ubuntu v8.10. This is over a serial port on a Pentium III desktop. Same meter reads perfectly on Windows 2000 SP4 with RadioShack's MeterView program through COM1.

zmeter says it opens the port. Either /dev/ttyS0 or ttyS1 gets this message. With stty, I observe the baudrate changing from the default 9600 to the correct 4800. Then no more output. With ps aux, I see S+ status for both zmeter parent and child processes (it does a fork). I thought zmeter was going to almost certainly be a slam-dunk on this basic setup. I wanted to try it out here before returning to my laptop scene, where I had unsuccessfully tried zmeter with a USB to RS-232 converter (no serial port on the laptop). I wanted to get zmeter to work before I purchased a serial port add-on card for the laptop.

Then I tried ttylog on the desktop. Also hangs against /dev/ttyS0 and 1 with the voltmeter running in its RS232 mode.

There is but one serial port on the back of the desktop CPU box.

I started researching on the internet. After what I've seen there, I suspect what's going on is that at the software level I'm seeing in the terminal on the Ubuntu desktop, all is well and good. But whether the software layers are hooked up correctly to the hardware below is an open question.

Is using the standard Applications->terminal a bad idea for this? I would think not. I am, after all, referring to THE file /dev/ttyS0. I think it's the terminal's own file descriptors that are pointing to /dev/pts/0, 1 and 2 (from memory - I'm on Windoze right now).

The desktop has a PCI bus, although there is an ISA slot (never used). I saw things on the internet that implied there may be difficulties with Ubuntu in such situations. However, I find it surprising that that could be what's stopping me here - Dell produced thousands if not millions of these machines with the same basic configuration.

It could be a big help to have a guiding hand, as I'm about to dive into it with setserial and the others I've read about. setserial appears to have its own load of gotchas. I may also consider simplifying/diagnosing the line input with a loopback connector and/or a RS-232 breakout box. But I doubt really I need to go out on the line to test, since Windows sees it.

Thanks in advance for any help,
Chuck