| |
PA2AGA > HDDIG 26.09.99 09:54l 178 Lines 7801 Bytes #-9759 (0) @ EU
BID : HD_99_241J
Read: GUEST
Subj: HamDigitalDigest 99/241J
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0MW<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8APD<
PI8WNO<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990926/0248Z @:PI8VNW.#ZH2.NLD.EU #:2723 [HvHolland] FBB7.00g $:HD_99_241
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19937 ; Sun, 26 Sep 99 00:34:57 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00015950 ; Sun, 26 Sep 99 01:09:10 MET
Date: Sun, 26 Sep 99 01:03:50 MET
Message-Id: <hd_99_241J>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/241J
X-BBS-Msg-Type: B
and useful application of amateur radio.
Those of us who worked toward its development also found designing
and building it to be fun, and a considerable technical and organizational
challenge. That's good, because we don't get paid any other way for doing
it than in the satisfaction of learning how to do an exacting job well, and
seeing our creation prosper and maintain the loyalty of its users. We haven't
attempted to coerce that loyalty (a fool's errand), instead we earned it by
delivering a network that our users have found to be of continuing utility.
The builders of a voice repeater with poor coverage, poor audio quality,
and poor reliability shouldn't expect to maintain a large group of satisfied
users. That's obvious. It should be equally obvious that the same applies
to amateur digital networks. If you can't provide the level of service
expected
of a digital network (ie fast and transparent transport of the data required
by your users' choices of applications), you shouldn't be surprised when
your users abandon you.
Gary
Gary Coffman KE4ZV | You make it |mail to ke4zv@bellsouth.net
534 Shannon Way | We break it |
Lawrenceville, GA | Guaranteed |
>.
------------------------------
Date: Fri, 24 Sep 1999 19:47:15 -0500
From: "Peter O. Brackett" <ab4bc@ix.netcom.com>
Subject: Let's look at real numbers for TNC software sales
Rob Janssen <nomail@pe1chl.demon.nl> wrote in message
news:slrn7und6b.gb3.nomail@linux.pe1chl.ampr.org...
> >
> For a small country like the Netherlands, a single network operated by
> a state-monitored company (i.e. operated to commercial standards but not
> faced with "competitors" that are only after profitable services, and not
> making too much profit itself) is the better option.
>
> Competition is also introducing extra complexity in the usage of the
system
> and the decisions a customer needs to make. When I want to call someone,
> I just want to dial his number, not be faced with stupid questions like
> "what carrier do you want to use".
>
> Rob
Rob:
I take it that you don't like to shop!
Heh, heh. Monopolists really love folks who hate to shop.
Anti-shoppers always get the products and services they deserve.
Of course that is one of the defining differences between America and most
of Europe.
The "shot heard round the world", was heard because of folks who did not
like, "taxation without representation".
If you want to believe that governments, Kings, beaurocracies, civil
servants, and monopolists will take care of your interests in the long term,
then God Bless You.
Me, I'll put my faith in good old competition every time!
Best Regards,
Peter AB 4BC
>.
------------------------------
Date: Fri, 24 Sep 1999 22:12:13 -0400
From: Gary Coffman <ke4zv@bellsouth.net>
Subject: Let's look at real numbers for TNC software sales
On Wed, 22 Sep 1999 18:21:42 -0700, "Cathryn Mataga"
<cathryn@junglevision.com> wrote:
>Okay, I'm still trying to figure out why his 25mile 'bad path' link
>would necessarily have a BER, as you say, above 1e6. Is there
>any reasonable way for him to really measure this? Maybe a
>problem here is that we 'think' we might have links that are good,
>but they have bit error rates, good enough so the the link 'seems'
>okay, but really the errors are bad enough to cause network problems.
>And that what's really needed are some good tests.
There are standard ways to measure the BER of data paths. One
way that we use is to feed continuous '0' to our modems and count
the '1's that we get at the other end with a totalizing counter. Divide
that number by 2, and we have the bit errors for the path. (We can do
that because our modems, like the G3RUH modem, use a randomizer
which keeps the channel active when we feed in unchanging data.)
>1e6 bits, that's 125,000 bytes or about 490 256 byte packets. Now,
>let's say, he digipeated 500 256 byte packets of random data from his
>system, to the other end and back, we should find that he should miss
>more than a couple, if his BER is worse than 1e6 -- right? Since that
>would have been 2*500*256*8 bits going through the link. That is twice
>for the trip up and back. I'd be curious to know the results of this kind
>of measurement to know how good or bad the link really is. Could
>this be a way to decide if new links are going to hurt or help the network?
>That is simply do measurements of bit errors, and if they're low enough
>it's okay, however the thing works.
The program ax25mon can passively monitor the packets on a channel
and give totals for channel usage and retries. We use something like that
as one of our network management tools to show us any problems network
links may be developing. We also do ping testing to gather statistics on
the network's performance. This has to be a continuing task because the
environment in which the network functions is not a static one (the
construction
crane is our state bird), and equipment does require maintenance from time
to time.
>Also, I'm also trying to figure out what exactly is the mechanism that
>brings in the errors -- assuming that if he did the measurement, we'd
>find BER's much worse. For the speed of light of 186000mps, the
>length of a bit is going to be about that divided 9600 or about 18.6
>miles -- right. So are we assuming then for his weird path of 25 miles,
>he's getting a direct path of 25 miles, and perhaps at the knife
>edge of the mountain in between there are going to be a bunch of
>paths, all coming in at slightly different lengths across the top of
>the mountain range -- as each one deflects off a slightly different point.
>So, maybe some signals are sneaking in on a path that's say 34
>miles long or 1/2 bit late.
That's one problem generated by multipath, ie intersymbol distortion.
The other is ordinary multipath induced RF fading. For that, the path
length differences only have to be a substantial fraction of a wavelength
at the operating frequency. For example, if there are trees on that ridge
line separating the two ends of the path, the wind generated motion of
the trees can induce multipath "picket fencing" similar to that commonly
experienced when a transmitter or receiver is mobile. It will come and go
with changing weather (worse when the trees are wet and the wind is
whipping). Or if that ridge has a highway, traffic along the highway can
produce a similar effect. These fades can punch holes in your data. So
you want to design your paths so that such obstacles aren't within the
first Fresnel zone.
If excessive power is used, reflectors well off the line of sight can
cause multipath reflections which will cause problems. For example,
a water tower 20 miles off to the left or right of the path may generate
a reflection that will be strong enough in the receiver to cause problems
if high power is used. Similarly, terrain features well beyond the receiver
can cause problems when excessive power is run.
You want to keep the power down as much as possible to minimize these
sorts of problems. You also want to use directional antennas and circular
polarization to minimize problems with reflection generated multipath. (CP
signals reverse handedness, like in a mirror, when reflected, and that can
gain you up to about 20 dB of isolation from multipath reflections if both
ends
of the path use CP.)
To be continued in digest: hd_99_241K
Read previous mail | Read next mail
| |
