<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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?<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
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:<br>
<br>
2012-07-12 00:56:19 UTC:
KB1TX-10>APWW10,W1CNH-5,WIDE1*,WIDE2-1,qAR,W2AFC:>FN43ju/#
APRSISCE/32<br>
2012-07-12 12:57:10 UTC:
KB1TX-10>APWW10,W1CNH-5*,WIDE1*,WIDE2-1,qAR,K9UDX:>FN43ju/#
APRSISCE/32<br>
<br>
<img src="cid:part1.08030700.08010607@homeside.to" alt=""><br>
<br>
(if the image isn't there, try <a class="moz-txt-link-freetext" href="http://tinyurl.com/cewmfao">http://tinyurl.com/cewmfao</a>)<br>
<br>
Of course, the packets over HF could be a lot shorter:<br>
<br>
KB1TX-10>APWW10:>FN43ju/#<br>
<br>
<br>
On 7/12/2012 5:51 PM, Bob Bruninga wrote:<br>
</div>
<blockquote cite="mid:0dda01cd6078$8b0f2520$a12d6f60$@edu"
type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:aprssig-bounces@tapr.org">aprssig-bounces@tapr.org</a> [<a class="moz-txt-link-freetext" href="mailto:aprssig-bounces@tapr.org">mailto:aprssig-bounces@tapr.org</a>] 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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">an
</pre>
<blockquote type="cite">
<pre wrap="">emergency ANYTHING might help even though it does IMPACT everyone else.
But ONLY in emergencies. Othwewise the recommendation for APRS packet was
NO DIGIPEATING.
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>