Next Previous Contents

29. Appendix G: Antique Modems

29.1 Introduction

By "antique" I mean modems with speeds of 14.4 kbps or less. Many of them were made in the 1980s. Faster modems are also included if they use a proprietary protocol. This appendix compares the antique modems with the modern ones. You should read it if you are interested in modem history or are intending to actually use an antique modem. Also, many modern modems and software still support the old protocols and you might find that such old protocols have been configured by mistake.

29.2 Old CCITT (ITU) and Bell Protocols

QAM= Quadrature Amplitude Modulation. The word "Quadrature" is short for "quadrature differential phase shift keying" =QDPSK

29.3 Historical Overview

Teletypes and dumb terminals

Prior to 1960, 110 bps modems were used for teletype machines (like an electric typewriter only much more noisy). What one typed at a teletype (or had saved on punched paper tape) could be printed on a remote teletype located far away. No computer was involved.

Then in 1960 AT$amp;T came out with a 300 bps modem (for use on it's phone system). Such slow and expensive modems were later mainly used for transmitting data between mainframe computers or for connecting a dumb terminal to a mainframe computer over phone lines. Many dumb terminals didn't even have a screen display, but printed on paper what you typed at the keyboard along with responses from the computer.

PCs and BBSs

With the advent of the personal computer (PCs) in the early 1980s, one could use a modem to dial into a remote mainframe computer. In this case, the PC was used like a dumb terminal. But now files could be transferred and one PC could connect to another via modems.

The 1980s saw the rise of the Bulletin Board System (BBS). A BBS was just a computer with a modem listening for incoming calls. The public could dial up a BBS with a modem and then download free software, participate in discussions on various topics, play on-line games, etc. Dialing in to a BBS was something like going to an Internet site. Except that to go to another BBS site, you would need to dial another number (and possible pay long distance telephone charges). Many BBSs would have a monthly charge but some were run by volunteers and were free. Many companies established BBSs for customers that contained support information, catalogs, etc. In the early 1990s, BBSs were booming. By the mid 1990s some even offered Internet connections. For some history of BBSs see Sysops' Corner: History of BBSing

The Internet

Then came the advance of Internet in the mid 1990s which resulted in the demise of the BBSs near the end of the 1990s. Some BBSs became websites, but when BBSs were dying in droves, websites were quite expensive so most BBSs just disappeared. The Internet contained far more information than any one BBS could maintain so BBSs were no longer competitive.

Modems permitted the public to connect to the Internet. In the 1990s, Modems became fast, cheap and widely used. Then in the late 1990s, faster non-analog "modems" appeared: ISDN, DSL, and cable. The history of these isn't in this HOWTO.

Speeds

Before V.32 (9600 bps), modems typically had speeds of 300 to 2400 bps. Some super fast ones had much higher speeds (such as 19.2k bps) and used non-standard protocols. To utilize these "fast" ones, both modems for a connection needed to support the same proprietary protocol which often meant that they must be the same brand.

Prior to the V.42 standard for error correction and the V.42bis (1990) standard for data compression, the MNP standards were usually used for both error correction and data compression. An X.PC error correction standard was used on some commercial data networks. Compression and error correction were available on some 2400 bps modems.

From 1960 to 1980 most modems only had a speed of 300 bps (which was also 300 baud). This is only 0.3kbps. Modern modems are over 100 times faster. Some old-slow modems are still in use so they are not really "antique" quite yet.

29.4 Proprietary protocols, etc.

These were used in order to obtain higher speeds before more standardized higher speeds became established. The modem at the other end needs to support the same protocol for this to work. The dates shown below may be only approximate.

The PEP used as much bandwidth as feasible by splitting the spectrum into as many as 512 sub-bands. It was supported by Ven-Tel's Pathfinder and Telebit's Trailblazer.

29.5 Autobauding

This term has a few different meanings. In general it means either the automatic adjustment of modem-to-modem speed or of modem-to-serial_port speed.

29.6 Modem-to-modem Speed

Modern modems negotiate the modem-to-modem speed and protocol when they first connect to each other and normally connect to each other at the highest possible speed. If one side can't negotiate, the other side should accept whatever speed and protocol that the fixed side has available. Except that some modern modems may no longer support some of the antique protocols. As a result of negotiations, one modem may need to use a lower speed than its maximum in order to communicate with the other modem. This is sometimes called "autobauding" or "automode". It might also be called "fallback". A more intuitive use of the word "fallback" is where both modems automatically lower their speed due to a noisy line. While autobauding is normally the default, setting a fixed modem-to-modem speed instead of autobauding is done with either an AT command like or by a register like S37.

Early modems didn't have such autobauding or fallback. If you have such a modem, it will likely work OK if the other modem you connect to is a modern one that can adjust it's speed and protocol to yours. But a problem arises if both modems which want to communicate with each other are both antique and don't support automode. In this case they need to be manually set to the same speed and protocol.

Even when this automode existed, there was sometimes a limited choice of speed (like only 1200/300 bps). In olden days (rarely today), a computer dial-in site might have one phone number a certain speed (like say 2400) and another phone number for a different speed (say 1200). It was often not quite this simple as there might be a few different phone number for one speed, or one phone number might support say only a couple of speeds (like 1200/300). Also one phone number might support only a certain protocol such as the Bell 212A modem. Once a site obtained modems that could support a wider variety of speeds and protocols, then there was no need to have different groups of phone lines.

29.7 Modem-to-serial_port Speed

Same speed required

For old modems (mostly under 9600 bps) the modem-to-serial_port speed had to be the same as the modem-to-modem speed. This was because data flowed straight thru the modem without "speed buffering" (storing bytes) inside the modem. This meant that both the modem's serial port and the computer's serial port had to be set to this speed. That is, both ends of the serial cable had to be set for this speed.

One might erroneously reason that if the serial port speed was higher than the modem-to-modem speed, all would work OK since then there would be no bottleneck in the serial line. This works OK in the direction from the modem to the PC since a higher speed line can have a lower thruput speed due to greater time spacing between bytes. But disaster strikes for the flow from the PC to the modem since it would flow into the modem at a speed faster than the modem could transmit the data. Data would be lost since there is no speed buffering.

Equalizing speed

If a modem had only one modem-to-modem speed (or was set by software or physical switches to only operate at one speed), then this wasn't a problem since one would just set the PCs serial port for this speed. And the modem would set it's serial port for this speed. Another way make the speeds equal is for the modem to detect the PC's serial port speed and then set both it's serial speed and it's modem-to-modem speed the same. This will be explained later.

But for modems that used more than one modem-to-modem speed there's a problem. In that case it's not known in advance at what speed the modem will connect to another modem. For example, if a fixed speed modem dialed in to you modem and your modem supported the remote modems fixed speed, then that's the speed it would connect at. If the PC's serial port speed had been previously set to a different speed, then this speed needs to be changed.

But setting the computer's serial port to the modem-to-modem speed was a problem since the modem has no way to directly give commands to the PCs serial port to change it's speed. Only system software can do that. The modem finds out what speed to use based on negotiations with the other modem and thus the change of this serial port speed can't be done in advance. How does the modem communicate its modem-to-modem speed to the system software?

Use "CONNECT" message to set speed

Here's one way to do it. Consider the case of a dial-in modem that others dial into. A getty program will be used to send a login prompt thru the modems to a user's terminal screen. Getty will also be the system software that changes the speed of the serial port. The modem will tell getty what modem-to-modem speed it's using by sending getty a "CONNECT" message giving the modem-to-modem speed (such as "CONNECT 2400").

But there's one problem here. How does one insure that the "CONNECT" message, which the modem sends to getty via the serial port, is sent at the same speed as the PC's serial port which is expecting a "CONNECT" message? Here's how it's done.

When the modem is first sent an init string, the modem detects the speed of the computer's serial port and sets it's modem-to-serial_port speed to this value. Now it can communicate with getty and the "CONNECT" message can get thru.

To sense the speed the modem has examined the "AT" at the beginning of the string. This is sometimes also called autobauding. For modern modems, this same modem-to-serial port speed is always retained, even after the modem connects to another modem and regardless of what the modem-to-modem speed is. But for our old modem this initial serial speed may need to be changed later to that of the modem-to-modem speed once a connection is made.

For example, getty gets a CONNECT 2400 from the modem and switches the PC's serial port speed to 2400. The modem also switches its serial port speed to 2400. Now both ends of the modem serial cable are at 2400 and there is no speed mismatch. Then getty sends a login prompt out over the phone line thru the modems. The 2400 bps is now both the modem-to-modem speed and the modem-to-serial_port speed. Problem solved. Mgetty can do this by configuring it for "autobauding" but it's only of use for very old (and slow) modems.

For dialing out, the same method is used, but now the communication software must handle it instead of getty.

Setting modem-to-modem speeds by the serial speed

Another way to switch modem-to-modem speed was by using a modem feature where the modem would set its modem-to-modem speed to be the same as the modem-to-serial port speed it detected. The Bn AT commands would enable this and determine what protocol to use for each speed. So with this enabled, setting the serial speed by the computer would also set the modem-to-modem speed to be the same. This should result in this modem being inflexible in any speed negotiations between the modems.

Manual bauding

Another (but cruder) way to solve the serial speed problem when dialing in to a site was to get the remote site to change it's modem-to-modem speed to match your serial port speed. It works like this: The person trying to login over a modem connection doesn't see any login prompt because of a speed mismatch. So the person trying to login hits a "break" key to send a break signal over the phone line (via modem) to getty on the remote machine. A break signal will always get through even if there is a speed mismatch in a serial line.

The remote getty gets this break signal and switches the remote's serial port to the next speed as specified in its getty configuration file. This new remote serial port speed causes the remote modem to switch to the same modem-to-modem speed as previously configured by the ATB command. Then the local modem would transmit the login prompt over the local's serial line at this speed. If one doesn't see a login prompt, then they hit the break key again and a new speed is tried. This continues until the remote getty finally gets the speed correct (equal to the serial speed set on the local PC) and a login prompt finally displays. Note that PC keyboards have no "break" key but dumb terminal keyboards did. Mgetty, agetty, and uugetty can do this obsolete break method and it's called "manual bauding".

Unsupported speeds

In Linux, there's a problem if the speed is set to a speed not supported by Linux's serial port (for example 7200 bps). You may dial out and connect at 7200 bps (both modem-to-modem and modem-to-serial_port speed) but you only see garbage since Linux doesn't support 7200 on the serial port. Once you connect there is no simple way to hang up because even the +++ escape sequence can't be sent to the modem over a 7200 baud interface.

Modern modems, speed buffering

To dial out by the antique method using some modern modems set &Q0 N0 and S37=5 (if you want 1200 bps). Some of the S17 settings vary with the make of modem. S37=0 is the default that connects the modern way at the highest speed supported.

Modern modems can use almost any serial port speed. It doesn't depend at all on modem-to-modem speed. To do this, they employ speed buffering and flow control. Speed buffering means that modems have buffers so that there can be a difference between the modem-to-modem speed and the modem-to-serial_port speed. If the flow entering the modem is faster than the flow exiting it, the excess flow is simply stored in a buffer in the modem. Then to prevent the buffer from overflowing, the modem sends a flow control signal to stop the input flow to it. This is true for either direction of flow. See Flow Control for more details.

29.8 Before AT Commands

Hayes introduced the AT command set and other modem manufacturers adopted it as a standard. Before the AT commands, many modems used dip switches to configure the modem. Another command set is the CCITT V.25bis command set. Some modems supported both CCITT and AT commands. The CCITT V.25bis also specifies how Synchronous modem-to-serial_port communication is to take place using either the ASCII or 8-bit EBCDIC character sets.

29.9 Acoustic-Coupling

This is where one connects a modem to a telephone using audio tones that one can hear. The modem contains a microphone and speaker which "talks" directly into the telephone handset without using any wires. It's "wireless" in a sense but uses sound waves instead of radio waves. The modem speaker is placed in contact with the telephone microphone (on the handset) so that the tones from the modem go into the telephone. The modem microphone, picks up tones from the telephone handset speaker. This scheme is called "acoustic coupling".

A major problem is that outside noises can interfere and cause errors. The advantage is convenience: There are no cables to plug in. Most modems that could do this were only 300 baud, but higher speeds were used too. It's said that 9600 bps didn't work very well using this scheme.

29.10 Data Compression and Error Correction

MNP 2, 3, or 4 were used for error correction. MNP 5 was compression. Modern modems generally use V42 (error correction) and V42bis (compression). Many modems support both MNP and V42.

END OF Modem-HOWTO

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:21