RXTX serial port pain

The failure of the USB serial ports to work is puzzling. I've used them lots of times before with other serial devices, and they've been fine. What's the issue? There's nothing wrong with the lead. The last remaining non-USB serial port in my house is on my desktop. A null modem lead from the USB serial port connected to this port, and a minicom on either port proves that messages are delivered correctly.

Uh? It works. OK, I'll try that again. I could cry. I have a minirc.usb0 in /etc, so I can start 'minicom usb0' for another serial device (my phone, I think). Starting minicom this way, and changing the bps to 38400 from 9600, I can communicate with the scope. Starting minicom with no rc file (it uses the default minirc.dfl), the port settings are /dev/modem 38400,N,8,1 with no flow control. The only thing I appear to need to change is the port. Changing the port to /dev/ttyUSB0, so that all settings appear to match, I can't communicate with the scope. With the null modem lead between the two ports, I see the data is garbled.

Again, more carefully... Null modem between USB serial and built in serial. Minicom on one terminal, minicom usb0 on the other. Change the bps to match, and it works. Minicom (/dev/modem) on one terminal, change the port to ttyUSB0, minicom won't start in another xterm: /dev/modem is locked. Not another bug! I'll try updating to latest (2.2) minicom, mine is 2.1. The minicom project is at http://alioth.debian.org/projects/minicom/

Hmmm...same problem. Looking at the code (my eye sockets are starting to bleed), it doesn't seem to re-initialise the port after the user selects a new serial device. The lock remains on the port minicom originally started with. The code does look awfully neat and tidy though, so I'm not keen to edit it. Saving the new settings, exiting minicom and invoking it as 'minicom usb0' (for example) seems to work a treat. Something to remember, while I forget the rest.

Scope software

Back to that software. With a null modem lead between the GDS-2062 and the USB serial port, and trying to acquire a 12,500 point waveform, it seems the read of the InputStream stops at 4,095 bytes. Interesting number! There should be 25,014 bytes in this message. There's no further reply from the scope. Trying to toggle between USB and RS232 on the scope settings results in the scope locking up, necessitating a power cycle. I don't understand why the scope is bothered - there's no flow control on the port (only rx, tx and gnd are connected, according to the user guide).

I use a java.io.BufferedInputStream to get bytes from the serial port. A quick glance at the web tells me the default buffer size in BufferedInputStream is 2048 bytes. I use BufferedInputStream to wrap the InputStream obtained from RXTX's SerialPort object. The InputStream Object is a RXTXPort$SerialInputStream, which has no buffer, but wraps the native functionality. My code loops around after issuing a command to the scope, sleeping and polling the InputStream's available() method until the whole message has been returned. The RXTXPort's available method is a wrapper for a nativeavailable function, which in turn calls ioctl(fd, FIORDCHK, 0). Ooh, that's deep.

Checking again, I notice that using minicom to retrieve the long sample memory also fails. It's not minicom's fault. Trying 'cat /dev/ttyS0' on one terminal, and 'echo "acq1:mem?" > /dev/ttyS0' on another, also fails. It seems like a few thousand characters in minicom. I tried 'cat /dev/ttyS0 | hexdump -C' and this tells me I get over 11,000 characters. That's more than the java code reports, but still short of the expected 25,000. Interestingly, I get 4,096 characters again if I use 'hexdump -C < /dev/ttyS0'. Is it just down to the serial port's buffer not being emptied fast enough? How big is the serial port's buffer?