The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I made a bunch of various such cables back in the 90s, and three-wire doesn't always get the job done.
Not everything I had to connect used EIA 232 (RS-232). All of our terminal servers were from DEC so EIA 423 (DECconnect) was most common and there were also some others.
Eventually I wrote up a Word document with all the pinouts I knew and the types of cross-wirings I had to make. I still have the document, but some of the diagrams are missing because I hadn't inserted them properly.
The last time I had to make such a cable was to connect a DB9 RS-232 USB adapter to the MMJ DECconnect console of one of my AlphaServers and it didn't work reliably as three-wire. It doesn't help that the MMJ console port is flaky.
It depends on the pin-out of whatever you're connecting it to -- "standards" is often considered an optional term, in serial comms.
RS232 only uses three wires, but not every manufacturer always uses the same pins.
What I often do is cut the end off an RJ45 (Ethernet-style) cable, and solder it up to the pins of the DB9 or whatever as described in the manual for the serial device (or by using a meter to find which pins are used).
You can afford a bit of trial and error (mixing up Tx and Rx is quite easy, because a wire that's Tx at one end is Rx at the other, and the documentation for serial devices can be confusing, on that point), because it's only comms voltage, so you won't burn anything out.
I wanna be a eunuchs developer! Pass me a bread knife!
3/4's of the way down are diagrams for null modem / crossover cables. See also the diagram after the null model cable, on the software handshaking cable. Even if you don't use software handshaking, wiring it up that way is a good idea.
Yeah - I should know that list of alternate null modems by heart; in the 1990s I was teaching that stuff to engineering students. All the different alternatives for flow control.
Soldering it was a minor problem, compared to making the students understand the need for flow control - and the need for so many different mechanisms. With X-ON / X-OFF (software control) coming in as yet another alternative.
The survey you link to is a good description of the issues. Recommended reading for anyone who needs to use COM port communication anno 2019.
It's going to depend on how the software on the computer side sets up the port. If it sets it up such that it needs to see some particular signal line enabled before it will talk, then you will have to set up that line and enable it on your side.
Or, if it's doing that, it may also be enabling an outgoing one as well. If so, you can always just loop that one back on the one it wants to see high, allowing it basically to enable itself. So wire RTS to CTS and/or DTR to DSR. Most likely the former I would guess.
Years ago I bought 100m normal twin flex (2 wires only) and cut it into 2 pieces - a 75m and a 25m. Soldered them booth up to db25 connectors (pin 2 to 3 and pin 3 to 2 ; no pin 5) used both with laplink, the 25m at work (office to office) and the 75m between my flat on the 4th floor and a friend on the 2nd floor in the next building of flats. worked fine.
(well, lost a serial card, you tend to forget that it is connected. there was some lightning in the surrounds, and the computer shut down a second or two before I heard the thunderclap. Fortunately only the serial card was lost - The computer started up normally when the serial card was removed)
Two most common causes of mistakes I've faced:
1. Cable crossed or straight. That ties in neatly into male vs. female connectors. At the end, I've built myself an own cable tester to find out which is straight and which is crossed.
2. Hardware flow control lines. Some devices use them, some don't and if a device uses that, you better solder the lines in place.
Remember to cross your fingers as well, hoping for the receiver always being ready to pick up another byte when the sender insists on transmitting it.
Flow control was included for a reason. Sure, most of our modern CPUs are so fast that they can "always" keep up with a COM port, but if it in exceptional cases are busy with something else, it is still nice to be able to tell the sender "Could you hold it for a little while?"
And it works over a 2 line connection, such as a POTS line.
BUT: It is not bit transparent. And it requires the sender to respond fast enough. The latency is generally a lot higher with software flow control.
I was teaching networks at college level in the 1990, when 622 Mbps B-ISDN and ATM was still an option, and optic fibers were becoming commonplace, running for 50 km or more without repeaters. (They could run for much greater distances even in the 1990s, but towns are usually no further apart.) I used to start first lecture on B-ISDN with a question: How big is a bit? How many centimeters long? Light in a fiber moves at roughly 200,000,000 m/s. If you sende 622,000,000 per second, that gives them about 30 cm each. Before the first bit has come to the end of a 50,000 m long fiber, you have poured in more than 150,000 bits. And before the STOP!!! signal has come back to you, you have sent another 150,000 bits down the line. Now, let us see how well our basic frame mechanimsm from lower speed lines works under those conditions...
Lots of the students first thought I had made an error in the calculation, missing by a factor of a thousand. After checking and counting zeroes, they shook their head with a "But... What shall we do then?". (The next layer-1 protocol we treated was DQDB - another now forgotten alternative, which is a pity; it did have something going, with its reservation scheme. It never made any success, but we should learn for failures, too - failure in the market doesn't prove that it was without merits. Around 1990 it taught the students that there is more than one way to skin a flow control cat!)
I've read through everything, and I'll suggest the one thing that noe one else has
You said you have a number of pins not connected right? WOuld they at all happen to all be grounds?
A 10ft cable that's NOT properly shielded will loose quite a lot to stray radio waves in the surrounding environment. I have a 10 meter one that I can drop down out of my Loft hatch and into my PC in the office below, fro when I need to reprogram the switch in my server rack.
Over the years, it's starting to get old, and I can tell straight away when the shielding is starting to come loose.
The shorter the cable is, the less shielding matters, the GPS plugged into my PC for example has a really thin unshielded cable on it, but it's only a meter in length, the switch programming cable is a nightmare, we have so much wireless kit in our house with Phones, Thermostats, WiFi based TV's and Wifi capable smoke alarms that it's often better for me to find the shorter cable and drag either the PC system unit or one of the older laptops with a 9 pin on up intot he loft and do the work up there.
Cisco flat cables with an RJ45 on that are longer than about 3 meters are terrible, they pick up all kinds of crap, so much so I have some old ferrite chokes lying around that I salvaged from old electronics, and wraping the cable through them a couple of times, one at each end near the plugs, usually helps a lot.
Excellent suggestions all with debugging the cable differences. I'm going to have to file this under face-palm.
It is a true statement that simple serial communications only require the 3 wires, we do it all the time on various projects. Points go to Mr. DCB suggestion man - if one's handling of the data is fast enough, you really don't need Dtr and Rts control wires. But if your application enables them in the DCB, you're going to need to hook them up.
So, the mystery is solved, and there is a lot of good info in this discussion. Thanks to all of you.
Charlie Gilley Most life and software issues can be solved by checking your inputs....
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
As I recall from my college work-study program forty years ago, that's the way we wired up RS-232 terminals: four wires, two of them ground. My memory is no longer great, but I know we had 25-pin connectors, and I'm thinking in that world pin 1 was ground, 3 & 4 swapped, and 8? was a second ground. I have nothing to help you, but thank you for bringing back memories of some good times!
Must have been 1, 2, 3 & 7. A forty year span is a LONG time to maintain an image in one's mind. Connecting terminals to a PDP-11/34; life was simple back then. Old men want a time machine because the past looks better, or at least longer, than the future.
You're right. You only need 3 wires for duplex communication. Assuming you connected these wires correctly. the next question is what kind of cable are you using. Transmission lines cause reflections and energy loss. At 10 feet, your cable is long enough to be affected by it. If you're using 3 loose wires, that's a problem; try twisting the wires together. Ideally, you want 100 ohm impedance with 24 AWG wire. If you're using a pre-built cable, check the specs. It may be designed for something else. I also suggest you make sure both computers are powered from the same circuit; otherwise, you may have issues with ground loops.
I have a whole box of serial cables that I have accumulated over 20 years of use. I have male-female, female-female, and male-male straight-through cables, and a null modem cable. This lets me make up whatever is called for. I verify my connection using one or two of these cables, then build a custom cable. If the custom cable doesn't work, I know it's the cable.
You can connect a serial port using only transmit, receive, and ground, but even at 9600 baud, a steady stream of bytes is likely to overrun your PC's receiver buffer. That's why you want to connect RTS and CTS, which do hardware handshaking. You can do software handshaking using XON and XOFF if your USB-serial box understands that and your terminal software understands that.
Last Visit: 28-Oct-20 5:45 Last Update: 28-Oct-20 5:45