[aprssig] Msg reply path (for SSn-N)
bruninga at usna.edu
Sat Oct 5 08:09:12 CDT 2013
> What about the acks? I get a message... [from] five hops away
> on a SS5-5 path and my acks only go out WIDE2-2.
Now that might be a good idea. I agree with Lynn that there are so
many marginal, misconfigured, and obsolete digis out there that
revers-pathing will only create as many problems as it solves.
BUT, in this specific case, of an SSn-N packet, maybe it is a good
idea to change the ACK from the standard (usually WIDEn-N) to a
returning SSn-N. Reason being, it is the ONLY way the ack could get
back and if it was received, then apparently surrounding digis support
I'd suggest that client softwware have a setting for MYSSn-N's so that
the operator can indicate the SSn-Ns in his area. There are so many
and they can be locally strange that the client should not have to
figure out what is an SSn-N call but can use from its configured set.
In that case, I'd suggest a list of 4. That way someone lliving in he
corner of a state but that has interest in surrounding states can
Maybe the list is not needed, and the client can just recognize
anything of the form XX..# - # that is not WIDE or TEMP or TRACE?
On Fri, Oct 4, 2013 at 6:10 PM, Tony VE6MVP <tony at ve6mvp.com> wrote:
> At 04:23 AM 2013-10-04, Lynn W. Deffenbaugh (Mr) wrote:
> 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.
> 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.
> 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).
> 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
> 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.
> 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.
> 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
> 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.
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig