Xref: utzoo comp.protocols.misc:308 comp.dcom.modems:2074 Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!westmark!dave From: dave@westmark.UUCP (Dave Levenson) Newsgroups: comp.protocols.misc,comp.dcom.modems Subject: Re: UUUUU Message-ID: <239@westmark.UUCP> Date: 10 Jul 88 12:46:20 GMT Article-I.D.: westmark.239 References: <407880.880706.KFL@AI.AI.MIT.EDU> <2799@ttrdc.UUCP> Organization: Westmark, Inc., Warren, NJ, USA Lines: 29 In article <2799@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > In article <407880.880706.KFL@AI.AI.MIT.EDU>, KFL@AI.AI.MIT.EDU ("Keith F. Lynch") writes: > # > From: "Benjamin I. Goldfarb"> # > # > OH YEAH? More likely the "UUUUUUUUUUU" was an erroneously > # > initiated test mode in the modem in question. Racal-Vadics are > # > notorious for this ... The standard data-transfer mode for an AT&T 212-compatible 1200 bps full-duplex modem calls for scrambling (by the sending modem) and unscrambling (by the receiving modem) to prevent long strings of identical bits from being sent over the communication line. The scrambler exclusive-or's the data bit-stream with UUUUU (actually, alternating 1 and 0 bits). This is helpful in that during idle time (between characters, for example) the modems get to re-synchronize by identifying the 0 to 1 or the 1 to 0 transitions. If you send a _very_long_ string of UUUUU or ***** in your data, you may defeat the purpose of the scrambling circuits, and cause the modems to lose sync with each other. The result could then be that during subsequent idle time, you will see the behaviour you've described. The other possibility is that you've gotten the modem into self-test mode. -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave