OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   23.04.03 09:23l 203 Lines 9862 Bytes #999 (0) @ WW
BID : 1195-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 20, 6/8
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0MRW<OK0PPL<RZ6HXA<SP7MGD<IW8PGT<ON0AR<
      VE2PAK<N1UAN<ZL2BAU<ZL3VML
Sent: 030422/1103Z @:ZL3VML.#80.NZL.OC #:64355 [Chch-NZ] FBB7.00i $:1195-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: a few basic questions....
From: Randy Allen <ka0azs@earthlink.net>
Date: Sun, 20 Apr 2003 20:05:03 -0400
X-Message-Number: 31

"Daron J. Wilson" wrote:

>1.  Automatic Position Reporting System as I understand it, so why do so
>many home stations (who obviously are in the same place all the time)
>beacon endlessly with their position?  What is the benefit of this?

  I have mine set to beacon every 1/2 hour so that it stays active on
DOS screens.  I don't know what the decay rates for other versions are. 
Hopefully enough to keep me active while minimizing chanel loading.

  I beacon a fixed home position for several reasons:

        a.  So that if it drops off the air while I'm not home, I know I
have a problem with the shack.

	b.  Gives others a place to drop me a message if I'm not on the air
with my mobile station.

        c.  And gives someone with a low power tracker or mobile a station
to relay to one of the local WIDE digi's.

  It also gives me a station to demo my mobile unit to someone with
messages, direction/bearing, etc. without filling someone else's inbox.

  I will probably eventually set up an I-Gate as well, but can't bring
myself to lose the stability and reliability of my dedicated DOS machine
to move to something that will talk with my LAN and cable modem.

 I don't do weather station (yet) and so won't address this point

>3.  I'm unclear on the RELAY vs. WIDE setting.  Lets say that I can hear
>two WIDE digi's and three RELAY stations, and I have my tracker set to
>transmit RELAY,WIDE2-2.  Do all three relay stations attempt to transmit
>my packet?  What if I am out of range of any relay station, and I
>transmit?  Do the WIDE stations picking up my packet retransmit it
>anyway even though it is prefaced with a RELAY?  Is there any
>Delay_before_retransmit type timer in the digipeater software that could
>be set to different parameters?  It seems like a heirarchial timing
>scheme would allow the closest relay/wide digipeater to handle the
>traffic.

  If you're using a tracker with RELAY,WIDE2-2, then it's possible that
all 3 RELAY stations will re-transmit, but once of the WIDE-N  DIGI's
hears it, the other DIGIs should ignore the RELAY and only re-transmit
according to the WIDE-N protocol. Most DIGIs I know of will also
re-transmit a RELAY it hears, but I learned long ago never to say  "ALL"
or "WILL" on this SIG :-). 

 Since you never can be sure which stations will hear the tracker when,
this gives an increase reliability, (probability of being heard on the
network) even if not the most efficient.  At the risk of speaking for
others on the sig, APRS was designed for TACTICAL operations, with a lot
of redundancy to ensure something gets through.

  A side note.  If you are a fixed station, you almost NEVER should have
a path of RELAY,WIDE...  You need to determine what DIGI's you can hear,
and place those DIGI's in the path to digipeat through.  Example.  I can
hear KC8HFX-10, W8APR, and W8MWO direct from my house.  I have a
rotating path set up in APRS DOS where 50% of the time I'll go via
W8APR, and 25% of the time each for KC8HFX-10 and W8MWO.  That way, if
one goes down, the others will cover me for at least 50% of the time.  I
do NOT have RELAY in my path. (but do have it as an ALIAS to help any
low power trackers in the area).

  I hope this helps

73

-- 
Randy Allen, KAĜAZS

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

Subject: RE: a few basic questions....
From: "Daron J. Wilson" <daron@wilson.org>
Date: Sun, 20 Apr 2003 17:40:30 -0700
X-Message-Number: 32

>>1.  Automatic Position Reporting System as I understand it, so why do so
>>many home stations (who obviously are in the same place all the time)
>>beacon endlessly with their position?  What is the benefit of this?
> 
>It allows others to know that they are there?
>The arguement about if a stations moves or not is moot.

I disagree.  The whole point to having a dynamic positioning system is
that the data transmitted indicates change.  If this were not the case,
we could employ a static system that would simply pull data from a
license database, draw a quick map, and be done (perhaps like a grid
square map).

>Although it may look like a home station, they could be acting as an
>I-Gate or a relay station and just choose the House Symbol.

Certainly it could.  I have successfully transmitted from my mobile
tracker my position many times without any knowledge of who was an
I-Gate or relay station, so I'm unclear why they must beacon regularly.

>>2.  The weather data is very interesting, and I have a home weather
>>station putting data on the internet already.  But then I got to
>>thinking, if we are concerned with channel crowding, what roll in
>>Automatic Position Reporting do fixed weather stations provide? Perhaps
>>it would be better if they output their data on the packet network or a
>>dedicated weather network and then it were picked up since their
>>position doesn't change?
> 
>Think of the total collective picture.  Take your grid square for
>example....how many 'anything' do you have in your grid square?
>Anything...Houses, objects, items...anything.  Even on Firenet!  Does what
>is showing in your grid square represent the enviroment to any major
>degree?
>I think you will notice hardly anything
>is truely represented in your own grid square.  I use the grid square
>approach to show that APRS and the data that is there now is nothing
>compared to what it could be.  The ability is there!  The technology is
>there....the attitudes and the rules Hams have to live by do nothing but
>hurt the ability of APRS.
>If the postions were not reported, you could not know where they were at.
>Let's say you were driving down the freeway and because you noticed the
>weather, right where you are at that given time,
>was getting bad...and indicators....like cars coming the other direction
>had
>their lights on, dragging tree limbs behind them, dark skies ahead, etc.,
>you look at your ever reliable APRS map and you look at...let's just say 5
>weather stations that are 20 miles from you in the direction you are
>heading.
>And they were showing gusts of 150 miles an hour and loads of rain, would
>you continue( okay...let's assume you are not a storm chaser)?
>That is what they could provide.  You would know that there was something
>seriously wrong ahead and that maybe you should not continue....the data
>does not have to be exact, but you would know something is up as you just
>ingested several pieces of the total picture.  A.  Car with lights on. B.
>Cars dragging tree limbs.  C.  Weather getting bad right were you are. D.
>Dark skies ahead.  E.  Flaky APRSWXNET weather stations are reporting very
>high winds and loads of rain.
>Collectively, your instincts are telling you there is trouble ahead with
>the
>all the data you've just ingested.  As I keep preaching, how you ingest
>that
>data is your choice!  And another one...MORE IS BETTER.

Wow!  That is a fascinating emotional story, I particularly enjoyed the
image of the cars dragging tree limbs.  I am unable to glean a logical
explanation from most of it.  Let me say I am not against weather data,
I will likely add a weather station connection at some point as well.
My point was that there is in fact congestion on a network designed and
implemented for position reporting, and one way to reduce that
congestion is to not propagate signals that are not of dynamic
positioning data.  More is not necessarily better for data.  A very
basic understanding of data should show that in order for the data to
provide valid information it must in fact be accurate (or reasonably
so).  A quick bit of math would show that every bit of inaccurate data
decreases the reliability of the total data collected.

>When a company builds a network....and over time the network begins to
>show
>signs of overload, what do they do?  They get with the program and design
>additions so that their network will grow and be healthly, they invest in
>their network.
>What do many hams do?  I've seen this since the first day of packet in So
>Cal.  First, they build their little network and become gods.  When it
>overloads they whine like it's the end of the world and tell everyone it's
>the fault of the users.  They then become control freaks and start placing
>limits on things.  Instead of "growing" their part of the network, they
>hinder it to the point it's worthless.  Add a channel, add a backbone,
>lower
>a high node, teach a class, but dont whine to me as a user for cluttering
>the channel...it's not yours!  This is not directed at you...just
>conversation.  So, there really is not an overload problem anywhere except
>in the minds of those who do nothing to make it better.  I am not saying
>dis-respect your neighboring hams
><this soapbox switch wont turn off!  Darn>

Not too sure who stepped on your toes there, wow.  I do understand
networking, I was knee deep in the packet digipeater conversion to
nodes, in fact put up one of the first ones in Oregon.  Later we added
220 and 440 backbones that are still in place, in the same cabinet with
the new APRS digi.

As far as overloading the network, I see only one thing that can do
that.  To overload a network, you must attempt to push more data through
than the network was designed for.  Whose fault that is really doesn't
matter.  To fix it one either has to reduce the data, or increase the
network bandwidth.  Until the network bandwidth is increased, the
responsible option is for all the users to conserve.  This part is
rather basic, this same understanding can apply for all networks
including voice.

Thanks for your input, I certainly know your viewpoint now!

73's

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



Read previous mail | Read next mail


 15.11.2026 01:10:01lGo back Go up