[aprssig] UIDIGI and the New Paradigm - WARNING - LONG!

Robert Bruninga bruninga at usna.edu
Thu Apr 7 09:31:06 EDT 2005


What an excellent assessment of UIDIGI ROM support
for the New n-N Paradigm.  Great work!
I can think of two comments:

1)  One of the issues you raise does not appear to be 
unique to the new Paradigm but may just be a bug no one 
has noticed before.  From what you wrote, it appears to me 
that a UIDIGI ROM counts down the WIDEn-N algoirthm 
differently than any other application and adds an extra 
digi hop on the end of every such use.    This might explain 
why you get an  extra hop.

What we expect from WIDEn-N:

   Send WIDE2-2:  then WIDE2-1, then WIDE2*

What UIDIGI appears to be doing is:

   Send WIDE2-2: then WIDE2-1, then WIDE2, then WIDE2*

Appearing to imply that UIDIGI ROMS do not set the 
*has-been-digipeated-bit* when 2-0 has been reached, 
but only does it on the NEXT additional digipeat.  Thus,
all along, UIDIG ROMS have been adding an additional
hop to all WIDEn-N paths.  So this bug should not be
attributed to the New n-N paradigm per se.

2)  The inability to not-trap out *intentional* abusive behavior
is not a failing of the New n-N Paradigm.  No one is traping
them out now, so the fact that we can trap out unintentional
mistakes with the New n-N Paradigm is only a plus.  No 
other stand-alone digi can trap out all possible intentional
abusive paths either.  So again, this is not considered a
fault of the UIDIGI ROM

3) There is no need to worry about the *unintentional* bad
path combinations where N does not equal "n" anyway, 
because if ALL digis simply trap out the 4-4, 5-5, 6-6, 7-7 
at the point of entry, then no other digi will see the other
combinations in the first place.  They wont get into the

4)  Thus the only failing you found left is the fact that you
have to use WIDE1-1, as an alias instead of letting the
WIDEn-N algorithm handle it.  Again, this is not any problem
at all, beacuse (I think) the UIDIGI ROM uses one overall
dupe-elimination algorithm no matter what digi method was
used.  Thus the UIDIGI ROM digi does perfect dupe
elimination on all packets and so having to use WIDE1-1
as an alias is not a problem at all.

Thus, in my accounting, of all the issues you raised, there
is nothing wrong with using a UIDIGI ROM to support the
New n-N Paradigm (with WIDE1-1 as an alias)...   And secondly
there are two things we ask the author to fix in his next release:

1) Allow the sysop to set  a MAX-N limit
2) Fix the beacon algorithm so that the UIDIGI ROM beacons
    can go out locally more often and via 1 hop and 2 hops
    less and less often

Did I miss anything or missinterpret anything?


>>> Ron Stordahl <ron.stordahl at digikey.com> 4/7/05 12:05:42 AM >>>
Testing this evening produced some unexpected results and the
that the New Paradigm cannot be fully implemented in UIDIGI as it 
currently exists.  Skip to the end for a summary.

Wishing to allow only these paths to be fully functional:

WIDE1-1 (for 1 hop)
WIDE2-1 (for 1 hop) - but it's really 2 hops.
WIDE2-2 (for 2 hops)
WIDE1-1,WIDE2-1 (for 2 hops)
WIDE1-1,WIDE2-2 (for 3 hops)

I set the relevant parms thus on the nearby UIDIGI and surrounding 
UIDIGI's that can hear the nearby UIDIGI:

