# What are TX and RX relative to?

I have been working with a device that uses RS232 communication to a PC. There has been some confusion as they have defined their TX and RX pins relative to the device. In their definitions they use to mean TX being the pin that sends data from the device. In my mind this should be labeled RX because it is the pin the computer receives on.

How should the pins be defined? Are they relative to each device or relative to the "controller"?

• I have never seen TX/RX be from other perspectives than the sending party. So that TX is the pin that the sending part sends on and RX is received on. I have never encountered naming like you suggest. – Morten Jensen Jul 2 '18 at 16:09
• RS232 pin naming is a bit of a special case because they defined things in terms of DTE (Data terminal equipment) and DCE (Data communications equipment) and managed to cause utter confusion. DCE has the data output on the RX pin and input on the TX pin, DTE is the opposite. In theory the sex of the connectors should tell you what is what, in practise enough manufacturers got this wrong to make it a less then reliable guide. There is a reason you used to be able to buy little boxes with D9 & D25 of different sexes with a kit of little jumper wires and some LEDS on the common signal lines. – Dan Mills Jul 2 '18 at 16:28
• When it is your birthday, I do not receive you a present. – ctrl-alt-delor Jul 2 '18 at 23:06
• @MortenJensen well if they're named from the perspective of the sending party, both should be called TX. – immibis Jul 2 '18 at 23:08
• @TerryCarmen Not true for DCE where the pin names and data flow directions are reversed per the standard. DTE Tx -> DCE Tx and DTE Rx -> DCE Rx, yea, weird and crap but it is what it is. – Dan Mills Jul 3 '18 at 9:12

It might be easier to understand, if we quickly review how the RS-232 standard was originally used.

Note: All pin numbers below refer to the original 25-pin D connector; the numbering changed on the 9-pin connector used on later PCs.

Background

DTE = Data Terminal Equipment - in the old days, this would usually be a terminal or a printer, or equipment emulating those.

DCE = Data Communications Equipment - in the old days, this would usually be a modem or other WAN interface.

Pin 2 on the original 25-pin D connector (described in the standard as "Transmitted Data", "Circuit BA", "V24. number 103") should be data from the DTE to the DCE.

Pin 3 on the original 25-pin D connector (described in the standard as "Received Data", "Circuit BB", "V24. number 104") should be data from the DCE to the DTE.

This meant that the cable linking a terminal and a modem was "straight through" - pin 2 on a terminal (DTE) at one end of the cable where data originated, was connected to pin 2 on a modem (or similar) at the other end of the cable (DCE) where that data was received. The modem then sent that data out using the communications link, to whatever equipment was on the other end of that link.

Pin 3 "Received Data" was the data signal in the opposite direction - transmitted by the modem (DCE) on pin 3, and received by the terminal (DTE) on pin 3.

Therefore you can see that the labelling of what was Transmitted and what was Received, was from the point of view of the DTE (i.e. the terminal). This all made sense when the typical connections were between a DCE and a DTE.

