<html>
<body>
<font size=3>At 04:23 AM 2013-10-04, Lynn W. Deffenbaugh (Mr)
wrote:<br><br>
<snip><br><br>
<blockquote type=cite class=cite cite="">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.</blockquote><br>
</font>Fair enough. I keep forgetting about those because I
don't see any in my usual area of travel in western
Canada. Leave the settings to default as is then but
give the rest of the amateur population the abiltity to enable the proper
tools to use the APRS system in the proper fashion.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>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).</font></blockquote><br>
Sure but so what. xx7-7 is only going to be used for
occasional testing and disasters. Normally from my location I'd use
AB7-3 to get into the big city.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>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.</font></blockquote><br>
I do completely agree with your reasoning there. One of the
very nice features of the APRS system is the redundant nature of the
network of digi's and the dupe suppression of the digi's.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>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.</blockquote><br>
That's be a step but in my opinion only a partial one. What about
the acks? I get a message from James VE6SRV who is five hops away
on an AB path and my acks only go out WIDE2-2. So now my
system sends out a number of acks that will never, ever make it to
him.<br><br>
Tony</font></body>
</html>