[aprssig] KJ4GQV ClusterBalloon Flying

[Stephen H. Smith]

  On 7/31/2010 12:45 PM, Matti Aarnio wrote:
>
> What?  Is my APRS digipeater code wrong as it treats all  WIDEn-N
> constructs the same and does dupe suppression on them all?

Under the current "New Paradigm" standards, WIDE1-1 _*IS*_   treated 
differently from higher orders of N-N

The whole WIDE1-1, WIDE2-1 construct was invented (it was my proposal years 
ago) to work around the "brain-dead" firmware limitations in Kantronics KPC3 
TNCs. These TNCs are by far the most widely-used piece of hardware for 
stand-alone digis without a computer in the US.   [It's hard to beat the 
simplicity and low power consumption (15mA at 12 VDC) of a KPC3+radio digi at a 
remote site.]    The problem is that KPCs do dupe suppression on WIDEn-N paths 
but NOT on plain  RELAY or plain WIDE.

On the other hand, many home users operating first-tier low-level digipeaters 
(that in the past responded to "RELAY") use old TNCs (such as PK-232s, TAPR 
TNC-2s, MFJ 1270s, etc) that do not have APRS-aware firmware in them.  These 
older devices _CAN NOT_ do   n-N   decremented SSIDs.

With rapid APRS growth in the early '2000s, the volume of unnecessary APRS 
traffic due to RELAY and plain WIDE not supporting dupe checking just 
exploded.    A lot of discussion followed on how one could migrate to an 
exclusively WIDEn-N network (with effective dupe control)  while still 
allowing  non-N-N-aware   home fill-in digis to remain part of the APRS 
infrastructure.  At the same time, one wanted to prevent home digis from acting 
on anything but the very first hop of a path.

The solution was the two-part  WIDE1-1,WIDE2-n path I proposed.

All home low-level digis set WIDE1-1 as a simple alias to be treated as an 
ordinary callsign of WIDE1 with an SSID of -1.   When a "dumb" home digi hears 
WIDE1-1 as the first hop in a path, it digipeats it just like any other fixed 
callsign, marks it as used, and passes the second WIDE2-1 or WIDE2-2 part 
onward to the next tier of "real" N-N digis.    (The home digis completely 
ignore WIDE2-anything or higher since only WIDE1-1 is set as an alias to 
digipeat on.)

True high-level WIDEn-N will respond to any value of WIDEn.  If a high-level 
digi (that DOES have proper WIDEn-N support) happens to hear the initial 
transmission, it will process WIDE1-1 as a decremented n-N, mark it used up and 
hand the second half WIDE2-n to the next (high-level) digipeater(s).


The difference when monitored off the air after the first hop is that a home 
fill-in digipeat of the first hop would yield

      WA8LMF to APRS via  WIDE1-1*,WIDE2-1

while a first hop captured by a "real" decrementing WIDEn-N digi, would produce

      WA8LMF to APRS via WIDE1-0*,WIDE2-1
               or possibly
      WA8LMF to APRS via *WIDE1*,WIDE2-1

if the monitoring TNC's firmware treats an SSID of "zero" as effectively no 
SSID at all for display purposes.


The low-level WIDE1-1 home digis far outnumber the WIDE2-n "true wides".   
Beaconing WIDE1-1 as the first hop from aircraft (that have a range of hundreds 
of miles/km line-of-site) can potentially trigger hundreds of home WIDE1-1 
digis simultaneously,  when then ALL retransmit to the nearest true WIDEn-N 
systems.  If the first hop from an airborne station is a WIDE2-n only (which 
the home digis just ignore) a few "true wides" rather than hundreds of home 
stations will be triggered.



Yes, the whole scheme is a kludge to work around the limitations of 20-year-old 
"clunker" TNC hardware, but it does kinda' sorta' work.........


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

--

Stephen H. Smith    wa8lmf (at) aol.com
EchoLink Node:      WA8LMF  or 14400    [Think bottom of the 2M band]
Skype:        WA8LMF
Home Page:          http://wa8lmf.net

NEW!    *** HF APRS over PSK63 ***
    http://wa8lmf.net/APRS_PSK63/index.htm

Universal HF/VHF/UHF Antenna Mounting System
   http://wa8lmf.net/mobile/UniversalAntMountSystem.htm

"APRS 101"  Explanation of APRS Path Selection & Digipeating
   http://wa8lmf.net/DigiPaths



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20100731/3b28fe51/attachment.html>