IS> It's certainly common to every USR Courier for many years, but it's not
IS> common to other brands, no.  This quite often comes up in the BINKLEY

PE> Also, what possible rationale can you think of in USRs defence
PE> for sending "OK" at 38400 but "RING" at 57600? 
My terminal
PE> can't be set to both speeds simultaneously.  And there's
PE> further info from Bill (not verified by me yet) that ATZ will
PE> fail to auto-baud detect for the subsequent RING, but any other
PE> command, such as AT&F1, will!

IS> See my msg to Bill; ATZ should restore all &W settings.  I'm not going to 

And see my reply to your reply to Bill.  :-)

IS> buy into arguing about what USR ought or ought not to do with their modems.

Too late!

IS> Must be setup differently to any of the ones I've called at V.32bis; I've
IS> never seen one retrain on me after a 14400 connect, and yes, I get good
IS> indication on the front panel of retrains, and when the modem has fallen
IS> back (Dataplex DPX-596) .

PE> Could you do me a favour and call me with your Dataplex modem
PE> and see if this is true of my modem too?  My system is 3:711/934,
PE> phone 02-436-1785.  FREQing "FILES" will be a good enough test.

IS> No indication of retraining or any delays here (apart from a longish wait 
IS> till hangup after receiving your filelist?)  What do your stats have to 
IS> say?

I will insert them below.  Not that they give me any info.  The
info I was after was whether YOU would see a retrain request
reported on your modem.  Since you didn't see one, we have a 
new query.  Why are you not seeing a "retrain", but Rod is?

As for the 10 second delay after getting the file, that is I
assume the behaviour of Binkley 2.50.  Just who is meant to
hang up after a zmodem transfer?  I'll have to investigate
that though, as I think both ends should hang up.

IS> problem is related to the Supra or not will show by other Courier owners
IS> experiences with them.  Your indication that it happens with Poe's and
IS> Davids (?) as well, would indicate a Supra/Courier problem, perhaps.
IS> Doesn't happen here, though.

PE> When you say "doesn't happen here", are you referring above to your
PE> Dataplex modem, or are you saying you have a Courier online and no
PE> Supras have problems?  If the latter, Rod can call you and try.

IS> No, I've the DPX596 only, currently.  What doesn't happen here is any 
IS> connect difficulties, obvious retraining or rateshifting, nor any other 
IS> problems when calling any Couriers, to date.  No Supras call here, to my 
IS> knowledge.

Would it be possible that you have retrains disabled, and your
modem only reports when it accepts a retrain request, or 
initiates one?

IS> It's the old problem - if modem A and modem B aren't getting along, and
IS> both work well with modems C, D and E - whose 'fault' is it?
IS>  Usually, but
IS> not always, there's a workaround that can be applied to one or the other

PE> Exactly, it needs to be analysed by a manufacturer and then
PE> a workaround done.  Having seen manufacturers (Digicom, Maestro,
PE> Supra)'s responses to the LAPM double-send problem, I wouldn't
PE> hold out any hopes of seeing this fixed.

IS> If it was happening from many V.32bis modems calling Couriers, I guess we'd 
IS> have heard about it?  

This is a classic mistake.  Someone always has to be first.  I
was the first to document the Spirit double-send problem, which
happened to be a problem with ALL Spirit modems.  You will notice
that AFTER I documented those various USR bugs, suddenly we
started getting confirmation of them.  

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

Yeah, but all that does is lump USR with every other manufacturer.
You're on your own when you walk out the door.  Netcomm don't even
appear to be willing to call my BBS to get a sale!  Forget this
walking out the door rubbish!  I wanted them to confirm that the
<28800 connects the Netcomms are getting to my USR are due purely
to USR and telstra problems and that it is nothing to do with
their modems.

IS> Do I gather from later streams of messages that new flashware may have 
IS> fixed this, anyway?

You mean the OLD flashware?  :-)  No, David D has always been
using the old flashware, and Rod has the problem with him too.

BFN.  Paul.

Here's the log as requested...

# 09 Feb 02:28:31.43   RING
> 09 Feb 02:28:31.56   ATA
# 09 Feb 02:28:42.87   CONNECT 14400/ARQ/V32/LAPM/V42BIS
* 09 Feb 02:28:51.71   Magic Puddin' (3:626/660{at}fidonet)
* 09 Feb 02:28:51.75   Remote Uses BinkleyTerm Version 2.59
: 09 Feb 02:28:51.75   Sysop: Ian Smith
: 09 Feb 02:28:52.90   WaZOO method: ZedZap
+ 09 Feb 02:28:54.53   CPS: 7 (7 bytes)  Efficiency: 0%
+ 09 Feb 02:28:54.53   Received-Z/32 C:\Binkley\Inbound\Known\02c703a6.req
* 09 Feb 02:28:56.40   File Request (FILES)
+ 09 Feb 02:29:19.40   CPS: 1551 (34139 bytes)  Efficiency: 107%
+ 09 Feb 02:29:19.40   Sent-Z/32 c:\minpoint\F711X934.ZIP
+ 09 Feb 02:29:19.43   Nothing to send to 3:626/660{at}fidonet
* 09 Feb 02:29:29.53   End of WaZOO Session
> 09 Feb 02:29:29.53   session over, hanging up
* 09 Feb 02:29:29.53   Session with 3:626/660{at}fidonet Time: 00:00:44 Cost: $0.00
> 09 Feb 02:29:29.65   dropping DTR
> 09 Feb 02:29:31.15   running aftercall
> 09 Feb 02:29:31.15   string is ATI11I6|
> 09 Feb 02:29:31.50   ATI11I6
# 09 Feb 02:29:31.53   USRobotics Courier V.32bis Dual Standard V.34+ Fax
Link Diagnostics...
# 09 Feb 02:29:32.03   Modulation               V.32/bis/terbo
# 09 Feb 02:29:32.06   Carrier Freq (Hz)        0/0
# 09 Feb 02:29:32.06   Symbol Rate              0/0
# 09 Feb 02:29:32.09   Trellis Code             
# 09 Feb 02:29:32.09   Nonlinear Encoding       
# 09 Feb 02:29:32.12   Precoding                
# 09 Feb 02:29:32.12   Shaping                  
# 09 Feb 02:29:32.15   Preemphasis (-dB)        
# 09 Feb 02:29:32.18   Recv/Xmit Level (-dB)    0/0
# 09 Feb 02:29:32.18   Roundtrip Delay (msec)   
# 09 Feb 02:29:32.21   USRobotics Courier V.32bis Dual Standard V.34+ Fax
Link Diagnostics...
# 09 Feb 02:29:32.25   Chars sent                35674      Chars Received 
            389
# 09 Feb 02:29:32.28   Chars lost                    0
# 09 Feb 02:29:32.31   Octets sent               35631      Octets Received
            340
# 09 Feb 02:29:32.34   Blocks sent                 425      Blocks Received
             42
# 09 Feb 02:29:32.37   Blocks resent                 0
# 09 Feb 02:29:32.40   Retrains Requested            0      Retrains
Granted              0
# 09 Feb 02:29:32.43   Line Reversals                0      Blers          
              0
# 09 Feb 02:29:32.46   Link Timeouts                 0      Link Naks      
              0
# 09 Feb 02:29:32.50   Data Compression       V42BIS 2048/32
# 09 Feb 02:29:32.50   Equalization           Long
# 09 Feb 02:29:32.53   Fallback               Disabled
# 09 Feb 02:29:32.53   Protocol               LAPM 128/15
# 09 Feb 02:29:32.56   Speed                  14400
# 09 Feb 02:29:32.56   Last Call              00:00:47
# 09 Feb 02:29:32.59   Disconnect Reason is DTR dropped
# 09 Feb 02:29:32.59   OK
@EOT:

---