[aprssig] 30M APRS and digipeaters... (aliases)

Thu Jul 12 21:02:09 EDT 2012

There is still the ONE MAIN problem with any generic alias on HF, and that is DWAIT.  On VHF we depend on Fratricide to force all digipeats at the same time, so the packet goes radially outward one tier per slot.  A WIDE2-2, though it might generate 3 to 5 dupes on the first per tier and 9 to 20 packets on the second slot, it sill only consumes 2 slot times.

On HF that all goes out the window.  If even TWO stations digipeat the packet and remember they are ALL OUT THERE, then both, or 3 r 4 or 10 or 20 will all digipeat at once and NO ONE will decode the digipeated packet because there is total collisions and no RANGE discrimination like there is on VHF.  There is also not any FM capture to at least let a really strong one win.  On HF, any collision is bad.  So we simply CANNOT use Dwait of 0.

But the alternative is WORSE!  With Dwait set to any other value, then every single station hearing a packet WAITS randomly for a clear channel and then SENDS OUT ITS DUPE.  If there are 20 stations on the air, then there are 20 copies all spread out over the next full minute, and one packet consumes a FULL MINUTE of channel capacity!

This cannot work either.

So I am still FIRMLY convinced that having GENERIC ALIAS digipeaters is simply bad practice on HF.  If someone wants to have a digipeat off a strong station he hears, then by all means feel free to use it.  THen you get two clean copies of the packet without collisions from other unwanted responses.

Now if someone with in-depth HF propagation smarts and experience wanted to designate a system of LINKED path of specific digipaters, where they are spaced such that each one only hears its two adjacent neighbors and has a low probablity of hearing the hop beyond, then I would not object to experimenting with such a linear path system.

I think the HF experts could reasonably answer the question as follows:

WHAT is the optimum distance X for a 30m reliable QSO.  Then what is the distance Y which seems to be nearly impossible.  Then hopefully X is something similar to 1/2 of Y and space the digipeaters accordingly.

Then you could even name each such system differently to determine what area you wanted to QRM best (wink)...

Bob, WB4APR

---- Original message ----
>Date: Thu, 12 Jul 2012 18:13:06 -0400
>From: aprssig-bounces at tapr.org (on behalf of "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>)
>Subject: Re: [aprssig] 30M APRS and digipeaters... (aliases)  
>To: TAPR APRS Mailing List <aprssig at tapr.org>
>
>   It definitely clarifies it and thanks for the
>   response.  But I'm wondering how useful a "hot"
>   standby system will be if there's no known alias
>   "waiting in the wings" so to speak.  If I am in a
>   situation and need to get a packet out, I may or may
>   not be able to (or may not have time to) copy
>   anything from the air, so how would I know what
>   specific digipeater to put in my path?
>
>   If I understand the original HF APRS system here in
>   the states, the digipeater alias was ECHO.  I know
>   that some have abused that with their fixed station
>   beacons, but I don't think we should throw the baby
>   out with the bath water.  Maybe we just need to do
>   another round of education for the new HF APRS users
>   (I'm purposely ignoring the proposal from the EU at
>   this point).
>
>   I do agree that it's probably time for the old
>   GATE,<more> to go by the wayside.  As was pointed
>   out, most of the HF stations are probably using PCs
>   and soundcards instead of the old dual-port KAM TNCs
>   and can directly gate received packets to the
>   APRS-IS rather than cross-banding them from HF to
>   VHF with <more> as their unused path.  Shorter
>   packets are always good.
>
>   But I still think it would be good to keep some ECHO
>   alias enabled HF digipeater stations on the air so
>   that a station that really needs the coverage in an
>   unexpected (read: unable to receive) situation can
>   have an alias to put in the path to request
>   digipeater services.  And the operators of said ECHO
>   digipeaters could take it upon themselves to contact
>   stations that are routinely using the alias to
>   provide some education in its proper use.
>
>   Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
>   Mobile and Win32
>
>   PS.  Speaking of shorter packets, I've been beefing
>   up GridSquare support in APRSISCE so that stations
>   can beacon just a short status report packet with a
>   6 character GridSquare and be located approximately
>   on the map.  These stations show up, not with an
>   ambiguity circle, but by actually highlighting the
>   (4 or 6 character) GridSquare that they beaconed.
>   For instance, the following packets put the station
>   below on the map:
>
>   2012-07-12 00:56:19 UTC:
>   KB1TX-10>APWW10,W1CNH-5,WIDE1*,WIDE2-1,qAR,W2AFC:>FN43ju/#
>   APRSISCE/32
>   2012-07-12 12:57:10 UTC:
>   KB1TX-10>APWW10,W1CNH-5*,WIDE1*,WIDE2-1,qAR,K9UDX:>FN43ju/#
>   APRSISCE/32
>
>   (if the image isn't there, try
>   http://tinyurl.com/cewmfao)
>
>   Of course, the packets over HF could be a lot
>   shorter:
>
>   KB1TX-10>APWW10:>FN43ju/#
>
>   On 7/12/2012 5:51 PM, Bob Bruninga wrote:
>
> Lynn,
>
> As you may have seen by now in my other email, my rants against Digipeating
> on HF have only to do with GENERIC blind digipeating.  You are correct below
> to question the details and point out the difference between HAVING the
> ALIAS digipeaters and actually USING them.
>
> But I think I still stand behind the NO GENERIC DIGIPEATING even to the
> extent of not even having the ALIASES in place (except for the TUNE ones.
>
> I think the only digipeating we need is as it has always been.  That is, we
> can use any other STRONG station on a case-by-case basis to digipeat BY
> ACTUAL CALLSIGN if we think it will benefit the QSO at hand.  But we don't
> want ANY UNATTENDED blind GENERIC ALIAS DIGIPEATING which is just QRM to
> others trying to use the channel.
>
> I hope that helps clarify what I'm thinking.
>
> Bob, WB4APR
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Lynn W. Deffenbaugh (Mr)
> Sent: Thursday, July 12, 2012 11:45 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] 30M APRS and digipeaters...
>
> On 7/12/2012 11:37 AM, Bob Bruninga wrote:
>
> Yes, I agree fully.  We never want digipeating on HF.  It just adds QRM to
> everyone and cuts throughput in HALF on an already slow channel.  Now if I
> was SINKING and in a MAYDAY situation, then I might digipeat, because in
>
> an
>
> emergency ANYTHING might help even though it does IMPACT everyone else.
>
> But ONLY in emergencies.  Othwewise the recommendation for APRS packet was
> NO DIGIPEATING.
>
> I hate to pick at details, but does this mean to not set up digipeaters
> on HF, or to not request a digipeat in your transmitted path?  It would
> seem more like the latter because otherwise there'd be no digipeaters
> around even if you wanted to use one for some reason.
>
> And the logical follow-on, based on the response I read from the
> European station, is what alias is supposed to be used if a digipeater
> is configured, but hopefully only used in extreme duress?  I've seen
> ECHO documented on HF APRS most often, but I also see that APRS
> Messenger is doing some WIDE* stuff and the mention was made for WIDE2
> or some-such earlier today.
>
> Lynn (D) - KJ4ERJ - Just trying to learn the details from those that know
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>________________
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig