Data Carrier Detect
Data Carrier Detect, abbreviated as DCD, or alternately Carrier Detect abbreviated as CD, is a control signal present inside an RS-232 serial communications cable that goes between a computer and another device, such as a modem. This signal is a simple "high/low" status bit that is sent "from DCE to DTE", or in a typical scenario, from the peripheral to the computer. It is present on virtually all PC serial ports - pin 1 of a nine-pin (DE9) serial port, or pin 8 over a 25-pin (DB25) port. Its purpose varies depending on the device connected, but the most typical meaning is to indicate when a modem is connected to another remote modem via telephone lines.
The word "carrier" is a reference to the analog carrier signal generated by a modem, which is modulated to carry the data. On a data modem, loss of the carrier equates to termination of the connection.
Much like the Ring Indicator signal, on a PC's serial port, changes to the DCD signal state generate a hardware interrupt that can be captured by the processor any time the DCD signal changes state, preventing the PC from needing to constantly poll the pin.
Although DCD is a one-way signal from the device to the computer, the DTR (Data Terminal Ready) is the corresponding line that carries the same status from the computer back to the device, when applicable.
As used on modems
DCD is very important on modems, as it is the computer's primary way to find out that the modem has lost its connection to the remote host. Aside from intentional disconnects, modems can lose their connection for a variety of reasons unexpectedly - such as the phone line being disconnected. It is possible to use a modem without the DCD signal, however the only way for the computer to know that a connection is disconnected is by the modem transmitting the words "NO CARRIER" over the data lines. Because the words "NO CARRIER" are also a message that could appear in the context of a normal data session (for example, if typed by a person on the remote end), there is no positive way for a computer program to differentiate the words being sent over the connection versus from the modem.
External modems with LED status lights usually have a light labeled "CD" (carrier detect). This status light is directly coupled with what the modem is sending the DCD line.
By default, when a modem is powered up, the DCD signal stays low. It does not go high until the modem either makes an outgoing call, or answers an incoming call, and then connects with a data modem on the other end. The signal goes high at the same time the modem reports its CONNECT message, and stays high until the call is disconnected. The signal goes low again once the local modem has lost contact with the remote modem, regardless of which side initiated the disconnect. So long as the DCD signal is high, the computer can assume that any data coming from the modem was actually sent from the remote side.
DCD configurability on modems
Virtually all newer modems have a built-in capability of modifying what they do with RS-232 signals, depending on the application. The AT command for manipulating DCD is typically
AT&C followed by a single digit. More frequently, the setting is buried in a longer initialization string - such as
AT&F&D2&C1S0=0X4. Note that per the specifications, AT commands can be concatenated together by only specifying the characters "AT" once, followed by all the remaining commands strung together.
- AT&C0 - Always assert DCD
- This command tells a modem that it should always hold DCD high, regardless of the connection state. This takes away the ability for the host to positively detect a loss of connection. But in some cases it can be useful - such as when using a pre-configured modem to automatically answer and provide remote access to some equipment that wasn't meant to be connected to a modem. In that case, that equipment may require a "high" signal at all times for the communication setup to function. An external modem that has been configured with AT&C0 will have its CD light on at all times - even when not connected to a remote modem - to reflect the asserted DCD pin.
- AT&C1 (default for nearly all modems) - Assert DCD only when connected
- This sets the modem to behave normally, with DCD high only when connected to a host.
- AT&C2 (supported by most but not all modems) - Always assert DCD with disconnect signalling
- The modem asserts DCD whenever it is powered on, except immediately after sensing a disconnect. Upon sensing a disconnect, the DCD line goes low for a brief time (typically 1–2 seconds), and then returns high. Support can easily be determined by attempting the command, and noting the modem's response (ERROR versus OK).
The meaning of DCD differs when the modem is in fax or voice modes. In these modes, its importance is diminished. The fax and voice protocols provide for a data link escape (DLE) character in the data stream that permits the computer to differentiate between reports from the modem and data from the remote side. In those cases, if the remote side sends a byte matching the DLE byte, the modem sends it to the host PC twice in a row to signal that it came from remote. During fax and voice transmission, flow control (such as over RTS/CTS pair) is much more important than the DTR/DCD signal.
As used with null modems
A frequent use of a serial port is for a direct computer-to-computer connection. This requires an adapter called a null modem, which isn't actually a modem in the traditional sense, but rather a connector plug that simply crosses the complementary pins on two serial ports so the two sides can communicate. A null modem connects the DTR output of each computer to the DCD input of the other.
When used in this scenario, DCD is used to simply detect the presence and/or readiness of the other side to start a session. For example, on PCs running Windows, the DTR output is kept low until some program is run to access the serial port and raise the DTR signal high. The remote side will sense this as the DCD input going high. Some equipment will recognize the transition alone as the beginning of a session. Other equipment (such as the console port of a router) may expect characters to be transmitted, but the DCD signal high is still a prerequisite for every communication.
PPS (Pulse per second) timing use
One convenient means to provide a PPS signal to a computer system is to connect that signal to a modem-control pin on a serial-line interface to the computer. The Data Carrier Detect (DCD) pin is frequently used for this purpose. Typically, the time-code output of the time source is transmitted to the computer over the same serial line. The computer detects a signal transition on the DCD pin, usually by receiving an interrupt, and records a timestamp as soon as possible.
As used with other hardware
||This section possibly contains original research. (May 2013)|
Sometimes a computer is connected to a device that doesn't provide a DCD signal at all. If the computer software requires a DCD signal to properly recognize a connection, then this is mitigated simply by connecting a wire between the computer's own DTR and DCD pins, so the computer sees the high DCD signal it needs. Since DTR and DCD are typically used as a pair, any computer program requiring DCD high is likely to also provide a high DTR as output.
In Linux, each serial port is referenced by two device names - one being (for the first serial port)
/dev/cua0. Although these both refer to the same physical port, one important distinction between the way Linux treats these two device names has to do with the DCD line. When ttyS0 is waited on in a system call, Linux assumes that since this device is for receiving telephone calls, it will put a process to sleep— figuring that so long as DCD is low, there is nothing to do. When cua0 is used - as it is when placing telephone calls - Linux assumes that the software needs to access the port while DCD is low for the purpose of dialing the number, so this blocking behavior doesn't exist. Nevertheless, there is a control mode flag called CLOCAL that is what actually activates or deactivates this behavior, and by default the flag is set for cua0 but not for ttyS0. An application that insists on using a "tty" port versus a "cua" port is an example of one that might require a jumper wire to force DCD high in order to work properly.
- Hayes command set
- Mogul, J.; Mills, D.; Brittenson, J.; Stone, J.; Windl, U. (March 2000). "Introduction". Pulse-Per-Second API for UNIX-like Operating Systems. IETF. p. 3. RFC 2783. https://tools.ietf.org/html/rfc2783#page-3.
- Coldwell, Charles Terminal concepts in GNU/Linux