BG> I've been able to reproduce the problem which Paul had detailed re his
BG> serial port mismatch, and have posted it here for a wider distribution...

Yeah, looks like its been convincingly resolved now.

Thought there must have been something odd going on when Dave Hatch
agreed it was quirky after initially saying it was standard behaviour.

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

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

Yeah, rather bizarre. Tho strictly speaking you dont mean its been
saved to the NVRAM in the sense it lasts over a modem power off,
just that the speed is the one reported in a status report etc.

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

Oh sure, no one has ever disputed that there isnt a viable workaround.

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

Which presumably means you agree about a modem power cycle.

BG> And now for the strangest aspect of all, re this complete
BG> and utter weirdness, the one AT command which does NOT
BG> auto-baud the serial port is (of all things) ATZ !

There is a sort of weird warped logic in that, if you have been taking
lots of magic mushrooms. It is the only one which does a full reset of the
modem, so its sort of weirdly logical that it resets the port speed too.

Main massive hole in that argument tho is that it STILL uses that
new speed for the OK that it uses to respond to the ATZ with.

That does smell VERY like a true bug, using a block of code to do
the reset, for all the ATZ, DTR reset and the initial power on one
too. They just havent managed to handle the special case of the port
speed and the ATZ properly except for the OK itself. They should
also set the port speed to that after the OK has gone out as well.

Be interesting to see what USR themselves have to say.

BG> This basically means that if ATZ is used as a generic
BG> initialisation string, the very first RING response on an
BG> incoming 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
BG> init$, I simply changed it to AT&F1^M instead (no &W write command,
BG> of course). Unlike ATZ, AT&F1 allows the serial port to auto-baud
BG> correctly, as you'd expect.  The same init$ change solved this
BG> anomaly in all of my other comms apps too.

Or you could just have ATZ^M AT^M as an init string etc.
@EOT:

---