Here are some good guides:

http://tldp.org/HOWTO/Serial-Program...WTO/index.html
http://digilander.libero.it/robang/rubrica/serial.htm

More examples can be found by googling.

BTW many devices will not automatically send data over RS-232 until the computer first sends a request.

Looks good. Will that help me interpret the hex dump, or should I scrap that and just try what's in the guides?

-Peter

What is in the guides? Hopefully the guilde will help you interpret the hex dump.

Great, Thanks. I'll try to post how it's going later.

-Peter

I still think you are going about this the wrong way. Using a USB monitor will give you the data coming from the device, as well as communication from the USB<>Serial port adapter. In other words, you're getting more data than you really need.

Ignore the USB bus. Let the kernel handle it, since you are using a converter anyways.

You need to figure out the data tansmission settings for the serial port first, then you can write a program that uses the serial port. If you have a system with a serial port, try using it to communicate with your Windows software. Have the Windows system send data, and tweek the serial port settings until you get ledgible data on the other side. If you don't have two computers to work with, download a serial port sniffer (google returned several free versions).

The problem is that when I use a serial port sniffer on the device, it returns zip. I see the port open and then no data crosses the wire. This was the only data I could get. I agree with you. I'm just not sure what else to do. I'll try to install a serial port on my other box, but I'm not sure if I can.

-Peter

If you can see it open the port, then you should be able to get enough info on the data transmission settings. This is the information that the serial port needs to communicate with the device (baud, data bits, parity, stop bits - i.e. 9600,8,n,1). Once you have this info, then it gets easier. But without it, you're stabbing in the dark.

Software sniffers shouldn't interfere with the data transmission. They just monitor the data to<>from the serial port, much the same way that a network packet sniffer works.

OK, sounds good. I'll see what I can find out.

-Peter

OK, I know it's been a while, but I've been studying for and taking exams. Now I've got some more time. I connected to the serial port with the sniffer, and I got this:

Max Baud Rate: configurable
Data Bits: 5, 6, 7, 8
Stop Bits: 1, 1.5, 2 stop bits
Parity: None, Odd, Even, Mark, space parity
Current Rx Que: 4096 bytes
Capabilities: DTR/DSR, RTS/CTS, RLSD, Parity Check, XON/XOFF, settable XON/XOFF, Total timeouts, Interval time outs.

I don't know how much of this is relevant, but I thought I'd put it all down anyway. Now this is with the device off, because the software seems to snatch the device (it disappears from the list of monitorable devices on the sniffer). Also, the software never closes the serial port, and no data is recorded on the sniffer except the opening of the port and then just 58 (probably should be 58h). Does that mean anything?

-Peter

Unfortunately those are just serial configuration settings and not real helpful. Typical settings are 9600 BAUD, 8 data bits, no parity, and 1 stop bit and hardware flow control.

Any ideas why I can't get data from the device when the software's working with it?

-Peter

OK, does anyone know where I can go from here? I'm a little lost. I found a tutorial here there seems pretty good for USB drivers. I'm thinking about setting up a small Gentoo partition so I can mess with usb-skeleton.c to familiarize myself with the whole kernel... thing. Yes? No?

-Peter