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.

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

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

You reckon this happens on Rockwell-based modems?

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?

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

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.  

???

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.

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

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?

V32bis.

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.

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

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 19200 
DH> to my USR regular as clockwork for some time.  Setup or hardware.  What did 
DH> that site get while you had a Thunder online?  (I'd suspect excellent..)

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

PE> 7. USR to USR connect failed due to a retrain failure.  Also,
PE> USR to USR is showing 21600/2400 as the connect rate.

DH> This one is being chased.  It's not the USR, it's telstra.  Reasonably 

BTW, I dial you using Optus, with "145602-xxxxxxx"

DH> recent, and it's the same thing that used to plague us during the early VFC 
DH> days when "sudden disconnect" was the order of the day. 
Wildly split baud 
DH> rates are the hallmark of the fault at the moment.  You'll find this 
DH> happening to top quality lines - good connect, transfer rolling at high 
DH> speed - sudden halt, frantic attempts to retrain, all fail, exit with one 
DH> direction only affected, and it at some ridiculously low speed as the last 
DH> attempted.

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

PE> 8. Failed to connect to Hayes modem at all.  Very weird sounds
PE> coming out.  No problem when I was using a Spirit.  This actually
PE> happened with an older revision of the ROMs, and cannot confirm
PE> at this stage whether it still exists because the modem was 
PE> taken offline so that I could connect.

DH> Unknown situation.  I connect Hayes/USR nearly every day, both VFC and V34 
DH> models.  Possibly setup, possibly defective modem, possibly very early 
DH> Rockwell set with major bugs still present.   And possibly a wierd bug 
DH> still in the USR - hard to tell without definitive tests.

Even harder to tell with the modem no longer online.  :-)

PE> 9. A Netcomm modem (PCMCIA or something) gets connects of 1200, 
PE> 2400, 14400 and 28800 with me.  This also happened with the
PE> older ROMs, and the caller has not called since I changed ROMs,
PE> so cannot confirm the continued existance of this problem.

DH> ????

You need the exact brand of the modem?  I'll have to ask.  
BFN.  Paul.
@EOT:

---