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

Robert Bruninga bruninga at usna.edu
Sun May 15 08:52:33 EDT 2005

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 

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.


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

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.

More information about the aprssig mailing list