Lose Weight
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows XP

Getting Started with Modem Communications : Modem-to-Modem Communications

3/21/2011 6:26:30 PM
Modem communications is one of those ideas that, after you learn a bit of background, you wonder how on earth your system actually pulls it off. I mean, you’re talking about tens of thousands of bits per second busily bustling between two computers, all the while negotiating compression routines, FIFO buffers, parallel-to-serial UART conversions, modulations, and who knows what else. To combine all of these complex technologies and achieve a remarkably high level of accuracy is an amazing achievement. To help you appreciate some of the hoops your computer, serial port, and modem have to jump through to accomplish this wizardry, this section takes a closer look at just how two modems communicate with each other.

Flow Control: The Communications Traffic Cop

Modem downloads come in fast and furious, so what’s your computer supposed to do if it isn’t ready to receive any data? Conversely, what if you’re sending data and the remote system indicates that it can’t receive any more data just now? How does your modem tell the CPU to stop processing data temporarily?

These kinds of situations fall under the rubric of flow control, which defines how the computer and the modem communicate with each other to coordinate data exchanges and prevent overruns when one device isn’t ready to receive information from the other. There are two types of flow control: software and hardware.

Software Flow Control (XON/XOFF)

With software flow control, the computer and modem send signals to each other that indicate whether they’re ready to receive data. For example, suppose that you’re downloading a file and the computer needs to pause the download briefly while it attends to some other chores. To do this, it sends to the remote system’s modem a special “hold your horses” signal called XOFF. (In data communications circles, X stands for transfer, so XOFF means transfer off.) XOFF is an ASCII control code character (ASCII 19 or Ctrl+S) that gets shipped out to the remote system just like any other character. When the computer decides it’s okay to resume the download, it notifies the remote system by sending a signal called XON (which is another control code character: ASCII 17 or Ctrl+Q). Because of these two signals, software flow control is also known as XON/XOFF flow control.


If you find that a data transfer has halted, it might be because your system has inadvertently sent an XOFF flow control signal. Try pressing Ctrl+Q to send an XON signal. If the remote system supports software flow control, this might be enough to get the transfer going again.

Hardware Flow Control (RTS/CTS)

Because of the high overhead associated with software flow control, it becomes inefficient at data transfer rates higher than 2,400bps. For higher speeds, hardware flow control is a much better option. That’s because instead of firing an entire character out to the remote device, hardware flow control just uses individual serial port lines to send signals. Hardware flow control uses two of these lines: RTS and CTS (which is why this method is also called RTS/CTS flow control).

For example, suppose that your modem wants to stop the computer from sending any more data (because, for example, it has lost its Carrier Detect signal and so doesn’t have a connection with the remote system). To do that, all it does is turn off its CTS (Clear To Send) signal. The computer reads that the serial port’s CTS wire is off, so it stops processing data for the modem.

Similarly, the processor’s willingness to accept more data from the modem is controlled by the RTS (Request To Send) wire. If the processor turns off RTS, the modem reads that the serial port’s RTS wire is off, so it pauses the data transfer.

Data Bits: The Crux of the Matter

The role of the serial port’s UART chip is to convert the eight parallel bits that PCs use to represent data into a series of eight consecutive bits suitable for squeezing through the serial port’s TD (Transmit Data) wire.

The problem, though, is that not all computer systems use eight bits to represent their characters. All PCs do, because they need the eight bits to represent all 256 characters in the ASCII character set (because each bit can use one of two states—on or off, 1 or 0—and 2 to the power of 8 is 256). Most mainframe systems, however, use only seven bits to represent characters because they recognize only the first 128 ASCII characters (2 to the power of 7 is 128). The number of bits used to represent a character is called the data bits setting or the character length.

So, one of the most important parameters when a remote system is involved is the number of data bits it uses. Problems can arise, for example, if you send eight-bit bytes to a system that knows how to deal with only seven of them. In PC systems, fortunately, the first 128 ASCII characters have a 0 as their eighth bit, so it can be safely discarded during communication with seven-bit systems.

Start and Stop Bits: Bookends for Your Data

The data coursing through your computer is transferred from place to place at extremely high speeds by using exquisitely timed procedures to coordinate the transfers. This type of communications is called synchronous because it depends on timing signals.

The vagaries of modem communications, however, prevent such precise timing, so modems use asynchronous communications. In asynchronous communications, as long as the remote system is willing and able to receive data, the data is just sent out whenever it’s ready to go.

But with no timing involved, knowing where one character ends and the next begins becomes a problem. You might think that you could just use the number of data bits. For example, if your system and the remote system both use eight-bit bytes, you could simply define every eighth bit as the starting point for each character. Unfortunately, that approach would work only in a perfect world that boasted noiseless telephone lines and error-free data transfers. In the real world, in the journey between here and there, legitimate bits can become missing, and extraneous “bits” (that is, line noises) can get tossed into the mix.

