| |
PA2AGA > TCPDIG 19.09.96 04:35l 123 Lines 5384 Bytes #-10881 (0) @ EU
BID : TCP_96_192A
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/192A
Path: DB0AAB<DB0PV<DB0MAK<DB0HOT<DB0LPZ<DB0ERF<DB0DNI<DB0FP<DB0SRS<DB0ZDF<
DB0AIS<DB0NDK<DB0ACH<DB0ACC<PI8DRS<PI8DAZ<PI8APD<PI8GCB<PI8WFL<PI8VNW
Sent: 960918/2207Z @:PI8VNW.#ZH2.NLD.EU #:5472 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA17657 ; Wed, 18 Sep 96 21:15:51 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00004784 ; Wed, 18 Sep 96 00:29:09 MET
Received: from pa2aga-10 by pa2aga with SMTP
id AA00004733 ; Wed, 18 Sep 96 00:16:24 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.61/7.1) with SMTP
id AA00005576 ; Wed, 18 Sep 96 00:16:19 MET
Date: Mon, 16 Sep 96 21:42:29 MET
Message-Id: <tcp_96_192A>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/192A
X-BBS-Msg-Type: B
TCP-Group Digest Mon, 16 Sep 96 Volume 96 : Issue 192
Today's Topics:
ARRL "Representation" on code and other issues
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sat, 14 Sep 1996 18:11:41 GMT
From: gary@ke4zv.atl.ga.us (Gary Coffman)
Subject: ARRL "Representation" on code and other issues
In article <5181co$eu5@news.ais.net> carl@ais.net writes:
>In <515dh1$i6n@hil-news-svc-4.compuserve.com>, 73700.12@compuserve.com (Jim
Nuytens) writes:
>>While I don't like CW and don't see it as anything I'm likely to pursue, the
>>plain fact is that to have anyone believe that the reason we don't have
viable
>>high-speed packet links is because of CW, is going WAY out on the proverbial
>>limb.
>
>I'm saying that we'd be further along if we had not driven hordes of
>technically skilled/computer-savy folks away with the code requirement.
Years ago that was correct. When packet was enjoying its first burst
of activity, there was not yet a code test free license and it was
harder to create a critical mass. That's not as true at VHF+ now where
we do have a code test free license, but now we have to fight an established
inertia toward the slower methods. That's a problem, but we're dealing
with it, and it would have existed to some extent even if Morse testing
had never been an issue.
The Morse requirement is still a problem at HF, but restrictive rules
are a bigger problem there. The rules were shaped around RTTY, plain
text, and plain FSK. They express a narrower is better bias. As people
who've studied communications theory know, narrow is not always better.
There are situations where it is better, and other situations where it
is not. Many of the modern techniques fall in the latter category.
HF in general is plagued by too many restrictive sub-bands. This is
hindering fuller exploitation of the resource. As Phil Karn has noted,
use of SS technique on HF would have very large benefits toward more
effective utilization of the resource. And of course systems like Piccolo
and the NATO STANG modem require a larger bandwidth in which to operate
than is permitted, yet they use the bandwidth more efficiently than
most current narrow techniques so the net effect is that congestion
should actually decrease. Narrow technique is not necessarily always
inferior, however. There are cases where narrow is best. We should
retain the flexibility to go either way as the situation warrants.
>>I'll tell you why packet has stagnated. It's because hams (in general)
reflect
>>the apathy and laziness of the general population. Couple that with the
(until
>>recently) high costs of those links and you get no forward progress.
Everybody
>>agrees (in theory) that we need the network to be there, but nobody wants to
>>PAY for it. Try and ask hams for finances to pay for the radios, TNCs, and
>>computers to run these systems and see how far you get. They'll cough up
money
>>for voice repeaters, but not digital ones.
>>
>
>The "radios, TNCs, and computers" part is a BIG part of the problem.
>The (computer+TNC+radio) model is backward, limiting, and expensive.
>
>Try (computer+RF_modem) ... problem is all the appliance operators can
>think of is (radio+TNC+computer)=(big_bucks_4_1200/9600SLOW))
>
>New blood and new ideas are what are needed to leap forward ...
There's a good bit of truth to this. This obsolete paradigm is
a costly hinderance. I constantly see people tying up as much
money in a 1200 baud station as it would cost to run 56 kb.
This is ridiculous. It is an educational problem, however. The
task is to show people the better way and explain the benefits.
>>Besides, you can't get more than 2 hams to agree on anything. I remember a
few
>>years ago when they (BBS ops, node ops, etc.) tried to get together to form
a
>>comprehensive plan for a network here in DE. By the time the "meeting" broke
>>up, there were threats of bodily harm being flung about because these jack-
>>asses couldn't park their egos at the door and compromise for the good of
the
>>amatuer packet community as a whole. That's another big reason you don't
have
>>the high-speed networks in place as well. 2 people trying to get a high-
To be continued in digest: tcp_96_192B
Read previous mail | Read next mail
| |
