IS> Fairly obviously - I don't run a Supra :)  Yes, I was watching that call 
IS> very closely.  Your log entry shows clearly enough that ring to connect was 
IS> about 11 seconds; average, and nowhere near time for a full retrain after 
IS> trainup.  Nine seconds later it was into session - again, about average for 
IS> YooHoo.

The former is irrelevant, as Rod reports that the retrain happens
AFTER the connect.  The latter is not possible for me to tell this
end, as I have fast Yoohoo here, although since you are the 
initiator the delays will be until you send an x'f1'.

PE> assume the behaviour of Binkley 2.50.  Just who is meant to
PE> hang up after a zmodem transfer?  I'll have to investigate
PE> that though, as I think both ends should hang up.

IS> Both did, though a WaZOO session isn't just a zmodem transfer.  The extra 
IS> 10 seconds between the last file and hangup would be yours checking for 
IS> nothing else to send, I expect; it's not that uncommon after file requests.  
IS> My end drops DTR synchronously with logging of 'End of WaZOO/EMSI Session'.  
IS> Yours obviously did too; .1 sec later your log said - near enough.

Actually on closer inspection, it looks like the last zmodem
"transfer" (sending the "no more files" sequence) is what took
the time.  I'll post the log.

IS> Whether it only happens when some/all Supras of that
IS> vintage call Couriers, is perhaps what's worth finding out.
IS> I rather doubt
IS> USR would be interested in investing development time if it
IS> doesn't effect
IS> more than a few oldish modems, though it may cover some generic range ..

PE> Yeah, but all that does is lump USR with every other manufacturer.
PE> You're on your own when you walk out the door.

IS> That hardly appears to be the case.  Until we get reports of other V.32bis 
IS> modems having this problem with Couriers, there's nothing to go on.  If you 

There is DEFINITELY something to go on, as it is a reproducible
problem.  If USR REALLY wanted to do something, they could easily
debug it, find out why 30% of the calls are failing, who is
violating protocol, why/if a retrain is being requested, and 
assuming in the end it is a Supra problem, then create a workaround
for this real-world modem.  As it is, they're no better than 
Digicom, Maestro, Supra et al.

IS> expect every modem to work with every other modem, especially older models 
IS> no longer in development, your expectations are much higher than those of 
IS> any modem manufacturer I've come across.  

I expect that every modem that if fails to work with should be
documented as a wart, with a datascope tracing to prove who is
at fault, and if they were halfway decent, then a workaround in
their own code, at least with an option to enable it if it is
not possible to do the workaround without violating specs.

IS> How are Supra handling enquiries?

I gave up on Supra with the Spirit double-sending fiasco.  All I'm
doing now is adding USR to the list of no-support manufacturers.
Supra was there 2 years ago or something.

IS> Thanks for the log.

I'll post the bit showing the Zmodem delay too (looking at
other's connects, there is no similar problem).  Now if you 
had the source code for your terminal program, you could
find out who was violating protocol!  :-)

PE> # 09 Feb 02:29:31.53   USRobotics Courier V.32bis Dual
PE> Standard V.34+ Fax Link Diagnostics...
PE> # 09 Feb 02:29:32.03   Modulation               V.32/bis/terbo

IS> Terbo?

Don't ask me, I'm just the poor simp who almost shelled out $600
for a large bug.

PE> # 09 Feb 02:29:32.06   Carrier Freq (Hz)        0/0
PE> # 09 Feb 02:29:32.06   Symbol Rate              0/0
IS> [..]
PE> # 09 Feb 02:29:32.18   Recv/Xmit Level (-dB)    0/0
PE> # 09 Feb 02:29:32.18   Roundtrip Delay (msec)

IS> Hmm, have you already had Binkley issue an ATZ at this stage?

No.  If I had done that the "chars sent" etc would be 0 as well.

PE> # 09 Feb 02:29:32.53   Fallback               Disabled

IS> Er, fallback disabled where?  It sure isn't here (%F1).

See previous "simp" comment.  :-)

PE> # 09 Feb 02:29:32.53   Protocol               LAPM 128/15

IS> Hmm, no 256 byte frames, despite 'Connect 14400/Lap-M/Compression' here ..

As above.  :-)

PE> # 09 Feb 02:29:32.56   Speed                  14400
PE> # 09 Feb 02:29:32.56   Last Call              00:00:47

IS> # 09 Feb 01:34:41 BINK 000:47    -- modem reported time online
IS> # 09 Feb 01:34:42 BINK 007       -- sig. qual. out of 7

IS> .. which is all the stats data I'm reporting, with 'Aftercall 2 ATKS69?'

NULL out of 7 is your score for signal quality?  Or is it out of
7 and into one of either 6 or 8?  Or simply "not 7".  An 
interesting way of reporting stats, anyway!  :-)  BFN.  Paul.
@EOT:

---