Serial comm

Serial port - Wikipedia

In computing, a serial port is a serial communication interface through which information transfers in or out one bit at a time (in contrast to a parallel port).[1] Throughout most of the history of personal computers, data was transferred through serial ports to devices such as modems, terminals, and various peripherals.

While such interfaces as Ethernet, FireWire, and USB all send data as a serial stream, the term "serial port" usually identifies hardware more or less compliant to the RS-232 standard, intended to interface with a modem or with a similar communication device.

Modern computers without serial ports may require serial-to-USB converters to allow compatibility with RS-232 serial devices. Serial ports are still used in applications such as industrial automation systems, scientific instruments, point of sale systems and some industrial and consumer products. Server computers may use a serial port as a control console for diagnostics. Network equipment (such as routers and switches) often use serial console for configuration. Serial ports are still used in these areas as they are simple, cheap and their console functions are highly standardized and widespread. A serial port requires very little supporting software from the host system.


Some computers, such as the IBM PC, use an integrated circuit called a UART. This IC converts characters to and from asynchronous serial form, implementing the timing and framing of data in hardware. Very low-cost systems, such as some early home computers, would instead use the CPU to send the data through an output pin, using the bit banging technique. Before large-scale integration (LSI) UART integrated circuits were common, a minicomputer or microcomputer would have a serial port made of multiple small-scale integrated circuits to implement shift registers, logic gates, counters, and all the other logic for a serial port.

Early home computers often had proprietary serial ports with pinouts and voltage levels incompatible with RS-232. Inter-operation with RS-232 devices may be impossible as the serial port cannot withstand the voltage levels produced and may have other differences that "lock in" the user to products of a particular manufacturer.

Low-cost processors now allow higher-speed, but more complex, serial communication standards such as USB and FireWire to replace RS-232. These make it possible to connect devices that would not have operated feasibly over slower serial connections, such as mass storage, sound, and video devices.

Many personal computer motherboards still have at least one serial port, even if accessible only through a pin header. Small-form-factor systems and laptops may omit RS-232 connector ports to conserve space, but the electronics are still there. RS-232 has been standard for so long that the circuits needed to control a serial port became very cheap and often exist on a single chip, sometimes also with circuitry for a parallel port.

IBM PC Serial Card with 25 pin connector (obsolete 8-bit ISA card) A four-port serial (RS-232) PCI Express ×1 expansion card with an octopus cable that breaks the card's DC-37 connector into four standard DE-9 connectors A converter from USB to an RS-232 compatible serial port; more than a physical transition, it requires a driver in the host system software and a built-in processor to emulate the functions of the IBM XT compatible serial port hardware.

DTE and DCE[edit]

The individual signals on a serial port are unidirectional and when connecting two devices the outputs of one device must be connected to the inputs of the other. Devices are divided into two categories data terminal equipment (DTE) and data circuit-terminating equipment (DCE). A line that is an output on a DTE device is an input on a DCE device and vice versa so a DCE device can be connected to a DTE device with a straight wired cable. Conventionally, computers and terminals are DTE while modems and peripherals are DCE.

If it is necessary to connect two DTE devices (or two DCE devices but that is more unusual) a cross-over null modem, in the form of either an adapter or a cable, must be used.

Male and female[edit]

DE-9 gender changers, showing both male (visible on the left) and female DE-9 connectors (visible on the right)

Generally, serial port connectors are gendered, only allowing connectors to mate with a connector of the opposite gender. With D-subminiature connectors, the male connectors have protruding pins, and female connectors have corresponding round sockets.[2] Either type of connector can be mounted on equipment or a panel; or terminate a cable.

Connectors mounted on DTE are likely to be male, and those mounted on DCE are likely to be female (with the cable connectors being the opposite). However, this is far from universal; for instance, most serial printers have a female DB25 connector, but they are DTEs.[3]


While the RS-232 standard originally specified a 25-pin D-type connector, many designers of personal computers chose to implement only a subset of the full standard: they traded off compatibility with the standard against the use of less costly and more compact connectors (in particular the DE-9 version used by the original IBM PC-AT). The desire to supply serial interface cards with two ports required that IBM reduce the size of the connector to fit onto a single card back panel. A DE-9 connector also fits onto a card with a second DB-25 connector. Starting around the time of the introduction of the IBM PC-AT, serial ports were commonly built with a 9-pin connector to save cost and space. However, presence of a 9-pin D-subminiature connector is not sufficient to indicate the connection is in fact a serial port, since this connector is also used for video, joysticks, and other purposes.

Some miniaturized electronics, particularly graphing calculators and hand-held amateur and two-way radio equipment, have serial ports using a phone connector, usually the smaller 2.5 or 3.5 mm connectors and use the most basic 3-wire interface.

Many models of Macintosh favor the related RS-422 standard, mostly using German mini-DIN connectors, except in the earliest models. The Macintosh included a standard set of two ports for connection to a printer and a modem, but some PowerBook laptops had only one combined port to save space.

Since most devices do not use all of the 20 signals that are defined by the standard, smaller connectors are often used. For example, the 9-pin DE-9 connector is used by most IBM-compatible PCs since the IBM PC AT, and has been standardized as TIA-574. More recently, modular connectors have been used. Most common are 8P8C connectors, for which the EIA/TIA-561 standard defines a pinout, while the "Yost Serial Device Wiring Standard"[4] invented by Dave Yost (and popularized by the Unix System Administration Handbook) is common on Unix computers and newer devices from Cisco Systems. 10P10C connectors can be found on some devices as well. Digital Equipment Corporation defined their own DECconnect connection system which is based on the Modified Modular Jack (MMJ) connector. This is a 6-pin modular jack where the key is offset from the center position. As with the Yost standard, DECconnect uses a symmetrical pin layout which enables the direct connection between two DTEs. Another common connector is the Dh20 header connector common on motherboards and add-in cards which is usually converted via a cable to the more standard 9-pin DE-9 connector (and frequently mounted on a free slot plate or other part of the housing).

9-pin to 25-pin D-type adapter cable A Hirose 3560-16S used for RS-232 on a Tatung TWN-5213 CU tablet computer. Below is a mating 3540-16P-CV connector.


The following table lists commonly used RS-232 signals and pin assignments.[5]

Signal Direction Connector pin Name V.24 (de) circuit Abbreviation DTE DCE DB-25 DE-9(TIA-574) MMJ 8P8C ("RJ45") 10P10C ("RJ50") EIA/TIA-561 Yost (DTE) Yost (DCE) Cyclades[6] Digi (ALTPIN option)[7] National Instruments[8] Cyclades[6] Digi[9]
Transmitted Data 103 TxD Out In 2 3 2 6 6 3 3 4 8 4 5
Received Data 104 RxD In Out 3 2 5 5 3 6 6 5 9 7 6
Data Terminal Ready 108/2 DTR Out In 20 4 1 3 7 2 2 8 7 3 9
Data Carrier Detect 109 DCD In Out 8 1 N/A 2 2 7 7 1 10 8 10
Data Set Ready 107 DSR In Out 6 6 6 1 8 N/A 5 9 2
Ring Indicator 125 RI In Out 22 9 N/A N/A N/A N/A N/A 2 10 1
Request To Send 105 RTS Out In 4 7 N/A 8 8 1 1 2 4 2 3
Clear To Send 106 CTS In Out 5 8 N/A 7 1 8 5 7 3 6 8
Signal Ground 102 G Common 7 5 3, 4 4 4, 5 4, 5 4 6 6 5 7
Protective Ground 101 PG Common 1 N/A N/A N/A N/A N/A N/A 3 N/A 1 4

The signal ground is a common return for the other connections; it appears on two pins in the Yost standard but is the same signal. The DB-25 connector includes a second "protective ground" on pin 1, which is intended to be connected by each device to its own frame ground or similar. Connecting this to pin 7 (signal reference ground) is a common practice but not recommended.

Note that EIA/TIA 561 combines DSR and RI,[10][11] and the Yost standard combines DSR and DCD.

Powered serial port[edit]

Some serial ports on motherboards or add-in cards provide jumpers that select whether pin 1 of the DE-9 connector connects to DCD or a power supply voltage, and whether pin 9 of the DE-9 connector connects to RI or a power supply voltage. The power supply voltage can be +5V, +12V, +9V, or ground. (Selection varies by vendor.) The power is intended for use by point-of-sale equipment. Makers include Dell[12], HP, and others[13] (This is not an official standard.)

