# Can't figure out EIA-232 (RJ45) to DB9 cable… (seems simple!)

I've purchased a used BayTech RPC4 unit (8-port power strip controllable using RS232).

The front of the unit has an RJ45 port (EIA-232) and has a wiring diagram on how to wire it to a DB9 port so you can connect it to a PC.

Here's the diagram:

If I use standard TIA-568B wiring for the RJ45 connector:

1 = orange/white
2 = orange
3 = green/white
4 = blue
5 = blue/white
6 = green
7 = brown/white
8 = brown


...then it looks like I need to connect to to a DB9 like this:

1 = DB9 #4
2 = DB9 #5
3 = DB9 #7
4 = DB9 #3
5 = DB9 #2
6 = DB9 #1
7 = DB9 #5
8 = DB9 #6+8


However, that doesn't seem to work. I'm using WinXP HyperTerminal for testing (9600-8-N-1) and I don't get any input or output.

Can anybody help me out? What am I doing wrong?

# Update

As I originally predicted, the wiring is proprietary and the flow control signals are a mess. @SofaKng has reversed engineered the official cable and produced this table (reproduced here):

RJ45 pin,   DB9 pin (female)
----------------------------
1           1
2           6 + 8
3           2
4           5
5           5
6           3
7           4
8           7


# Original

You missed a key detail. Their RJ-45 patch cable is null modem wired. That means it is reversed. You got all of your pairs backwards (you connected TX to TX, RX to RX, etc...)

## Assuming you are using a straight-through patch cable...

• as you indicated that you are with your comment "standard TIA-568B"
• you must use TIA-568B ordering on both ends of your patch cable

## ...it goes this way:

Device Signal, RJ-45 Pin#, DB9 Pin#, PC Signal
----------------------------------------------
> DTR 1 --- 6 DSR
> GND 2 --- 5 GND
> RTS 3 --- 8 CTS
> TxD 4 --- 2 RXD
> RxD 5 --- 3 TXD
> DSR 6 --- 4 DTR
> GND 7 --- 5 GND <-- note: repeats, bussed to device #2
> CTS 8 --- 7 RTS
> RI  9 --- 9 RI  <-- doesn't actually fit in an RJ-45 (only 8 signals), probably safe to ignore if I read their diagram correctly


The DB9 on a PC is pinned out this way (see figure). Note how it is null-modem reversed from the table listing you provided. That's because their RJ-45 cable is null-modem reversed to cancel it out. Tricky and silly, but that's how they chose to implement it.

## Some other thoughts...

Actually, I noticed from tracing in the diagram that they do some very strange stuff with the flow-control signals. For example, they short CTS and DSR on the PC side, but not on the other side. They route RTS on the PC side to DSR on the device side. And other weirdness.

This may be bad documentation, but I suspect they have implemented custom firmware/software that makes use of the flow-control signals in non-standard ways as a means of ensuring that you only buy and use their cables and adapters.

I would suggest that you make two half cables. On one end go RJ-45 to unterminated wire and the other go DB9F to unterminated wire. Then you can twist your way through all of these weird configurations until you get it right. I would start with my suggested mapping. If that doesn't work, report back and I'll give you my mapping for all of their weirdness in the flow-control lines.

### Good luck! =)

• Very well explained, thanks! However... I ended up purchasing a pre-made cable and adapter (from Pacific Custom Cables) and it was wired -differently-, but it worked. I'll post my results in another answer... – SofaKng Dec 29 '12 at 18:18

I ended up ordering a premade cable and adapter from Pacific Custom Cables and they worked so I checked the pin-out of the RJ45 (null-modem) to DB9.

Based on their pin-out, I made a new cable (crimped RJ45 on one end, soldered DB9 female on the other end) and here is the working pin-out:

RJ45 pin,   DB9 pin (female)
----------------------------
1           1
2           6 + 8
3           2
4           5
5           5
6           3
7           4
8           7


I don't understand why that is the pin-out but that's what works and the pin-out from "official" cables and adapter.

• +1 Glad to hear you figured it out! I'll update my answer. That pattern isn't derived from the original documentation, so there must be something undisclosed and proprietary in play. – DrFriedParts Dec 29 '12 at 20:14