Paul, at 15:50 on Feb 03 1996, you wrote to Bill Grimsley...

BG> Did you read the extracts which I posted yesterday, from the on-line text 
BG> Courier manual?

PE> Indeed I did.  I even read that bit before you quoted it, in an attempt to 
PE> find the bit about the auto-baud rate detect that DD told me to read
PE> (nevermind it wasn't even there).

As strange as it may seem, the hard-copy manual supplied with the Courier,
is nowhere near as comprehensive as the downloadable on-line ascii version,
and not by a long chalk either.

BG> You could've fooled me then.  You may have glanced at them, but you sure 
BG> didn't grasp what they had to say.  The bottom line is that you should 

PE> YOU are the one who can't grasp it.

Yes I can; no you can't; yes I can; no you can't...  BTW, is this just the
5-minute argument, or the full half hour ?

BG> simply set Binkley to a serial port speed of 57600 bps, fire up the modem, 
BG> and enter the required init$ (say AT&F1&K3S54=64&W,
which disables MNP5 but 
BG> not V.42bis, and also disables the V.25 call-indicate tones).  The
&W will 
BG> also write the port speed to the Courier's NVRAM, and like all error 
BG> correcting modems, you should NEVER need change it again, regardless 
BG> of the link rate of an incoming call.

PE> And like all other modems, expect that if I do change the baud
PE> rate, to test something out, I expect it to AUTO BAUD RATE
PE> DETECT.  What a shame that USR's are stuffed in that regard.

Of course, it couldn't be Binkley at fault, nor operator error, could it ?

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

PE> BTW, you can't even grasp that you keep on quoting something
PE> about the baud rate that happens AFTER a connect.  I am talking
PE> about something that happens BEFORE a connect.

(Rod, you'll doubtless be interested in the following too).

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

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

This is certainly peculiar behaviour, I'll agree, although it's not really
the end of civilisation as we know it.  Especially as I was able to fix the
problem almost immediately.  Seems that this only occurs when the terminal
is first started, but once any AT command has been issued (apart from ATZ,
for some obscure reason), the anomaly disappears permanently from that
session.

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

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

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

Port      2
Baud      57600
Carrier   80
Init      AT&F1|
TermInit  AT&F1|
Prefix    ATDT
Answer    ATA|
PreInit   |v``^``
PreDial   `
Aftercall 28 ~~ATI11~~I6|

And if AT&F1 doesn't, tough shit, I guess...  :)

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.

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

PE> Aha, the man suddenly understands what auto baud rate detect is
PE> in this context.

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

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.

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

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.

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

BG> Seriously though, if different, mine auto-bauds to the terminal's port rate 
BG> as expected, with either incoming or outgoing 

PE> Yay, the man is starting to understand.

BG> calls, and regardless of what had previously been written to NVRAM.  I just 

PE> Yay, the understanding continues.

BG> ran a few tests with 57600 saved to the modem, but varied my locked port 
BG> rate between 38400 and 115200 bps.  No problems at all, even on incoming 

PE> Yay, still going.

BG> calls.  If your Courier isn't doing the same thing, it may indeed be 
BG> faulty, 

Dunno why it worked OK for me yesterday, but today's tests have proved
beyond any doubt that the modem definitely needs an AT command when FIRST
started up, and as AT&F1 does the job, I'm more than happy with that
solution.

PE> ROFL!  Well what do you know?  I was right all along.  I'll still
PE> have to see the results of the proper test though.  Ok, the proper
PE> test to do, is have the NVRAM set to 57600 as usual, fire up your
PE> comms program at 38400, ATZ, should respond "OK".  Now get someone
PE> else to call you, and see if the word "RING" appears on your
PE> screen.  If it does, the bug is not affecting you.

Nope, with ATZ as my init$, I see garbage characters until such time as an
AT command has been issued.  With AT&F1 though, it works perfectly from
scratch.

BG> or (more likely) the last SDL didn't "take" properly.  That has 
BG> been known to happen before.

PE> I've just done a reload, just rerun the test, same thing.

OK, but it's probably wise to have eliminated that possibility anyway.

BG> It's specific behaviour is controlled by the &Bn command.

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

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

Regards, Bill

--- Msgedsq/2 3.20