BG> binkley.cfg;  Aftercall 34 ~~ATI11~~I6|.  Your logs should then indicate
BG> the reason for his premature carrier loss.

IS> .. as long as you don't use ATZ for / in your PreInit or
 IS> Init strings, yes?

 BG> Funny, mine logs the stats just fine, ATZ and all...  :)

 BG> Port      2
 BG> Baud      115200
 BG> Carrier   80
 BG> Init      ATZ|
 BG> TermInit  ATZ|
 BG> Prefix    ATDT
 BG> Answer    ATA|
 BG> PreInit   |v``^``
 BG> PreDial   `
 BG> Aftercall 34 ATI11I6|
 BG> [ ... ]

 BG> Of course, the fact that the Aftercall commands are issued
 BG> _before_ the modem reinitialises may just have something to
 BG> do with it.

Ah, well, if that's so, there's been a major change in the way Binkley
works with version 2.60.  Hitherto, the PreInit then Init strings were what
were always used to hangup the modem, after which AfterCall was issued,
which had meant that Courier users could not use ATZ in their PreInit or
Init.

Unless of course USR changed the modem to keep the stats after ATZ, which
was also being asked of them at one stage?  

 IS> Why the first 2
IS> second delay, for that matter?

 BG> Good question.  Earlier experimentation with my original
 BG> V.34+ Sportster had the second command occasionally being
 BG> missed, hence the delay.  Thanks for pointing that out, as
 BG> the Courier doesn't need this delay at all, so I've now
 BG> removed the tildes.

Goodo, faster.  Most modems seem to need some delay _after_ ATZ| (and some,
after AT&F), in terms of getting Binkley to swallow spurious OK
responses, and/or to prevent issuing further commands till they've digested
those.

Cheers, Ian

--- MaltEd 1.0.b5