PE> After receiving an "AT" command at a particular baud
PE> rate, the modem does not adjust to that baud rate, and
PE> instead stays 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.

 RS> I'm yet to be convinced it is actually all that common.

It's certainly common to every USR Courier for many years, but it's not
common to other brands, no.  This quite often comes up in the BINKLEY
conference, and the advice given is always the same.  According to the Bink
2.40 docs, there's also a register needs setting if you want to handle
locked computer-to-modem rates for /Arq calls, and floating rates, on lower
speeds, without /Arq - Binkley's 'Lockbaud /Arq' feature was specifically
developed to cater for this (and a similar feature found in Telebit PEP
modems).

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

Why would you want to?  Why not set it for the speed you'll be locking it
at all the time?  It's not 'wrong', because it's 'different' to other
modems.

 RS> The problem is MUCH worse the other way actually, if you dont remember
 RS> to do an &W at the new port speed you want to use you NEVER see the RING.

That's right, if you're changing your locked speed, you need to reinit the
modem (by typing AT in terminal mode), then storing the new speed, or so
the Binkley+USR gurus have been saying for years.  I believe the safe way
(to ensure keeping all current changes to AT&F) is:

ATZ
AT
AT&W

DH> It's not USR's fault - it's inherent in the situation.

 RS> I'm not convinced. All modern comms software does send an AT
 RS> command to the modem initially, and I think its mad to be
 RS> adopting that counter intuitive approach because of the remote
 RS> possibility that the AT command wont be seen by the modem

You'll have to tell that to USR - they've done it that way for years.

[..]

DH> but it can, and does, remember the last AT&W baud rate, that's permanent.

 RS> And VERY counter intuitive if you forget you have to do another after
 RS> a port speed change. Particularly with the modern approach of storing
 RS> the basic config you want to use with &W and using ATZ as an init string.

You're talking about the 'Rockwell' approach as the 'modern' approach -
from that viewpoint, it might well seem 'counter intuitive', or at least
counter to what you're used to.  Part of that 'basic config' on Couriers is
the 'sticky' port speed, is all.

DH> The cyclic init that Bink does is a genius class
DH> idea, to handle a very necessary situation.

 RS> So it makes no sense to just keep using the &W speed forever.

If you've got the locked port speed setup right, there is no problem.  If
you don't, there is.  Simple enough.

PE> bloody call.  Yet the ATI6 does not show that a retrain was requested.

DH> "Standard Operating Procedure".  Works better.  Much.

 RS> Not with *V32BIS* modems, and CERTAINLY not a full retrain, as opposed to
 RS> a rate negotiation, fall forward/back. Its demanding a full
 RS> retrain. Nuts.

Must be setup differently to any of the ones I've called at V.32bis; I've
never seen one retrain on me after a 14400 connect, and yes, I get good
indication on the front panel of retrains, and when the modem has fallen
back (Dataplex DPX-596) .

 RS> For V34, sure, V32bis, mad.

It's never a trivial matter to properly setup a modem of this type, if
you're getting away from fatory settings.  Of course, Paul may have lucked
upon a crook one; no modem manufacturer has a 100% success rate with
deliveries.

DH> Training going on during connect phase isn't all that reliable.

 RS> Possibly valid at V34, not at V32bis tho.

In marginal conditions (i.e on poorer lines and exchanges) the same is
certainly true at V.32bis.  I could go into a lot of detail about connects
here from a Maestro 144FM for a couple of years from a (then) rotten
exchange that consistently trained up low, and worked up (once it was setup
well enough to not lose the call on initial training) - but I'll spare you.

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

DH> 'Cause it's not a genuine retrain, which would
DH> take extra time. It's a forced "fall forward".

 RS> It is a genuine retrain tho, rate negotiation doesnt produce
 RS> the same display on the front of a Supra. And its already at
 RS> the maximum rate anyway, pointless to see if you can go faster.

Still looks like a setup problem (or faulty unit) to me.  Whether the
problem is related to the Supra or not will show by other Courier owners
experiences with them.  Your indication that it happens with Poe's and
Davids (?) as well, would indicate a Supra/Courier problem, perhaps. 
Doesn't happen here, though.

DH> Don't know the V34 spec well enough to hit the exact terminology.

 RS> Its usually called rate negotiation.

Yes, as (optionally) done by V.32bis too - though not all do it that well.

DH> Bloody HELL.  That's a serious indication of drastic problems.

 RS> You could say that |-)
 RS> Specially when its only seen when a USR V34+ is called.

It's the old problem - if modem A and modem B aren't getting along, and
both work well with modems C, D and E - whose 'fault' is it?  Usually, but
not always, there's a workaround that can be applied to one or the other
modem - have you shared this experience with other Supra owners in its
echo?  Has this particular problem come up in the USR echo?

Ian

--- MaltEd 1.0.b5