autobauding a TrailBlazer on a UNIX PC

[Shane P. McCarron]

In article <1030 at astroatc.UUCP> mag at astroatc.UUCP (Michael A. Goldsmith) writes:
>It is not necesasary to auto-baud at all with the Trailblazer.
>You can set a register (S66=1, I believe.  My manual is at home.)
>that locks the serial line betweeen the modem and the 3B1 at
>9600 or whatever you wish to use.  When a call comes in, the modem
>negotiates baud rates with the calling modem and then communicates
>with the caller at that rate.  The serial line remains at the
>locked-in rate.

This is true, but...  If someone dials in at a lower speed (for
instance, 1200 baud), you will have a problem.  Let's assume that they
dial in on a brain dead machine like the 3B1 (I have one, I know).
The cu on the 3B1 cannot update the screen as fast as the data is
coming in, so the ph0/ph1 driver attempts to send an X/Off to the
remote machine with the trailblazer on it.  The remote machine is (of 
course) not set up to use software flow control, since that really wouldn't 
work well for UUCP.  Moreover, the remote trailblazer doesn't handle flow 
control from the calling machine anyway, and it continues to spit out data
even though the calling machine can't take it.  This causes a lot of
garbage to appear on the screen, but nothing readable.

>The same thing happens on an outgoing call.  Thus, you can set up
>your /usr/lib/uucp/L* files to place all calls at 9600 (or whatever)
>and uucp will be unaware that the actual communication is taking
>place at a lower rate.

This is also true, but...  If the remote machine is one which spits
out its PEP tones last (e.g. uunet, most machines in MN, etc...) you
need to send a special initialization sequence (S50=255) before
dialing.  That is difficult to do if you are using the (again) brain
dead dialer on the 3B1.  It doesn't use the device type code (ACU,
DIR, whatever), but rather the speed and ttyline, to decide which 
definition in the L-devices file to use.  That's great, but if you want 
to send special sequences when dialing out to certain sites, and they 
are all at the same baud rate, you are screwed.

Of course, these problems may be unique to the 3B1 - I have certainly
never encounted this particular form of brain damage anywhere else,
but that doesn't mean it doesn't exist.  If you do lock the speed,
lock it at 19200 - you will get much better throughput.  Also, define
calling devices like TELEBIT and TELEBITFAST.  The TELEBITFAST device
can send the additional codes needed to make the modem communicate in
PEP mode.

Oh!  One other thing - Be sure to set S55 to 3 on dial-in modems.  It
enables the machine that is dialing in to send a +++ and not take your
modem off-line.  In my dialing sequence to trailblazers that I know
are set correctly, I have a sequence like:

\d\d\d+++\d\d OK ats70?\r 18031 ato\r "" \n "" \d\d\d\d\n ogin:

This assures me that (at least the initial) connection is as good as
it can be.  If you aren't getting full throughput, what is the point
of talking to a trailblazer?  Call it back, and the line may improve.

Oops...  Another thing :-)  If you are using different dialing
sequences when calling another trailblazer, you should be sure to set
the flag that tells the modem to reset when DTR is dropped (S52=2).
This way it will go back to the saved settings after the call is
complete.

>BTW, you can also chose (check the manual, I don't remember which register)
>whether to use XON/XOFF or RS-232 handshake signals for flow control.

S58
-- 
Shane P. McCarron			UUCP: ahby at bungia.mn.org
Systems Analyst				ATT: +1 612 224-9239