<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I've considered that on numerous
occasions but the issue is that in too many networks there are too
many different styles of digipeaters.<br>
<br>
In a perfect world, every digipeater would insert its callsign and
decrement the N in WIDEn-N or XXn-N so that assumptions could be
made at the receiver as to what the path originally was.<br>
<br>
Unfortunately, the APRS RF network is anything but perfect. There
are digipeaters that don't insert their callsign. There are
digipeaters that replace an alias with their callsign (WIDE1-1 is
a popular one to disappear). There are digipeaters that don't
decrement, but mark things used (ever seen a WIDE1-1*?). And
there are digipeaters that simply repeat the packet as received
with no changes.<br>
<br>
So, until all of the above are completely gone from the network
and the entire planet is fully WIDEn-N compliant (which means
replacing a bunch of obsolete hardware that cannot be made fully
compliant), I for one am not going to release software whose
default settings don't work in some areas. The support aspects
are overwhelming.<br>
<br>
Besides, just because you received a message that says AB7-3
doesn't mean you need to transmit an entire AB7-7 path. In actual
fact an AB7-4 or AB7-5 might be sufficient. Only a human can know
for sure (or at least make a better guess).<br>
<br>
And the logical extension to this is to simply reverse the used
portion of the path asking the response message to go back out
through the digipeaters that delivered it. That also doesn't work
because it's not necessarily true that if A can hear B on the way
here then B can hear A on the way back. Reversing used
digipeaters explicitly is, IMHO, less likely to succeed than using
a beefed-up alias.<br>
<br>
Now, if you were to ask software authors to make the received path
of message packets visible to the user and provide a QSO-specific
manually-entered outbound message path override (which of course,
defaults to the station's normal beacon path), that might be a
step in the right direction.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
On 10/3/2013 9:58 PM, Tony VE6MVP wrote:<br>
</div>
<blockquote cite="mid:0MYPXt-1VNqEK3DUH-00VlWz@mx.perfora.net"
type="cite">
<font size="3">At 07:38 AM 2013-10-02, Andrew P. wrote:<br>
<br>
>So we can find each other when needed, here's the start of a
list of
<br>
>APRS software authors. <br>
<br>
Excellent idea! I'm thinking. Wow, what an influential group
is following this mailing list. Now what suggestions do I have
that
are generic? <smile><br>
<br>
Here's one. If your device/software can reply to
messages please do not use the device/software default path. If
you
can review the path of the message you have received and attempt
to use
that path when replying. <br>
<br>
Scenario. My device/software is set to beacon on WIDE2-2. But
I get a message via AB7-7 (Alberta). I'd like to have the
acknowledgement and my reply automatically set to use AB7-7. Of
course by the time I get the message it might be AB7-3 but you
get the
idea.<br>
<br>
Tony VA6OO</font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>