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 ?

To change speed, I should only have to change binkley.cfg and my
mode command, which is all I had to do with my Spirit, no stuffing
around with NVRAM.  The reason for changing speed up or down is
to see how my system can cope with it.  And e.g. when the Spirit
was sending garbage to my modem at 38400, I chose to limit the
speed to 19200.  I would like to up the speed to 115200 to see 
what uncompressed rates I can get out of the modem, but I'm not
ready to do that yet.

BG> Well, I believe I've seen the symptom which you describe (at long last) and 
BG> I can seemingly reproduce it at will by starting Livewire/2 with COM2 
BG> locked to 38400 bps, whilst the modem's serial interface has been saved at 
BG> 57600 bps.

BG> If I induce a RING on the line by dialling 199, the modem responds with 
BG> garbage characters instead of the normal RING result code, and will 
BG> continue to do so until such time as any command (OTHER THAN ATZ) is 
BG> issued, at which time the new speed is "saved" to NVRAM,
the modem then 
BG> reporting RING correctly.

The new speed is not "saved" to NVRAM by issuing at AT command
that is not &W.

BG> This is certainly peculiar behaviour, I'll agree, although it's not really 
BG> the end of civilisation as we know it.  Especially as I was able to fix the 

I never said it was the end of civilisation, merely a bug.

BG> problem almost immediately.  Seems that this only occurs when the terminal 

I fixed the problem within minutes after seeing it a week ago.

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.

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

BG> And now for the strangest aspect of all, re this complete and utter 
BG> weirdness, the one AT command which does NOT auto-baud the serial port is 
BG> (of all things) ATZ !  This basically means that if ATZ is used as a 
BG> generic initialisation string, the very first RING response on an incoming 
BG> call after starting the program, is going to be garbage.

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.

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

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.

Ok, will try that later.

PE> In fact, if you type ATZ at 38400, it WILL auto baud rate
PE> detect, and send the answer, "OK" back to the computer.

BG> Actually, I didn't find that to be true at all, quite surprisingly.

You mean you didn't get "OK" back in response to ATZ?  If you
did get "OK", have a guess what speed it came back at?  Hint
- not the speed in NVRAM.

BG> But that's been my understanding all along.  What it DOES do though, is 
BG> match the current and stored baud rates without saving them permanently.  
BG> And if I read you correctly, you appear to be complaining that the FIRST 
BG> incoming RING is being seen as garbage by the modem, then subsequent RINGs 
BG> are OK, is that correct (because that's precisely what I'm seeing with 
BG> mine) ?

Subsequent rings are not OK.  All RINGS come in at 57600 (NVRAM).

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.

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

BG> Operator error perhaps?  

PE> Nope, any modem designed to send characters to the modem at two
PE> different speeds is fucked by design or by a bug.

BG> If you think this is a bug, let's just agree to disagree.

It could be a fucked design, not a bug, agreed.

PE> Yeah, and I've got &B1, locked com port.  With "OK" coming in
PE> at a different speed to "RING".

BG> Dunno why you choose to do it that way, but it's your system, so I guess 
BG> you can basically do whatever you bloody well like with it.  :)

I don't "choose" to do it that way, I actually want the RING to
come in at the same speed as my last AT command.  BFN.  Paul.
@EOT:

---