(Long) Why can't I get PCOMM to work with my Trailblazer?

Andy Pitts andy at rbdc.UUCP
Fri Sep 16 18:41:05 AEST 1988


In article <456 at kosman.UUCP> kevin at kosman.UUCP (Root) writes:
>
>All the rest of what Andy wrote made good sense, and some of it made me blush.
>Here, however, he falls prey to the RTFM trap: he believed what he read.
>In a long debugging session with Telebit, we found that in certain config-
>urations, S92 causes the firmware to go south on outgoing calls.
>[...]

Gee, I didn't know about that one.  Thanks, it could explain the occasional
bug I am seeing.  I'm sorry if I made you blush, it was not my intent.

While we are on the subject of hidden bugs, maybe we should post these little
pieces of information when we find them.  It may help someone.  On that theory
here are a few more.

According to Telebit, if S58 is set to something other than 0 when making
using uucp 'g' protocol spoofing, the modems attempt to flow control can
mess things up.  It usually just cuts throughput but can sometimes cause the
transfer to fail.  I have tried sending files using uucp with S58 set to
0 and 2 and found that there is about a 5 - 10% improvement with S58=0.

The following is unconfirmed by Telebit.  I posted it to comp.dcom.modems
a few days ago and should have cross posted it here for those who don't
get comp.dcom.modems.  I'll apologize in advance if you have seen it before.

There appears to be a bug in the firmware when S52=2 (restore EEROM parameters
when DTR drops).  I have talked with Telebit about this, but they have never
let me know if they confirmed this.  If the Telebit is connected to a distant
modem and the distant modem drops carrier there appears to be a period of time
following loss of carrier that the Telebit will ignore DTR.  This means that if
you establish a PEP connection with another Telebit by temporarily setting
S50=255 as part of the dialing sequence, and the distant system drops carries,
the Telebit will not be reset when your system drops DTR immediately after DCD
drops.  This leaves S50=255 and the Telebit will continue to answer with PEP
tones until the modem is powered off or DTR is forced high and dropped again.
The problem could be duplicated on my system as follows:

Use cu to call a distant Telebut in PEP mode (cu sets S50=255 in its dialing
sequence).  Login to the other system and type ^D forcing the other system
to drop carrier.  My system sees DCD drop and drops DTR.  The Telebit will
not be reset.

Use cu as above and login.  Now drop the connection by exiting cu (~.) 
forcing my system to drop DTR while the connection is up.  The Telebit
will be reset.

This problem also showed up with uucp.  Frequently the modem would not
be reset after a uucp call to another Telebit because the distant uucico
would drop carrier first.
-- 
Andy Pitts andy at rbdc.UUCP  : "The giant Gorf was hit in  one eye  by a stone,
bakerst!rbdc!andy          : and that eye  turned  inward  so  that it looked
kd4nc!gladys!rbdc!andy     : into his mind and he died of what he saw there."
pacbell!gladys!rbdc!andy   :   --_The Forgotten Beast of Eld_, McKillip--



More information about the Unix-pc.general mailing list