aburt@mnemosyne.cs.du.edu (Andrew Burt) (12/09/90)
Well, I thought I'd add my experiences (so far) with a PPI 9600 bps modem.
Having read the earlier posting about problems with slower speeds, I
was very curious to try this out... and found it to be true. I also spent
some time with PPI tech. support and think the problems will be solved soon.
Without changing any settings, the modem has had major problems with (non-mnp)
2400 or 1200 bps modems. MNP modems or 9600 bps -- no problems.
The problems with 2400/1200 have been varied. Starting with not connecting.
It'll just hang. Tech. support says it can take up to 45 seconds, but a
few times it just never happened. When it has connected, the negotiations
for protocol, compression, etc., have greatly disturbed the system at the
other end. All the above problems were solved by using AT&Q0 to force the
modem to make a straight async connection, no frills.
So, looking good... except that the connections seem *awfully* noisy.
Like, a steady trickle of garbage data, one or two bytes per second. This
never happens with any of the other 2400/1200 modems, and happens *always*
with the PPI. At this point I called tech support.
I found them to be very willing to help. He (Phil) didn't insult my
intelligence with "say, moron, is the modem plugged in?" type
questions. I felt that if I really didn't know anything, they'd be very
helpful, but since I did, they retargeted the level of help. So we spent
a couple hours (at their expense) calling modems back and forth.
It finally turned out we could reproduce the problem when he changed his
firmware to the same rev. as mine (1.05). They're up to 1.18. At 1.18,
no problem. (The only "problem" that still existed was that withOUT at&q0,
the feature negotiations confused our autobauding getty; understandable.
With at&q0, of course, even this went away. I can live with that.)
Apparently this noise problem only shows up on mediocre lines, since
when we connected directly we didn't have any problems; it was only connecting
to the campus phone system (historically noisy, though recently not much
problem) that I had major problems.
So, the problems appear to lie in their firmware. Apparently they go
through revs of firmware quickly, upping the # every time a bug is discovered
during testing (they didn't release 1.06...1.1?, they were all internal).
1.18 still hasn't been released. But will be soon.
I volunteered to be a guinea pig for 1.18, so I'll repost after a while.
Another note: The power switch is a contact switch, thus for BBSs, not
much good (it comes up "off" after being plugged in, or after a power outage).
Phil reports that the next rev. of the board itself will have a jumper
for initial state: power on/off. Due out in January, he said.
My hunch is that they wanted market share, and went to market a wee bit
early; classical management "mistake" (or is it really a mistake in the
long run?). But that's just my gut feeling.
Despite the 1.05 problems, I'm very positive about this unit. I like the
price, the 5 year warranty, and of course the v.32/v.42bis/etc. I felt their
tech support was very... supportive. After recent bouts with Wordperfect
(a couple antagonistic "you don't know what you're talking about" types) and
Borland (very unhelpful -- said I'd have to wait 4 months before they'd
even LOOK AT a bug that was 100% provably their problem, and was delaying
release of a product; and they wouldn't even supply me with the code so
I could fix it!) -- after that & a couple other minor nuisances with
assorted tech support, I'm really happy with PPI. Gee, tech support that
actually tries to help... now there's a novel idea!
Anyway, I would recommend the modem, though I would wait a leeetle while
for them to get the firmware solidified. Or buy now & swap chips.
--
Andrew Burt uunet!isis!aburt
or aburt@du.edu
"Kwyjibo on the loose!"sysop@mixcom.UUCP (System Operator) (12/10/90)
In article <1990Dec9.054531.20417@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (Andrew Burt) writes: > [deleted] > >Having read the earlier posting about problems with slower speeds, I >was very curious to try this out... and found it to be true. I also spent >some time with PPI tech. support and think the problems will be solved soon. > >Without changing any settings, the modem has had major problems with (non-mnp) >2400 or 1200 bps modems. MNP modems or 9600 bps -- no problems. > Any recent reader of this group has probably read my 9600SA reports. There was one test I had not tried until moments ago. I disabled error correction in the 9600SA, then called it using a non-error correcting 2400. Most of the connect-disconnect problems went away! Reenable EC in the 9600SA, and the connect-disconnect problem returns if the calling modem is not using error correction. (The disconnect happens immediately after the modem connect. This is not caused by a timeout.) Conclusion: a firmware bug in the 9600SA. I will ask PPI for the revision 1.18 ROM that has been reported in other messages. Standby for the further adventures of MODEM MANIA! Dean Roth -- Milwaukee Information eXchange (MIX), public access *NIX/Usenet MIX Communications, P.O. Box 17166, Milwaukee, WI 53217
blarson@blars (12/10/90)
In article <1990Dec9.054531.20417@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (Andrew Burt) writes: >(The only "problem" that still existed was that withOUT at&q0, >the feature negotiations confused our autobauding getty; understandable. The garbage characters MNP sends when negociating are known to cause problems on some non-mnp modems on some systems. The only solution is to turn of MNP before calling such a system. USC's v.22bis (2400 baud) modem pool is one example of a place that cannot be called successfully without diabling MNP. (The garbage fools the autobaud on the data PBX which eventually times out and drops DTR.) Fortunatly, the V.32 modem pool does support MNP most of the time. V.42 was designed to make this less likely to happen. Since all V.42 modems I use fall back to MNP if V.42 negociation is unsucessful, this attempt doesn't make any differnce in practice. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.