UIDCsb 1 (enable callsign substitution for UIDigi calls)
UIFlood MN (call to be used in the flood algorithm)
UIFLDfl 0 (make call substitution after last 'floodcall' digi'd)
UITrace WIDE (call to be used in the trace algorithm)
UITRFl 0 (make call substitution after last 'tracecall' digi'd)

Then I generated from a TinyTrak3 packets with these paths:

WIDE1-1  (it was digi'd once as expected) - shown in the dig'd packet
N5IN-2*,WIDE1 and not digi'd further.  I can hear 1 level out and did 
not hear another digi repeat the packet.

WIDE2-1 First as N5IN-2*,WIDE2, and a second time as N5IN-2,WIDE2*  I 
had expected it to act just as WIDE1-1, but in fact it acts as WIDE2-2

(in regards to the number of hops allowed).

WIDE2-2 - Shown in the first digi'd packet as N5IN-2*,WIDE2-1 and in
second as N5IN-2,WB0WTI-11*,WIDE2. If it was digi'd further I have no 
way to tell as I can't hear further out.  However I would be willing to

bet that it is in fact limited to 2 hops as it should be.

WIDE3-3 (it was digi'd once only as expected) - shown in the first 
digi'd packet as N5IN-2* with nothing following.  There were no 
additional hops, and I could hear them if they existed.

WIDE3-2 Shown in the first digi'd packet as N5IN-2*,WIDE3-1, in the 
second as N5IN-2,WB0WTI-11*,WIDE3 and I suspect there is a 3rd hop as 
N5IN-2,WB0WTI-11*,WIDE3*, although it would be too far out for me to 
hear. I draw that conclusion based upon what I could here in the case
WIDE2-1, where there were 2 hops.  And if this is so I suspect that 
WIDE3-1 will also produce 3 hops.

Now for combined paths:

WIDE1-1,WIDE1-1.  The first digi'd packet contains
and is not repeated by any of the surrounding digi's.  I had expected a

second hop, but it did not occur.

WIDE1-1,WIDE2-1.  The first digi'd packet contains
and is not repeated by any of the surrounding digi's.  I had expected a

second hop (and maybe a 3rd) but it did not occur.

WIDE1-1,WIDE2-2.  The first digi's packet contains
and is not repeated by any of the surrounding digi's.  I had expected a

total of 3 hops, but only one occurred.

Apparently the WIDE1 is the end of the line, perhaps I should have 
expected that.  In order to permit these to work I had to add WIDE1-1 
into the UIDIGI list thus:

UIDigi WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN  and I also 
made this change in the surrounding UIDIGI's..

Now combined paths again with this new setting:

WIDE1-1,WIDE1-1 The first digi'd packet contains N5IN-2*,WIDE1-1 while

the second and final digi'd packet contains N5IN-2,WB0WTI-10*

WIDE1-1,WIDE2-1 The first digi'd packet contains N5IN-2*,WIDE2-1, the 
second N5IN-2,WB0WTI-10*, and I suspect a third

WIDE1-1,WIDE2-2 The first digi'd packet contains N5IN-2*,WIDE2-2, the 
second N5IN-2,WB0WTI-10*,WIDE2-1 and I suspect a third 

Finally approaching some conclusions:

You can't shoehorn the New Paradigm into the UIDIGI, but you can get 
part way there.  a UID of 
WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 works thus:

WIDE1-1,WIDE1-1 (works as expected producing 2 hops)
WIDE1-1,WIDE2-1 (produces 3 hops and not 2 as hoped)
WIDE1-1,WIDE2-2 (works as expected producing 3 hops)

With RELAY added to UID (now both RELAY and WIDE1-1 are in UID)

RELAY,WIDE1-1 works as WIDE1-1,WIDE1-1 (2 hops)
RELAY,WIDE2-1 works as WIDE1-1,WIDE2-1 (3 hops not 2 as hoped)
RELAY,WIDE2-2 works as WIDE1-1,WIDE2-2 (3 hops)

WIDEn-N for n=N and n>2 but < 8 all terminate with a single hop, thus:
WIDE1-1,WIDE4-4 allows just 2 hops.

Unfortunately WIDE5-4 produces 5 hops (it is not trapped).

For WideN-M where M<N the trapping fails.

You will also note that in order to substitute WIDE1-1 for RELAY it is

necessary to place WIDE1-1 in the UID list (otherwise serious problems

result which are detailed above).  By doing so I believe RELAY and 
WIDE1-1 act identically, the latter not producing any less QRM.


1) If you wish to support both RELAY and WIDE1-1 (in the UID list, and

thus treated differently than WideN-n in that it is no longer a UIFlood

or UITrace token) then both of these must be placed in the UID list. 
doing so you will have space remaining for just additional 6 tokens. 
you are in a 3 hop area then the UID list would have to contain:

RELAY,WIDE1-1,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 plus 2 more tokens.  To 
fully implement restrictions against excessive paths you would need to

add WIDE4-3,WIDE4-2,WIDE4-1,WIDE5-4, etc which totals 18 tokens.  There

is no room to do this.  And the result is inconsistent as while it 
allows a path of WIDE3-3, it also allows a path of RELAY,WIDE3-3 or 
WIDE1-1,WIDE3-3 which is 4 hops.  Someone who wishes to break the rules

can use a path of WIDE7-6 and get 7 hops.  Also paths such as 

2)  If you wish to abandon RELAY and WIDE1-1 in its special application

as a twin to RELAY, then the UID list for a 3 hop area will contain
WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 giving you space for 4 additional
out of the 18 additional spaces you would need to fully implement.  In

this implementation the following paths will be permitted:

WIDE1-1 (1 hop)
WIDE2-2 (2 hops)
WIDE3-3 (3 hops)

but you will be able to block just 4 our of the remaining 18 paths such

as WIDE7-6 which will produce 7 hops.

3)  If you wish to retain RELAY, but not include the special
of WIDE1-1, you gain one additional slot in the UID list.

Conclusion:  The New Paradigm can only be poorly supported by UIDIGI at

present.  Abandoning RELAY (and/or the special use of WIDE1-1 as an 
equivalence for RELAY) simplifies things only slightly.  While I have
means to test the KPC3+, I suspect it may the same shortcomings as

Assuming users are well behaved it may be worthwhile to implement, but

if users were well behaved we wouldn't need to place limits upon them
intended by the New Paradigm in the first place.

I had hoped for better.

Only Marco Savegnago IW3FQG, the author of UIDGI, is in a position to 
fully solve this problem by allowing a simple hop limit to be enforced

in the code irrespective of what paths a user tries.

Ron, N5IN

aprssig mailing list
aprssig at lists.tapr.org 

More information about the aprssig mailing list