To help the receiving end delimit incoming characters, the sending system’s UART tacks on extra bits on both sides of the data. At the front of the data, the UART adds a start bit that defines the beginning of each character. This is followed by the data bits, and then the UART appends a stop bit to mark the end of the character.

The start bit is always the same, but different systems require different length stop bits. Most systems use a single stop bit, but a few rare cases insist on two stop bits. (You also read about systems that require 1 1/2 stop bits. Half a bit? It doesn’t make sense until you remember that these “bits” I’m talking are really electromagnetic pulses traveling along an analog carrier wave. Each pulse consumes a predefined amount of time—say, 1/14,400th of a second—so 1 1/2 bits is really just 1 1/2 pulses.)

At the receiving end, the UART busies itself by stripping off the start and stop bits before recombining the data bits into a full byte.

Parity: A Crude Error Check

The start and stop bits can tell the receiving modem it has received corrupted data. For example, if the modem is expecting eight data bits but gets seven or nine, it knows that something has gone haywire, and it can ask that the bit be retransmitted.

What if, however, a voltage spike or some line noise doesn’t add or subtract bits from a character, but instead changes one of the existing bits? The receiving modem still gets the appropriate number of data bits, so it won’t know that anything has gone awry. To cover this kind of trouble, many systems that use seven-bit characters also use parity checking. In this technique, an extra bit—called the parity bit—is added to the data bits (but before the stop bit). The parity bit is set to either 1 or 0, depending on the type of parity checking used:

Even parityIn this method, you first sum all the 1s in the data bits and see whether you end up with an odd or even number. Your goal is to send out an even number of 1s, so you use (or, technically, the UART uses) the extra parity bit to ensure this. For example, suppose that the data bits are 0000111. The sum of the 1s here is 3, which is odd, so the parity bit must be set to 1 to give you an even number of 1s. So, the UART sends out 10000111. Similarly, suppose that your data bits are 1000001. The sum of the 1s is 2, which is even, so the parity bit can be set to 0, like so: 01000001.
Odd parityThis is the opposite of even parity. Again, you first sum all the 1s in the data bits and see whether you end up with an odd or even number. In this case, however, your goal is to send out an odd number of 1s, and you manipulate the parity bit accordingly.

Most systems use even parity. (Two other kinds of parity—mark and space—exist, but these are virtually obsolete.)

How does this help the receiving system check the data? Well, if it’s using even parity, the receiving system’s UART checks the incoming bits and adds up all the 1s. If it finds an odd number of 1s, it knows that a bit was changed en route, so it can ask for a retransmit. Of course, if a voltage spike changes several bits, the number of 1s might remain even, so the receiving UART wouldn’t detect an error. Therefore, parity is only a crude error-checking mechanism.


When setting up a connection to a remote system, you need to make sure that the three settings I’ve just talked about—data bits, stop bits, and parity—match the parameters expected by the remote computer. If you’re not sure which settings to use, note that two combinations are the most common: seven data bits, even parity, one stop bit (usually written as 7-E-1); and eight data bits, no parity, one stop bit (8-N-1). The former combination is often used to connect to large online services that use mainframes (such as CompuServe); the latter works for most bulletin board systems and PC-to-PC connections.

Terminal Emulation: Fitting in with the Online World

When you use your modem to connect to a remote computer, you are, essentially, operating that computer from your keyboard and seeing the results onscreen. In other words, your computer has become a terminal attached to the remote machine.

It’s likely, however, that the remote computer is completely different from the one you’re using. It could be a mainframe or a minicomputer, for example. In that case, it isn’t likely that the codes produced by your keystrokes will correspond exactly with the codes used by the remote computer. Similarly, some of the return codes won’t make sense to your machine. So, for your computer to act like a true terminal, some kind of translation is needed between the two systems. This translation is called terminal emulation because it forces your system to emulate the kind of terminal that the remote computer normally deals with.

Most communications programs give you a choice of terminal emulation methods, such as ANSI for other DOS/Windows computers, TTY for teletype terminals, or specific terminal types, such as the DEC VT100 and VT52.

File Transfers: A Matter of Protocol

You’ll probably spend most of your modem time on the Internet. However, you can also use your modem to connect to other services, where you can chat with others, access data, and also transfer files back and forth. When you receive a file from a remote computer, it’s called downloading; when you send a file to a remote computer, it’s called uploading.

For your downloads and uploads to succeed, your system and the remote system must agree on which file transfer protocol to use. The protocol governs various aspects of the file transfer ritual, including starting and stopping, the size of the data packets being sent (in general, the larger the packet, the faster the transfer), how errors are handled, and so on. Many different file transfer protocols are available, but as you’ll see later, Windows XP supports the following seven:

