Shoehorning the ‘New n-N Paradigm’ into UIDIGI v1.9 Beta 3
By Ron Stordahl N5IN September 20, 2006 Version 2.3
This document: FIX14439_UIDIGI-ROM
0.0 Changes.
The setting of the UID parm has been changed back to my earlier recommendation by removing ‘WIDE1-1’ from the string. Extensive testing has demonstrated that this was unneeded for interoperability with KPC3 firmware 7395 8.2 as I had earlier thought in the case where the origin station transmits a route of WIDE1-1,WIDEn-N.
Timing parameters (PPersistance & Slottime), which control how aggressive UIDIGI is in transmitting, are now set to 255 and 1 respectively. This increased aggressiveness will reduce the lifetime of a given packet at the risk of more collisions. It is asserted that this is a worthwhile trade off in busy regions. I have tested this for several weeks in an area (NW Minnesota) of 10 digi’s, all set to P=255 and SL=1, and if there is an improvement it’s not immediately obvious. However I am persuaded by the arguments and have made the changes in my sample configuration files. UICHECK, the duplicate suppression window time, is changed to 30 for consistency with KPC3’s. Existing UIDIGI users should not feel the need to burn new eproms, but can set the new P, SL and U by remote sysop access if they wish.
The earlier Fill_In.txt configuration was incorrect in that UITRACE= and UIFLOOD= defaulted to TRACE and WIDE respectively when compiled rather than empty as I had assumed. I have in my recommended configuration replaced these with an arbitrary 6 character string,that is unlikely to ever be used in a path. Sort of ugly, but it works.
BeaconDestination has been changed to APNU19-3 to convey that the UIDIGI release is version 1.9 Beta 3. This can be remotely set using the UNproto command.
1.0 Standard configuration.
The 'New n-N Paradigm', hereafter referred to as New-N, is an effort lead by Bob Bruninga WB4APR: http://web.usna.navy.mil/~bruninga/aprs/fix14439.html.
Part of the goal is to allow the use of existing digipeaters and by the choice of appropriate parameters, in devices such as the Kantronics KPC3+ and TNC2’s UIDIGI firmware, achieve some headway in limiting excessive path length and reduction of duplicate packets.
The New-N has now been standardized, to the extent possible, given that it must be compatible with existing digipeaters. I have experimentally determined that a good solution can be made by the choice of appropriate parameters in UIDIGI, however a complete solution can be provided only by the author of UIDIGI, Marco Savegnano IW3FQG, should he care to do so.
The maximum number of permitted hops will be defined by sysops depending upon their judgment of digipeater loading. It is expected that the limit placed upon N will be such that N=2 will work everywhere, N=3 in all but the most congested area, with N=4 permissible in only the most remote areas.
The New-N eliminates RELAY, replacing it with WIDE1-1, as explained in http://www.ew.usna.edu/~bruninga/aprs/relayFIX.txt.
Included in the archive FIX14439_UIDIGI-ROM.ZIP are the sample configuration files UIDIGI_N.TXT, for N=2, 3 and 4. I encourage you to use these configuration files as there are quite a few subtle changes which you could easily miss if you try to update your existing configuration files manually.
NOTE: You must use the October 4, 2005 or later version of the DOS configuration program UIDGCFG.exe or the 32 bit version UIDGCFG32.exe, otherwise if you set UIFLOODOptions=4 (offset X’344 in the binary) and UITRACEOptions=2 (offset X’346’ in the binary) as desired, both options are forced to 4 in the generated binary!! This new version of the DOS configuration program, which corrects the problem, can be obtained in the files section of the UIDIGI Yahoo Group in the UIDIGI 1.9 folder. The version in the archive UIDG19B3.zip is the defective version. The 32 bit version of the configuration program, UIDGCFG32.exe, found in the archive uitools32.zip in the UIDIGI 1.9 folder, generates the correct binary.
Here are pertinent parameters for New-N:
UIFLD 4 (required!!)
UITRF 2 (required!!)
UIF SS (substitute your State or ARRL section)
UIT WIDE (which makes WIDEn-N tracable)
P 255 (max xmit aggressiveness in conjunction w/Slottime=1)
SL 1 (max xmit aggressiveness in conjunction w/PPersistance=255)
U 30 (duplicate suppression window time)
For N=2:
UID WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,WIDE4-3,WIDE5-4,WIDE6-5
For N=3:
UID WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,WIDE5-4,WIDE6-5,WIDE6-4,WIDE7-6
For N=4:
UID WIDE5-5,WIDE6-6,WIDE7-7,WIDE6-5,WIDE7-6,WIDE7-5
The ‘SS’ for State or ARRL section is for efficient support of section or state nets without spillover to other states or sections.
If you are curious how all this works, every literal in the UID list results in one digipeat. Entries such as WIDE7-7, which otherwise would be processed as a WIDEn-N, as provided for by UIT, will be interpreted literally and will not result in generating a decremented WIDE7-6 which would be subsequently digi’d, rather they will be ignored by surrounding digi’s. Also note that the ‘UIT WIDE’ command will result in WIDEn-N ‘tracing’ allowing you to see clearly the route a particular packet has taken.
The strange routes such as WIDE4-3, WIDE7-5, etc, are used to filter out specific problems in your area resulting from abusive routes relayed by area digi’s not yet in compliance with New-N. You can refine them if needed.
The New-N also speaks about ‘Properly setting up the beacon rate.’ This is impossible with UIDIGI, as it does not work as described in the UIDIGI documents. Every 10 minutes I send a beacon with a path of NULL, to inform local users, travelers, etc quickly of the existence of this digi. Because it is not further digi’d the QRM is low. The remaining timings are pulled out of a hat, sending a beacon via WIDE2-1 every 29 minutes and via WIDE2-2 every 59 minutes. The KPC3+ deals with this much better, but we can get by with this:
B 1 NULL
B 2 WIDE2-1
B 3 WIDE2-2
BE 1 600
BE 2 1740
BE 3 3540
BT 1 !4818.69NS09603.56W#PHG3320
W3,
BT 2 !4818.69NS09603.56W#PHG3320
W3,
BT 3 !4818.69NS09603.56W#PHG3320
W3,
The ‘W3’ tells users you are imposing a N=3 limit, so edit this for your region. The “MNn”, for
1.1 Configuring a ‘fill-in’ UIDIGI.
A ‘fill-in’ digi replaces the old relay digi’s, responding only to WIDE1-1 (and SS1-1). The purpose is to assist high digi’s where needed by filling in small areas with poor coverage. The configuration is the same as the standard configuration with these changes:
UITRACEcall = ABCDEF and UIFLOODcall = GHIJKL replace the defaults of TRACE and WIDE. ABCDEF and GHIJKL are completely arbitrary, representing paths that are very unlikely to ever occur. If you wish you can replace them by something of your choosing…except TRACE, WIDE or ‘empty’. Don’t use ‘empty’ as when compiled it will default to TRACE and WIDE.
UIT ABCDEF
UIF GHIJKL
UID WIDE1-1,SS1-1 (here SS may be your state abbreviation)
A sample configuration file, Fill_In.txt is provided.
2.0 Reflector
If you care to follow developments with UIDIGI there is a UIDIGI Yahoo Group at http://groups.yahoo.com/group/uidigi/
Ron Stordahl, N5IN