chris@mimsy.UUCP (Chris Torek) (02/02/88)
In article <3249@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >WARNING: Ultrix UUCP translates ='s in the "phone" number to commas, >apparently as an attempt to provide a dialer independent "pause" >capability. (And companies wonder why we insist on source for their `improved' systems!) >BTW, anybody have any ideas on what's a good cheap interface to support >the Trailblazer on a Vax? The Able DH/DM, while old, works fine. >The DMF32 has a little baby FIFO .... I wonder if there's any legit >way to enable the "hardware" X-on/X-off support on the DMF32? Beware; some clones (Emulex CS21/F, I think), and perhaps even DEC DMFs (I noted anomalous behaviour when I tried it), had bugs in the hardware flow control. Nobody noticed until VMS V4.0, when DEC first started to use the feature. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jerry@oliveb.olivetti.com (Jerry Aguirre) (02/11/88)
In article <10433@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <3249@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>BTW, anybody have any ideas on what's a good cheap interface to support >>the Trailblazer on a Vax? > >The Able DH/DM, while old, works fine. > >>The DMF32 has a little baby FIFO .... I wonder if there's any legit >>way to enable the "hardware" X-on/X-off support on the DMF32? > >Beware; some clones (Emulex CS21/F, I think), and perhaps even DEC DMFs >(I noted anomalous behaviour when I tried it), had bugs in the hardware >flow control. Nobody noticed until VMS V4.0, when DEC first started to >use the feature. I have had lots of problems trying to run 19200 to the Telebit with an Emulex DH/DM interface. The Emulex drops characters even on such short sequences as "OK". Needless to say this makes it hard to dial successfully, much less recognize the login prompt from the other system. I even tried setting S60=3 in the hope that two stop bits would slow the character arrival enough but there wasn't any noticable improvement. However the Telebit modem doesn't seem to handle 19200 very well either. First is the already mentioned problem of getting it to auto-baud reliably at 19200. Then it will refuse to dial if I send it the ATDT sequence at full speed. It just sits there. Even when I "tip" to the modem and type the ATDT sequence slowly it will suddenly type "RNG" or CNNT in the middle of my typing. Very strange. Jerry Aguirre
grr@cbmvax.UUCP (George Robbins) (02/12/88)
In article <14856@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: > > However the Telebit modem doesn't seem to handle 19200 very well either. > First is the already mentioned problem of getting it to auto-baud > reliably at 19200. Then it will refuse to dial if I send it the ATDT > sequence at full speed. It just sits there. Even when I "tip" to the > modem and type the ATDT sequence slowly it will suddenly type "RNG" or > CNNT in the middle of my typing. Very strange. > Jerry Aguirre Sounds like you're accessing the modem at the same time uucp or some other agency is. Seeing missing characters is often a sign of this. Especially if you start getting result codes when you aren't doing anything to deserve them. Or perhaps it's an incomming call? I've seen the "ignored" ATDT sequences, but I think this is just a sign of failure to auto-baud. One person represented that once the modem started to echo you knew it had auto-bauded, unfortunatly I run mine with echo disabled. Dropping DTR (or perhaps sending a break) then sending some A's or AT<cr>'s with delays between them seems to work, however it doesn't seem to work every time with only one extra AT... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
dave@onfcanim.UUCP (Dave Martindale) (02/15/88)
I've written a Telebit driver for 4.3BSD uucico. After opening the line,
it does:
for (i = 3; i > 0; i--) {
sendthem("A\\dA\\dA\\dA\\dT", dh);
if (expect("OK\r\n", dh) == 0)
break;
}
The string originally contained only three A's, and would sometimes fail
to autobaud the modem the first try, working on the second. After I added
the fourth A, I've never seen this fail (but I have no 300-bps connections,
just 1200, 2400, and PEP).
Once the loop above has received the OK that positively acknowledges that
the modem is listening, configuration and dialing commands sent at 19200
work fine.jeff@tc.fluke.COM (Jeff Stearns) (02/20/88)
In article <3313@cbmvax.UUCP> George Robbins writes: > In article <14856@oliveb.olivetti.com> Jerry Aguirre writes: > > > > However the Telebit modem doesn't seem to handle 19200 very well either. > > First is the already mentioned problem of getting it to auto-baud > > reliably at 19200. Then it will refuse to dial if I send it the ATDT > > sequence at full speed. It just sits there. Even when I "tip" to the > > modem and type the ATDT sequence slowly it will suddenly type "RNG" or > > CNNT in the middle of my typing. Very strange. > > Jerry Aguirre > > Sounds like you're accessing the modem at the same time uucp or some other > agency is. Seeing missing characters is often a sign of this. Especially > if you start getting result codes when you aren't doing anything to deserve > them. Or perhaps it's an incomming call? > > I've seen the "ignored" ATDT sequences, but I think this is just a sign of > failure to auto-baud. One person represented that once the modem started > to echo you knew it had auto-bauded, unfortunatly I run mine with echo > disabled. > > Dropping DTR (or perhaps sending a break) then sending some A's or AT<cr>'s > with delays between them seems to work, however it doesn't seem to work > every time with only one extra AT... Allow me to confirm Jerry's experience, and provide some further information on this phenomenon. Our Trailblazers (rev BA3.01) are attached to a machine which is dedicated to uucp; they are never used for any other purpose. They run at a fixed interface speed of 19200 baud, so autobauding is not an issue. It is unlikely that some other process is competing with uucico, since the lines are opened with exclusive access. And there is a pattern to the problem. I instrumented our uucico to log everything that it reads from the Trailblazer except for the pkxxx() data. This includes command responses, login prompts, echoed characters from the remote host, etc. Inspection of the log shows that the spurious and garbled data is always a Trailblazer command response. Once a connection is established, the data flows fine. The Trailblazer does a couple of undesired things. It sometimes emits fragments of command responses, as Jerry described above. It's schizophrenic about the parity bit in its responses. And sometimes it just wedges up and refuses to respond to any commands, or to toggling DTR. The blazer usually sets the parity bit of the first byte of its response to a dial command, as in: \215\012\015\012RRING\015\012 But here's one from this morning. Watch the parity bit here: \215\012\215\012N\317\240CARR\311ER\215\012 If you mask off the parity bit, you'll get the more readable: NO CARRIER After failed calls like this, it's not too unusual to find the modem a bit confused. In this case, dropping DTR and sending an "ATZ" prompted it to respond with "ERROR" instead of the customary "OK". Another toggling of DTR seemed to clear it this time. After other failed dial calls, I've received fragments of other messages. Bits of "NO CARRIER" are popular, as are pieces of "FAILED CALL". This may be related to a peskier problem wherein our Trailblazers simply wedge up while off hook. Uucico is helpless in this situation; we are unable to hangup the call without cycling the power. (We're going to be paying for several multi-hour long-distance calls this month. This could prove to be a costly habit.) I'd like to share information and workarounds with anybody else who has also experienced these problems. So far, my bag-of-tricks is somewhat empty. -- Jeff Stearns Domain: jeff@tc.fluke.COM Voice: +1 206 356 5064 UUCP: {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,sun}!fluke!jeff Snail: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206
wayne@teemc.UUCP (//ichael R. //ayne) (02/22/88)
In article <2929@fluke.COM> jeff@tc.fluke.COM (Jeff Stearns) writes: > >I'd like to share information and workarounds with anybody else who has also >experienced these problems. So far, my bag-of-tricks is somewhat empty. I have not had a chance to call Telebit on this one yet but will share it with the net. I use a Trailblazer on one of my inbound lines. It is configured to reset to EEPROM on losing DTR. Much of the time, it works OK but at least twice now it has gone into "strange mode". In this mode, the settings listed by ATN? do not correspond to what the modem is acutally doing. The first time, the speaker would come on every time the modem answered the phone even though M=0. I manually reset DTR a few times, check the settings and the problem persisted. Eventually, the modem would not answer the phone and I power-cycled it, after which everything seemed normal again. The second time was not so benign. The modem would speak ONLY the PEP tones although it is configured to do slow tones first and PEP last. Again, resetting DTR a few times made no change and I had to power cycle the modem. I am not pleased and begin to suspect that there is a "phantom" copy of the settings that is hanging around even after DTR is dropped. Has anyone else experienced this problem? I know of no workaround since that line is in almost constant use and it is not convenient to power-cycle it regularly. /\/\ \/\/ -- Michael R. Wayne --- TMC & Associates --- wayne@teemc.uucp INTERNET: wayne%teemc.uucp@umix.cc.umich.edu uunet!umix!teemc!wayne
grr@cbmvax.UUCP (George Robbins) (02/23/88)
In article <341@teemc.UUCP> wayne@teemc.UUCP (/\/\ichael R. \/\/ayne) writes: > > I have not had a chance to call Telebit on this one yet but will > share it with the net. I use a Trailblazer on one of my inbound lines. > It is configured to reset to EEPROM on losing DTR. Much of the time, it > works OK but at least twice now it has gone into "strange mode". ... assorted problems > ... I am not pleased and begin to suspect that there is a "phantom" copy > of the settings that is hanging around even after DTR is dropped. Has anyone > else experienced this problem? I know of no workaround since that line is in > almost constant use and it is not convenient to power-cycle it regularly. Hmmm, I've had some problems where the modem would answer the phone and just play dead! No aswer tones of any sort. Also one occurance of acute catatonia that could only be reset by a gentle prod with the paper-clip. I sort of suspect some degree of reseting to factory parameters, which would cause the modem to ingore DTR and perhaps force a 9600 buad interface rate. Still, I have just (I HOPE!) stabilized my operating environment and will see what kind of wedge factor there is when everything on my side is working reliably. TELEBIT: The UUCP community would really appreciate a jumper that would force a "power on" reset when DTR goes away. Our modems are not sitting at hand, they are off in the computer room and it is a real pain to have to go flip the on/off switch when they have decided to go to lunch. It is no big deal for the typical usenet site to have to open the case to change a jumper (like the transmit level resistor). Give me 1 jumper that forces power up reset on dropping DTR. Give me 1 jumper that write protects the EEPROM. The automated telecom users of the world will bless you!!! -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)