However the pieces of equipment we are using these days (even when they don't use RS-232 and are instead using a TTL or other voltage UART protocol interface) are usually all effectively DTE (with one exception being modems). Connecting pin 2 (which is an output) on one piece of DTE, to pin 2 (another output) on another piece of equipment configured as DTE, makes no sense (and when using logic level signals, could even cause hardware damage). This is where the use of "crossed" or "null modem" (i.e. no modem) cables comes in.

I have been working with a device that uses RS232 communication to a PC. There has been some confusion as they have defined their TX and RX pins relative to the device. In their definitions they use to mean TX being the pin that sends data from the device. In my mind this should be labeled RX because it is the pin the computer receives on.

How should the pins be defined? Are they relative to each device or relative to the "controller"?

From the above background info, you can see that their labelling is correct if their device is acting as DTE (which most are, unless it's a modem or other WAN interface). On a piece of DTE, the pin labelled "Transmitted Data" (pin 2 on the 25 pin connector) does send data. (And, as explained above, on a piece of DCE (e.g. a modem) the pin known as "Transmitted Data" (pin 2 on its 25 pin connector) is actually an input, which receives the signal from the DTE.)

The PC's serial port will also be configured as DTE (unless it has a very unusual serial port - that won't apply here, as you would know if it did apply).

Therefore you are connecting DTE device (this device you've mentioned) to DTE device (the PC) i.e. there is no DCE in "RS-232 terminology, i.e. no modem, and the "null modem" or "crossed" RS-232 wiring will be needed. Whichever pin is RS-232 "Transmitted Data" (probably the one you mention they have labelled as TX) on this DTE device, which will be an output, will need to be connected to the RS-232 "Received Data" pin on your PC (also a DTE device), which is an input (and obviously vice versa for data transfer in the other direction).

Although this doesn't seem to apply to you, I'll just add: To make life more complicated, some manufacturers try to "help" by effectively labelling their DTE equipment as if it was a piece of DCE. They mark their data input pin as Tx so that user just connects "Tx" from the external device (which, if it's DTE, will be the data output from there) to the pin marked "Tx" on their equipment (which they know is an input). Thereby allowing them to say "just connect Tx on your device to Tx on our equipment". They think they are trying to help, but such labelling often just adds to the confusion.

As Dan Mills mentioned in a comment, many of us who grew up with RS-232, spent happy hours having to connect various equipment with slightly different RS-232 implementations, using the "breakout boxes" which he described. These breakout boxes have LEDs, which show which signals are being actively driven (this quickly allows you to see if the equipment is configured as DTE or DCE: Is pin 2 driven on that equipment? Yes = it's DTE) and have places where short jumper cables can be used to link the various connector pins.

• Common practice if things don't work, is to swap connections on pins 2 and 3 at one end of the cable (this works on both DE-9 and DB25 connectors) – Peter Bennett Jul 2 '18 at 23:37
• True. In the context of this specific question where it's RS-232 (not logic-level signals) and no hardware handshaking is mentioned, then swapping pins 2 & 3 would be something to try (since accidentally connecting two RS-232 outputs shouldn't cause permanent damage). Unfortunately things get complicated when hardware handshaking is involved (as the problem could be in the various configurations of those signals). Then swapping pins 2 and 3 may not solve the problem, or may not solve the only problem. This brings back memories of breakout boxes & analysing what wasn't in the documentation. – SamGibson Jul 2 '18 at 23:55
• Oh yessss, RTS/CTS/DSR/DTR... So many, many possibilities, even before you get to fun things like one end wanting software flow control and the other expecting RTS/CTS. And yes, the documentation always stank. I bitch about USB (Three types of crap plug mainly, also mostly crap software stacks), but thinking back '232 was a whole other level of craptastic. – Dan Mills Jul 3 '18 at 10:36

Unlike many bus-like configurations, which use signal name, the serial communication traditionally uses function name for pins. So, if the device transmits on some pin, it is marked Tx. If it receives, it is marked Rx. Obviously you connect Tx of one device with RX of the other and vice versa.

To put it into perspective, the device you are talking about also has a "computer" in it, which is what MCU basically is. Why should one computer dictate the names of the other computer's pins, especially considering bi-directional asynchronous nature of communication?

The special case is when the device in question is pass-through kind, like an old modem or modern FT232 converter. They are not using Tx/Rx pins to communicate with computer, they use them to pass computer's communication further down the line. For this reason their pins are named after the signals coming through.

UPDATE: Here are couple examples to illustrate the point.

Probably millions of people are using Arduinos nowadays, some even without having slightest idea how it works. They connect Tx to Rx, Rx to Tx, Gnd to Gnd and they are good to go. What they often don't realize, is that they are technically creating null-modem, which allows two MCUs talk to each other.

Now, the same people sometimes want to add USB connectivity to their Arduinos. They connect TX to TX and RX to RX on the adapter or converter chip. Note that those often named "TX-IN" and "RX-OUT" to avoid confusion. Again, what seems to be obvious but rarely thought about, is that technically this USB adapter is a pass-through device. What it "says" on RX pin is not coming from adapter itself, it is coming from the device on the other side of the line. And guess what? It is connected to TX pin somewhere.

• This is incorrect. The standard specifies DTE and DCE (the two things talking to each other), and TX/RX are specified from the perspective of one of these (I forget which). This detail has been lost over the years and the use of the labels have gotten so murky that even experienced electrical engineers make the mistake. – Steve Jul 2 '18 at 21:42
• SamGibson's answer is very good. – Steve Jul 2 '18 at 21:43
• @Steve "The detail has been lost"?! The specification of RS232 is all over the web! The names TX/RX specified for DTE side because DTE and DCE are not "talking to each other" over those pins, they use multiple control signals for that. The modem and computer have nothing to say to each other otherwise. Modem simply passes those signals through. But you can connect two DTE using null-modem and where is you perspective then? They both are computers, they ARE talking to each other and that is exactly the situation described in OP question. – Maple Jul 2 '18 at 23:26
• DTE to DTE of course works. I'm surprised you didn't include any information about DTE and DCE in your answer, though, which goes a lot toward understanding why your answer is correct. I suppose I mis-spoke when I said your answer is incorrect, but it perpetuates the other misunderstanding here - By "the detail has been lost" I mean that most engineers don't even think about this and just "try it til it's right", or label DCE equipment with DTE signal names. And, not including that detail helps perpetuate this a bit... – Steve Jul 2 '18 at 23:40
• @Steve I intentionally avoided mentioning DTE/DCE because you cannot go there without discussing a lot of important but irrelevant to the question control signals etc. Anyway, I've updated the answer with some examples to make things clearer. – Maple Jul 3 '18 at 0:57

They're usually relative to the device, since RS232 devices don't have a "master/slave" or "client/server" relationship. The SPI protocol has a master/slave architecture, so they're labeled "MISO" (Master In Slave Out) and "MOSI" (left as an exercise to the student). That's at the device level; I can't speak to what individual circuit designers might choose as net names.

• They do have a "DTE/DCE" relationship, but as @Maple describes, they stopped there. Actually some deep history can explain what they did. – gbarry Jul 2 '18 at 16:33
• This answer, while accurately describing the current way people treat RS-232, is technically wrong (as @gbarry points out re DCE/DTE). – Steve Jul 2 '18 at 21:45

Unfortunately, for engineers this is a conundrum between two slices of turd.

There is no real logical solution, both ways can make logical sense.

I try to label pins, pcbs, IC layouts, tables of connections, software, with the words IN/OUT and/or arrows showing the direction. Use the words "TX-out" "RX-in" "CTS-out" "RTS-in" on your schematics etc. This completely resolves the ambiguity. [I do generally think that TX and RX should be correctly named i.e. TX should be an output].

Here is a pcb where the signals cross an isolation barrier. Note the arrows, so someone debugging it, or trying to fit a connector clearly knows which ways the signals are going.

The control signals are even worse. (as well as an electrical direction, they have a logical control direction too)

Control signals have a documentation explicitly laying out the function: 'CTS (out) signals the computer that the device is ready to receive data'

Sometimes both ways make sense at the same time: I have a chip where RX and TX are correctly named with their own function (from the chips perspective). But the handshake pins are named CTS and RTS matching the PC pins they will connect to, because this is what software and status lights refer to.

Something that has helped in recent years, is having devices use use a DE9F connector that connects directly to a PC serial port with a straight through m-f cable. That has reduced the free for all of the past.

• You're showing RXD> with the arrow pointing away from the pin, which means that there is a signal coming out of that pin - I would certainly expect that to be an output, not an input! – pipe Jul 3 '18 at 15:15
• @pipe If you consider where the chip is on the circuit board, relative to the connector, then it is not at all ambiguous to someone who is working on the product with no documentation. The arrow accurately represents signal flow. [interesting linguistic point: Unlike "out"/"in", arrows only have intrinsic meaning within a spatial context] – Henry Crun Jul 3 '18 at 21:20