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 years, but it's not 
IS> common to other brands, no.  This quite often comes up in the BINKLEY 

Also, what possible rationale can you think of in USRs defence
for sending "OK" at 38400 but "RING" at 57600?  My terminal
can't be set to both speeds simultaneously.  And there's 
further info from Bill (not verified by me yet) that ATZ will
fail to auto-baud detect for the subsequent RING, but any other
command, such as AT&F1, will!

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?  Why not set it for the speed you'll be locking it 
IS> at all the time?  It's not 'wrong', because it's 'different' to other 
IS> modems.

The problem comes when I decide to try changing baud rates as
an experiment.  I don't expect to have to have to save to NVRAM
just to change speeds.  And in fact, I can do all other operations
fine, by simply changing speed, going and dialling another
modem etc, no need to stuff around with NVRAM.  The only, and
UNREASONABLE exception being the word "RING".

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

Could you do me a favour and call me with your Dataplex modem
and see if this is true of my modem too?  My system is 3:711/934,
phone 02-436-1785.  FREQing "FILES" will be a good enough test.

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

When you say "doesn't happen here", are you referring above to your
Dataplex modem, or are you saying you have a Courier online and no
Supras have problems?  If the latter, Rod can call you and try.

IS> It's the old problem - if modem A and modem B aren't getting along, and 
IS> both work well with modems C, D and E - whose 'fault' is it?  Usually, but 
IS> not always, there's a workaround that can be applied to one or the other 

Exactly, it needs to be analysed by a manufacturer and then 
a workaround done.  Having seen manufacturers (Digicom, Maestro,
Supra)'s responses to the LAPM double-send problem, I wouldn't
hold out any hopes of seeing this fixed.

IS> modem - have you shared this experience with other Supra owners in its 
IS> echo?  Has this particular problem come up in the USR echo?

I documented it in that echo, same as here, yes.  I only changed
the "header".  I didn't say in the USR echo that I wouldn't touch
it with a barge pole, merely that I was "not impressed".  :-)
BFN.  Paul.
@EOT:

---