If you like the style of Practical Guides, let Niels help you understand Operating Systems in his newest book:
A Guide to Operating Systems: Troubleshooting and Problem Solving
Practical Guide to Analog Modems
...because it doesn't have to be complex.
by Niels Jonker
Copyright © 1997 Niels Jonker
All Rights Reserved
This is not meant to be the ultimate discussion of the Technical Aspects of modems; some technical aspects have been neglected for the sake of simplicity. This is just meant to be an understandable overview of what happens when computers talk.
Modem is a word born out of the combination of two words: Modulator / Demodulator. These words were picked since they describe the actions a modem takes in the most precise way. Modems are no more than an extension to a computer, designed to use ordinary telephone lines to carry digital computer data.
Analog / Digital.
So what is Analog and what is Digital, and what is the advantage of one over the other? To explain the principle, we will look at the brightness of light bulbs. First, we will look at the Digital Light bulb. This one is hooked up to a switch. You can either turn it on, or turn it off.
You cannot decide how bright the light will be; there is either light or no light. This makes things nice and simple if you wish to describe what the light bulb is doing: it is either glowing, or it is not. A light bulb hooked up to a dimmer, on the other hand, could be in many states. It can be off, or dim, or a little brighter, or very bright, and everything in-between!
The light bulb on the switch has a defined number of states: It is ON or OFF. We call it Discrete which is saying it has a finite number of states, and Binary since it only has two states. This finite-state discrete object would be called digital.
The light bulb on the dimmer would be called analog; we're never quite sure exactly where in the range from dark to light it is. All we know is the constraints of its range of possible states.
Computers are Digital; phone lines are Analog.
Computers are all digital inside. There is hardly any analog logic used. This is convenient, since it makes it possible for the machine to deal with great amounts of data at high speeds. Phone lines on the other hand, are analog by definition. They were designed to carry Voice traffic, which was being transformed into an Electrical signal by a Microphone. This signal is analog, and therefore the phone line is analog.
To make something digital talk over an analog line, you need to do 'something' to the digital signal. In a computer for example, a digital signal is represented by the presence or lack of an electrical current. Over a phone line, this cannot be done. However, if you have a way to make this current into a tone, you could make an analog representation of the digital data. Since the phone line was designed to carry tones, you should thus be able to carry digital data in the form of analog tones.
Digital to Analog: the Modem.
So what a modem does is really this: It reads the computers 'digital' signals, and makes them into tones. These tones are sent over the phone line. The modem on the other end listens; it picks up the tones, and transforms them back into digital signals that get sent to a computer. This function is referred to as Digital to Analog or D/A conversion, and Analog to Digital, or A/D conversion.
Practical description of a simple modem.
First we will look at how a simple modem works. Let's say we have one computer that wishes to call another. The modem on one end will dial on the line. The other side will ring; the modem will 'hear' the ring, and answer the call. Now, how do the modems know that the line is 'open' and 'working?'
On the receiving end, the modem will, immediately after answering the call, put a tone on the line. This tone will be a set frequency. The modem on the other end will listen to this tone, and recognize it as being 'A modem.' A human would not make that tone, so the modem knows right away whether it misdialed.
This initial Guard Tone is followed by a transmission from the receiving modem of what is called an Unmodulated Carrier. This is again a continuous tone of a set frequency. Depending on the speed the modem is trying to talk at, this tone will have a different pitch. The calling modem will listen for a pitch it recognizes.
If it hears one, it will also start sending a carrier. These Carriers will stay up throughout the modem connection. As long as there is a carrier, there is a connection. If the carrier is gone, the connection is broken. This is why most External modems have a carrier Detect, or CD light. it will normally only be lit when there is a carrier.
The two carriers are on different pitches or Frequencies. Both the Sending and Receiving carrier will exist at any given time on a connection, on the modem connections we deal with today.
Now that this is completed, as soon as both modems hear each other, they turn on the Carrier Detect light. This means the two modems have agreed on a carrier frequency pair, and are 'ready to talk'. Now, each modem can start accepting digital data from the computer connected to it. This data will come in as a stream of digital ones or zeroes. The modem takes these, and makes them into little frequency changes. These changes are sent over the line. However, the receiving modem will need to know when to start listening for data. For example, if we send all 0's, there would not be a change in tone!
This is why all serial communications like this, without a set clock to time what happens, use a chip called a UART. It adds some data to the data you want to send. In this case, we will need to add a notifier to let the modems know we will start sending data. This is done by sending one bit to start, a Start Bit. Then we will send the data bits, and then we will follow it by another bit, saying that we're done, the stop bit. The other end also has a UART, which will strip off the start and stop bits, so that the data comes out the other end looking the same as it did when you put it in.
Technically speaking, if everything goes right, we now have a great system of talking digital over an Analog line... but of course, not everything always goes right...
So if you think about it, sending Data over a modem line is no more than sending an endless series of 'beeps' of a slightly different pitch. Of course, for every bit there needs to be a beep. Needless to say that the faster the beeps can flow, the faster your bits will go.
Everyone making a phone call has heard a hiss, popping sound, or someone else's phone conversation on their line. Well, the same thing happens to modems. And since they just send 'beeps' what would happen? For example, what would happen if you lose one or a couple of these data bits? What would happen if you suddenly started seeing Data Beeps as Start and Stop beeps?
With old phone lines, this was of course a big problem... Speaking of problems: We did not even agree yet on how many bits we would send between Start and Stop, and what speed we would send bits on! So there is a lot left to do.
Let's say we pick a nice number of bits to get Data across. For example, we can pick 7 bits to be able to send clear ASCII text over a modem. We call this number the Data bits. Then we could do some simple error checking, a Parity check.
A parity (No, Not purity!) check does a very simple trick. It defines whether the sum of all bits in a data packet is an even or an odd number. For example, the data packet 1111110 is even since the sum of all the bits is 6, which is an even number. On the other hand, 1111111 is odd, since the sum of all the bits is 7, which is an odd number.
Of course, data can be either even or odd; but if one or more of the bits in the data change; there is a pretty good chance it will come out the wrong way. But... If it comes out wrong, how do we know??
Before the communications begin, they must agree on Even or Odd communications. What the computers will do is add in one extra bit to each set of data; this is called the parity bit. This bit is set or unset, to make sure the data will pass the parity test. For example, say you agree on even parity. That means the sum of all bits should be an even number. So to send 1111111 over the line, you would need to set the parity bit to 1. The 1111111 makes an Odd parity, plus the 1 for parity makes it Even, so this byte matches!
The same goes for the sequence 1111110. It is already an even number (6), so you add a 0 bit to the end for parity. Now if both sides agree on the parity, you got yerselves a nice deal; you can catch simple errors in the data (your parity will be wrong), AND you can catch it when you go Out Of Sync (you will not see the Sync bits at the right times anymore..), AND you can see when the line is still okay (You still hear the base carrier).
Putting it all together: Line Parameters.
So, the four parameters we described above really define the essence of the mode link. How Fast, How Many Data bits, What Parity, how many stop bits. This is usually described in a cryptic way; for example to say 300 bits per second, 7 databits, even party, one stop bit we usually just say 300 bps, 7E1. We agree we will always send one start bit.
The technique described above will work pretty well on clean lines at 300 bps or 300 baud. But what if we go faster? Well, simple: Just make the tones shorter! This works pretty good up to about 2400 tones per second or Baud. And then, you run into a new problem: The changes in frequency would happen faster than you could hear them on the line! So you could not hear individual tones anymore, simply since the audio quality of the phone line is not good enough!
What we are already doing though, is sending more than one tone at once; we have one tone for each of the two modems. So, what would happen if we fit more than one tone going in each direction on the line? The speed at which the tones keep changing will be the same, but there will be more than one tone at the line going in each direction at any given time.
Baud vs. Bits Per Second.
This technique will allow for every time unit on the line to carry more than just one piece of data, and that is where the difference between Baud and bps comes in. The Baud rate on a line indicates how many changes in tones per second there are; for example, on a 300 baud line there are 300 changes per second. On a 2400 baud line there are 2400.
The bits per Second rate explains how many bits can go over the line. For example, on a 300 bps modem connection, there is a 300 baud link, so there are only two sets of frequencies in use. On a 2400 bps line, there's 2400 baud speed, and one bit per baud unit.
Jumping from 2400 to 9600.
So why did modems go from 2400 to 9600 bps? Well.. they started putting more than one Bit in a Baud. On a 2400 bit line, there are 4 frequencies in use: Originate 0, originate 1, Receive 0, Receive 1. Each may change up to 2400 times a second.
On a 9600 bps line, the number of changes is the same; there are, however, more originate and send channels, 4 to be exact, which are all used simultaneously. Of course, this means there are more different frequencies on the line at each time, and that means the line needs to be 'cleaner.'
And 14400? Does it amaze you that this is 6*2400? And 28.8? 12*2400? So how far can we go?? Well.. it all depends on how many beeps we can send on a line simultaneously.
A way to measure this is Frequency Response on a line; this number defines the lowest and highest sounds a line will reproduce. There are standards for this, and about 150 Hertz to 6 Kilohertz is what a phone line will handle, with the peak performance in the 1500-300 Hertz range. Most distortions are clicks, pops and hums (low frequencies) and hisses, whistles and static (high frequencies). So the cleanest part of a line is 'in the middle,' which is where 9600 bps and lower speed modems have all their frequencies mapped. As a matter of fact, 9600 bps is guaranteed to work over all phone lines that adhere to the Bellcore Standard.
The higher you try to get your speed, the more you will get into the range of the noise on your line. 14,400 is more or less sensitive to this. 28.8, since it uses most of the frequencies available, most certainly is. These things did, of course, not go unnoticed: more speed on the lines caused more errors sooner. And not every error can be caught by Parity checks at higher speeds. Think about it: if a POP causes one bit to be lost at a 300 bps/Baud connection, it will cause 4 bits to be lost on a 1200 bps and 8 bits to be lost on a 2400 bps connection!
So, smart as humans are, we thought up a way to work around this. We defined a protocol that makes agreements between modems on how to handle data. It will take a block of data and calculate a checksum on it. This is a mathematical trick to describe the data in the block. This checksum will reflect changes in the block fairly accurately. What a modem will do with this Error Correction is calculate the data checksums as the data flows. Every so often it will pass on the Checksum numbers to the other side. This can, for example, be done every 128 bytes or less.
The other side also keeps a checksum and compares the two checksums when the block of data is complete. If there is an error, it will kindly ask the other side to re-send the block of data. Of course, it takes some time to do this, and if a block needs to be re-sent, this will be noticeable as a delay. But the data going from one side to the other will be correct, almost 100% guaranteed.
This Error Correction technology started out under the name MNP, it evolved all the way to MNP-4. Mainly performance improvements were made up to this point. Then the technique was adopted into the V.42 national standard.
In more modern error correction protocols, such as MNP-4 and V.42, the data is sent over the line Synchronously. The Error Correction Protocol puts little Synchronization Bits on the line, which the other end receives. Since they now have a Synchronized Clock that they agree on, they can just send data in-between those Clock pulses. Then, they do their own Error Correction, so why send the Parity Bits over the line? In other words, in modern modems with Error Correction, the actual transfer over the line is Synchronous. The modem on either end, and the computer on either end, use UART chips to translate from Synchronous to Asynchronous data.
And of course, with more demands on the phone lines, people started looking for ways to better adapt a modem to a phone line. One of the things used in home stereos to better adopt the speaker sound to your room is an Equalizer; a thing that can add or remove low or high tones, to respond to your room. Well, modem manufacturers did the same with the phone line.
They designed circuitry in the modem that will measure on a phone line how it responds to certain frequencies; some may need to be sent a little louder, some a little less loud. And on some lines, there may be frequencies that can not be used at all. So modems can then decide to not use certain frequencies and to use others.
And then Compression Technology came along. If you look at a stream of data, you can sometimes find patterns in it. For example instead of saying 0101 0101 0101 0101 0101 0101 0101 0101 You could say 8 times 0101, which may be shorter. This would mean that the slowest determining factor on a modem line - The actual line speed - would no longer be an issue.
So modem manufacturers got together and upgraded MNP-4 to MNP-5, and V.42 to V.42Bis. These protocols do the following two things: They still do all the error correction that we talked about before, but in addition they attempt to compress the data. But to do so, they will need some time and a little data to play with, so they need to be talking to the computer at higher speeds than they are on the line, assuming that they can compress the data and no errors occur.
The data is then compressed at one side, before it goes over the line, it is sent over the line at the good old speed of 2400 BAUD and 2400, 9600, 14400 or 28800 bps, and on the other side it is decompressed and fed to the receiving computer at the higher speed.
Once again: Making a connection.
Now that there are more things that can be done whilst making a connection, more speeds, line equalization, error correction and compression, things are becoming a bit more complicated when we make a connection.. Let's look at the steps again:
The Caller (The side we call the Originate) calls out, the other side (the Answer side) rings and picks up. Answer will send the Modem tone, then it will send an unmodulated carrier. The Originate modem will listen, and wait until it hears a carrier it knows. When it does so, it will also send out a carrier, which is slightly lower in pitch. To us, we have so far: Dialing, Ringing, High tone with Dips in it, higher continuous tone, static.
Now, the Answer will do the same, and we have two carriers. Next, the modems will query each other about their capabilities. This is done by adding carriers. The Answer will add all carriers it can; in the case of a 9600 modem 3, in the case of a 28,800 modem 11. Originate will hear this and answer with all carriers it knows. In some protocols, this is heard as a series of beeps going from low to high, in some others it just appears there is another burst of static.
Carriers that remain unanswered will be dropped. A 14.4 modem for example, dialing into a 28.8 modem, will only recognize and answer the 14.4 carriers. The 28.8 modem will drop the rest and they will start talking at 14.4. Depending on the line quality, some carriers may not be heard, this is how strange speeds like 21600 bps come to be.
Now that the modems are talking, they will go through the Adoptive Equalization stage. You hear this as a short low buzz, followed by a lower Hiss, then another beep and a higher Hiss, then another beep and the 'normal sounding hiss.' During these stages, the modems have measured the quality of the line. They will change how they transmit and listen to compensate for line imperfections.
If all goes well, the speaker will now shutup, and the CD light will come on. The modems have now successfully managed to talk to each other. Next, they start 'talking' over the carriers. The conversation goes in the form of questions and answers. The Answerer will ask whether it is okay to do MNP-2, MNP-3, MNP-4, MNP-5, V.42, V.42Bis, etc. etc. The two modems will shortly arrive at a mutual conclusion, and now they are ready to start sending and receiving data. Some modems wait until this point to turn on Carrier Detect. This entire process the modems go through to build up a connection is referred to as Handshaking. At this point, the traffic on the line will most likely be Synchronous, that between the modem and computer will be Asynchronous.
The modems will now talk until the connection is broken, or until things go wrong...
Retrain, Fall Back and Fall Forward.
The modems continuously monitor the status of the line; the quality of the signals they get, the number of errors corrected, the validity of data on each of the carriers. When the modems see excessive problems, they can ask for a re-evaluation of the line. This is done by interrupting the carriers, and sending a low burst tone on the line. Now, the modems will again go through the process of sending out carriers, and doing the adoptive line equalization. This process is called retraining, and may occur at any time. You will hear that your speaker comes on, and your modem starts hissing again.
Usually, the initial re-train will result in a 2400 bps connection. This uses only a limited number (2) carriers, and thus will most likely work. This process is called Automatic Fall Back. After a while, if we see few errors, we will again try to re-train. This time, more carriers will be used. Hopefully, if a connection with multiple carriers is indeed successful, our speed will come back up. This process is called Fall Forward.
Both Fall back and Fall Forward sequences are controlled by the modems; both sides of the line must support this feature for it to work. On modems that do not support this feature, or that do not support retrains, the connection will often seem to 'drop' on poor lines.
The amount of time allowed without a carrier can be configured; it is a good idea to set this to a longer time, such as 20 seconds, and to set the retrain period to a longer period, such as 10 seconds. This way, if someone picks up a telephone, or a call-waiting tone is received, modems may retrain and stay online, instead of loosing a connection.
Problems in Handshaking, Retraining, Fall Forward and Fall Back.
It should be obvious that the way a modem handles the training, handshaking, Fall Forward and Fall Back procedures will play a large role in the performance of the modem. This is one of the places were manufacturers try to make their mark, by adding and/or removing features. The most problems happen with Error Correction and Compression.
A lot of manufacturers make their own non-standard protocols. These are built to not interact with standard protocols.. But they are not always able to avoid interaction with non-standard protocols! This is why sometimes modems of one brand have trouble dialing into, or dialing in on, modems from another brand.
U.S. Robotics is a prime example; when driving the negotiation (i.e. being the Answer modem) things go fine, when Originating (i.e. listening to other people's questions) things sometimes go wrong. Especially when negotiating Data Compression and Error Correction, or when determining Carrier Frequencies, things tend to go wrong. A good way to prevent this from happening is to turn the specific feature that causes the problem off, for example: U.S. Robotics in Originate mode works a lot better without Compression enabled.
Data Communication Equipment and Data Terminal Equipment.
At this point, when we talk about compression, the difference between DCE (Data Communications Equipment, the modem itself) and DTE (Data Terminal Equipment; the computer) becomes essential. The computer to computer connection looks like this:
As was explained in the compression paragraph, the DTE speed is now higher than the DCE speed, in order to facilitate compression and error correction. The part of the modem that does this used to be called an Interspeeder, but has now become so standard that it is hardly ever mentioned anymore.
More important, the DTE typically adds Start Bit, Parity Bit, and Stop Bit to the data it sends out. It needs to take care of the signaling etc., and for this it uses a chip called a UART. (Universal Asynchronous Receiver and Transmitter). You simply feed this chip data, it will ad start and stop bits, computer parity, and send things out at the right speed. The higher the speed, the more is asked from the UART.
With the DCE speed typically lower than the DTE speed, and oftentimes the two DTE speeds being different, we need a way to make the data start and stop at the right moment: Flow Control.
The standard technique of flow control, left over from the old and slow days of the teletype, uses what is called the Xon/Xoff protocol. Both Xon and Xoff are normal ASCII characters; Control-Q, ASCII value 17, is Xon. This is read as: Start Sending, I am ready! Control-S, ASCII value 19, is Xoff. It is seen as: Stop Sending! I cannot read anymore!
So with Xon/Xoff flow control, a computer will start sending information to a modem. If DCE and DTE speed are equal and there is no compression, it will simply pass all data on to the other end. It will get the data, and send it to the computer, who should have the same DTE and DCE speed. The computer will process the data, and everything will work fine.
And if the receiving computer needs a moment to do something? It simply sends an Xoff character down the line. The sending computer will get it and stop sending, waiting for an Xon so it can start sending again. The same happens the other way around.
When modems got smarter and got buffers, the Xon/Xoff characters were actually used by the modems themselves. Rather than going across the DCE channel, they controlled data flow on the DTE channels. The modems themselves used the same protocol on the DCE channel, but this control is usually out of the users' hands.
Obviously, the flow control is done as a part of the data stream; you need to insert special things in your data to make it flow or stop. This technique is called inband signaling. The two biggest disadvantages of inband signaling are that you continuously need to monitor the data stream, at high speed, to find the signals, and if one of the DTE's happens to send an Inband Signal as part of the data, unpredictable things may happen!
Hardware Flow control and other Out of Band signaling.
With higher DTE speeds, and faster computers, modems and computers are not always able to get the Inband Signaling on time; and with the way we send data nowadays, there is a good chance we will use the Inband Signaling Characters in our data stream!
So, instead of trying to cram everything into the data stream, we have defined a set of electrical signals that can go to and from the modem and computer to let the other know what is happening. These signals are used for Flow Control and Call Control. We will discuss each one shortly.
Remember when you read this: DCE means Modem, DTE means computer, and the functions mentioned can all be changed by software! This is 'standard operating procedure.' We will later look at variations.
Data Set Ready, DSR. This signal is controlled by the DCE. It tells the DTE that the Equipment (Modem) is available and functioning to receive data.
Ready To Send, RTS. This signal is also controlled by the DCE. It tells the DCE that the Equipment is ready to accept data for transmission over the line, or to the command processor.
Carrier Detect, CD. This signal, controlled by the DCE, tells the DTE that there is a carrier, which means there is a DCE-DCE connection.
Ring indicator, RI. The DTE will use this signal to let the DCE know that it hears a RING on the line, i.e. there is an incoming call.
Data Terminal Ready, DTR. This signal is controlled by the DTE. It tells the DCE that the Equipment (Computer) is available and functioning to receive data.
Clear to Send, CTS. This signal is also controlled by the DTE. It tells the DCE that the equipment is ready to accept data for reception from the DCE.
All these signals, as well as the standard way of sending and receiving data, are grouped together in a protocol which we know as RS-232. The computers we use today, use all RS-232 signaling with a slightly different voltage level for Signals. Their interfaces are referred to as RS-232C. All these signals are electrical levels on a set of Pins. The RS-232C interface has three more:
Signal Ground, GND. This is the electrical Zero for all signals on the serial port.
Transmit Data, TX. This is where a device transmits data to the other device.
Receive Data, RX. This is where all data comes in from the other side.
And now, we have a total of 8 signals that will let us do Serial Communications with Out -Of-Band signaling.
The Chip that does it all: The UART.
In most equipment, data flow is Synchronous. This means: There is a clock, and everything happens in rhythm with this clock. On serial lines, this is not the case. The data start and stop bits make the clock. We say this is not Synchronized, or Asynchronous.
The UART is the chip in the computer that does the conversion between Synchronous and Asynchronous data. It will take a byte of data from the computer, add start, parity and stop bits, and spell it out on the Serial lines. It will also control all out of band signaling. A UART will however NOT deal with In-Band signaling, that is the task of the software!
With Error correction and data compression, the links between two modems are synchronous, so we will need a UART in the modem as well, to translate the Asynchronous data from the computer into Synchronous data on the line, and vice versa. It is needless to say that the faster data moves, the more we will demand from these UARTs.
A commonly used UART in PC's is Intel's 8250. According to the specifications, it will work up to asynchronous speeds of 19200 bps. Trying to run faster is not supported by the chip! Although it will work most of the time, it will also often fail. The major problem is that the 8250 only has a one-byte buffer. So when it has received a byte, it needs to get rid of it before the next byte comes. If the software or modem is not fast enough to facilitate this, data loss will occur.
Intel solved this by making the 8450 UART, which has a larger buffer and higher speed. it is rated up to 57600 bps. In order for things to work right, we should allow the UARTs to take care of all the signaling (Which means we must use Hardware Flow Control), and we should use UARTs that are fast enough to do the job. So, both the modem and the computer should use 8450 UARTs, or their 16 bit brothers, the Intel 16450 or the 16550, which has a top speed of 115,200 bps.
UARTs have an internal clock that they use to make the speed at which serial data flows. This clock is derived from an oscillator, which oscillates at a set frequency, by using a programmable divider. The divider can only divide in steps of two and four. The frequencies it can create directly are: 76800, 38400, 19200, 9600, 4800, 2400, 1200, 600, 300 150 bps. The highest two are only available in the 8450. By multiplication, it can also derive odd numbers such as 57600 (38400 * 1.5) and 115200 (38.4*3). These are, however, not totally precise. Choosing any other frequency will ask the 8240/8450 to 'create' it. It will do so, but the result is NOT guaranteed. The timing will not be precise, and this may cause some serious trouble. Remember: RS-232C is only guaranteed to work up to 19200 bps! Higher than 38400 is usually more trouble than pleasure.
The DCE serial Interface and the DTE Serial Interface
So now, let's look at tying a modem and a computer together. RS-232C interfaces come in two flavors: DTE for the computer (A Male, 25-pin, Dtype connector, a.k.a. a DB-25M), and DCE for the modem (A Female, 25-pin, Dtype connector, a.k.a. DB-25F). Male means: Pins stick out of the connector. Female means: The connector has holes, no pins. The diagram below shows the Pin assignment:
All it takes is a straight-through cable that has a DB-25F on one end, and a DB-25M on the other. Count and you see only 9 pins in use. This is why some smart people decided to use a DB-9M for the DTE instead of a DB-25M. The signals stay the same. They are, however, (of course) mapped to completely different pins.
The arrows indicate the direction in which the data flows. You will see that on the DCE side of the interface everything is in Reverse. We say this interface is viewed from the perspective of the DTE side. It should be obvious that a connection with UART controlled Hardware Flow Control will not work unless all lines (Except RI) are connected.
Software and settings...
And now we get to the fun part: Variations to a theme! Not every computer may support all signals in the standard, not every modem may do so either. Sometimes you may need to make some changes, sometimes you may not wish to use Out Of Band signaling....
You guessed it: The behavior of the computer and modem with regard to every set of signals is fully programmable on both ends. Obviously, there are no signals to have one tell the other what it is doing, nor is there an agreement on what to do over the data channel. In other words, it is humans with programs to the rescue! Hayes, one of the modem pioneers, designed the Hayes modem Command Language. It uses simple inband commands in ASCII form to control the modem. The modem has a command mode in which it resides when it is not connected to another modem.
In command mode, it will read every line that asks for its attention. This is done by prefacing a line with the letter AT, from ATtention! Then, numerous commands can be given that will tell the modem what to do. Everyone in the industry has copied these commands. Hayes was stupid enough to forget to copyright or patent them. This was of course good, since it created an open standard...
...and it was also bad, since everyone started making extensions to the command set! There is, however, still a group of core commands that works on nearly every modem. An overview with the exact explanation of what it means follows. In the list, the first column gives the command, the second column gives the recommended setting, and the third column gives the explanation.
A Answer Incoming Call When a call RINGS, the word RING will appear on the screen. Giving the ATA command will tell the modem to pickup and start a connection. This takes the modem out of command mode. D Dial a telephone number. This is followed by the number to call. Some special things that may be used in a number are: T Dial Tone dial P Dial with Pulse dial , Wait a few seconds w Wait for a second dialtone 0-9,* and # are just sent out as you'd expect. On most modems, entering letter instead of numbers will not work, and may produce some very weird results! Ex E1 Echo Characters in Command Mode. When set to 0, you will not see an echo of commands you type. Should in almost any case be set to 1. Hx Hook Switch Control. Sending the ATH0 command hangs up the phone line if it was Off Hook. Sending ATH1 will force the line off-hook, but not start the handshaking process. Useful for busying out a line. Kx K1 Break during Error Control Allows or Prevents retrain breaks during Error Control situations. This should always be left in the K1 setting, which should be the default. Mx M1 Speaker Mode. Controls when the sound on the phone line is passed through in the internal modem speaker: M0 Speaker always off M1 Speaker On until Carrier Detect M2 Speaker Always On Qx Q0 Quiet Mode When set to Quiet mode, a modem does not return responses to commands given to it. This is not useful for normal use, and should be left in the default Q0 setting. Q1 enables Quiet mode. Vx V1 Verbose Mode. When set to 1, all responses to commands will be sent as verbal messages, such as OK and ERROR. When set to V0, only a number will be returned. This setting should generally be left V1. Xn X5 Response and Dialing Mode This command controls what responses will be given when dialing other modems, and what checks will be performed whilst dialing and connecting. These are the options: X0 Basic Response, do not check for Dialtone or Busy X1 Extended response, do not check for Dialtone or Busy X2 Extended response, check Dialtone, do not check Busy X3 Extended response, do not check Dialtone, do check Busy X4 Extended response, Dialtone and Busy detection X5 Basic Response, Dialtone and Busy detection If you are behind a PBX and can't dial out, using No Dialtone Detection usually fixes the problem. Using No Busy Detection can be useful when a modem sees a RING as a Busy (Sometimes happens in PBX's). I suggest using Basic Responses, since it will not tell the user all the scuzzy details about the line speed... Z Reset modem to NVRAM defaults. Stay away from this command.. you NEVER know what you will get into! Rather, use AT&F and create your configuration. In some cases, when all else fails, ATZ does miracles though. &Bx &B0 DSR Behavior. This is an important one! It controls how DSR behaves on your modem, and that is of course one of the Hardware Flow Control lines! Settings are: &B0 DSR always ON &B1 DSR does what DTR does &B2 DSR signals normal RS-232C behavior Due to software legacy, you should ALWAYS use &B1!! This says: The modem equipment is Ready. Without this signal, and with Hardware Flow Control, you will not be able to talk to the modem AT ALL, since your computer will refuse to talk to something that is not ready to listen!! CD and CTS will take care of online detection and flow control issues. &Cx &C1 Carrier Detect behavior. This should always be set to &C1 in normal situations! It will tell the software whether there is a carrier or not, so the software can redial if no carrier is present anymore (We lost the line.) This is often used to detect whether a connection is Up or Down, so setting this one wrong may cause some real confusion! &C0 DCD Always ON &C1 DCD follows RS-232C standards &C2 DCD Wink; always on but 'winks' off when carrier lost &Dx &D2 Response to DTR This setting controls what the modem does when DTR is toggled. In most applications, this should be set to &D2. This will cause the modem to disconnect as soon as the DTR line is dropped. Most software drops DTR to break a connection. Setting this to &D0 may cause connections to not drop when you attempt to close a connection. Setting it to &D3 will cause an ATZ to happen every time the modem hangs up.. Depending on the settings in your NVRAM, this is NOT a good idea! Safest option is &D2. &D0 Ignore DTR &D1 Go to Command mode after DTR drop &D2 Drop connection after DTR drop &D3 Drop connection and reset to NVRAM settings after DTR drop &F Reset to Factory Settings. Will load the modem's factory setting from the ROM on the modem. Factory Settings are usually Full Flow Control, All Error Correction, Most Flexibility and Reliability. This is a good setting to try, without anything else! On most modems there is more than one AT&F option nowadays. AT&F1 through 8 have been seen on a lot; it may be a good idea to walk through several AT&Fx options until you find one that works, rather than trying to work out all the right parameters by yourself. S0=x 0 Numbers of Rings to Auto Answer Should be set to 0; this is the number of rings after which the modem will automatically try to answer a call. S7=n 60 Wait time for remote carrier. Should be set fairly high; this is the time the modem will take to wait for a carrier after it dials, and also after a retrain is initiated for whatever reason. It will really not hurt anything to set this high! S9-n 5 Carrier Detect Time required for Recognition. After a carrier has been heard for this long, we say it is really a carrier. Increasing this value sometimes helps on noisy lines.. Do not make higher than about 10! S10=n 60 Wait on Loss of Carrier Time waited after a loss of remote carrier before we stop attempting to retrain; again this should be set high, 60 would be a good value!
Where are the Hardware Flow Control Commands?
Note that the table has no Enable or Disable Hardware Flow Control commands?? That is because those happen to not be standardized! Here are a few:
U.S. Robotics &H1&R2
LineLink &K3 or \Q3
A lot of modems use Rockwell Chips. Here are two common types and the Hardware Flow Control Enablers:
All of these set up Bi-Directional Out of band (or hardware) Flow Control. Note that by far not all modems are listed here. You will need to look in the manual to enable Hardware Flow Control, RTS/CTS Flow Control, or Out-Of-Band Flow Control.
Most modems can offer Xon/Xoff on top of Hardware Flow Control. This is not a good idea! Avoid using this setting at all cost!
Some common problems.
The modem will not dial, it says no dialtone, but I can hear it!
To you it may sound like a dialtone, to the modem it does not. It may be either a wrong pitch, not loud enough or too loud. Try giving the ATX0 command before you dial. You may also want to look at your phone cord; is it "straight through" or are the wires crossed? You may also want to try unplugging some other equipment plugged into the modem or into the same line.
The modem dials; when the other end rings it says BUSY and hangs up, but I hear it ringing!
The modem does not recognize the ringing signal as a ring. This happens often when you're dialing from a PBX or Keys System, or dialing long distance or international. Try giving the ATX0 command. Also, check to make sure your phone cord does not have wires crossed, and make sure there are not many other things plugged into your line like answering machines.
My modem dials, the other answers, and they negotiate forever!
Usually, this is caused by poor line conditions. Try calling again, or calling a different number. If you are calling long distance, try using a line without Echo Cancellation; your long distance carrier should be able to tell you what prefix to dial to do this. This may also point to interference of other equipment on your line. Alarm systems, fax machines, answering machines and other things that use modems (Such as Credit Card machines!) are suspect. Try unplugging these.
Another cause can be an incompatibility between your modem and that at the other end; try turning of Data Compression, dial again. If that does not work try turning off error correction, and try again. If that does not work, try forcing your modem to dial at a lower speed (For example, 9600 instead of 14400).
The connection continuously retrains.
You probably have a noisy line from you to the other modem. This problem can literally be anywhere. Make sure you have a healthy phone cord, make sure there is not too much equipment on your phone line such as answering machines, faxes etc. etc. Try dialing in at a lower speed, to a different number, too. Try what happens when you turn of Retrain, Fallback or Data Compression / Error Correction.
The connection just drops with a No Carrier message.
You lost the other side. Look at the S switches that set the time you will try to retrain, make sure there is no one picking up the phone on the line you are using. Make sure call waiting is disabled, make sure there are no devices such as Fax Machines or Answering Machines or Alarm Systems trying to use the line.
Whenever it rains,, my connections fail.
Congratulations, you are the proud owner of a dirty line! You can check your inside wiring, to make sure it is correct, and all your connections to the line. Also check that your phone connection, if outside, is absolutely dry. The Phone company can usually come out and attempt to fix this (mostly without success) for a hefty fee. You should notice your line also hisses when it rains.
Sometimes I am unable to connect.
Well... This is not an Exact Science! Numerous conditions can cause this, including the way calls are routed in the switch, the traffic on other lines, etc. etc. Try to find a pattern in this problem.
Whenever I receive a lot of data, I lose pieces of it.
Check your Flow Control, make SURE both Computer and Modem are set for Hardware Flow Control, and Hardware Flow Control ONLY!
Whenever I receive a lot of data, my modem hangs up after a while.
Make sure your software uses RTS/CTS Flow Control, and NOT DSR/DTR flow control! What will happen when your buffer is full is that your computer will drop DTR to signal the modem to stop sending.. but the modem reads this as: Hang up the line, which it promptly does!
I can type lowercase letters, but the return key does not work!
Check to make 100% sure you have your software set for 8 Databits, No Parity, and One Stop Bit. Usually, this problem is caused by 7 databits, Even parity, One Stop bit setting.
When Xmodem sends me a file, it always hangs at block 19.
When Zmodem sends me a file, it stops at about 19 Kilobytes!
Make sure Computer and modem are both set for Hardware Flow Control (Or RTS/CTS flow control). If so, make sure your modem is set for Xon/Xoff pass through. Xmodem and Zmodem both send block counters.. The block counter for block 19 is ASCII Value 19, which is the same as Control-S, which is the same as Xoff, and will stop the data flow!
My connection dies when I send or receive a lot of data, but the modem stays online, and I can see the RD and SD lights flash..
You probably had a buffer overflow. Here are a few things to try: Make sure you use hardware Flow Control, and Hardware Flow Control ONLY! make sure you use a correct serial port speed that is not too high for your port. Try 38400 or lower (19200, 9600 etc.) Make sure the modem is setup for hardware flow control.
I am set for hardware flow control, but the problems continue!
Make sure you have a full cable, that holds all 8 active pins! Radio Shack sells Gizmo's you can plug in your modem to verify all lines are working. If you have an internal modem, you're out of luck.
Suddenly, in the middle of a connection, I get nothing but garbage.
Probably, you lost Sync on the Synchronous part of your connection (The DCE-DCE part) and error correction is not yet aware of this, or unable to correct it. Hang up and dial again. If this keeps on happening, turn of error correction and/or compression.
I get nothing but garbage, my commands are not recognized!
Make sure you are set for 8 databits, No Parity, One Stop bit. Make sure you use one of the supported bps rates (38400, 19200, 9600, 2400, 1200, 300).
My speed is 19,200. I can dial, but then I only get garbage!
Probably your modem is not properly set for Interspeeding or Speed Adoption. Try dialing at 9600 and see what happens. Especially if you have a slow (say.. 2400 bps modems) try this! In general, modems will not talk faster than 4 times their top speed in Modem mode. Modems without compression often do not talk faster than their top speed, or the next 'notch' over it (i.e. 19200 for a 14400 modem). Some modems that are 14400 will not talk faster or slower than 14400. This is not a speed the UART deals with very well; you will probably run into a lot of trouble.
I have a sound board that doubles as a modem, and it doesn't work too good.
That is right. A sound board was not created with this purpose in mind! It uses its Digital Signal Processing or DSP chips to try to emulate a modem. This would work fine, if it weren't for all sorts of little things that the sound board people left out, such as special Filters and Adaptive Equalization. Best bet is getting a real modem.