xeee02@mixcom.COM (Dean A. Roth) (03/05/91)
I have tried using a PPI 9600SA to answer calls
on a UNIX system using a Digiboard multiport
serial card. The 9600SA will usually connect with
the caller, then abruptly drop the call (hang up).
Recalling will eventually result in a connect
that is held (and a login).
I have three other modem brands (total of 5 modems)
attached to the machine.
All others work fine. Only the 9600SA exhibits this
behavior. The Telebit, USR and Cardinal modems work fine.
Is anyone else using a 9600SA to answer calls on
a system using a multiport serial card? What is
different about the 9600SA? (Yes, I've checked the
configuration, talked to PPI tech support, and nothing
has been solved.)
I am using this configuration:
N1 S36=7 S37=9 &C1 &D3 S0=1 S2=128 E0 Q1 L0 &K3 &Q5
And have ROM 1.29. Any ideas?
--
Dean Roth deanr@mixcom.comroot@crash.cts.com (Bill Blue) (03/11/91)
In <333@mixcom.COM> xeee02@mixcom.COM (Dean A. Roth) writes: }I have tried using a PPI 9600SA to answer calls }on a UNIX system using a Digiboard multiport }serial card. The 9600SA will usually connect with }the caller, then abruptly drop the call (hang up). }Recalling will eventually result in a connect }that is held (and a login). } }I have three other modem brands (total of 5 modems) }attached to the machine. }All others work fine. Only the 9600SA exhibits this }behavior. The Telebit, USR and Cardinal modems work fine. ... }And have ROM 1.29. Any ideas? Yes, get another 9600SA. Those modems have a horrible problem with quality control and component failure. If you can get a good one, they work well, but that's not as easy as it may sound. Two of the lines here on crash have 9600SA's on them. So far, to get two that work consistently, I have gone through a total of seven (7!) modems. Everything from failing to answer, failing to connect in V32 modem, static on the line when the modem picks up, long pauses during MNP, etc., etc. One bizarre thing after another. Right now, I have two that do pretty well (and have ROM version 1.26 in them). For how long is another story. Try another one -- chances are your symptoms will go away, or at least change. --Bill
squishy@casbah.acns.nwu.edu (Shishin Yamada) (03/12/91)
Recently, I called PPI tech to inquire about the new ROMS. I
suppose I have been lucky in that most of my 9600 calls are local to my
university's mainframes, and my PPI 9600SA has worked just fine.
The guy only asked what ROM version I had (1.18 at the time), and
he promptly asked if I'd like the new ROMS. I got the 1.29 revision and am
curious as to the changes (all I remeber was not to get the 1.00 and make
sure I had 1.18 when I bought it in early January). Well, the new ROMS came
in and work fine. I guess I am lucky to be an electrical engineer, as it
came with absolutely *NO* instructions (I happen to have all the
necessaried for static chip handling, chip extractors, etc). The new ROMS
work fine, and seem to do a better job of recapturing a lost carrrier
(Sometimes our campus lines are static prone during storms).
I would like to just add my $0.02 worth and say the PPI seems like
a fine modem. It is arguably VERY noisy electrically, but I am used to that,
since I work under 5,000 watts of WNUR college radio station (can be heard
on Walkmans everywhere on campus; even those without radios) on the
building next door. However, it has no problem with the radio that creeps
onto the line.
I would like to know why PPI didn't fully test/de-bug their
software before it's release? Was it an administrative decision? Were they
hand-assembling the code (ie. New modem micro-controller)? I would think it
would tend to be coslty for them, and I appreciate their customer support.
I just don't see why it was done, and what exactly are the changes. Also,
if someone from PPI reads this, it would be good to stick instructions to
those who aren't technically inclined.
=====================================================
Shishin "Squish" Yamada |\/\/\/|
squishy@casbah.acns.nwu.edu /---------\ | |
Northwestern University | Yo | (o)(o) |
Electrical Engineering | Dudes! \ ( < )
Class of 1991 \__________\ |___/ |
\ |
"Life sucks, but Death swallows!" / \
/______\
=====================================================scotty@l5comp.wa.com (Scott Turner) (03/13/91)
In article <333@mixcom.COM> xeee02@mixcom.COM (Dean A. Roth) writes: > >I have tried using a PPI 9600SA to answer calls >on a UNIX system using a Digiboard multiport >serial card. The 9600SA will usually connect with >the caller, then abruptly drop the call (hang up). Oh boy do I recognize this problem! First let me state that if Intel/AT&T knew how to write a Streams based serial device driver I'd be a happy camper right now with the 9600SA, so I don't really blame PPI for my troubles in setting up the 9600SA. Although PPI COULD have made my life easier... The problem: The Carrier Detect line goes high BEFORE the modem is ready for you to talk to it. It goes like this, modem raises CD and bang yer getty runs out and slaps a login on the modem and it hangs up. Under SYSV/386 R4V2 I fixed this problem by switching back to the stock serial driver and then using ttymon which can be told to wait a programmable number of <CR>'s before sending out the login prompt. But alas there is one more fix required, the modem sends out "RING" messages and the "CONNECT" message. Echoing these back to the modem anytime before the final <CR> on "CONNECT" causes the modem to hangup as well. So I had to turn off all the echo's in /etc/ttydef as well. On pre-SYSVR4 systems I'd suggest uugetty since it waits for one <CR> before sending out the login: prompt. Set the modem to only send "CONNECT" and no "RING"'s (X0???) and you may just slide under the wire. You'll still need to turn off all the echo's in /etc/gettydefs on the first half of all the speeds. Leave the echo's in on the second half of the gettydef entries or your user's won't be able to see their user id's as they type them in. I haven't bitched to PPI since switching back to the brain dead serial device driver from good ol' FAS 2.08 has had me up late hours. AT&T still won't let cu do anything but ASCII transfers, hey, we've got uucp for binary transfers right? (The best of BSD? Where's tip guys?) And nothing on this planet except cu and uucico seem to know how to open /dev/tty01h and talk to the modem (and it took 3 MONTHS to get Intel to tell me how to get cu and uucico to do THAT!) You can't just open( "/dev/tty01h", O_RDWR) and have a talk with a modem, sigh. Trying to cobble together a terminal program with incomplete dox (where oh where is termio(7)?) has me in no mood to talk to low-level tech weenies at PPI, I'm afraid they'd tell me they're terribly un-able to help me and I KNOW I'd flip out. Yep, just plain loose it all over that tech weenie. All Intel/AT&T's fault of course, but PPI wouldn't understand that. :) Please let me know if you have any luck trying to explain this CD thingy to PPI. But I can state that once ttymon is setup properly I get 100% reliable auto answer operation. So it isn't that the modem is in-capable of being used in this fashion on a unix box, but unless PPI fixes the CD problem your mileage under anything but SYSV/386 R4V2 may vary (and I wouldn't recommend switching to SYSV/386 R4V2 to my worst enemy, hell I don't think switching to SYSV/386 R4V3 would be all that swift either csh might not crash and log out remote users on the modem but the serial driver is still going to be B.D.O.A...) Scott Turner scotty@l5comp.wa.com