Article 584 of comp.dcom.modems: From: Carl S. Gutekunst Subject: Re: Break definition (Some Answers from the Standards) Date: 12 Sep 88 07:39:16 GMT >Higher-speed modems are *NOT* just transmitting the RS232 signal as tones; >they are actually receiving the characters, packaging them up in odd ways >(e.g. more than one bit per line transition), and reversing the process at >the other end. Um, this is rather oversimplified. Allow to me explain, and in doing so give a partial answer to the original question. There are several levels of things going on here, each of which impose their own constraints. First is the modulation scheme: how bits are encoded on the wire. All modems at 300 bits-per-second or slower use frequency shift keying (FSK), which just means that one tone means a mark (1) bit, and another tone means a space (0). Note that an FSK modem is _n_o_t transmitting bits _p_e_r_ _s_e; it is sending out the current state of the RS-232 Transmit Data line as a tone. The line can change state whenever it wishes, and the modem will follow. Modems at 1200 bps and above all use some kind of phase-shift encoding, where multiple bits of data are encoded into a single phase shift of a carriertone. Bell 212 and V.22 (1200 bps) use phase encoding (PE), where a pair of bits are represented by one of four phase changes: 0, 90, 180, or 270 degrees. V.22bis (2400 bps) modems use quadrature amplitude modulation (QAM), in which two bits specify an x-y quadrant, and two more bits specify a shift of phase and amplitude within the quadrant; so four bits are encoding in a single state change. In V.29 (9600 bps), the first bit specifies amplitude, and the next three specify phase angle (0, 45, 90, 135, etc.); again, 4 bits are encoded into a single state change. V.32 (9600bps full duplex) defines two schemes: QAM similar to V.22bis, and a five-bit variation of QAM called trellis coding. In trellis coding, four bits are still encoded into a single state change, but a "redundant" bit is also calculated, for 32 distinct QAM states. (Anybody know how trellis coding got that name? I'd guess that is comes from the way that two of the data bits and the redundant bit are permuted based on the bits in the previous five-bit group. The bits climb all over themselves, like flowers climbing a trellis.) In each case there exists a precise one-to-one relationship between _b_i_t_s on the digital side and state changes on the wire. This is very different from FSK, which is insensitive to bit boundaries. But note that the phase- encoding techniques remain insensitive to _c_h_a_r_a_c_t_e_r framing. All characters are just concatenated strings of bits, and break is just a string of space bits. These high-speed standards were all designed for synchronous communications, in which all the bits dance in lockstep to the beat of the modem's clock. In asynchronous (which is what we all use for dialup and UUCP), the data bits are framed according to the transmitter's internal clock. This clock will almost certainly not even be the same speed (much less the same phase) as the modem's clock. This creates a major dilema: the modem _m_u_s_t run at exactly its nominal bits-per-second speed, but it has no control over the speed of the data being sent to it. So the V.22bis standard provides a lengthy set of rules for how asychronous devices must behave. The critical elements of the V.22bis asynchronous specification are: - The amount by which the asynchronous bit rate may deviate from the nominal speed of 2400bps. If the transmitter is running a little faster, then the modem must occasionally discard stop bits. If the transmitter is running slow, then the modem has to occassionally add stop bits. - The precise specification of a break signal: from _M to 2_M+3 consecutive start (space) bits, where 'M' is the number of bits per character. In fact, if the modem receives a break shorter than 2M+3 bit times, it is required to extend it to the full time. Breaks longer than 2M+3 bits are passed through for their full duration. And a break must always be followed by 2_M stop (mark) bits, to allow the receiver to resynchronize. So, the real reason why fast modems need to know how many bits-per-character are being used is so they know where the stop bits are. And breaks are defined so that the modems will know when the normal progression of character frames is disrupted. (By the way, V.22bis only allows character sizes of 8, 9, 10, and 11 bits. Those of us in the UNIX and PC worlds always use is 10 bits: 1 start; 8 data; 1 stop.) An added restriction arises in all _p_r_a_c_t_i_c_a_l implementations of V.22bis and other high-speed modems: they use microprocessors and UART chips. UART chips, being character oriented devices, are very fussy about character framing. :-) Finally, modern modems are often "smart." At the least, they accept command strings to do autodialing and set options. At the most, they have modem protocols like Microcom's MNP and Telebit's PEP that bundle up characters, strip off the start and stop bits, perform compression, and do a lot of other character-oriented shredding. Here there is actual interpretation of the data going on, and the modem's CPU needs to know a lot more about the data than it does to simply satisfy the encoding scheme. None of which answers the original question. :-) The problem is that the CCC is an internal modem. When dealing with an exter- nal modem, you talk to a serial interface on the PC. The serial interface has a UART chip on it (a Signetics 8251, I recall). And the UART has a control port with a bit in it that, when set by the CPU, drives the Transmit Data line into the space state. To send a break, the CPU sets this bit, spins for the appropriate number of CPU cycles, and then clears the bit. Voila, a break. For the CCC modem, then vendor has to supply something equivalent: a bit that you can assert to cause a break. If they are really clever, they'll make it a toggle, so that the modem itself will time the break rather that you having to use the PC's CPU or timer to do it. An ugly alternative is an escape sequence: you send a magic sequence of characters, and the modem sends a break. My Cermetek 199A modem does this, and it's useless; UUCP uses *all* the characters, so I have to disable the modem's escape character. ============================================================================= Article 585 of comp.dcom.modems: From: Carl S. Gutekunst Subject: Re: Break definition (Some Answers from the Standards) Date: 12 Sep 88 08:23:54 GMT Followup-To: comp.dcom.modems Someone's gonna flame me for it elsewise, so I suppose I should mention how a Telebit TrailBlazer works. (I suppose this is preaching to the choir, but if you've carried through this far I might as well finish the job.) The TrailBlazer uses a proprietary modulation scheme called Dynamic Adaptive Multicarrier Quadrature Amplitude Modulation (DAMQAM). Rather than the single high-frequency carrier used by other modulation schemes, the TrailBlazer uses 511 different low-frequency carriers. Each is QAM modulated at a rate of 12 baud (that is, 12 state changes per second); so each carrier has a data rate of 48 bits per second. Each carrier can be slowed down to 8 or 4 baud (32 or 16 bps), or dropped entirely. On real phone lines, quite a few carriers are dropped, and a number are slowed down to 8 baud; so the theoretical speed of 24528 bits per second is reduced to a real maximum of 18031. (Why an odd num- ber? I don't know.) Note that since DAMQAM modulation broadcasts across the entire bandwidth of the telephone line, it is half duplex -- only one end can be transmitting at a time. On top of DAMQAM, Telebit uses a proprietary data packetizing scheme, the Packetized Ensemble Protocol (PEP) that we've all come to know and love. PEP incorporates error correction, and a family of dataflow prediction schemes that make the modem appear to be full-duplex. This latter process is called "Adaptive Duplex," a term to which both Telebit and Racal-Vadic claim trade- marks (the latter for the RV 9600-VP modem). PEP and DAMQAM are trademarks of Telebit Corp, too. MNP is a trademark of Microcom. But you knew that, didn't you? ============================================================================= Article 593 of comp.dcom.modems: From: Richard Siegel Subject: Clarifying Modulation Theory Date: 13 Sep 88 16:32:11 GMT Just a brief note with regard to the various descriptions of modulation theory that have been going on for the last few days ( I think the discussion was a spinoff from BREAK timing). First, thanks go to Carl Gutekunst for his clear dissertation on BREAK timing and modulation formats for low speed modems. Second, I'd like to clarify the PEP and DAMQAM modulation description that Carl published, to fill in some details that readers may (or may not!) find interesting. I'm including the previously posted article that Mike Ballard and I wrote discussing the theory of operation for the Telebit modems. I hope that this reposting doesn't inFLAME too many people :-) Let me know if you have any comments/questions, although I'm going to be gone till mid-October, and won't be able to respond immediately. And of course if you have technical/configuration questions, we have the account to handle those. Send mail to {ames, sun, uunet, hoptoad, pyramid}!telebit!modems if you have any technical/configuration questions. If you have sort of technical/marketing questions send them to either myself or to Mike Ballard (who manages Telebit's Unix program) at telebit!mike. AND - Watch the skies for an EXCITING announcement from Telebit in the next month! Regards, ========================================================================== Richard Siegel Phone: (415) 969-3800 Product Manager UUCP: {sun,uunet,ames,hoptoad}!telebit!rls Telebit Corporation ARPA: telebit!rls@ames.ARPA "We are, after all, professionals"...HST ========================================================================== ======================================================================== Telebit Corporation Revision 1.00 07 APR 1988 ======================================================================== A BRIEF TECHNICAL OVERVIEW OF THE TELEBIT TRAILBLAZER MODEM By Michael Ballard, UNIX Program Manager, Telebit Corp. Before starting on this document, a caveat: this document is intended to address many of the questions and comments about the Telebit TrailBlazer that have appeared from the user community. We are striving to provide as much information as possible, in such a way that will be useful to the widest group of readers. This is NOT intended to be a Marketing Article, but rather a technical overview for the more sophisticated reader. Its purpose is to inform, not to sell product. If anyone is offended by Telebit taking this action, please mail directly to me first, to avoid cluttering the newsgroup. Thank you. I would like to provide some background for Unix users considering the use of Telebit's TrailBlazer Plus high speed dialup modem. I served as project manager and principal programmer for Telebit's protocol support developement. The UUCP "g", Kermit, Xmodem and Ymodem protocols are directly supported in the TrailBlazer modem's firmware. Peter Honeyman, co-developer of ATT's HoneyDanBer/BNU UUCP, coded those portions of the TrailBlazer firmware which support the "g" protocol. The Telebit modem employs a patented multicarrier modulation scheme coined DAMQAM (Dynamically Adaptive Multicarrier Quadrature Amplitude Modulation). A CRC-16 based sliding window protocol with selective retransmission runs on top of this modulation scheme insuring data integrity across the phone line. This telephone line protocol is known as the Packetized Ensemble Protocol or PEP. PEP is the trademark by which all modems employing this technique can be recognized. This technique (DAMQAM) divides the voice bandwidth into 511 individual channels each capable of passing 2, 4, or 6 bits per baud based on the measured characteristics of the individual frequencies associated with each channel. On a typical phone connection, the modem uses a subset of about 400 of those channels. Each time the modem connects to a circuit established on the dialup Public Switched Telephone Network (PSTN), the TrailBlazer measures the quality of the connection, and determines the usable subset of the 511 carriers. The aggregate sum of bits modulated on this subset of carriers multiplied times the baud rate yields a bit per second rate that on a local telephone connection (i.e. round trip through your local telco) is 18031 bps. This 18031 bps is then reduced by about 20% to allow for the CRC overhead, to about 14400 bps of data throughput. Long distance line quality varies with location and carrier, but you can expect this number to be in the 10000 to 17000 bps range under most conditions domestically. By choosing a high quality long distance carrier, you will ensure the best throughput overall. The modem operates at 7.35 and 88.26 baud, transparently changing baud rates to accomodate the pace and quantity of data traffic. When in "interactive mode" the modem sends data using 11 msec packets (which run at 88.26 baud). Each packet contains 15 bytes of data. In "file transfer mode" the modem uses 136 msec packets (that transfer at 7.35 baud) that contain 256 bytes of data. The TrailBlazer decides which packet size to use on an ongoing dynamic basis. No intervention from the user is required. At lower speeds, such as 300, 1200, and 2400 bps, the TrailBlazer provides emulation (performed in the DSP section, not by a "chip" modem) to support these standards. The 300 bps standard is called Bell 103C. At 1200 bps, two standards exist, Bell 212A and CCITT V.22. Both are supported. At 2400 bps, the standard is called CCITT V.22 bis. These speeds are all available with or without MNP Class 3 Error Correction. The TrailBlazer employs a Motorola 68000 and a Texas Instuments TMS32010 digital signal processor to accomplish this performance. Because of this substantial computer horsepower (about 7.5 MIPS), the TrailBlazer is really a communications processor, rather than a conventional modem. The software defined architecture produces a flexible product platform that allows broad feature development capabilities while allowing the product's installed base to benefit from those developments by installing upgrade EPROM sets. All four protocols (Kermit, Xmodem/Ymodem, UUCP), V.22bis support, MNP at low speeds, multiple releases to improve the interactive performance (earlier TrailBlazers utilized only one baud rate), a multitude of RS-232 behavior related features, leased line capabilities, remote command processor access, echo suppressor compensation, increased data rates, and a myriad of user requested features have found their way into current production modems and are available to earlier revisioned modems via the EPROM uprgrade kits. PEP modems provide a full duplex serial interface to an attached computer, however they employ a half duplex implementation on the telephone line. Telebit refers to this half duplex technique as "Adaptive Duplex". As the name implies, the ownership of the line (i.e. the ability to transmit) adapts to the quantity of data available to send at any single moment. Maximum efficiency is achieved by sending data in a nonstop data stream at 19.2Kbps relying on serial interface flow control to moderate the data flow into and out of the modem. This allows the maximum amount of data to be available every time a transmitting modem takes ownership of the line. In this way the modem, not the DTE, controls the line turnarounds. The protocol provides a ceiling at about 3k of sent data before a transmitting modem must give up its turn and allow the other modem an opportunity to send. A continuous 19.2Kbps data flow into the modem is required to ensure that there is always 3k of data to send each time a transmitting modem takes its turn. The serial interface speed must exceed the telephone line speed, potentially 18,031 bps, or the maximum efficiency of the modems can not be reached). UUCP's "g" protocol behavior on dialup lines was a clear contradiction of the desired behavior with the PEP protocol. "g" sends 3 small data packets at time and then waits for the remote UUCP to ACK or NAK their receipt. The resulting throughput when using UUCP and "g" with the TrailBlazer was only a little better than a standard 1200 bps modem. This was unacceptable. Telebit decided to improve UUCP performance. The TrailBlazer can be configured to "spoof" the protocol by setting a register (S111) to one of several values. The spoof can support four different protocols: UUCP "g", Xmodem, Ymodem, and Kermit. "Spoof" means to fool the various protocols into thinking that they are getting their acknowledgment packets from the remote computer, when in reality they are getting them from the modem. All of these protocols are what are commonly referred to as "send and wait" protocols. This type of protocol builds a packet in computer A, sends it out through the modems, where it is received by computer B. Next, computer B looks at the packet to determine whether or not it arrived intact. If it did, it sends an ACK (acknowledgement) packet back to computer A. If it did not arrive intact, it sends a NAK (non-acknowledgement) packet. In either case, computer A can't send the next packet out until it gets the ACK from the first packet. This is slow! Since our modems are error-free between the modems, the only place data could get "broken" is between the modems and their respective computers. Let me draw the connection diagram below: Ca <======> Ta <----------------> Tb <======> Cb Ca = Computer A Cb = Computer B Ta = Telebit Modem A Tb = Telebit Modem B ====== RS-232 Cable ------ Phone Line When we are running our protocol support, we look at the packet coming from Ca. Ta checks the packet for validity and sends the ACK or NAK. Ca can begin building the next packet immediatly upon receipt of Ta's ACK. This results in Ca building and sending packets as fast as it can. Many packets are now forwarded to Tb. Tb now delivers the packets to Cb, observing the rules of the protocol. Tb will deliver the next packet or retransmit the previous packet based on the ACK or NAK received from Cb. Cb ACKs and NAKs are then thrown away so as not to return to Ca. Protocol support can be configured to run in parallel with data compression enabled. The real world result of this is to increase protocol transfers from 2-3 Kbps to 10-19.2 Kbps. This covers most of the commonly asked questions about the TrailBlazer. If any of the above information is unclear, or you have questions regarding other aspects of modem technology or performance, send mail to: Michael Ballard Telebit Corporation 1345 Shorebird Way Mountain View, CA 94043