[aprssig] Re: SSn-N and the New Paradigm for UIDIGI

[Robert Bruninga]

Dick,
Im reading in reverse chronological order this morning, so
got  your later mesage first.  OK, here is my understanding
of what you are saying below about the support of SSn-N
under UIFLOOD in the UIDIGI ROM:

1) You cannot find a way for the path SS1-1,SSn-N to arrive
as DIGI1,DIGIx*,SSn-N where DIGIx is the last digi heard,
for example  DIGI1,DIGI3*,SS5-2 at the 3rd hop and ultimately
DIGI1,DIGI5,SS5* at the last hop.

2) BUT it does still propogate.  So the user of SS1-1,SSn-N
will be heard and will get out 1+N hops.  So packets traversing
a UIDIGI area will still "work"...

You mentioned setting bits 3,2,1 in various combinatinos,
but did you try all 3 at once?  Because setting bits 2 and 1
did do the callsign insertion when no prior field was present.
(that makes SS1-1,SS5-5 take the first hop as DIGI1,SS1,SS5-5
but since UIDIGI rom WILL digipeat the SS1 (without a *) one
more time, and if ou set bit 4, then it will do callsign substitution
and then become DIGI1,DIGI2*,SS5-5.   Then when the next UIDIGI
hears it, is DOES overwrite the DIGI2* with its call< but nothing
is lost because the DIGI1 is 2 calls back.  Thus the next hop
is DIGI1,DIGI3*,SS5-4 and so-forth down to DIGI1,DIGI5,SS5
and finally ending with either a SS5* or maybe it does 
DIGI1,DIGI5,DIGI6?

Sorry to ask, but the overwrite of the precious position is
part of the process even in the KPC-3's, but the SS1-1
at the start makes it initially then a 3-field path so that
the overwrite is always only happening on the second
field.  THus it arrives with first and last intact?

I hope I got that right...
So would a test of setting that parmamter to 14 for
bits 4,3,2 or some other combination make it work this
way?  thanks.
Bob

Bob


>>> Richard Jenkins <rejenkins at adelphia.net> 05/15/05 7:18 AM >>>
Bob,

Our area has yet to convert to the new paradigm so my testing has
been done with the current settings and translated to the new setup.

I tried setting UIFLDfl to 6 ie: bit 1 insert callsign before WIDEn-N
and bit 2 put "has been repeated" flag on WIDEn-0, in an effort to
produce a trace callsign for SSn-N.  I got mixed results.

1. When there was a previous callsign present, the new callsign would
overwrite the previous callsign and the * would be properly placed at
the end of the WIDEn-0 statement, however

2. When there was no previous callsign present, the new callsign
would be placed prior to the WIDEn-0 statement but the * was placed
on the callsign, not on the WIDEn-0 statement where it should have
been placed.

Therefore I deem UIFLDfl = 6 to be unusable.

I also tried to set UIFLDfl = 8 ie; bit 3 make call substitution on
WIDEn-0.  I saw nothing happen in the time I spent watching so I also
deem bit 3 to be of no use.

Therefore UIFLDfl = 4 ie: bit 2 put "has been repeated" flag on
WIDEn-0 is our best choice as it works all the time, even with
SS1-1,SSn-N statements.  (Remember, that the WIDE statements
described here will become SSn-N statements under the new paradigm.)

The current version of the New Paradigm for UIDIGI will not insert a
first and last callsign in the digi field for the SSn-N command. 
Neither will this new method.  The new method with UIFLDfl = 4 will
insure proper handling of the SS1-1,SSn-N sequence.  <-- some clown
is going to try it!

It also means that every digi is going to process the WIDE1-1
statement as recommended in the current new paradigm.

The bottom line is that I would recommend modifying the new paradigm
for UIDIGIs to include UIFLDfl = 4 and keep everything else the same
regarding the SSn-N sequence.