Paul, at 08:27 on Feb 05 1996, you wrote to Bill Grimsley...

BG> Also, just indulge me for a moment Paul, and tell me why you'd ever want to 
BG> change your locked serial port speed (which also means editing binkley.cfg, 
BG> your MODE command, and the modem's NVRAM).  If 57600 bps works IOW, why 
BG> would you bother changing it ?

PE> To change speed, I should only have to change binkley.cfg and my
PE> mode command, which is all I had to do with my Spirit, no stuffing
PE> around with NVRAM. 

Simple solution then, buy another fucking Spirit.

PE> The reason for changing speed up or down is to see how my system can cope 
PE> with it.  And e.g. when the Spirit was sending garbage to my modem at 38400, 
PE> I chose to limit the speed to 19200.  I would like to up the speed to 115200 
PE> to see what uncompressed rates I can get out of the modem, but I'm not
PE> ready to do that yet.

Big deal, so you do it once, determine that the system can handle that
speed, then leave it there.  So what ?

BG> is first started, but once any AT command has been issued (apart from ATZ, 
BG> for some obscure reason), the anomaly disappears permanently from that 
BG> session.

PE> Ok, thanks for that info, I didn't actually try any other command.

Too busy slagging off at USRs, were we ?

BG> The fix, however, is dead easy.  Rather than use ATZ^M as Livewire's init$, 
BG> I simply changed it to AT&F1^M instead (no &W write command,
of course).  
BG> Unlike ATZ, AT&F1 allows the serial port to auto-baud correctly, as you'd 
BG> expect.  The same init$ change solved this anomaly in all of my other comms 
BG> apps too.

PE> I'd probably use ATZ S0=0 myself, if that worked.

It won't.  Think about it for a minute, and you'll see why.

BG> Now a suggestion, Paul.  Can you edit your binkley.cfg to something like 
BG> the one below, and see if using AT&F1| instead of ATZ| as your init$ will 
BG> allow the serial port to auto-baud when the program is first started ?  
BG> I've already done mine, and it now works a treat.

PE> Ok, will try that later.

I've given you the fix.  It's now up to you to use it.

PE> It decides to send "RING" to the computer at a rate other than
PE> 38400 though.  Fucked, either by design or by a bug.

BG> I fail to see why it should want to do that though.  Please explain.

PE> Please explain why USR fucked up?  Probably the logic in their
PE> code says that on an incoming call, get the speed from NVRAM,
PE> because that's what you're supposed to do IN THE ABSENCE of 
PE> another "AT" command.  In fact, they probably have a flag set,
PE> to say whether an AT command has been sent or not.  Now the ATZ
PE> is probably resetting that flag to the default of 0, so that's
PE> where the faulty logic is.

Pure conjecture so far.  For the definitive answer, ask Joe F in the
USR_Modems echo.  Anything else is just a guess.

Regards, Bill

--- Msgedsq/2 3.20