PE> You're not hearing me Dave.  I agree, SAY NOTHING TO THE SPIRIT
PE> and yes indeed, the RING will come out at the speed of the
PE> last AT&W.  NO PROBLEM.  However, SAY ANYTHING TO THE SPIRIT
PE> STARTING WITH AT, and suddenly any future RINGs will come out
PE> at the speed of the AT, NOT at the speed of the AT&W.

PE> With the USR on the other hand, even AFTER I have SAID SOMETHING
PE> STARTING WITH AT to the modem, the RINGS *still* come through
PE> at the baud rate of the AT&W, NOT at the speed of the AT command
PE> which I JUST SENT.

Ahah.  Ok - that's a marginal bug.  It should pick up any AT command and
shift, including the RING speed.  (Agree - it doesn't.)

DH>> "Power up" includes a glitch on the supply that didn't
reset the computer, 
DH>> at least now and then, on most modems I've seen.  The cyclic init that 
DH>> Bink does is a genius class idea, to handle a very necessary situation.

PE>>> 2. Regularly getting 26400 connects with a Netcomm instead of
PE>>> 28800.

DH>>> Such be life.  Is that line capable of 28800 with negligible errors?

PE>> He can connect to others at 28800.  I can connect to others at
PE>> 33600.  I would have expected at least one of his calls to get
PE>> through successfully at 28800.

DH>> So would I.  Do the final transfer bit rates still match 26400?

PE> Yes they do.  Every single one 26400/26400.  Never skips a beat
PE> in fact, every single one like that.

PE>>> 3. Modem is initiating a retrain straight after each connect,
PE>>> even with V32bis modems.  I would expect that the initial
PE>>> negotiation would have figured that out, no need for a retrain
PE>>> on every single bloody call.  Yet the ATI6 does not show that
PE>>> a retrain was requested.

DH>>> SOP.  

PE>> ???

DH>> "Standard Operating Procedure".  Works better.  Much. 
The handshake time 
DH>> is going on while the equalizer is settling, the exchange is still 
DH>> buggering about, and generally the worst of all possible worlds.  10 
DH>> seconds later is a lot more stable.  As near as I can see, what USR have 
DH>> done is to do a fast and rough approximate, and make it on the 
DH>> conservative side.  Follow through with a final polish on the desirable 
DH>> parameters for this call several seconds in.

DH>>> This is the major reason for success where other modems fail - the 
DH>>> USR is designed to connect VERY conservatively - then train up if 
DH>>> indications warrant. Training going on during connect phase isn't all 
DH>>> that reliable.  If you watch it, eventually you'll see it
-not- train up 
DH>>> - the line wasn't good enough.

PE>> So it trains up after every call by design?  Ok, then why doesn't
PE>> ATI6 show the retrain?

DH>> 'Cause it's not a genuine retrain, which would take extra time.  It's a 
DH>> forced "fall forward".  Don't know the V34 spec well
enough to hit the 
DH>> exact terminology.

PE> The V32bis Supra modem is showing a retrain.  It (the Supra) is 
PE> not following the V34 spec.  It is presumably following the 
PE> V32bis spec.  Does the V32bis spec include "fall forward"?

PE>>> 4. Having problems talking to a Supra modem, 50% dropouts where
PE>>> previously there were none (with a Spirit Thunder modem).

DH>>> Supra on v34 or VFC?

PE>> V32bis.

DH>> Bloody HELL.  That's a serious indication of drastic problems.  14400 
DH>> should get through almost a barbwire fence.

PE> Indeed.  However, I overstated the dropouts, only 30% are dropping
PE> out, not 50%.  I think he told me 50% originally, but that was
PE> only after the first day.

PE>>> 5. AT&F1 sets S56 equal to 16 instead of the default of 0 listed
PE>>> in the manual.

DH>>> Confirm.  There's a fair amount more of that as well.

PE>> Want to document some of them?  BTW, David Drummond says the
PE>> default on his is "definitely 0".

Mine is now too.  Changed over to the SDL0705 version yesterday.  Works
fine, and beats the -20 or worse dbm send level AustHell problem.

DH>> The word just coming through to me is to fall back to his SDL version.

DH>> I/D seems to be both supervisor and datapump dated 5 July, 1995.  To be 
DH>> advised, not tried here yet.  Watch this space.

PE> Ok, I have asked David to make his ROMs available, watch my
PE> space, might be here quicker!  :-)

If you haven't got it already, F/R of SDL0705.ZIP from 711/809 or 711/810.

PE>>> 6. A Spirit Thunder is getting connects with me at 2400 bps far
PE>>> more often than 19200.  1200 bps connects too.

DH>>> El yuck.  This -could- be the Spirit.  Your setup on your Thunder got 
DH>>> 19200 to my USR regular as clockwork for some time.  Setup
or hardware.  
DH>>> What did that site get while you had a Thunder online?  (I'd suspect 
DH>>> excellent..)

PE>> He got 14400 all the time when I had my Thunder online.  That
PE>> is because I had V32ter disabled on my Thunder (for incoming
PE>> calls).

PE> I've asked him to call you with his modem, but he's been rather
PE> slack to say the least.

PE>> How do you know it is Telstra, BTW?  The results of ATI6 (defying
PE>> the laws of physics) make it look like the USR is screwed.

DH>> It's not happening to just USR's.   The USR diagnostics are good
enough to 
DH>> rub your nose in it - but once knowing it was there and how to look for 
DH>> it, I got exactly the same thing with a pair of Hayes 28800 Optima vFC's.

PE> And did the Hayes modems report statistics that defied the laws
PE> of physics?  No matter WHAT happens on the phone lines, the USR
PE> has NO RIGHT to report statistics that defy the laws of physics.
PE> Even if my the line in is connected directly to 240V AC instead
PE> of the telephone line.  Hey, maybe that's what my problem is?
PE> :-)  BFN.  Paul.

Nah - you just FEEL like hooking up 240 volts to the #{at}{at}#{at} thing...:-)

 Dave Hatch

Dave

--- Msgedsq 3.20