[aprssig] Good God! Western Mountain Top Digies Go Vast Distances!

[AE5PL Lists]

> -----Original Message-----
> From: nc8q-1
> Posted At: Wednesday, September 29, 2004 7:48 AM
> Subject: Re: [aprssig] Good God! Western Mountain Top Digies 
> Go Vast Distances!
> 
>  "This is STRICTLY RF"
> How can you tell?  I see many DX stations with WIDE#-# in 
> their digipeater fields, when I run UI-VIEW.  Does not this 
> indicate that, at some point, the data was transported over 
> the internet?  You did not show the 'raw' data received.  

Packets gated to RF are in third-party format and will have either
TCPIP* or TCPXX* in the 3rd-party header (reference the APRS
specification).

WIDEn-n in the AX.25 path simply indicates that the sending station is
trying to use the flood algorithm between digipeaters.

It is possible that UI-View does not differentiate between gated and
RF-only packets, but having traveled extensively through the mountainous
west, Stephen's statement about distances covered by mountain-top
digipeaters is true.  Even back in the 80's when we were using simple
NetRom based on digipeater nodes on mountain tops, it was not unusual to
make a LA-Phoenix connection (although it tended to be very unreliable).
Of course the more hops that you go through, the less reliable the
communication (especially using UI frames in the broadcast mode that
APRS uses).

By the way, it is incorrect to call the broadcast method that is
implemented in APRS "ALOHA".  The ALOHA transmission protocol as defined
by the U of H in their testing and operation is reliant on positive
acknowledgement of every packet from the remote station which, of
course, does not exist in APRS except in messaging.  Even in messaging,
as Bob has pointed out, some clients such as APRSDos do not actually use
positive acknowledgement but rather broadcast multiple acknowledgements
over time for the same packet.  I am not saying that this is bad, just
that it is not the ALOHA transmission protocol.

APRS, as defined today, uses a simple broadcast method based on no
signal being received on the transmitting frequency.  This is a
rudimentary CSMA operation as stations are not guaranteed to see one
another, yet it is CSMA none-the-less.  Setting Persistence and Slottime
are simply adding a randomness to the "wait-for-silence" algorithm
theoretically reducing the number of collisions over time.  Bob has
indicated in the past that WIDEn-n digipeaters should be set for a
slottime of 0 and a persistence of 255 as collisions between these types
of digipeaters should be inconsequential (and possibly beneficial for
overall bandwidth availability).  I don't remember any other recommended
settings for these values although there has been good discussion here
about this.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net