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

Thu Jul 12 18:13:06 EDT 2012

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120712/d9697630/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fagdhefh.png
Type: image/png
Size: 50415 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120712/d9697630/attachment.png>