On 1995-01-11 03:05, Lewin Edwards of 3:634/396 wrote:

CA> the USR 28k8 Courier V.Everything, it has a EPROM which allows you to
CA> update your modem very cheaply..  It is also Bug Free as it has been
CA> around for a long time.  The Microcom however is supposed to be very good

LE> b) USR is not bug free. Anything but !!

CA> in which it has a Flash Rom which also allows you to upgrade using
CA> software, but it is only a new Product and is prone to have Bugs.  So yea
CA> the USR V.Everything modems would be your best purchase.....

LE> Nonsense !

In case you're interested, you are correct.  Wanna compare lists? ...


              Problems with USR Courier V34+
              
Note: Supervisor Date = 1995-07-05
      DSP Date        = 1995-07-05



1. After receiving an "ATZ" command at a particular baud rate,
the modem does not adjust to that baud rate, and instead reverts
to the rate at the time of last "AT&W".  It actually responds
"OK" at the same rate that the AT command was sent at, but an
incoming "RING" will show up as garbage (assuming a different
speed is stored in NVRAM).  It is acceptible to use the speed
stored in NVRAM in the ABSENCE of an "AT" command, but after
an "AT" command it should do auto-baud detection.  It is possible 
that this is a design fault rather than a bug.  I do not know of 
any other modems that do this.  I also do not know of a single 
terminal (VT100, WYSE, etc) nor a single comms program (Telix, 
etc), which when it sees an "ATZ" command at 38400, will wait for
the "OK" response at 38400, and then quickly revert to the speed
of last NVRAM save (e.g. 57600) in case an incoming "RING" is
seen.  The workarounds for this problem include:
a) Whenever changing port speeds, don't rely on auto-baud detect,
instead go and do an AT&W as well at the new speed.
b) Change the init string to AT&F1|
c) Change the init string to ATZ|ATS0=0| or similar, since the
USR auto-bauds on the other AT commands properly.

2. Regularly getting 26400 connects with a Netcomm instead of
28800.  Actually, that was with the 1995-07-18 Supervisor Date.
It has got worse since I went back to 1995-07-05, with almost
all connects at 24000, the occasional at 26400 and 21600.

3. Modem is initiating a retrain straight after each connect,
even with V32bis modems.  I would expect that the initial
negotiation would have figured that out, no need for a retrain
on every single bloody call.  Yet the ATI6 does not show that
a retrain was requested.

4. Having problems talking to a Supra modem, 30% dropouts where
previously there were none (with a Spirit Thunder modem).

5. AT&F1 sets S56 equal to 16 instead of the default of 0 listed
in the manual.  Actually, this problem happens with the
1995-07-18 Supervisor Date, and is gone with the 1995-07-05 one.

6. A Spirit Thunder is getting connects with me at 2400 bps far
more often than 19200.  1200 bps connects too.  Actually, this
problem occurred with the 1995-07-18 Supervisor Date and one
from 1995-01-25, and has gone away with 1995-07-05 ROMs.  It
seems to have not occurred too many times with the 1995-07-18
ROMs either.

7. USR to USR connect failed due to a retrain failure.  Also,
USR to USR is showing 21600/2400 as the connect rate.  This
was done with the 1995-07-18 ROMs and being fairly rare has
not yet happened with the new ROMs.

8. Failed to connect to Hayes modem at all.  Very weird sounds
coming out.  No problem when I was using a Spirit.  This actually
happened with an older revision of the ROMs (1995-01-25), and 
cannot confirm at this stage whether it still exists because the 
modem was taken offline so that I could connect.

9. A Netcomm Cardmodem V.34 modem (PCMCIA or something) gets 
connects of 1200, 2400, 14400 and 28800 with me.  This also 
happened with the older (1995-01-25) ROMs, and appears to have 
gone away with both 1995-07-05 and 1995-07-18 ROMs.

10. Previous user (using the 1995-01-25 roms) says that whenever 
he is connected to his Internet Service Provider for more than an
hour, the USR invariably drops out.  I don't connect for that
long so cannot confirm this problem first hand with new roms.

11. The following stats obtained from ATI11 + 6 apparently defy
various Laws of Physics, but this was on the 1995-07-18 ROMs...
CONNECT 28800/ARQ/V34/LAPM/V42BIS
USRobotics Courier HST Dual Standard V.34+ Fax Link Diagnostics...
Modulation               V.34+
Carrier Freq (Hz)        44672/44672
Symbol Rate              48905/48905
Trellis Code             64S-4D/64S-4D
Nonlinear Encoding       ON/ON
Precoding                OFF/ON
Shaping                  OFF/OFF
Preemphasis (-dB)        2/6
Recv/Xmit Level (-dB)    28/17
Roundtrip Delay (msec)   0
OK
ATI6
USRobotics Courier HST Dual Standard V.34+ Fax Link Diagnostics...
Chars sent                17910      Chars Received          1093329
Chars lost                    0
Octets sent               17783      Octets Received         1093235
Blocks sent                 259      Blocks Received            4696
Blocks resent                31
Retrains Requested            0      Retrains Granted              8
Line Reversals                0      Blers                        27
Link Timeouts                 3      Link Naks                     0
Data Compression       V42BIS 2048/32
Equalization           Long
Fallback               Enabled
Protocol               LAPM SREJ 244/15
Speed                  21600/2400
Last Call              00:08:23
Disconnect Reason is Unable to Retrain
OK


12. I set S34=128 to disable V32terbo.  This had the result
of making the calling Supra NOT show retrains on his display.
This is a Good Thing.  The Supra is a V32bis modem.  It seems
that V32terbo logic is affecting V32bis calls when it 
shouldn't be.  However, now, instead of the Supra getting 30%
failed calls (screwing up in the retrain AFTER connect), the
Supra now gets somewhere around 30% connects at lower speeds, 
such as 12000 and 7200.

13. I set ATS27=48 as someone suggested I do.  The result of
this was that I connected on my outgoing call with LAPM, my
incoming calls were all MNP, except for some which failed
completely.  I would have expected the results of ATS27=48 to
be consistent.

14. Got a 28800 (no EC) connect to a Spirit Viper.  The call
was actually successful, I just had to put up with garbage
appearing on my screen every now and again.  Called again
and it connected with EC.  Sysop confirmed that he had not
been fiddling at the time.
@EOT:

---