PE>> 1. After receiving an "AT" command at a particular baud rate,
PE>> the modem does not adjust to that baud rate, and instead stays
PE>> at the rate at the time of last "AT&W".

DH>> That's common to nearly every high performance modem I know of nowdays.  
DH>> Any change in the locked baud rate to the UART requires a fresh
AT&W.  

DH>> Complicated by the fact that there are circumstances where the USR isn't 
DH>> too happy to accept a ATZ.

PE> I'm not sure if I described it satisfactorily...

PE> The last &W was done at 57600.  I then go and use 38400.  I type
PE> in ATZ.  It auto-detects the AT and sends the response, "OK" back
PE> to me at 38400.  I then proceeds to send the "RING" word to me
PE> at 57600.  It's either designed wrong, or it's a bug.  There is
PE> absolutely no sense in using two different baud rates to my session.
PE> Didn't happen with my Spirit II either.

DH> This is as dangerous as walking on razor blades.  It's held together by the 
DH> dynamic ATZ that it may or may not see in time.  If the RING comes in 
DH> first, you get rubbish.

DH> It's not USR's fault - it's inherent in the situation.  After a reset, the 
DH> modem has no record of the DTE baud rate - but it can, and does, remember 
DH> the last AT&W baud rate, that's permanent.

PE> You reckon this happens on Rockwell-based modems?

DH> Yep.  Including the Spirit.  Do a power up, say nothing to it, and send in 
DH> a ring.  Guaranteed, "RING" will come out at the speed of
the last AT&W.

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

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

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 Bink 
DH> 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?

Yes they do.  Every single one 26400/26400.  Never skips a beat
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 conservative 
DH> side.  Follow through with a final polish on the desirable parameters for 
DH> 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 that 
DH>> reliable.  If you watch it, eventually you'll see it -not- train up - the 
DH>> 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.

The V32bis Supra modem is showing a retrain.  It (the Supra) is 
not following the V34 spec.  It is presumably following the 
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.

Indeed.  However, I overstated the dropouts, only 30% are dropping
out, not 50%.  I think he told me 50% originally, but that was
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".

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.

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

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).

I've asked him to call you with his modem, but he's been rather
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 it, 
DH> I got exactly the same thing with a pair of Hayes 28800 Optima vFC's.

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

---