Paul, at 11:22 on Jan 26 1996, you wrote to Bill Grimsley...

BG> Not at all.  What's happened is that because you loaded the SDL with a 
BG> locked baud rate of 57600, that has also been written to NVRAM.  If you 
BG> attempt to run it at 38400, you'll get a baud rate mismatch until you issue 
BG> any AT command to match the speeds.

PE> I have done that Bill, it is a bug.    

This has been discussed at great length elsewhere, and assuming that we're
talking about the same thing, it's not a bug, just the way the USRs work.

PE> What I am describing is a *BUG*.  It is not adapting to the AT commands.

Yeah, that doesn't sound right at all, assuming that you've described the
problem accurately.  That simply shouldn't happen anyway, as mismatched
baud rates should "equalise" immediately the first AT command is
issued under a locked port.  However, the fact that nobody else has EVER
described the problem would indicate to me that the problem is not with the
modem, but the manner in which it's being used.  If it WAS a specific USR
bug, I'd expect to see the USR_MODEMS echo full of complaints about this,
and I haven't.  Indeed, all of my USRs (including the 3 Couriers I've used
here, as well as the literally hundreds I tested prior to sale at CHH) have
worked exactly as expected, and not one has shown the peculiar symptom that
you indicate.

Can you try this?  Run up your favourite comms app with its port locked to
your preferred speed (I strongly suggest 57600 bps, BTW), do an ATZ, which
should immediately match the modems speed to the comms app's, then do an
AT&F1&W.  That will write the port speed of 57600 bps to the
modem's NVRAM, and your problems should then be solved.  If not, try
flashing the ROM again (under native DOS, and following the SDL directions
TO THE LETTER), then repeat the above.  An ATI7 will confirm that the modem
has saved the 57600 to NVRAM.

Regards, Bill

--- Msgedsq/2 3.20