If your instrument also has a USB port, try that first: many have a USB-serial chip inside and speak the same commands over a plain USB cable, with no adapter to choose.
RS232, not TTL
RS232 signals swing between about −5 V and −12 V and +5 V and +12 V. Many cheap “USB serial” cables are TTL: 3.3 V or 5 V, made for microcontroller boards. A TTL cable cannot talk to an RS232 port, and the RS232 voltages can damage it.
- Choose a cable sold as USB to RS232 with a moulded DB9 plug; it has the level converter inside.
- Cables ending in loose wires, pin headers or a small bare board are almost always TTL.
Straight or null-modem wiring
RS232 has a sending line and a receiving line, and each end must send into the other’s receiving pin. A USB to RS232 cable is wired like a PC: it receives on pin 2 and sends on pin 3, ground on pin 5. What the instrument needs depends on how its own port is wired, and its manual says so in the pin table:
| Instrument manual says | Instrument port is | You need |
|---|---|---|
| Pin 2 TXD (sends), pin 3 RXD (receives) | wired like a modem | Straight cable: 2-2, 3-3, 5-5. The USB cable plugs in directly. |
| Pin 2 RXD (receives), pin 3 TXD (sends) | wired like a PC | Null-modem cable or adapter: 2-3, 3-2, 5-5. |
Examples: OWON OEL electronic loads need a straight connection (below); the Agilent 34401A multimeter, B&K Precision 8600 loads and GW Instek AFG-3000 generators need a null-modem cable.
- A wrong cross-over gives no answer at all, never a wrong one: both ends send into each other’s sending pin.
- Small DB9 “gender changers” are sometimes null-modem adapters inside. If a setup that should be straight gets nothing, check for one in the chain.
- The other DB9 pins are often not handshake lines on an instrument: some carry RS485, a trigger input or output. A cable that connects all nine pins also connects the adapter’s handshake outputs (DTR, RTS) to them. Where the manual documents only pins 2, 3 and 5, a three-wire cable (2, 3, 5) is the safe choice.
Adapter chips and drivers
The chip inside the cable decides whether the computer needs a driver. Linux names the chip with lsusb; on Windows it is in Device Manager under Ports (COM & LPT).
| Chip | Drivers | Notes |
|---|---|---|
| FTDI FT232R, FT231X | Built into Linux, macOS and Windows | The most reliable choice. Each cable has its own serial number, so BenchMesh tells two identical cables apart. |
| WCH CH340, CH341, CH9102 | Built into Linux and current macOS; Windows usually installs it by itself | Works well. The CH340 has no serial number: two identical cables are told apart by the USB port they are in and by the instrument’s own serial number. |
| Silicon Labs CP2102, CP2104 | Built into Linux and macOS; Windows installs it | Works well. |
| Prolific PL2303 | Linux built in; macOS and Windows need Prolific’s driver | Older chips and clones (PL2303HXA, XA) are refused by the current Windows driver: Device Manager shows “PL2303HXA PHASED OUT” or code 10. The usual reason for a cable that “used to work”. Prefer another chip. |
Linux also needs your user in the serial port group, and on Ubuntu the braille service brltty can take CH340 ports away: see Run on Linux - serial ports. macOS: Run on macOS.
Settings on the instrument
The cable only carries bytes; both ends must also agree on how to read them. Check the instrument’s communication menu:
- Baud rate - the instrument and the BenchMesh configuration must use the same one. Many instruments leave the factory at 9600 and keep whatever was chosen in the menu later.
- Format - almost always 8N1 (8 data bits, no parity, 1 stop bit), no flow control.
- Protocol - instruments that also speak Modbus RTU must be set to SCPI.
- Interface - when one DB9 serves both RS232 and RS485, choose RS232; some instruments use only one of them at a time.
Detect in BenchMesh’s Instruments drawer asks each serial port at the rate the instrument’s BenchMesh definition names (shown next to the model in the results). Set the instrument to that rate, or set the instrument’s baud rate in its configuration entry.
Example: OWON OEL electronic loads
The OEL15 / OEL30 series (OEL1515, OEL1520, OEL3020 …) has a USB port (with a CH340 inside) and a DB9 port for RS232, RS485 and the trigger. Both speak the same SCPI commands.
| DB9 pin | On the load |
|---|---|
| 2 | TXD - the load sends |
| 3 | RXD - the load receives |
| 5 | GND |
- Cable: a USB to RS232 cable plugged straight in; no null-modem cable or adapter. A three-wire cable is enough. Our test bench runs an OEL1515 through an FTDI FT232R cable.
- Settings: the load leaves the factory at 9600 baud, 8N1; the menu offers rates from 1200 to 115200. BenchMesh’s definition and Detect use 115200: choose it in the load’s menu (or set 9600 in the configuration entry). Set the protocol (COMM PRO) to SCPI, not Modbus RTU.
- RS232 and RS485 cannot be used at the same time.
- The load answers its identification query even when its keys are not locked; BenchMesh switches it to remote control after connecting and back to local when it disconnects.
The instrument does not answer
The instrument stays offline, or Detect does not find it. Check in this order:
- Does the computer see the cable? A new port appears when you plug it in (
ls /dev/ttyUSB*on Linux,ls /dev/cu.*on macOS, Device Manager on Windows). If not, it is a driver (see chips) or a broken cable. - Is the port free? A vendor tool or a terminal program holding it makes it busy.
- Baud rate and protocol match on both sides (see settings).
- Wiring: straight or null-modem, as the instrument’s pin table asks; remove gender changers to check.
- RS232, not TTL (see levels).
Still nothing? The instrument console in BenchMesh (panel header) shows every byte sent and received: copy it into a question to the community.