Hardware abstraction[edit]

Operating systems usually create symbolic names for the serial ports of a computer, rather than requiring programs to refer to them by hardware address.

Unix-like operating systems usually label the serial port devices /dev/tty*. TTY is a common trademark-free abbreviation for teletype, a device commonly attached to early computers' serial ports, and * represents a string identifying the specific port; the syntax of that string depends on the operating system and the device. On Linux, 8250/16550 UART hardware serial ports are named /dev/ttyS*, USB adapters appear as /dev/ttyUSB* and various types of virtual serial ports do not necessarily have names starting with tty.

The DOS and Windows environments refer to serial ports as COM ports: COM1, COM2,..etc. Ports numbered greater than COM9 should be referred to using the \\.\COM10 syntax.[14]

Common applications for serial ports[edit]

The RS-232 standard is used by many specialized and custom-built devices. This list includes some of the more common devices that are connected to the serial port on a PC. Some of these such as modems and serial mice are falling into disuse while others are readily available.

Serial ports are very common on most types of microcontroller, where they can be used to communicate with a PC or other serial devices.

Since the control signals for a serial port can be easily turned on and off by a switch, some applications used the control lines of a serial port to monitor external devices, without exchanging serial data. A common commercial application of this principle was for some models of uninterruptible power supply which used the control lines to signal loss of power, low battery, and other status information. At least some Morse code training software used a code key connected to the serial port, to simulate actual code use. The status bits of the serial port could be sampled very rapidly and at predictable times, making it possible for the software to decipher Morse code.


Some common speeds Bit rate(Baud rate) Time perbit Windowssupport[19]
50 bit/s 20000 µs No
75 bit/s 13333.3 µs Yes
110 bit/s 9090.9 µs Yes
134.5 bit/s 7434.9 µs Yes
150 bit/s 6666.6 µs Yes
300 bit/s 3333.3 µs Yes
600 bit/s 1666.7 µs Yes
1,200 bit/s 833.3 µs Yes
1,800 bit/s 555.6 µs Yes
2,400 bit/s 416.7 µs Yes
4,800 bit/s 208.3 µs Yes
7,200 bit/s 138.9 µs Yes
9,600 bit/s 104.2 µs Yes
14,400 bit/s 69.4 µs Yes
19,200 bit/s 52.1 µs Yes
38,400 bit/s 26.0 µs Yes
56,000 bit/s 17.9 µs Yes
57,600 bit/s 17.4 µs Yes
76,800 bit/s 13.0 µs No
115,200 bit/s 8.68 µs Yes
128,000 bit/s 7.81 µs Yes
230,400 bit/s 4.34 µs No
256,000 bit/s 3.91 µs No
460,800 bit/s 2.17 µs No

Many settings are required for serial connections used for asynchronous start-stop communication, to select speed, number of data bits per character, parity, and number of stop bits per character. In modern serial ports using a UART integrated circuit, all settings are usually software-controlled; hardware from the 1980s and earlier may require setting switches or jumpers on a circuit board. One of the simplifications made in such serial bus standards as Ethernet, FireWire, and USB is that many of those parameters have fixed values so that users cannot and need not change the configuration; the speed is either fixed or automatically negotiated. Often if the settings are entered incorrectly the connection will not be dropped; however, any data sent will be received on the other end as nonsense.


Serial ports use two-level (binary) signaling, so the data rate in bits per second is equal to the symbol rate in baud. A standard series of rates is based on multiples of the rates for electromechanical teleprinters; some serial ports allow many arbitrary rates to be selected. The port speed and device speed must match. The capability to set a bit rate does not imply that a working connection will result. Not all bit rates are possible with all serial ports. Some special-purpose protocols such as MIDI for musical instrument control, use serial data rates other than the teleprinter series. Some serial port systems can automatically detect the bit rate.

The speed includes bits for framing (stop bits, parity, etc.) and so the effective data rate is lower than the bit transmission rate. For example, with 8-N-1 character framing only 80% of the bits are available for data (for every eight bits of data, two more framing bits are sent).

Bit rates commonly supported include 75, 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bit/s.[20]Crystal oscillators with a frequency of 1.843200 MHz are sold specifically for this purpose. This is 16 times the fastest bit rate and the serial port circuit can easily divide this down to lower frequencies as required.

Data bits[edit]

The number of data bits in each character can be 5 (for Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for most kinds of data, as this size matches the size of a byte), or 9 (rarely used). 8 data bits are almost universally used in newer applications. 5 or 7 bits generally only make sense with older equipment such as teleprinters.

Most serial communications designs send the data bits within each byte LSB (least significant bit) first. This standard is also referred to as "little endian." Also possible, but rarely used, is "big endian" or MSB (most significant bit) first serial communications; this was used, for example, by the IBM 2741 printing terminal. (See Bit numbering for more about bit ordering.) The order of bits is not usually configurable within the serial port interface. To communicate with systems that require a different bit ordering than the local default, local software can re-order the bits within each byte just before sending and just after receiving.


Parity is a method of detecting errors in transmission. When parity is used with a serial port, an extra data bit is sent with each data character, arranged so that the number of 1 bits in each character, including the parity bit, is always odd or always even. If a byte is received with the wrong number of 1s, then it must have been corrupted. However, an even number of errors can pass the parity check.

Electromechanical teleprinters were arranged to print a special character when received data contained a parity error, to allow detection of messages damaged by line noise. A single parity bit does not allow implementation of error correction on each character, and communication protocols working over serial data links will have higher-level mechanisms to ensure data validity and request retransmission of data that has been incorrectly received.

The parity bit in each character can be set to none (N), odd (O), even (E), mark (M), or space (S). None means that no parity bit is sent at all. Mark parity means that the parity bit is always set to the mark signal condition (logical 1) and likewise space parity always sends the parity bit in the space signal condition. Aside from uncommon applications that use the 9th (parity) bit for some form of addressing or special signaling, mark or space parity is uncommon, as it adds no error detection information. Odd parity is more useful than even, since it ensures that at least one state transition occurs in each character, which makes it more reliable. The most common parity setting, however, is "none", with error detection handled by a communication protocol.

Stop bits[edit]

Stop bits sent at the end of every character allow the receiving signal hardware to detect the end of a character and to resynchronise with the character stream. Electronic devices usually use one stop bit. If slow electromechanical teleprinters are used, one-and-one half or two stop bits are required.

Conventional notation[edit]

The data/parity/stop (D/P/S) conventional notation specifies the framing of a serial connection. The most common usage on microcomputers is 8/N/1 (8N1). This specifies 8 data bits, no parity, 1 stop bit. In this notation, the parity bit is not included in the data bits. 7/E/1 (7E1) means that an even parity bit is added to the 7 data bits for a total of 8 bits between the start and stop bits. If a receiver of a 7/E/1 stream is expecting an 8/N/1 stream, half the possible bytes will be interpreted as having the high bit set.

Flow control[edit]

In many circumstances a transmitter might be able to send data faster than the receiver is able to process it. To cope with this, serial lines often incorporate a "handshaking" method, usually distinguished between hardware and software handshaking.

Hardware handshaking is done with extra signals, often the RS-232 RTS/CTS or DTR/DSR signal circuits. Generally, the RTS and CTS are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. DTR and DSR are usually on all the time and, per the RS-232 standard and its successors, are used to signal from each end that the other equipment is actually present and powered-up. However, manufacturers have over the years built many devices that implemented non-standard variations on the standard, for example, printers that use DTR as flow control.

Software handshaking is done for example with ASCII control characters XON/XOFF to control the flow of data. The XON and XOFF characters are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the data being sent. The circuit starts in the "sending allowed" state. When the receiver's buffers approach capacity, the receiver sends the XOFF character to tell the sender to stop sending data. Later, after the receiver has emptied its buffers, it sends an XON character to tell the sender to resume transmission. It is an example of in-band signaling, where control information is sent over the same channel as its data.

The advantage of hardware handshaking is that it can be extremely fast; it doesn't impose any particular meaning such as ASCII on the transferred data; and it is stateless. Its disadvantage is that it requires more hardware and cabling, and these must be compatible at both ends.

