PE> Oh yes it is. $200 is a HELL of a lot of money. You do realise that
PE> even if I put the $200 into my home loan, the INTEREST alone will be
PE> 40c per week to me, so I would have to save 40c per week on my phone
PE> bill from DAY 1, nevermind paying back the principle.
BG> And if you delve a bit deeper into that premise, you might be horrified to
BG> learn exactly how much your computer has cost you as well. And your TV,
Yes, that is true, but then with the VCR I can take a look at how
many man-hours I spend watching the VCR, and the cost of the VCR
is NOTHING. Anyhow, it still doesn't alter the fact that I want
to see $200 of improvements on the USR.
BG> Does your contents insurance policy cover lightning damage? Mine does now,
I don't believe in insurance. I prefer to play a long-term gamble
with the odds in my favour.
PE> Bill, I've never been able to get any modem manufacturer to fix
PE> my bugs. I couldn't get Borland to fix their compiler, etc etc.
PE> Not much use having the feature if the real problem is that they're
PE> not going to fix it.
BG> Why do you think USR have released half a dozen SDLs over the past 18
BG> months or so then? Some were feature upgrades, but most were bug-fixes,
Bill, I sent a massive list of bugs to USR technical support, and
not even half-an-answer on one of them. I do not consider them to
be any different to Borland.
BG> and even more importantly, ALL of them were free. You may not care for the
BG> Courier's quirky behaviour with auto-bauding (or Rod's Supra :)), but I
BG> find it hard to believe that you think that USR don't fix their bugs.
BG> Clearly, they do.
Clearly they don't, unless you can crosspost a reply from USR that
was something other than a heap of shit.
BG> Forget the speed difference.
PE> Then you're forgetting the only thing that would be of any difference
PE> to me anyway. And only a VERY MARGINAL difference at that. Certainly
PE> isn't saving ME any money. It MIGHT save my ISD callers some money,
PE> but every time I've looked, ISD callers get very low connect speeds
PE> anyway.
BG> No, you're completely ignoring interconnectivity (and yeah, I know how you
"any difference to me" I said.
BG> feel about people who use non-ITU protocols, but your M34F also does V.FC,
BG> in case you hadn't noticed :)), plus the future upgradeability of the
Although I find the V.FC polluting my modem mildly disconcerting, I
probably wouldn't actually switch it off. I would switch it off the
moment I thought it might be interfering with my standard V. things.
In other words, they're of ZERO value to me, and you have to come up
with *$200* worth of benefits to *ME*. Otherwise, the Netcomm is the
better buy, to *ME*. Actually, you can get $200 in Dieter's SE, the
modem lockup I experienced, and the USR Courier failures.
BG> Courier, which IMO, is its most valuable feature. It basically means that
BG> there's no longer any need to replace your modem every time a new feature
BG> is introduced, and over a year or two, that more than makes up for the
BG> extra $200 up front anyway.
Over the last year and a half that USR have been flogging their V.34
modem, how many features have been added that would be worth $200
to *ME*?
BG> worthwhile). The REAL advantage with the top-end modems, like the USR
BG> Courier and the AT&T Paradyne, is the future upgradeability of these
BG> products, and I for one am more than happy to pay a premium for that
BG> ability.
While my $200 compounds, by the time you find a feature worth $200,
the modem wil probably only cost what my money has compounded to
anyway!
BG> bought a lemon (ever tried juicing a lemming? Urk!), I do believe that
BG> you've locked yourself into a modem which will never be anything more than
BG> it is now. And if you don't mind that, fine. Incidentally, it's a great
Yeah, I would agree with that. I said at the outset that no matter
what modem I bought, I would have to live with all the bugs that
were in it, because I knew at the outset that no-one was going to
fix my bugs.
BG> pity you insist on running Austel approved, because the sysop price for the
BG> Courier is US$249, which is not too shabby at the current A$0.78/US$1.00
BG> exchange rates.
I thought the Courier was meant to be cheaper here? Something about
less sales tax?
PE> If you want to convince me that I got landed with a lemming in order
PE> to save $200, you have to come up with something that interests *ME*.
BG> I can't answer that, because apart from murdering pigeons, I have
BG> absolutely no idea what you find interesting.
Very little actually. Speed (standard speeds) and incoming faxes
come to mind.
BG> Did you ever have a read of
BG> the Courier's on-line manual, which lists all of its extra features in
BG> great detail?
No. But the major ones you have mentioned are of little interest.
PE> Most of my users are local, and if they buy proprietry modems they
PE> deserve all they get.
BG> That's a bit unfair, don't you think?
No. Proprietary standards are a menace.
BG> And you have V.FC after all...
If they come for no extra cost, I guess they're not a problem. I have
seen V.FC connects here before, and I am wondering whether the stupid
V.FC has somehow interfered with the V.34 negotiation. I'll have to
see what happens if I switch it off for a while, assuming I can.
PE> What concerns me is people like Dieter, who are using a standard modem, and
PE> not connecting.
BG> Is he still having problems then?
Not right at the moment, but he may in the future, or maybe someone
else with an SE will.
BG> I thought he'd replaced the Maestro with
BG> a NetComm, or something like that. I guess not, eh? :) BTW, did he have
BG> any problems connecting with Paul's Courier while you had it? I forget
BG> now.
No, he had no problems with the Courier or the Viper. Maybe I
should swap with the Spirit Viper, which I can do for free? He is
one of these internet guys who thinks the M34F is really great,
even though it has the occasional lock-up! I didn't particularly
trust them before when they described the problem to me in terms of
Unix CICO or some-such rubbish.
PE> You're not doing a very good job, Bill. You have to tell me why CID
PE> and distinctive ring are worth $200 to me.
BG> I'm not suggesting that they are though. I'm merely using those features
BG> as an example of the desirability of a generic DSP powered modem in which
BG> the flash ROM code controls the entire modem. Somebody mentioned the other
BG> day that if USR so desired, they could even flash their ROM to work as a
BG> sound card. :)
Ok Bill, for no extra cost, yes it is desirable to have a generic
DSP modem, and indeed, I would want one. However, for an EXTRA
cost, of a massive $200 even (not that far from the cost of a
Dynalink?), you have to be a hell of a lot more specific than
"things in the pipeline".
BG> No problem, the USRs work quite well when discriminating between fax and
BG> data, although the required init$ is a bit of a nightmare. I also read
BG> somewhere that their Class 1 mode will also discriminate, but I have no
BG> proof of that.
Do you know if the Netcomm does? BTW, good news! Binkley 2.60 is
supposed to be released in a couple of weeks (I've heard that
before though!), so if Netcomm + Binkley 2.60 can do faxing for me,
that would be really great.
PE> No, your zealotry is in making unsubstantiated claims, and dragging
PE> out strawmen like "the manual doesn't say you can use ATZ as an init
PE> string". You really don't know how pathetic that looks from here, Bill.
BG> Don't take everything I say too seriously Paul, will you? :)
If you are making jokes, do them outside a serious technical
discussion. So are you coming clean about the ATZ now?
BG> I don't have your Courier "fault" list immediately at
hand, but there are a
BG> couple of complaints on it which are COMPLETELY unjustified (the one about
BG> the S56 register, for a start). It's a shame also that you weren't using
Why is it unjustified that S56 should match the manual?
BG> one of the better SDLs, as changing that is basically identical to changing
BG> the entire modem.
I was using the latest Austel-approved one. If that is faulty, it
is not my fault.
PE> Although I listed a greater number of technical faults with the USR,
PE> the problems were not as severe as those that I had with the Netcomm.
BG> And some weren't even legitimate problems at all.
You'll have to elaborate on that. I only listed them as faults because
they were faults, IMO.
BG> Anyway, if you ever manage to find a modem which connects perfectly with
BG> every other modem in the field, do let me know - I'd buy it at ANY price.
What I'm after is the best one in that regard. Oh, and that doesn't
lock up, either.
Here's the fault list...
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. Later trials were unable to reproduce
this problem, got solid 14400 connects always, so probably not
a problem after all.
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.
15. A Spirit II was getting 9600 bps connects to me. Replacing
the Courier with a Netcomm M34F or a Spirit Viper restored the
14400 bps connections.
@EOT:
---
* Origin: X (3:711/934.9)
|