throbber
http://groups.google.com/d/topic/comp.dcom.modems/MqianzrgMrQ/discussion
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket