[aprssig] Final version of New n-N aradigm

Keith - VE7GDH ve7gdh at rac.ca
Tue Jan 11 16:22:13 EST 2005


Wes KD4RDB wrote on 11/01/2005 7:41:31 AM PST

> What we really need is smarter RELAY digis.... we should have the APRS software
> disable the MYA RELAY in TNCs, and ONLY if you run in KISS mode can you be
> a relay.  The reason for this is that in order to make the relay stations
> smarter, they need to queue a packet instead of RELAYing it immediately. Then
> if, say 5 seconds goes by and the packet isn't heard from one of the "big 3",
> then relay it... otherwise discard it and realize that there is no need to
> relay forward to a digi.
> 
> I think DOS aprs is the only aprs client remaining that does not provide KISS as
> a connection method.  We could just ask DOS aprs users in the LA area to turn
> off their TNCs built in RELAY function.  Of course there is no chance to add
> this feature to UI-View... bummer.

Re your final comment about UI-View... I think that UI-View32 is perfectly capable of doing what you are describing. Just look in "digipeater setup" and look for "dupe seconds" and hit F1 to read the help on the subject. Here is an exact quote.

"Dupe secs - if this is set to a value other than zero, then, every time UI-View32 is going to digipeat a frame, it checks to see if it has digipeated the same frame within the previous "Dupe secs" seconds. If it has, then it won't digipeat it again. The idea is, for example, to avoid digipeating a frame heard via one digipeater and then heard via another digipeater.

Deciding if a frame is a duplicate is not an exact science! For instance, message frames that fail to get an ACK will be resent; if "Dupe secs" is set too high, then the resend of the frame by the originating station will be regarded as a duplicate when in fact it isn't. A value of 15 seconds for "Dupe secs" is a reasonable starting point."

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"





More information about the aprssig mailing list