I have a model 100 also (*WONDERFUL* little computer), and noticed the same
thing happening when I logged in to my Unix box. I finally traced it down
to the following: When the model 100 recieves the garbage, it's VERY slow
LCD logic cannot keep up with it, and issues a <CTRL_S>, and then a <CTRL-Q>,
which the autobaud routines see, and step down to 300 baud. This does not
seem to be a real problem, but if you want to eliminate it you can turn off
the handshaking (it's not really needed at 300 baud), and it goes away.
--
----------------
Brad Silva "Seeker"
...!ptfsa!gilbbs!altunv!brad
No disclaimer
No cute joke
No nothin'
.... Yet!
---------------
I believe this would be due to the Model 100 sending out XON/XOFF
characters on it's own, then the host detects the framing error, etc..
The LCD screen on the M100 has an overall average response of about 600
baud, but what takes the most time is scrolling there, and it does send
out a LOT of xon/xoff's to the host during normal communications. The
600 baud avg. LCD rate means that if you ever use a 1200 or 2400 bps
modem on the M100, your avg. receive speed for screen text display will
still be only 600 bps, although file xfer speed (like via xmodem) will
go faster.
Getty listens to the digital portion of the line, not the analog, and can't
hear the tones. Why does the fact that the MODEM can recognize the speed
make those messages ok?
Yes, having the modem tell the DTE the speed by sending a message at that
speed isn't my idea of something wonderful, but that doesn't make the message
go away. And the impact on autobauding machines depends on the autobaud
algorithm ... if it wants to see a carriage return, sooner or later, at
a recognizable speed, then the modem I referenced will make it happy. If
it wants to only see data from the distant end, and of a particular type,
then they are incompatible with that modem.
Some modems use an RS-232 pin to indicate which of two "speeds" (modem
protocols) is being used. My Racal-Vadic VA3451 turns pin 12 ON when
a 1200 baud carrier is detected, and OFF if 103 detected (R-V calls
this pin CI - Speed Indication per EIA, while a summary card calls it
Secondary DCD). The tty device driver would obviously have to change
speeds if CI was detected.
Also, some modems do speed conversion. The RS-232 interface runs at a fixed
(high) baud rate with flow control.
--
Scot E. Wilcoxon Minn Ed Comp Corp {quest,dicome,meccts}!mecc!sewilco
45 03 N 93 08 W (612)481-3507 ihnp4!meccts!mecc!sewilco
Laws are society's common sense, recorded for the stupid.
The alert question everything, and most laws are obvious to them.
> Many of those smart modems send a string saying they've connected,
> and at what speed. ...
An awful lot of people have suggested this one. Give me credit for a bit
of intelligence, folks; our modems are (*flame on*) professional quality
equipment, not these dimwit-friendly junkboxes (*flame off*) and don't
do such stupid things. When they connect, they raise Carrier Detect,
period.
Martin Minow suggested that badly-balanced lines can echo to the host to
some degree; apparently DEC has patented the use of this phenomenon for
testing some types of equipment!
Several people suggested that the modem's speed-sensing transitions, or
the beginning of carrier from the originating end, might be seen by the
host as a framing error. Apparently old 300-baud modems in particular
often are sloppy about oscillator startup. This sounded like a possibility,
although the Model 100 modem is relatively new and I would be a bit surprised
if the relatively fancy modems on our machine passed startup transients on
to the host.
Finally, as you've probably all seen, Brad Silva has definitely pinned the
problem down to the Model 100's quite slow screen-handling doing a lot of
XON/XOFF handshaking, which of course shows up as framing errors until the
host finds the right speed.
I believe Ron's point was that the signalling tones for 1200 and 2400 imply
a unique baud rate, so it is reasonable for the modem to tell the host about
it (although one may debate the wisdom of this particular method). But in
103 mode, the baud rate is *not* uniquely known -- it could be 300, 150,
134.5, 110, or several other still less likely values, all of which use the
103 signalling tones. Admittedly nowadays 300 is by far the most probable
speed when you hear 103 tones, but it's not the only possibility.
Almost everybody - including myself - exceeds the RS-232C distance
specification of 50 feet (actually, the spec says 2500 pF of capacitance,
which usually equates to 50 feet of cable). Exceeding this specification
can be an invitation to spurious character echo, especially if "homemade"
cables are incorrectly wired. The most common wiring error that I have
seen involves the use of multi-conductor cable having wire in pairs; some
people think that TD (BA) and RD (BB) should be in the same pair - this is
the WORST thing that anyone can do, since these leads are hardly a balanced
pair! If you're going to use twisted pair cable, pair TD and RD each with
ground if there are enough conductors; if not, at least pair them with some
lead that is "static" in state - like DSR (CC) or DTR (CD). If you're really
determined to "push" a RS-232C line to a long length, the best way is to use
multi-conductor cable having individually shielded (i.e., coaxial) wires.
An even worse echo problem can result through the use of RS-422 as
a limited-distance modem. RS-422 lines should have a termination resistor.
Not all RS-422 interfaces have this resistor, because they assume that the
_other_ end will have the termination resistor. So, if you connect two
RS-422 devices together, and neither one provides the termination resistor -
chances are there will be trouble over any significant cable length.
==> Larry Lippman @ Recognition Research Corp., Clarence, New York
==> UUCP: {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry
==> VOICE: 716/688-1231 {hplabs|ihnp4|seismo|utzoo}!/
==> FAX: 716/741-9635 {G1,G2,G3} "Have you hugged your cat today?"