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