`comp.dcom.modems ›
`Clarifying Modulation Theory (LONG!!)
`1 post by 1 author
`Richard Siegel
`9/13/88
`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
`
`Page 1 of 3
`
`
`
`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
`
`Page 2 of 3
`
`
`
`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
` {ames, uunet, hoptoad, sun, dwon}!telebit!modems
`Click here to Reply
`
`Page 3 of 3