The advantage of software handshaking is that it can be done with absent or incompatible hardware handshaking circuits and cabling. The disadvantage, common to all in-band control signaling, is that it introduces complexities in ensuring that a) control messages get through even when data messages are blocked, and b) data can never be mistaken for control signals. The former is normally dealt with by the operating system or device driver; the latter normally by ensuring that control codes are "escaped" (such as in the Kermit protocol) or omitted by design (such as in ANSI terminal control).

If no handshaking is employed, an overrun receiver might simply fail to receive data from the transmitter. Approaches for preventing this include reducing the speed of the connection so that the receiver can always keep up; increasing the size of buffers so it can keep up averaged over a longer time; using delays after time-consuming operations (e.g. in termcap) or employing a mechanism to resend data which has been corrupted (e.g. TCP).

"Virtual" serial ports[edit]

A virtual serial port is an emulation of the standard serial port. This port is created by software which enable extra serial ports in an operating system without additional hardware installation (such as expansion cards, etc.). It is possible to create a large number of virtual serial ports in a PC. The only limitation is the amount of resources, such as operating memory and computing power, needed to emulate many serial ports at the same time.

Virtual serial ports emulate all hardware serial port functionality, including baud rate, data bits, parity bits, stop bits, etc. Additionally, they allow controlling the data flow, emulating all signal lines (DTR, DSR, CTS, RTS, DCD, and RI) and customizing pinout. Virtual serial ports are common with Bluetooth and are the standard way of receiving data from Bluetooth-equipped GPS modules.

Virtual serial port emulation can be useful in case there is a lack of available physical serial ports or they do not meet the current requirements. For instance, virtual serial ports can share data between several applications from one GPS device connected to a serial port. Another option is to communicate with any other serial devices via internet or LAN as if they are locally connected to computer (serial over LAN/serial-over-Ethernet technology). Two computers or applications can communicate through an emulated serial port link. Virtual serial port emulators are available for many operating systems including MacOS, Linux, and various mobile and desktop versions of Microsoft Windows.

See also[edit]


Further reading[edit]

  • Serial Port Complete: COM Ports, USB Virtual COM Ports, and Ports for Embedded Systems; 2nd Edition; Jan Axelson; Lakeview Research; 380 pages; 2007; ISBN 978-1-931-44806-2.

External links[edit]

Serial Communication

5. Ethernet wiring











Port Transport Protocol Name Application
7 TCP/UDP echo echo
20 TCP ftp File Transfer (data)
21 TCP ftp File Transfer (command)
23 TCP telnet Telnet, unencrypted text communications
25 TCP smtp Simple Mail Transfer Protocol
43 TCP whois WHOIS protocol
80 TCP http Hypertext Transfer Protocol
101 TCP   NIC host name
107 TCP   Remote TELNET Service protocol
109 TCP pop2 Post Office Protocol 2
110 TCP pop3 Post Office Protocol 3
115 TCP sftp Simple File Transfer Protocol
554 TCP/UDP RTSP Real Time Streaming Protocol
5004 TCP/UDP RTP Real-time Transport Protocol (media)
5005 TCP/UDP RTP Real-time Transport Protocol (control)







If you are interested in the binary level on Ethernet standard. Here is some basic information on the low level or hardware aspect Ethernet from Analog Devices.

- 2008-04-00 A Beginner Guide to Ethernet.pdf

The Ethernet looks very remote to me when I first try to understand it. It is very complex. After a few years of experience, I slowly gain enough confident to talk about this type of communication.

In fact, Ethernet is another form of serial communication. The hardware aspect is similar to RS485, with pin 1 & 2 handling the transmission of the serial data, while pin 3 & 6 is for the  receiving of serial data. I have not find any concrete information, but I imagine it closely to a RS422. One pair of wire for TX, the another pair for RX. The physical signal for RS422 is the same as RS485. The signal are interchangeable. RS422 is a duplex while RS485 is a half duplex communication line (see above for further information).

The beautiful part of Ethernet is on the streaming bytes riding on the serial communication line. This stream of bytes is also define as the data packets or protocol. It is the data protocol that make Ethernet so special. Which is why there is so little information on the physical aspect on the Ethernet. Ethernet is all about protocol. Protocol consist of the data and the header. The header contains the MAC, IP, PORT and other information which will helps the data packet to be routed to the correct destination. You can imagine a letter to be delivered. Letter contains address which helps the post man to deliver the letter.

What we typical see on the cover of a letter:

Att: David

myCompany Pte Lte (business registration number J123456789)

Street 3, Blk 3, #03-33.

myCompany denote the company name which can be quite unique. You can imagine the MAC address as the company name or as a business registration number. The MAC address is a set of number (6 bytes, 0x11 0xAA 0x22 0xBB 0x99 0xFF) which uniquely identify the electronics hardware Ethernet device. It is the basic number the hardware will have, which identify itself from the rest from other gadgets. Most computer have at least one network card/adaptor. Each card is a unique communication device, and therefore have it's own MAC address. If a PC has 3 network card installed, it would have 3 different MAC address. MAC address is the 6 bytes ID of the Ethernet hardware.

