There are a few things you can still do. Make sure the pins on the DB-9 connector are properly jumpered: pin 4 (DTR) or Data Terminal Ready should connect to pin 6 (DSR) or Data Set Ready; pin 7 (RTS) or Request to Send should connect to pin 8 (CTS) or Clear to Send. Then use a multimeter to measure the voltage level at pin 2 (TxD) or Transmit Data. IIRC, this should be a negative potential with respect to pin 5 (SG) or Signal Ground when no data is being transmitted. It will briefly oscillate between the negative voltage and a positive voltage for each character transmitted, but too fast to see with a multimeter. If there is no voltage on pin 2, measure pin 3 (RxD) or Receive Data. The idea is to determine which of these two pins is the RS-232 output and which is the input. If you don't measure voltage on either pin 2 or pin 3, there is something wrong internally, and there is probably no solution.
I had a motorized programmable speed stirrer that went on the fritz and wouldn't respond to ASCII commands, although it did produce ASCII messages. Turned out there was an ASIC (Application Specific Integrated Circuit) inside with a line receiver that was damaged. Manufacturer wouldn't provide a replacement part, so we ended up buying a new controller. The old controller could still be operated manually, but we needed a new one to control the stirrer remotely with a PC.
When transmitting ASCII commands, there is almost always some sort of protocol involving <LF> and/or <CR> characters after each command. Use Hyper Terminal to either insert or delete carriage return (CR) and/or line feed (LF) after sending a one-letter command. Sometimes there is also an ASCII prefix character (or two or three) associated with a command, although the Instruction Manual doesn't mention that. If there are prefix characters, good luck finding out what they are. If you have the software that goes with this instrument, it might be possible to disassemble part of it to determine what it expects. Sometimes binary executables contain plain text that offer clues to operation. As for serial protocol, this is commonly 9600 baud, No Parity, 8 Data Bits, and 1 Stop Bit... usually abbreviated 9600 N, 8, 1. You may have to reverse pins 2 and 3 at your computer. If you have a DB-9 or DB-25 serial port on your computer, use that instead of the USB adapter until you get this figured out. Make sure the serial communications port shows up in Device Manager as COM1 or COM2. You should wire up a loop-back connector to attach to the computer serial port to make sure it is working. Use Hyper Terminal to test the loop-back functionality.
This instrument appears to be in "like new" condition. It is hard to believe that no one at Kistler has any documentation on it. Maybe you could try an
e-mail inquiry to their Switzerland office? They list Jason
[email protected] as a point of contact.
There are "modern" versions of your instrument, the Model 5015A and the Model 5018A. You will have to register on the Kistler website to download more information and software.
These later instruments require an ASCII colon
) prefix to the command line and a <CR><LF> characters at the end of the command line. You might try that. Also, the Model 5015A appears to default to a baud rate of 19200 (page 52, paragraph 5.21 RS-232 Interface) according to the Instruction Manual I downloaded from the Kistler web site.
Please let us know if you find out any more information. Oh, BTW, Kistler shows a "null modem" cable is required between the Kistler instrument and a PC for the Model 5015A.