XmodemDesigned in 1977, this was the first protocol for PCs. Because it uses only a simple error-checking routine and sends data in small, 128-byte packets, Xmodem should be used only as a last resort.
1K XmodemThis is an updated version of Xmodem that uses 1024-byte data packets and an improved 16-bit cyclic redundancy check (CRC) error-checking protocol. This makes 1K Xmodem more reliable than plain Xmodem and, as long as the telephone lines are relatively noise-free, much faster as well.
KermitThis is a flexible protocol that can handle the seven-bit bytes used by mainframes and minicomputers. It’s very slow, however, and you should avoid it if the remote machine supports any other protocol.
YmodemThis protocol provides all the benefits of 1K Xmodem (including 1024-byte packets and CRC error control) but also implements multiple-file transfers and the exchange of file data, including the name and size of each file.
Ymodem-GThis protocol is the same as Ymodem, except that it performs no error checking. Instead, it relies on the built-in error checking of modern modems (such as V.42 and MNP 4).
ZmodemThis is the fastest of the file transfer protocols and the most reliable. Zmodem doesn’t use a fixed packet size. Instead, it adjusts the size of each packet based on the line conditions. For error checking, Zmodem uses a 32-bit CRC for enhanced reliability. Zmodem is, by far, the choice among online aficionados.
Zmodem with Crash RecoveryThis version of the Zmodem protocol offers crash protection. This means that if the file transfer bails out before completing, you can restart and the Zmodem protocol resumes the transfer where it left off.

Configuring Serial Ports

As you’ve seen so far, serial ports play a vital role in modem communications. To make sure that your serial ports are ready to do their duty, you might want to set a few properties. Here’s how it’s done:

Double-click Control Panel’s System icon to display the System Properties dialog box.

In the Hardware tab, click Device Manager.

Open the Ports (COM and LPT) branch.

Double-click the COM port you want to work with. The COM port’s property sheet appears.

Display the Port Settings tab, shown in Figure 1. These drop-down lists set up default communications settings for the port. You don’t need to adjust these values for your modem’s port, however, because the settings you specify for the modem will override the ones you see here. You need to change these values only if you’ll be attaching some other kind of device to the port.

Figure 1. The Port Settings tab controls various communications parameters.

Click Advanced to display the Advanced Settings dialog box.

Make sure that the Use FIFO Buffers check box is activated, and make sure the UART’s Receive Buffer and Transmit Buffer sliders are all the way to the right (High).

Click OK to return to the COM port’s property sheet.

Click OK and, if necessary, restart your computer.

Other -----------------
- Tuning Windows XP’s Performance : More Optimization Tricks
- Tuning Windows XP’s Performance : Optimizing Virtual Memory
- Tuning Windows XP’s Performance : Optimizing Applications
- Tuning Windows XP’s Performance : Optimizing Startup
- Monitoring Performance with System Monitor
- Monitoring Performance with Task Manager
- Administering Your Network - Broadcasting Console Messages
- Administering Your Network - Managing a Remote Computer
- Administering Your Network - Monitoring Performance on a Remote Computer
- Administering Your Network - Connecting to a Remote Registry & Connecting to Remote Group Policies
- Sharing Resources with the Network
- Accessing Network Resources - Mapping a Network Folder to a Local Drive Letter
- Accessing Network Resources - Adding a Network Place
- Accessing Network Resources - Using My Network Places
- Setting Up a Peer-to-Peer Network : Working with Network Settings
- Setting Up a Peer-to-Peer Network : Implementing Wireless Network Security
- Setting Up a Peer-to-Peer Network : Configuring a Wireless Gateway
- Setting Up a Peer-to-Peer Network : Running the Network Setup Wizard
- A Modem Communications Primer - Serial Ports: Communicating One Bit at a Time
- A Modem Communications Primer - Modems: The Inside Story
Popular tags
Active Directory Biztalk Exchange Server Microsoft Access Microsoft Dynamic Microsoft Excel Microsoft LynServer Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Pen and Touch Sharepoint Sql Server Windows Server 2008
Most view of day
- Windows Phone 7 Programming Model : Asynchronous Programming - Background Threads
- Maintaining Windows 7 : Defragment Your Hard Drive on a Schedule
- Windows Server 2012 Requirements and Installation : Customizing the Interface with Features on Demand
- Windows Phone 8 : Configuring Basic Device Settings - Screen Brightness (part 2) - Manually Adjusting the Screen Brightness
- Windows Server 2012 : Managing a Server Core installation using sconfig
- Configuring and Troubleshooting IPv6 in Windows Vista (part 1) - Displaying IPv6 Address Settings
- Managing Windows 7 : Troubleshooting Problems - Find a Troubleshooter, Run a Troubleshooter
- Developing with SharePoint 2010 (part 4) - Developer Toolbar
- Games and Windows 7 : Using the Games Explorer (part 1)
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 5) - Creating a Package from a Definition File
Top 10
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
- MDT's Client Wizard : Application Properties
- MDT's Client Wizard : Operating System Properties
- MDT's Client Wizard : Customizing the Deployment Share
- Windows Server 2012 : Software and User Account Control Administration (part 5) - Maintaining application integrity - Configuring run levels
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro