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. 

BG> Simple solution then, buy another fucking Spirit.

That has major problems too.  I want to try again.  

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 
PE> 38400, 
PE> I chose to limit the speed to 19200.  I would like to up the speed to 
PE> 115200 
PE> to see what uncompressed rates I can get out of the modem, but I'm not
PE> ready to do that yet.

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

So it's a bug, which I documented, and had a workaround for in
10 minutes.  I didn't document it as "a bug so bad that I intend
to commit Hurry Curry if it isn't solved by the this time next
week".  Sorry you fail to see the difference.

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.

BG> Too busy slagging off at USRs, were we ?

I documented it, worked around it, and had a solution.  It is
up to USR to fix the bug, not me to diagnose every single
aspect of it.

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.

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

You don't know what will or will not make a code bug appear.

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.

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

I am happy with my other workaround.  I don't change speed very
often.

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.

BG> Pure conjecture so far.  

What did you expect me to do in order to diagnose the cause of
a USR bug when I don't even have the source code?

BG> For the definitive answer, ask Joe F in the 
BG> USR_Modems echo.  Anything else is just a guess.

So why did you ask me instead of him then?  BFN.  Paul.
@EOT:

---