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

[Ron Stordahl]

Testing this evening produced some unexpected results and the conclusion 
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:

UIDigi WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN
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 as 
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 the 
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 of 
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 N5IN-2*,WIDE1,WIDE1-1 
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 N5IN-2*,WIDE1,WIDE2-1 
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 N5IN-2*,WIDE1,WIDE2-2 
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 N5IN-2,WB0WTI-10,WIDE2*

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 
N5IN-2,WB0WTI-10,WIDE2*

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.  By 
doing so you will have space remaining for just additional 6 tokens.  If 
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 
RELAY,RELAY,RELAY,RELAY,RELAY will be supported.

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 just 
WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 giving you space for 4 additional tokens 
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 application 
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 no 
means to test the KPC3+, I suspect it may the same shortcomings as UIDIGI.

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 as 
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