BG> This has been discussed at great length elsewhere, and assuming that we're 
BG> 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.

BG> Yeah, that doesn't sound right at all, assuming that you've described the 
BG> problem accurately.  That simply shouldn't happen anyway, as mismatched 
BG> baud rates should "equalise" immediately the first AT
command is issued 
BG> under a locked port. 

That's right, it's a bug.

BG> However, the fact that nobody else has EVER described 
BG> the problem would indicate to me that the problem is not with the modem, 
BG> but the manner in which it's being used.  

I was the first person to document the Spirit double-sending bug,
the first person to encounter it with a Maestro SE 9600, the 
first person to find their modem spewing garbage at them at
38400 bps when the caller had long pissed off.  No thanks, Bill.

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

Bill, that's not my problem.  Yes, if I save at 57600, and then
run my comm port at 57600, everything is hunky dory.  What I
want to do is save my config at 57600, run my com port at 38400,
and then get the modem to switch the RINGs to 38400 as soon as
it gets an AT command from me.  I do not mind getting garbage
from "RINGs" IF I HAVE NOT ISSUED AN AT COMMAND.  BFN.  Paul.
@EOT:

---