OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    12.10.99 14:22l 172 Lines 7711 Bytes #-9721 (0) @ EU
BID : HD_99_257B
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/257B
Path: DB0AAB<DB0ZKA<DB0CRL<DB0TTM<DB0FP<DB0SRS<DB0SIF<DB0HSK<PI8DRS<PI8DAZ<
      PI8GCB<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991012/0809Z @:PI8VNW.#ZH2.NLD.EU #:7484 [HvHolland] FBB7.00g $:HD_99_257
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA21131 ; Tue, 12 Oct 99 07:02:45 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00016339 ; Tue, 12 Oct 99 07:46:47 MET
Date: Tue, 12 Oct 99 07:44:17 MET
Message-Id: <hd_99_257B>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/257B
X-BBS-Msg-Type: B

> >> >Southern NJ on 2M 1200 baud. Worked quite well for us when
> >> >we used it. KW and 4 long yagis in NJ, 200W and two long yagis
> >> >in MA. Antennas at 170 and 120 feet above local terrain.
> >>
> >> Incredible. I bet you were *real* popular with the other people
> >> trying to use that segment of the band across at least 3 states.
> >> And for nothing more than a half duplex 1200 baud link at that.
> >
> >Yes, totally terrible that we should carry on a QSO on 2 meters over
> >a long haul path. My oh my. Better see the "coordinator" and see if it
> >is ok to call CQ using high power on 2M SSB, find someone to talk
> >to a few states away, and then decide to play with digital communication
> >over that path. Oh dear! Next thing you know one will have to get
> >permission to work Aurora or Troposcatter, much less EME!
> >
> >You seem to have misread "... when we used it ..." and pretended
> >that I said "Network link always up."
>
> You presented it as a network link, and the context of the discussion,
> as you reminded me in another post, is network links. Network links
> are coordinated (at least they are if one wants to be responsible),

You mean hams are not allowed to play with digital modes and link
things together without permission from some coordinating group?
When did this happen?

> and such monster troposcatter links wouldn't be coordinated because
> of their impact on other operators and other network links sharing the
> same band segment. Part 97 requires us to use good engineering
> practice, and such links are not good engineering practice on shared
> spectrum. Radio  gaming (Dxing, contesting, etc) is a different topic,
> which I won't address here except to say that those activities shouldn't
> occur in band plan segments set aside for data networks.

Where did I say these troposcatter links were in "band plan segments
set aside for data networks"? Your very narrow view of ham radio
does not even allow you to consider any other activity than "perfect,
planned, coordintated, up forever" network links? Guess you will just
have to miss out on a good deal of the fun that can be had playing
with the various digital modes. Perhaps it is this narrow thinking which
has caused the GRAPES network to become disconnected from the
larger and more extensive ham radio network? Makes sense.

> >Curious: why do you bother to post these messages here?
> >Trying to convince hams to give up ham radio?
>
> I'm trying to explain how to do ham radio effectively and responsibly
> in compliance with both the spirit and letter of good network engineering
> practice. If the sort of chaos one finds on Ch 19 is what you want, I'd
> respectfully suggest you move your activities there.

Har! Gary, you are a giggle!

> Gary
> Gary Coffman KE4ZV  | You make it  |mail to ke4zv@bellsouth.net
> 534 Shannon Way     | We break it  |
> Lawrenceville, GA   | Guaranteed   |


>.

------------------------------

Date: Sun, 10 Oct 1999 13:12:03 -0400
From: Gary Coffman <ke4zv@bellsouth.net>
Subject: Let's look at real numbers for TNC software sales

On Mon, 04 Oct 1999 14:14:11 -0700, Mark VandeWettering <markv@pixar.com>
wrote:
>Honestly, you've done this long exposition about how you desired to
>build a single hop link between these two stations, with absolutely no
>justification that it is better or even desireable to do so.   The
>shortest distance between two points isn't always the straight line that
>you imagine. 

In fact it often isn't. The "do it with one hop" mentality seems to spring
from Dxer roots. It is rarely the best answer to a network design problem 
because of associated link reliability and capability issues. AT&T 
established a set of RF path guidelines for network engineering over 
50 years ago. They're still valid. Physics hasn't changed.

>Your "solution" to overcoming the large amounts of local noise at
>station B by upping the ERP at station A is mighty un-neighborly. 
>Spraying all that extra power around limits the abilities of others to
>use that spectrum space that you're polluting.
>
>As hams, we are supposed to operate within the bounds of good amateur
>practice.  This governs not only what we should do, but also what we
>should not do.  We should not needlessly pollute spectrum with excessive
>QRM just to satisfy our largely egotistical need to generate a single
>hop link.  

Right. One of the factors in sound system engineering design is the impact
the design will have on other spectrum users, and on spectrum re-use by 
the same system. Again, the Dxer mentality of "more power, more power"
is seldom if ever the right answer. It may work for the individual, but at the
cost of a negative impact on the larger community of amateurs.

>When a network WORKS like a network should, multi-hop links aren't the
>bug-a-boo that people seem to think they are.  Heck, a network without
>any multi-hop links isn't a network at all, it is just a bunch of people
>yelling at each other.

Right. A network with only two stations isn't really a network. It is just 
an isolated link. In my view, a packet network has to be able to switch
packets at the network layer, and that requires at least 3 stations to
be anything but the null set, ie a single closed switch is the same as
no switch at all.

>I've seen the argument made here that "any network is better than no
>network".  In fact, I know of at least one reason why that isn't true:
>investing your time in networking strategies and equipment which provide
>only marginal utility keeps you from devoting your time, money and
>energies to strategies which will work.   You can't convert the 1200
>baud BBS packet radio infrastructure into a real network that services
>the applications and users that might wish to use it.  Quite literally,
>"you can't get there from here".

Well, you might, if the original topography of the network, and the individual
link designs, included sufficient margin and low enough multipath for the
higher speed. This requires thinking ahead when designing the original
system, of course. That's rarely done in amateur circles, so you often
do literally have to start over with a clean sheet of paper to build a higher
speed network. That ultimately takes more time and costs more money 
than doing it right in the first place. 

So you're right, investing your time in networking strategies of marginal
utility 
often detracts from the effort which should be expended doing the job right
the 
first time. The latter method grows the network more slowly, but it is more
sure, and produces a network with sufficient robustness and utility to
maintain
continuing support by the user base. I've frequently referred to the GRAPES
network in this context. By holding to a realistic scope and pace of
deployment,
we've been able to maintain a robust and sustainable packet network. Helter 
skelter ad hoc collections of links don't seem to have been able to do as well
in
sustaining a user base or in maintaining network integrity, as witness the
whining 
of Charles, Hank, and a few others.

Gary
Gary Coffman KE4ZV  | You make it  |mail to ke4zv@bellsouth.net
534 Shannon Way     | We break it  |
Lawrenceville, GA   | Guaranteed   |
>.

------------------------------

Date: Sun, 10 Oct 1999 14:27:35 -0500


To be continued in digest: hd_99_257C




Read previous mail | Read next mail


 25.05.2026 09:08:28lGo back Go up