Next comes the IP address. You can think of it as your home address. The number for IPv4 (IP version 4) is 4 bytes long ( Unlike a MAC address, IP address can be configured by the user/programmer. You can imagine that while the company name remains no change, no matter where it shifted it's address. IP address can be changed. Like a letter, the IP address will allows your data packet to be delivered to the correct place. Each Ethernet hardware (network card) will have it's own MAC address. Each MAC address will be assigned the IP address. Your company will be identified by it's unique number and the location address. A typical computer installed with 1 Ethernet card, can be identified with it's MAC and IP address.

PORT is quite tricky to me at first. What is exactly a port. You can relate it to the name of the person on our letter example. The letter may be delivered to the correct address, but it does not indicate who should receive the letter. Port identify the person that should receive the data packet. In our computer example PORT is a number which defines the application software that receive the data. When you open up your web browser, the browser software will open it's port number 80. Any incoming data packet indicating port 80, will be passed to the browser software. The browser software will then render the data onto the screen for you to read. Similarly other network application works in this way. Some common application's protocol and it's port number are as follows,


Protocol in details.


IPv4 (Internet Protocol version 4)


IPv6 (Internet Protocol version 6)


TCP (TCP Transmission Control Protocol)


UDP (User Datagram Protocol)


ICMP (Internet Control Message Protocol)



My complete understanding about port, actually started off from it's strange name "port". At that time, I cannot visualize what is exactly a port. I started to think about its name. Why people call it a port. While writing article on RS232 com port, my mind suddenly opens up. I am convinced today that, the word port comes from our old computer parallel/serial port. It is a revolution of data communication.

I started to imagine wildly with any references. Imagine in olden days where Ethernet is not known yet, people used serial/parallel port for communication. Each application occupy a port, which is the current situation with serial and parallel port. You cannot have two software application using the same port number. If there are more application that needs to communicate, you can imagine that the computer will need a lot of RS232 port at the back. Each and every port is being occupied by the respective software for communication. Many cable as we can imagine. That will be quite a headache. The Ethernet consolidate these physical communication lines into just only one. In order for the application to identify their own data, the port number is implemented into the data header/protocol. The port number actually acts as a virtual port for the computer, and will route the packets to the correct software application. Now all packets communicate through the same physical Ethernet cable. A bit of imagination will helps a lot in understanding the topic.

The data packet route to the correct IP address, after which it will check if it arrive to the correct MAC ID. When the packet reaches into the computer, the packet is further route to the port, where the appropriate application software will read and further interpret the data packet.

Ethernet has more features, but the basic concept is still as easy to understand as a RS232 serial communication.





What we have discuss so far is only the protocol on IPv4 header. Protocol or header is just bytes of information that describe about the data it carries. The data itself may also contains its own header which interpret another data within. It is like layers and layers of onion skin. Just as you peel off the header for the data, you notice another header to peel. Layer after layer, we finally got our data.

The first layer is IPv4 (still quite common in this era dated: July 2009) or IPv6 header (new protocol).

Going deeper, we have another layer typically TCP or UDP. They defines the manner, the data is being exchanged across the communication channel. TCP/IP protocol means that the data is transported using the IP and TCP header. Two layer actually.






- rfc792 (ICMP protocol)

- icmp protocol

- an-139 (how to route PCB)

- all about Ethernet


Loop Back Ethernet Connector

-         Short Pin 1 to Pin 3

-         Short Pin 2 to Pin 6


After so much theory, let's talk more physical stuff on Ethernet. As shown on the bottom and left, these are the typical wiring on the network. Straight cable between the network equipment and PC, and also cross cable between PC to PC or equipment to equipment.




Ethernet Pin Out from your computer device

Pin no. Color   Description
1 Orange /White TX+
2 Orange   TX-
3 Green /White RX+
4 Blue   ---
5 Blue /White ---
6 Green   RX-
7 Brown /White ---
8 Brown   ---




I have been looking for hours a confirmation on the network pin 1 & 2 (TX). Whether the pin out is referring to a DTE (a computer) or DCE (network switch/hub). Most website indicates the TX RX pin out scheme, but did not indicate whether the description is for a DTE or DCE. After searching for so long, I finally found it.

I would like to give credit to this website for providing the information.







CAT7, SSTP, individual shielding, solid core


1 Jacket2 Shield-braid3 Shield-foil4 Solid twisted pair5 Drain wire
CAT6a, STP, individual shielding, solid core


1 Jacket2 Shield-foil3 Drain wire4 Solid twisted pair
CAT5e, FTP, shielding, solid core



1 Jacket2 Shield foil3 Drain wire4 Protective skin5 Solid twisted pair
CAT5, UTP, no shielding, solid core


1 Jacket2 Solid twisted pair


Cable manufacturers





About cable

Notice that a network cable contains 4 pair of twisted cable, and the pair is differentiated by the 4 sets of color pair. If you remember the RS485 wiring as mention in the earlier section, these twisted wire will look very familiar to you again. The twisted wire provides a better protection against possible interference. Notice how the twisted pair is assigned to the RX signal and the other pair assigned to TX signal.

There are many type of cat cable to choose from. Depending on your deployment need, these are some of the selection that you may have to consider.

- CAT5e, CAT6a, CAT7, CAT8


- Solid or Stranded wire core

- Indoor or Outdoor

- AWG wire size


Some people may refer the network cable as RJ45, which is not correct. RJ45 is actually the name of the plug. Another name for the plug is 8P8C connectors.

The twisted pair cabling standard is refer as the CAT standard. The term is typically being referred to when selecting the type of network cable. The CAT define the signal frequency that the cable is able to carry for a distance of 100m. High frequency signal gets filter away as the cable becomes longer, which also means that the data rate will be reduced. This means that a short CAT5e cable is able to transmit as fast as a longer CAT7 cable. Therefore 100m is a normalize distance to compare between the cable quality.


Standard Max Frequency
CAT7a 1000Mhz
CAT7 600Mhz
CAT6a 500Mhz
CAT5e 100Mhz


Some network cable comes with aluminum foil shielding to protect the signal from external noise interference. FTP cable have a single foil covering the 4 twisted pair. STP call for a foil shielding for each twisted pair inside the cable, improving interference from adjacent twisted pair. SSTP is similar to STP with an extra foil around the 4 twisted pair, creating a double foil shielding. Unshielded cable is indicated by UTP.

The cable may also comes with either a solid or stranded for the core of the wire. Solid core is typically suitable for permanent deployment where it is unlikely that the cable position would be changed. Stranded version is suitable for patching purposes, where the cable get to be used or bend more frequently. Stranded cable is more robust then a solid core version for patching use. cable also comes in a more rugged packaging for outdoor use. The protective cable skin is tougher and the cable core may be reinforced with a backbone that protects the cable from being crush by heavy weight.

The AWG (America wire gauge) specify the size of the copper wire core. Bigger AWG number denote a smaller cross section area, though lower current than a smaller AWG cable. cable has AWG ranged from AWG 22 to 24.








Coaxial cable is a much better structure than a twisted pair configuration. Coaxial cable can carrying a much higher frequency due to it's structure carrying signal in transverse electric magnetic (TEM) mode. The cable is however bulky, heavy and more costly as compare to a twisted pair alternative.



reference from:

Serial communications

Serial Communications

Serial transmission is often preferred over parallel transmission, even though it has a lower transfer rate, due to its simplicity, low cost and ease of use. Many peripherals also do not require the high data rates of a parallel interface.

Baud rate

The number of changes/symbols transmitted, per second. When there are only two states, this is equal to the Bit rate.

Bit rate

The number of bits transferred per second.

Data rate

The rate at which meaningful information is sent - the bit rate less the overhead of start and stop bits.

Asynchronous Serial Data Transmission

The asynchronous serial interface is so called because the transmitted and received data are not synchronised over any extended period of time and therefore no special means of synchronising the clocks at the transmitter and receiver is necessary. The fundamental problem lies in how to split the data stream into individual bits and how to then reconstruct the original data. The format of the data on a serial data link is in fact simple, and is shown in Figure below. Data is grouped and transferred in characters, where one character is a unit comprising 7 or 8 bits of information plus 2 to 4 control bits. The idle state is referred to as the mark level and traditionally corresponds to a logical 1 level. A character is transmitted by placing the line in the space level (logical 0) for one period T, then the information is sent bit by bit, with each bit T seconds long, then the transmitter calculates the parity bit and transmits it and finally one or two stop bits are sent by returning the line to mark level.

Format of Asynchronous Serial Data

The data word length may be 7 or 8 bits with odd, even, or no parity bits plus either 1 or 2 stop bits. This allows for 12 different possible formats for serial transmission. Also, there are at least 7 different commonly used values for the bit period T. Thus, connecting two devices via a serial link may be difficult due to all the available options.

At the receiving end, the receiver monitors the link, looking for the start bit, and once detected, the receiver waits until the end of the start bit and then samples the next N bits at their centres using a locally generated clock. Once the character has been assembled from the received bits, the parity is checked, and if the calculated parity does not agree with the received parity bit, a parity error flag is set to indicate a transmission error. The most critical aspect is the receiver timing. The falling edge of the start bit triggers the receiver's local clock, which samples each incoming bit at its nominal centre. Suppose the receiver clock waits T/2 seconds from the falling edge of a start bit and samples the incoming data every T seconds thereafter until the stop bit has been sampled. Let us assume that the receiver clock is running slow, so that a sample is taken every T+dt seconds. The first bit of the data is thus sampled at (T+dt)/2 + (T+dt) seconds after the falling edge of the start bit. The stop bit is thus sampled at time (T+dt)/2 + N(T+dt), where N is the number of bits in the character following the start bit. The total accumulated error in sampling is thus (T+dt)/2 + N(T+dt) - (T/2+NT), or (2N+1)dt/2 seconds. This situation is shown in Figure below.

 Effect of Unsynchronised Transmitter and Receiver Clocks

For correct operation, the stop bit is sampled within T/2 seconds of its centre. 

Thus, if N=9 for a 7-bit character with one stop bit and one parity bit, the maximum permissible error is 100/19 = 5%. Fortunately, today's clocks are all crystal controlled and the error between two clocks of the same frequency is often less than a fraction of a percent.

The most obvious disadvantage of asynchronous serial transfer is the need for start, stop and parity bits for each transmitted character. If 7-bit characters are used, the overall efficiency is only 7/(7+3) = 70%. Another problem is when asynchronous transfer is used to, for example, dump binary data onto a storage device: If the data is arranged in 8-bit bytes and all 256 values represent valid binary data it is difficult to embed control characters (e.g. tape start or stop) within the data stream because the same character must be used both for pure data and control purposes.


Synchronous Serial Data Transmission

The type of asynchronous serial data link described in previous sections is widely used to link processors to relatively slow peripherals such as printers and terminals. Where information must be transferred, for example, between individual computers in a network, synchronous serial data transmission is more popular. In synchronous serial data transmission, the information is transmitted continuously without gaps between adjacent groups of bits. Note that synchronous data links are often used to transmit entire blocks of data instead of ASCII-encoded characters.

As this type of link involves long streams of data, the clocks at the receiving and transmitting end must be permanently synchronised. Of course, one could simply add a clock line to the link where the transmitter's clock signal is passed to the receiver. However, this requires an additional line and is thus an unpopular choice. A better solution is to encode the data in such a way that the synchronising signal is included in the data signal. The figure below shows one of the many methods which may be used. In this case the data is phase-encoded (or Manchester encoded) by combining the clock signal with the data signal. A logical one is thus represented by a positive transition in the centre of the bit and a logical zero by a negative transition. At the receiver, the data signal may easily be split into the clock and pure data components. Integrated circuits that perform this modulation and demodulation are readily available.

A Phase-Encoded Synchronous Serial Bit Stream

Having divided the incoming data stream into individual data elements (i.e. bits), the next step is to group the bits into meaningful units. The incoming data must be examined for recognisable bit groups which signify the beginning of a block of data, the end of it or some other control character. 



There may well be noise on a communications line, and it is helpful to have some check that the correct information has arrived. One common test is Parity. Send a parity bit set so that the number of 1 bits sent (data + parity) is odd.

Parity is normally taken as odd, because a single pulse on the line, taken as a start bit, records as a bad byte.

The parity check will detect one erroneous bit in each byte. There are more serious methods of encoding data that can send messages down noisy lines, and recover from erroneous bits. 


A Universal Asynchronous Receiver Transmitter (UART)

Serial information is normally transmitted and received by a Universal Asynchronous Receiver Transmitter (UART). The programming interface for a UART usually has four registers:

Transmit control - baud rate, parity, send now

Transmit data - the byte to be sent

Receive control - byte available, parity check,

Receive data

Serial Communication -

Favorited Favorite 41


Embedded electronics is all about interlinking circuits (processors or other integrated circuits) to create a symbiotic system. In order for those individual circuits to swap their information, they must share a common communication protocol. Hundreds of communication protocols have been defined to achieve this data exchange, and, in general, each can be separated into one of two categories: parallel or serial.

Parallel vs. Serial

Parallel interfaces transfer multiple bits at the same time. They usually require buses of data - transmitting across eight, sixteen, or more wires. Data is transferred in huge, crashing waves of 1’s and 0’s.

An 8-bit data bus, controlled by a clock, transmitting a byte every clock pulse. 9 wires are used.

Serial interfaces stream their data, one single bit at a time. These interfaces can operate on as little as one wire, usually never more than four.

Example of a serial interface, transmitting one bit every clock pulse. Just 2 wires required!

Think of the two interfaces as a stream of cars: a parallel interface would be the 8+ lane mega-highway, while a serial interface is more like a two-lane rural country road. Over a set amount of time, the mega-highway potentially gets more people to their destinations, but that rural two-laner serves its purpose and costs a fraction of the funds to build.

Parallel communication certainly has its benefits. It’s fast, straightforward, and relatively easy to implement. But it requires many more input/output (I/O) lines. If you’ve ever had to move a project from a basic Arduino Uno to a Mega, you know that the I/O lines on a microprocessor can be precious and few. So, we often opt for serial communication, sacrificing potential speed for pin real estate.

Asynchronous Serial

Over the years, dozens of serial protocols have been crafted to meet particular needs of embedded systems. USB (universal serial bus), and Ethernet, are a couple of the more well-known computing serial interfaces. Other very common serial interfaces include SPI, I2C, and the serial standard we’re here to talk about today. Each of these serial interfaces can be sorted into one of two groups: synchronous or asynchronous.

A synchronous serial interface always pairs its data line(s) with a clock signal, so all devices on a synchronous serial bus share a common clock. This makes for a more straightforward, often faster serial transfer, but it also requires at least one extra wire between communicating devices. Examples of synchronous interfaces include SPI, and I2C.

Asynchronous means that data is transferred without support from an external clock signal. This transmission method is perfect for minimizing the required wires and I/O pins, but it does mean we need to put some extra effort into reliably transferring and receiving data. The serial protocol we’ll be discussing in this tutorial is the most common form of asynchronous transfers. It is so common, in fact, that when most folks say “serial” they’re talking about this protocol (something you’ll probably notice throughout this tutorial).

The clock-less serial protocol we’ll be discussing in this tutorial is widely used in embedded electronics. If you’re looking to add a GPS module, Bluetooth, XBee’s, serial LCDs, or many other external devices to your project, you’ll probably need to whip out some serial-fu.

Suggested Reading

This tutorial builds on a few lower-level electronics concepts, including:

If you’re not super familiar with any of those concepts, consider checking those links out.

Now then, let’s go on a serial journey…

Rules of Serial

The asynchronous serial protocol has a number of built-in rules - mechanisms that help ensure robust and error-free data transfers. These mechanisms, which we get for eschewing the external clock signal, are:

  • Data bits,
  • Synchronization bits,
  • Parity bits,
  • and Baud rate.

Through the variety of these signaling mechanisms, you’ll find that there’s no one way to send data serially. The protocol is highly configurable. The critical part is making sure that both devices on a serial bus are configured to use the exact same protocols.

Baud Rate

The baud rate specifies how fast data is sent over a serial line. It’s usually expressed in units of bits-per-second (bps). If you invert the baud rate, you can find out just how long it takes to transmit a single bit. This value determines how long the transmitter holds a serial line high/low or at what period the receiving device samples its line.

Baud rates can be just about any value within reason. The only requirement is that both devices operate at the same rate. One of the more common baud rates, especially for simple stuff where speed isn’t critical, is 9600 bps. Other “standard” baud are 1200, 2400, 4800, 19200, 38400, 57600, and 115200.

The higher a baud rate goes, the faster data is sent/received, but there are limits to how fast data can be transferred. You usually won’t see speeds exceeding 115200 - that’s fast for most microcontrollers. Get too high, and you’ll begin to see errors on the receiving end, as clocks and sampling periods just can’t keep up.

Framing the data

Each block (usually a byte) of data transmitted is actually sent in a packet or frame of bits. Frames are created by appending synchronization and parity bits to our data.

A serial frame. Some symbols in the frame have configurable bit sizes.

Let’s get into the details of each of these frame pieces.

Data chunk

The real meat of every serial packet is the data it carries. We ambiguously call this block of data a chunk, because its size isn’t specifically stated. The amount of data in each packet can be set to anything from 5 to 9 bits. Certainly, the standard data size is your basic 8-bit byte, but other sizes have their uses. A 7-bit data chunk can be more efficient than 8, especially if you’re just transferring 7-bit ASCII characters.

After agreeing on a character-length, both serial devices also have to agree on the endianness of their data. Is data sent most-significant bit (msb) to least, or vice-versa? If it’s not otherwise stated, you can usually assume that data is transferred least-significant bit (lsb) first.

Synchronization bits

The synchronization bits are two or three special bits transferred with each chunk of data. They are the start bit and the stop bit(s). True to their name, these bits mark the beginning and end of a packet. There’s always only one start bit, but the number of stop bits is configurable to either one or two (though it’s commonly left at one).

The start bit is always indicated by an idle data line going from 1 to 0, while the stop bit(s) will transition back to the idle state by holding the line at 1.

Parity bits

Parity is a form of very simple, low-level error checking. It comes in two flavors: odd or even. To produce the parity bit, all 5-9 bits of the data byte are added up, and the evenness of the sum decides whether the bit is set or not. For example, assuming parity is set to even and was being added to a data byte like 0b01011101, which has an odd number of 1’s (5), the parity bit would be set to 1. Conversely, if the parity mode was set to odd, the parity bit would be 0.

Parity is optional, and not very widely used. It can be helpful for transmitting across noisy mediums, but it’ll also slow down your data transfer a bit and requires both sender and receiver to implement error-handling (usually, received data that fails must be re-sent).

9600 8N1 (an example)

9600 8N1 - 9600 baud, 8 data bits, no parity, and 1 stop bit - is one of the more commonly used serial protocols. So, what would a packet or two of 9600 8N1 data look like? Let’s have an example!

A device transmitting the ASCII characters ‘O’ and ‘K’ would have to create two packets of data. The ASCII value of O (that’s uppercase) is 79, which breaks down into an 8-bit binary value of 01001111, while K’s binary value is 01001011. All that’s left is appending sync bits.

It isn’t specifically stated, but it’s assumed that data is transferred least-significant bit first. Notice how each of the two bytes is sent as it reads from right-to-left.

Since we’re transferring at 9600 bps, the time spent holding each of those bits high or low is 1/(9600 bps) or 104 µs per bit.

For every byte of data transmitted, there are actually 10 bits being sent: a start bit, 8 data bits, and a stop bit. So, at 9600 bps, we’re actually sending 9600 bits per second or 960 (9600/10) bytes per second.

Now that you know how to construct serial packets, we can move on to the hardware section. There we’ll see how those 1’s and 0’s and the baud rate are implemented at a signal level!

Wiring and Hardware

A serial bus consists of just two wires - one for sending data and another for receiving. As such, serial devices should have two serial pins: the receiver, RX, and the transmitter, TX.

It’s important to note that those RX and TX labels are with respect to the device itself. So the RX from one device should go to the TX of the other, and vice-versa. It’s weird if you’re used to hooking up VCC to VCC, GND to GND, MOSI to MOSI, etc., but it makes sense if you think about it. The transmitter should be talking to the receiver, not to another transmitter.

A serial interface where both devices may send and receive data is either full-duplex or half-duplex. Full-duplex means both devices can send and receive simultaneously. Half-duplex communication means serial devices must take turns sending and receiving.

Some serial busses might get away with just a single connection between a sending and receiving device. For example, our Serial Enabled LCDs are all ears and don’t really have any data to relay back to the controlling device. This is what’s known as simplex serial communication. All you need is a single wire from the master device’s TX to the listener’s RX line.

Hardware Implementation

We’ve covered asynchronous serial from a conceptual side. We know which wires we need. But how is serial communication actually implemented at a signal level? In a variety ways, actually. There are all sorts of standards for serial signaling. Let’s look at a couple of the more popular hardware implementations of serial: logic-level (TTL) and RS-232.

When microcontrollers and other low-level ICs communicate serially they usually do so at a TTL (transistor-transistor logic) level. TTL serial signals exist between a microcontroller’s voltage supply range - usually 0V to 3.3V or 5V. A signal at the VCC level (3.3V, 5V, etc.) indicates either an idle line, a bit of value 1, or a stop bit. A 0V (GND) signal represents either a start bit or a data bit of value 0.

RS-232, which can be found on some of the more ancient computers and peripherals, is like TTL serial flipped on its head. RS-232 signals usually range between -13V and 13V, though the spec allows for anything from +/- 3V to +/- 25V. On these signals a low voltage (-5V, -13V, etc.) indicates either the idle line, a stop bit, or a data bit of value 1. A high RS-232 signal means either a start bit, or a 0-value data bit. That’s kind of the opposite of TTL serial.

Between the two serial signal standards, TTL is much easier to implement into embedded circuits. However the low voltage levels are more susceptible to losses across long transmission lines. RS-232, or more complex standards like RS-485, are better suited to long range serial transmissions.

When you’re connecting two serial devices together, it’s important to make sure their signal voltages match up. You can’t directly interface a TTL serial device with an RS-232 bus. You’ll have to shift those signals!

Continuing on, we’ll explore the tool microcontrollers use to convert their data on a parallel bus to and from a serial interface. UARTs!


The final piece to this serial puzzle is finding something to both create the serial packets and control those physical hardware lines. Enter the UART.

A universal asynchronous receiver/transmitter (UART) is a block of circuitry responsible for implementing serial communication. Essentially, the UART acts as an intermediary between parallel and serial interfaces. On one end of the UART is a bus of eight-or-so data lines (plus some control pins), on the other is the two serial wires - RX and TX.

Super-simplified UART interface. Parallel on one end, serial on the other.

UARTs do exist as stand-alone ICs, but they’re more commonly found inside microcontrollers. You’ll have to check your microcontroller’s datasheet to see if it has any UARTs. Some have none, some have one, some have many. For example, the Arduino Uno - based on the “old faithful” ATmega328 - has just a single UART, while the Arduino Mega - built on an ATmega2560 - has a whopping four UARTs.

As the R and T in the acronym dictate, UARTs are responsible for both sending and receiving serial data. On the transmit side, a UART must create the data packet - appending sync and parity bits - and send that packet out the TX line with precise timing (according to the set baud rate). On the receive end, the UART has to sample the RX line at rates according to the expected baud rate, pick out the sync bits, and spit out the data.

Internal UART block diagram (courtesy of the Exar ST16C550 datasheet)

More advanced UARTs may throw their received data into a buffer, where it can stay until the microcontroller comes to get it. UARTs will usually release their buffered data on a first-in-first-out (FIFO) basis. Buffers can be as small as a few bits, or as large as thousands of bytes.

Software UARTs

If a microcontroller doesn’t have a UART (or doesn’t have enough), the serial interface can be bit-banged - directly controlled by the processor. This is the approach Arduino libraries like SoftwareSerial take. Bit-banging is processor-intensive, and not usually as precise as a UART, but it works in a pinch!

Common Pitfalls

That’s about all there is to serial communication. I’d like to leave you with a few common mistakes that are easy for an engineer of any experience level to make:

RX-to-TX, TX-to-RX

Seems simple enough, but it’s a mistake I know I’ve made more than a few times. As much as you want their labels to match up, always make sure to cross the RX and TX lines between serial devices.

FTDI Basic programming a Pro Mini. Note RX and TX’s crossed!

Contrary to what the esteemed Dr. Egon Spengler would warn, cross the streams.

Baud Rate Mismatch

Baud rates are like the languages of serial communication. If two devices aren’t speaking at the same speed, data can be either misinterpreted, or completely missed. If all the receiving device sees on its receive line is garbage, check to make sure the baud rates match up.

Data transmitted at 9600 bps, but received at 19200 bps. Baud mismatch = garbage.

Bus Contention

Serial communication is designed to allow just two devices to communicate across one serial bus. If more than one device is trying to transmit on the same serial line you could run into bus-contention. Dun dun dun….

For example, if you’re connecting a GPS module up to your Arduino, you may just wire that module’s TX line up the Arduino’s RX line. But that Arduino RX pin is already wired up to the TX pin of the USB-to-serial converter, which is used whenever you program the Arduino or use the Serial Monitor. This sets up the potential situation where both the GPS module and FTDI chip are trying to transmit on the same line at the same time.

Two transmitters sending to a single receiver sets up the possibility for bus contention.

Two devices trying to transmit data at the same time, on the same line, is bad! At “best” neither of the devices will get to send their data. At worst, both device’s transmit lines go poof (though that’s rare, and usually protected against).

It can be safe to connect multiple receiving devices to a single transmitting device. Not really up to spec and probably frowned upon by a hardened engineer, but it’ll work. For example, if you’re connecting a serial LCD up to an Arduino, the easiest approach may be to connect the LCD module’s RX line to the Arduino’s TX line. The Arduino’s TX is already connected to the USB programmer’s RX line, but that still leaves just one device in control of the transmission line.

Distributing a TX line like this can still be dangerous from a firmware perspective, because you can’t pick and choose which device hears what transmission. The LCD will end up receiving data not meant for it, which could command it to go into an unknown state.

In general - one serial bus, two serial devices!

Resources and Going Further

With this shiny, new knowledge of serial communication, there are loads of new concepts, projects, and technologies to explore.

Would you like to learn more about other communication standards? Maybe something synchronous?

Many technologies make heavy use of serial communication:

Or maybe you’d like to see serial in action?

Download Serial Communications


Recording and playing back data from the serial communications port ... Editor: Serial Player is a utility for recording and playing back data from the serial communications port of the computer. The ...

MarshallSoft Computing

Win/CE Standard Serial Communications Library for eVB ... The Windows/CE Standard Serial Communications Library for eVB (WSC4eVB) is a serial port communication library for Embedded Visual Basic (eVB) ...

MarshallSoft Computing, Inc.

Serial communication Win/CE library for serial port communications for eVC++ ... Serial communication component Win/CE library (WSC4eVC) for serial port communications from embedded Visual C++ (eVC++) ...

MarshallSoft Computing

dBase software for RS232 or multidrop RS422/RS485 serial port communications ... MarshallSoft Visual dBASE serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. ...

MarshallSoft Computing

Xbase++ component for RS232 or multidrop RS422/RS485 serial port communications ... MarshallSoft Xbase++ serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. ...

MarshallSoft Computing

Delphi software for RS232 or multidrop RS422/RS485 serial port communications ... MarshallSoft Delphi serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. Features ...

MarshallSoft Computing

Visual FoxPro RS232/R485/RS422 serial port communications software library ... MarshallSoft Visual FoxPro serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. ...

MarshallSoft Computing

C/C++ RS232/RS485/RS422 serial port communications software library ... MarshallSoft C/C++ serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. Features of WSC4C ...

AGG Software

Monitor and log serial port communications easily with this new convenient tool! ... Editor: Advanced Serial Data Logger input RS232 data directly into file, Excel, Access, or any Windows application. ...

Charon Software, Inc

It is compatible with all physical and virtual serial ports on server, desktop ... It is compatible with all physical and virtual serial ports on server, desktop, and mobile devices. This 100% .NET ...

Serial Communication

The serial module is used to communicate from RoboRealm to serial based controllers. The module can be used to communicate to SSC, Parallax, etc. type controllers. Before embarking on using the serial module check that the specific device is not already supported by another RoboRealm module as that will be easier than understanding and implementing a particular device's protocol.

The serial module allows you to configure the serial port for various communication parameters (baud rate, stop bits, etc.) and specify the communication protocol for initializing, sending and receiving data. The text boxes allow you to enter in the necessary command numbers for each respective sequence type (read or write).



1. Port - Select the COM port to use. Note that COM1-4 are typically assigned directly to hardware ports. COM5+ are typically assigned to virtual ports created by USB devices.

2. Baud - Specifies how fast communication will occur between the PC and serial device. Typically rates are 9600 with the fastest being 115200. Note that if you see irregular characters being received from the serial device this many indicate a mismatch between baud rates.

3. Data Bits - Indicates how many bits are reserved for data communication between the serial device and the PC. Typical value is 8.

4. Parity - Indicates what kind of error checking that is performed during serial communication. Even means the last bit is set to ensure that an even number of bits are used, whilst odd means the last bit is set to ensure that an odd number of bits are used. When the receiving side sees a discrepancy (i.e. an odd number of bits being transmitted when even parity is required) the device knows a transmission error has occurred. Typical value is None.

5. Stop Bits - Refers to how many bits are used to indicate a delimiter between data bits.

6. Flow Control - Allows you to set the flow control options for the serial device. By default RoboRealm sets all flow control to off/disabled. By clicking on the Flow Control button you can set the following options

XON/XOFF for both transmission and reception CTS/DRS (clear to send)/(data set ready) DTR/RTS (data terminal ready)/(request to send)

7. Wait for reply - Forces the module to wait for a reply after characters have been sent. This ensures that the module pauses until a reply has been received from the remote device. Note, this can cause the pipeline to slow down due to the pause for a reply. Only select this checkbox if you require a reply before continuing the pipeline.

8. Session Timeout - when receiving information from a serial device this number represents how long the module will wait for a character until giving up and resetting the connection. Note that the value is in milliseconds, where 1 second = 1000 milliseconds. The default is 5000 or 5 seconds.

9. Message Timeout - When receiving information from a serial device this number represents how long the module will wait for the next character until giving up and assuming the message is complete. Note that the value is in milliseconds, where 1 second = 1000 milliseconds. The default is 100 or 0.1 seconds. This is very useful when no delimiter is specified and a complete message is determined by the lack of new characters for a small period.

10. Console - if the device supports reading you will start to see a large amount of numbers scrolling by in the console. This shows the current values being read from the device and provides a log of the ongoing communication activities. The green text is from RoboRealm, the red text are characters received and the green text are characters sent by RoboRealm to the device. To copy the log click on the Copy button, likewise to clear it click on the Clear button. Note that the console log only shows several lines at a time with older information being discarded. You can switch the output to various formats for better viewing:

ASCII - shows the data as ASCII characters. Any character outside of printable characters will be represented with a \ followed by the actual integer data that was readDecimal - shows the data as sets of single byte integer numbersHexadecimal - shows the data as sets of hexadecimal numbers (base 16 numbers, e.g. FF)Short Binary - shows the data as binary numbers with prefix 0's removedBinary - shows the data as sets of single byte binary numbers

11. Send Now - often you need to quickly test the device by sending a certain sequence of characters. To do so just type in the character sequence (using for carriage return, [image_count] for variables, etc.) and click on Send Now. The text will be parsed and sent to the serial device and the response will then appear in the console log. Note that this is different from the send sequence which will be sent each time the serial module is encountered in the processing pipeline. The Send Now button is a manual testing mechanism meant for debugging purposes. Also note that the returned text will be parsed by the Receive Sequence so that you can test your parsing code and see if the variables have been created. Use the Watch Variables module to see those variables being created.

12. Refresh Rate - to slow the scrolling of the numbers select a different refresh rate for the console. This will just slow down how quickly RoboRealm reads information from the device.

13. Initialization Sequence - The initialization data sequence sends the provided string to the serial device on initialization of communication. You may want to use this to command the receiving device into a specific mode ready for communication with RoboRealm. This initialization sequence is sent each time the serial communication is reset. This happens when you click on the "Stop" button in this interface, change one of the above parameters (Baud, Port, etc) or when the RoboRealm starts running for the first time. It is NOT sent when the Run button in the main RoboRealm interface is toggled. See the Text Formats page for additional information about the text string format.

14. Send sequence - Used to enter commands sent per pipeline loop (i.e. image processed) by RoboRealm. You can use this sequence to transmit variables created by other RoboRealm modules to the serial device. Each time an image is captured and processed the serial module will interpret the Send Sequence text and send the result to the serial device. See the Text Formats page for additional information about the text string format.

15. Enable - Allows you to temporarily disable sending text to the serial device while performing edits. Note that the Send Sequence textarea will turn red to indicate this setting.

16. Send Rate - Some serial devices cannot handle data streams even given a slower baud rate. Use this dropdown to select how quickly you want the data to be sent. At AFAP (As Fast As Possible) the data will be sent out about 30 times a second (this assumes a camera running at 30 fps).

17. Clear serial buffer trigger - there are cases when too much data may be buffered on the serial port that needs to be cleared due to some event. In this case specify a variable whose value when set to "clear" will remove all data scheduled to be sent over the serial port.

18. Send only on change - If your data does need to be sent out to your serial device every iteration through the processing pipeline loop this selection will prevent the same data from being sent to the serial device that was last sent. This is also an elegant way to reduce the data bandwidth to the device if your sequence does not change rapidly.

19. Receive sequence - used to receive and parse text send from the serial device. The text string is matched against the incoming serial bytes. When a match is found variables are added into RoboRealm for use in other modules. Reading into variables just requires adding in a variable at the appropriate spot within the receive string similar to the scanf routine in C/C++. The Receive sequence works similar to an expect string, i.e. you need to specify patterns that match the incoming text and substitute the areas that need to be fed into variables with the [ variable_nane ] format. Note that even if you are missing one space or newline the patter will not match and the variable will be zero or blank. See the Text Formats page for additional information about the text string format.

20. Test Receive - instead of waiting for the correct data bytes to come from your serial device you can type in a test sequence that will be parsed by the receive sequence. This can be handy when first testing that your receive sequence is picking up the right bytes.

To learn more about what text can be used in the the Sequence boxes please refer to the Text Formats page.


To read digital inputs from a VEX Robotics System robot over the serial port you can configure the settings to port COM5, baud 115200, 8 data bits, no parity, 1 stop bit with the sequences as:

Initialization Sequence \x0f\x0f\x08\x40\xb8\x04

Send Sequence \xaa\x55\x00\x00\x00\x0B\x00\x00

Receive Sequence DIN [din1] [din2] [din3] [din4] [din5] [din6]<lf>

which would command the Vex in the online mode (be sure to download that code to your Vex robot) and read in the digital inputs into variables din1, din2, din3, etc. You can add the Watch Variables module to see these variables change when you press a bump switch on the Vex.

Note that the Vex online mode needs to be downloaded prior to using this serial sequence. Be sure your Vex is reacting to the online interface provided by Vex to ensure correct online operation.

See Also

MCU CommunicatorSSCParallax

For more information

CodeGuru: Serial Communications in WindowsThe Code Project: Serial library for C++
Serial Related Forum PostsLast postPostsViews
Serial Communication Arduino Uno Hi, good days. im unable to perform serial communication to arduino. i attach robo file and arduino source code for your referen... 8 months 5 529
numbers vs strings I am trying to control motors with a microbasic ARC32. The problem is when I send wheel speed info over serial, RR sends strings... 1 year 3 366
Syntax to receive char from arudino to vbscript hey guys. I'm doing a project which uses roborealm vbscript and arduino (using serial module). the vbscript will send a characte... 1 year 2 451
navigation by computer vision am writing a simple vbscript for navigation of car by computer vision ie. image processing i want to send serial c... 2 years 27 1814
Socket Client data to Variable STeven, I'm successfully getting TCP data sent to me from a radar device. Data looks like this and updates at 1 Hz... 2 years 8 792
hardware lab program to do serial communication using usart how to transfer data from kit to pc may i have mnemon... 2 years 2 788
Display Serial Data Hi, I have serial data displayed but it flashes on and off at the at the serial data refresh rate. I... 2 years 5 1009
xy table Hi Everyone- Well, I'm brand new to the forum, so please bear with me......What I'm trying to do is this: I am in manufacturing,... 2 years 5 1244
serial communication code I am trying to control a Pelco D protocol PTZ camera using rs-232 to 485 convertor and the serial module found in roborealm. 2 years 4 1085
serial defaults Hi STeven Looking at the serial screen, most of the fields are blank. What are these... 2 years 2 879
Serial Module skips/sends/returns wrong data Greetings STeven! Thank you for this impressive software. I am trying to identify and sort various ... 3 years 4 1095
RobotC My nxt brick is currently running the robotC firmware on it, this is different from the nxt firmware that comes out of the box. ... 3 years 2 1036
RR Crash every few minutes Both RR 2.61.8 and 2.61.9 crash every few minutes, no matter what I am doing - running, editing, ignoring... Pleas... 3 years 19 1404
Serial Communication Hi, I am using RR to interface with my PIC based embedded system, using the serial module to send commands to the board. Using t... 3 years 2 1138
null characters How does one send null characters, ie 0x00 through the serial port in a string? As s... 3 years 2 1045
Serial receive - order Hi Is there a simple way to set the receive order of variables? 3 years 3 1088

Serial Communications Support

Most serial ports follow a standard called the RS-232, also known as the EIA-232 specification. RS-232 is an advanced plan-for-all needs specification. Being that it is from origins in the 60's, it is neither simple nor perfect in every situation for every computer or peripheral. In fact, it is well beyond what is required for most standard communication. However, it does work. Though it has been difficult because of design complexity and a lack of thorough understanding, it is good enough to have become an industry standard, or as the RS indicates, a Recommended Standard.

DB-25 TableDB-25 pin configuration Pin Name EIA Signal
1 FG Frame ground
2 TD Transmitted data
3 RD Received data
4 RTS Request to send
5 CTS Clear to send
6 DSR Data set ready
7 SG Signal ground
8 DCD Data carrier signal
9 None Positive voltage - Test Conditions
10 None Negative voltage - Test Conditions
11 None Unassigned - Test Conditions
12 SDCD Secondary DCD
13 SCTS Secondary CTS
14 STD Secondary TD
15 TC Transmit clock
16 SRD Secondary RD
17 RC Receive clock
18 none Unassigned - Test Conditions
19 SRTS Secondary RTS
20 DTR Data terminal ready
21 SQ Signal quality detector
22 RI Ring indicator
23 DRS Data rate selector
24 SCTE Clock transmit external
25 BUSY Busy

RS-232 defines the meaning of the different serial signals and their respective pin assignments on a standard 25-pin (DB-25) serial connector. The DB-25 Table shows these assignments. Under most conditions in the real world and in standard types of communications only 9 of these pins are important: 1-8, and 20.

DB-25 connectors are either male, with the pins sticking out, or female, with matching holes. Often there are very small numbers marking the pins or holes 1-25. The female connector is a mirror image of the male so that pins and holes match.

Originally, there was no standardization of the gender of connectors and serial devices. Both connectors and serial devices could be either gender. However, since male connectors are more susceptible to injury than female, most expensive computing hardware these days has female connectors, while cables are male on both ends.

Since RS-232 defines signals that are not used for most standard communication, sometimes DB-25 connectors are missing unneeded pins. In this case, serial cables simply leave the unused pins disconnected.


There are two cable configurations in use today for serial equipment:

DTE (Data Terminal Equipment) Generally used for computers, terminals, and printers.DCE (Data Communications Equipment) Generally used for modems and devices that act as modems.

These different configurations determine which signal a device anticipates on which pin. All devices are configured as either DTE or DCE. Because terminals are typically DTE, and modems are generally DCE, a different cable between a computer and a terminal must be used as opposed to a cable used between a computer and a modem.

The RS-232 specification defines the the maximum length of serial cable to be 75 feet at 9,600 bps. This is a pretty conservative figure and has been stretched as far as several thousand feet, especially at this baud rate. With current modem baud rates limited only by the communications guidleline of just under 56 kbs, direct serial communications now are capable in certain cases of 512 kbs. How far the limit can be stretched depends on the brand of terminal and computer you are using. This is something to keep in mind when connecting terminals (and computers simulating terminals) to computers in distant or remote locations.

Alternate Serial Connectors

Because of the fact that RS-232 defines signals that go unused in standard types of communication, and because the traditional DB-25 connector is cumbersome (especially for small equipment, such as laptops), many alternate serial connectors have come into widespread use. These connectors provide the same necessary pins as a DB-25, but are smaller, more manageable connectors. Because they provide access to the same signals, devices that use different connectors are compatible as long as you use the right kind of converter cable. The popularity of DIN-8 is not high compared to the DB-25 and DB-9, therefore ready made cables are not easily found. There are converters that allow use of standard cables.


DIN-8 serial connectors are small, and nearly circular in pin placement. They have a key so that they can only be connected one way. They look like the original keyboard connectors for PCs, though those were DIN-5 connectors. They are used on Macs, and on some laptops because they are so compact. DIN-8s provide the seven most common serial signals whose pin assignments are shown in the DIN-8 Table.

DIN-8 TableDIN-8 pin configuration DIN-8 Pin Corresponding DB-25 Pin EIA Signal Function
3 2 TD Transmitted data
5 3 RD Received data
6 4 RTS Request to send
2 5 CTS Clear to send
4,8 7 SG Signal ground
7 8 DCD Data carrier detect
1 20 DTR Data terminal ready


DB-9s are most commonly found on modern PCs and laptops. Many computers had both a DB-25 and a DB-9, designated as COM1 and COM2. Modern equipment still uses at least one DB-9, along with one or more USB ports. They look like smaller versions of the DB-25 connector. DB-9s provide the eight most common serial signals whose pin assignments are shown in the DB-9 Table.

DB-9 TableDB-9 pin configuration DB-9 Pin Corresponding DB-25 Pin EIA Signal Function
2 3 RD Received data
3 2 TD Transmitted data
8 5 CTS Clear to send
7 4 RTS Request to send
6 6 DSR Data set ready
5 7 SG Signal ground
4 20 DTR Data terminal ready
1 8 DCD Data carrier detect


RJ-45 connectors look a lot like standard telephone connectors, however, they are not. They house eight wires, sometimes solid and sometimes stranded, instead of the normal four wires in a telephone connector, designated as an RJ-11. RJ-45s are not typically found on computers or normal serial equipment, but, because they are so small, they are often used on devices that have a lot of ports very close together. RJ-45s are also used for 10-Base-T and 100-Base-T network connections. Terminal servers, multiplexors and data port switches are a good example of devices that often use RJ-45 connectors.

There are many wiring schemes for mapping the pins on an RJ-45 connector to a DB-25 connector. Possibly the best is the Yost standard, which wires all RJ-45 to DB-25 connections the same way. The advantages this system provides are:

  • All cable connections are of the same gender.
  • There is no distinction between DTE and DCE.
  • Because of the above, you can use the same kind of cable everywhere.

For more information about the Yost wiring standard see the optional document, Yost Serial Device Wiring Standard.

Hard Vs. Soft Carrier

When a serial device is attached to the system and turned on, Unix, Xenix, Linux, and most other operating systems with roots and foundations in the 60s and 70s, expect the DCD signal (data carrier detect) to be asserted. If your system pays close attention to whether that signal is asserted, you are using what is called hard carrier. Most current operating systems also allow the use of soft carrier where the system pretends that the DCD signal is always asserted.

Soft carrier is often a very good thing for certain devices. For instance, with a terminal, it lets you use only 3 wires for a connection: transmitted data, received data, and signal ground, pins 2, 3 and 7 on a DB-25. However, in a modem connection, you really want to pay valid attention to DCD. When you are connected via a modem, if the carrier signal is lost, you want the modem to hang up. If you are using soft carrier, DCD is assumed to be asserted, perhaps as in this case, an invalid assumption. Even if you lose the signal, the modem can remain connected. This can be a potentially devastating problem over a long distance connection since the modem could potentially remain connected for days.

Most modern systems set a default carrier mode for serial ports in their configuration files. The command stty -CLOCAL will force a terminal to use soft carrier, so for instance:

stty -CLOCAL < /dev/ttya

would enable soft carrier on serial port ttya.

Смотрите также