Electronic – Does usb to serial multi port communicate only for one port at a time

Here is how I would suggest going about debugging this problem:-

1. Check the connections.. if you've mixed up signal ground and chassis ground (shield) you could get funny behavior just like you describe. Pin 7 on the DB-25 is the one you want to connect to DE-9 pin 5. I'll assume you're using a commercial adapter/cable or have one wired like this.

   

   Maybe check the transmit out line to ensure it's idling at -12 ( < -3 anyway).

2. Make sure the instrument is set to RS-232, and not current loop (Jumper 7,8 and 1,2).

3. Try the most common serial port setting (9600/8-N-1), 9600 baud, NO parity, 1 stop bit switch 1, 2, 3 OFF switch 4, 5 ON switch 6 ON switch 7, 8 ON

   Make SURE you understand which is 'OFF' and which is 'ON'. Don't laugh, I've seen this happen more than once, and some types of DIP switches are kind of ambiguously marked. If in doubt, an ohmmeter across the switch.. in fact you could check all of the switches to ensure they're working.

   I like Realterm as a terminal program. It's free, and easy to change the parameters. Try it on something known working first of course, and look for an online tutorial. Really worth it.

4. If still gibberish after that, get a scope screen cap or photo and post it.

5. If you have a continuing need for a logic analyzer, this one is very cheap and relatively useful. Not as good as my Tektronix boat anchor, but this one will fit in a coat pocket. But I'd get a scope first if you don't have one. Even the worst scope is better than nothing.

USB - Universal Serial Bus - Signaling (WikiPedia)

The real problem with USB is not in the physical signalling. Say you capture a waveform with a scope right after the device is connected. It's likely to be a part of a Setup packet which is a part of a control transfer which is a part of a descriptor request which is a part of device enumeration, and that's only to have your device recognized by the host. Actual data transfer hasn't even started yet, and it will be wrapped inside transfers (of 4 different kinds) to some endpoint belonging to some interface that implements some device class, standard one like HID or completely custom. It's a lot like trying to understand HTTP by looking at Ethernet signal with a scope. In fact, you'd probably have a hard time finding your UART data even in a USB sniffer log (unlike a TCP/IP sniffer, a USB sniffer may well not know the exact protocol that e.g. FTDI uses to transfer data).

Together with the great USB in a Nutshell tutorial (HTML version), I found this book to be an excellent reference if you actually want working knowledge of USB to e.g. create your own USB devices.