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.

IS> It's certainly common to every USR Courier for many
IS> years, but it's not common to other brands, no.

Yeah, thats what I meant, I should have said
that more carefully on the USR question.

IS> This quite often comes up in the BINKLEY conference, and the advice
IS> given is always the same. According to the Bink 2.40 docs, there's also
IS> a register needs setting if you want to handle locked computer-to-modem
IS> rates for /Arq calls, and floating rates, on lower speeds, without /Arq
IS> - Binkley's 'Lockbaud /Arq' feature was specifically developed to cater
IS> for this (and a similar feature found in Telebit PEP modems).

Yeah, the USR &B2 is rather weird, allowing the ARQs to be locked and the
non ARQs to float. I really cant see the point over allowing them both
to be locked, but presumably there is some situation where thats useful.

Clearly in that particular situation the speed to used for the locked
connects has to come from somewhere, and hence the NVRAM value.

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.

IS> Why would you want to?

Thats was just a clear statement of what was being discussed.

IS> Why not set it for the speed you'll be locking it at all the time?

Yes, but the point is that you shouldnt have to.

IS> It's not 'wrong', because it's 'different' to other modems.

Well, it is in the sense that its rather counter intuitive and has
a hell of a capacity to fang you on the bum, even if you do understand
the problem. VERY easy to try a different port speed in a situation
where you are having some problems and forget to &W it into the NVRAM.

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.

IS> That's right, if you're changing your locked speed, you need to
IS> reinit the modem (by typing AT in terminal mode), then storing the
IS> new speed, or so the Binkley+USR gurus have been saying for years.

Yes, but if the modem implements that port speed more intelligently,
you dont have to remember to do that. The industry has FAR too many
of those quirks already, the less the better.

IS> I believe the safe way (to ensure keeping
IS> all current changes to AT&F) is:

IS> ATZ
IS> AT
IS> AT&W

Sure, but you shouldnt have to fart around like that, and the USR
manual certainly doesnt belt you over the head with the danger either.

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

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

I was commenting on the 'its not USR's fault', thats PRECISELY what it is.
Particularly if the vast bulk of other modem manufacturers dont do it like that

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.

IS> You're talking about the 'Rockwell' approach

I'm not convinced it is a rockwell approach, the Spirit, which
had nothing to do with Rockwell at all, does it the same way.

IS> as the 'modern' approach - from that viewpoint, it might well seem
IS> 'counter intuitive', or at least counter to what you're used to.

Nope, its just nuts to be autobauding on the AT letters, thats
the whole point of the use of the AT letters, so you can, and
then ignoring that speed when you send out a RING. Even the OK is
correctly sent back to the port at the speed determined from the AT.

Yes, in a FEW special cases like a DTR reset of the modem, it may
not have any speed to use and THEN it certainly makes sense to use
whats in the NVRAM, but it makes no sense whatever to ignore the
speed determined later from an AT command which has been acknowledged.

I cant think of a single situation in which THAT
makes any sense and its VERY counterintuitive.

IS> Part of that 'basic config' on Couriers is the 'sticky' port speed, is all.

I'm not convinced, and it CERTAINLY isnt adequately documented in the USR
online manual. It would be perfectly reasonable to assume that where it does
mention that it ONLY applys to the &B2 mode, which Paul isnt even using.

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.

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

Nope, FAR too quirky and counter intuitive, AND there isnt
any good reason to do it so weirdly either. AND I have yet
to see anyone other than USR think that approach makes sense.

If they are going to do that it should be very
unambiguously documented in the manual too.

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
RS> retrain, as opposed to a rate negotiation, fall
RS> forward/back. Its demanding a full retrain. Nuts.

IS> Must be setup differently to any of the ones I've called at V.32bis;

Thats rather unlikely given I get precisely the same
result with Poes and the bulldogs modems as well as Pauls.


(Continued to next message)
@EOT:

---