| |
VK7AX > UIDIGI 28.04.05 03:16l 120 Lines 4421 Bytes #999 (0) @ VKNET
BID : VK7AX-2804LY
Read: GUEST
Subj: [Ui-Digi] Digest #472
Path: ON0AR<ON0AR<IW8PGT<IW2OAZ<IK6IHL<I0TVL<TU5EX<N4ZKF<W4JAX<VK4TUB<
VK7AX<VK7AX
Sent: 050428/0246z @:VK7AX.#ULV.TAS.AUS.OC [NWTNOS-NWTas] #:37999 $:VK7AX-2804L
Date: 24 Apr 2005 11:04:19 -0000
From: uidigi@yahoogroups.com
To: uidigi@yahoogroups.com
Subject: [uidigi] Digest Number 472
There are 2 messages in this issue.
Topics in this digest:
1. Re: Brute Force Control of Max Number of Digis
From: Ron Stordahl <ron.stordahl@digikey.com>
2. New Paradigm settings
From: "wsp4400" <markandlisarasmussen@verizon.net>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Sat, 23 Apr 2005 08:15:45 -0500
From: Ron Stordahl <ron.stordahl@digikey.com>
Subject: Re: Brute Force Control of Max Number of Digis
Dick
Ideally the 'New Paradigm' should be implemented in new UIDIGI firmware:
http://web.usna.navy.mil/~bruninga/aprs/fix14439.html
What Bob WB4APR is trying to do as described in his FIX14439 pages is to
do this in as much as is possible with existing digipeaters. As such it
can only be moderately successful, really new firmware is the only real
solution for the reasons you give showing how it can easily be
circumvented. What you suggest, a hard limit, on the number of allowed
digi's in the path, is the real solution. One question arises in what
you suggest..should a sender who's intended path is too long simply be
ignored, or converted to a single digipeat. There may be sysops who
would prefer a choice of one or the other in such cases.
Another part of the 'New Paradigm' is the need to gain greater control
over the scheduled beacon transmissions of a digi so as to legally ID,
yet keep QRM to a minimum. To do so also requires a change in the
UIDIGI firmware as the current beacon offset function does not work.
However this is much less critical than the long path issue.
I would also eliminate the clock function, and simply show in the MH
display the minutes and seconds offset from the current time as was done
in TheNetX1J4. I currently run 10 remote UIDIGI's and have simply given
up on keeping their clocks accurate, it's not worth the effort.
Ron, N5IN
dhrailfan wrote:
>
> I would like to see Marco add a method for the brute force control of
> the maximum number of digis in a path. The routine would be added at
> the start of parsing of the path statement. It would make use of a
> config file parm called "MaxNumDigis". The routine would total the
> number of digis in the path statement and compare that to
> MaxNumDigis. If the count exceded the MaxNumDigis parameter, the
> packet would not be digipeated, period.
>
> This method would take care of the clown who puts "wide2-2,wide2-
> 2,wide2-2" into his path statement to get around a wide6-6 block, or
> the lid who uses "wide,wide3-3" to get around a wide4-4 block.
>
> The routine is simple and short, thus possibly fitting in the little
> remaining space that Marco has to deal with in eprom memory. If
> Marco has insufficient room to implement this function, then I would
> recommend elliminating the forward-by-SSID function.
>
> With the new APRS paradigm's maximum number of digis parms being
> violated by many individuals who will not reduce their number of
> digis, we need a method to fight back. We do have a bud list for the
> occasional individual. However this problem is much larger than the
> available space in the budlist.
>
> Opinions?
>
> Dick W2GWY
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Sun, 24 Apr 2005 02:29:14 -0000
From: "wsp4400" <markandlisarasmussen@verizon.net>
Subject: New Paradigm settings
Hello everyone,
Has anyone tried the new paradigm settings concerning the elimination
of "relay" and using wide1-1. I have tried eliminating "relay" in the
UIDigicall list. That didn't work. I also wrote in "wide1-1" in the
UIDigicall list. That didn't work either. My packets always get
didipeated by the digi I am testing, but it seems that the surrounding
Wides in the area ignore any digied packets that used the wide1-1. Can
anyone help? In case anyone is interested, I am using the path wide1-
1,wide2-2.
Thanks
Mark
N9MEA
________________________________________________________________________
________________________________________________________________________
End Ui-Digi Digest #472
Read previous mail | Read next mail
| |
