UIFlood

UIFlood

UIFLOOD is very similar to UITRACE, but with a major difference. UIFLOOD and UITRACE both use an SSID which is decremented, and keep a CRC packet payload log to keep from acting upon the same packet twice. The difference between UIFLOOD and UITRACE is that UIFLOOD inserts it's callsign before the path being acted upon like UITRACE, but if there's a callsign already inserted, UIFLOOD overwrites that callsign. UITRACE will insert its callsign each time it acts upon a packet. UIFLOOD can also be configured to not insert its callsign as well. In the Kantronics line (where it was developed and implemented first), the command syntax is as such: UIFLOOD name[,time[,{FIRST | ID | NOID}]] (name = 5 char max)(time = 0-255) default disabled,30,NOID When a UI frame is received with a call in the to-be-digipeated field of the form 'name'x-y where x is a number (1-7) appended to 'name' and y is an ssid (1-7), the ssid is decremented and the UI frame is digipeated without setting the H bit. When the packet is digipeated, a checksum is formed over the source, destination, and data fields of the packet. This checksum is kept for time seconds (0-255). If an incoming UI packet is eligible for digipeating as above, but its checksum matches one of those being saved, the packet is discarded (not digipeated). The buffer holds a maximum of 64 checksums. Of the optional parameter ID is selected, the MYCALL callsign is inserted in an additional digipeater address field with its H bit set. From the Kantronics KPC-3+ user manual In the new-N Paradigm, UIFLOOD is used to set up the capability for statewide digipeating. It will support up to 7 hops, but because the digipeater aliases used in each state are different, the packets do not propagate across into neighboring areas. This is to facilitate getting packets of local importance distributed in the local area, without flooding out into adjacent areas. The standard implementation is as such: UIFLOOD SS,30,ID where SS is the two letter state abbreviation. For Florida, UIFLOOD FL,30,ID would be used to configure for SSn-N flood digipeating. KJ4ERJ-7>APTT4,FL3-3: would be handled thusly by a digipeater: <DigiXForm>FL3-3=@FL3-2</DigiXForm> <DigiXForm>FL3-2=@FL3-1</DigiXForm> <DigiXForm>FL3-1=@FL3*</DigiXForm> KJ4ERJ-7>APTT4,Digi1*,FL3-2: KJ4ERJ-7>APTT4,Digi2*,FL3-1: KJ4ERJ-7>APTT4,Digi3*,FL3*: With NOID enable, the digipeater callsigns would not be inserted, and only the SSn-N would be decremented until complete thusly: <DigiXForm>FL3-3=!@FL3-2</DigiXForm> <DigiXForm>FL3-2=!@FL3-1</DigiXForm> <DigiXForm>FL3-1=!@FL3*</DigiXForm> KJ4ERJ-7>APTT4,FL3-2: KJ4ERJ-7>APTT4,FL3-1: KJ4ERJ-7>APTT4,FL3*: This is different from the APRSISCE/32 implementation of UITRACE, which would mark up the packets in this manner: <DigiXForm>FL3-3=FL3-2</DigiXForm> <DigiXForm>FL3-2=FL3-1</DigiXForm> <DigiXForm>FL3-1=FL3*</DigiXForm> KJ4ERJ-7>APTT4,Digi1*,FL3-2: KJ4ERJ-7>APTT4,Digi1*,Digi2*,FL3-1: KJ4ERJ-7>APTT4,Digi1*,Digi2*,Digi3*,FL3*: The DIGIFORM rules will insert the callsign each time it is called. The ! is used to suppress callsign insertion and/or the @ is used to drop the entire used portion of the path. APRSISCE/32 supports a fourth variant of ID and/or Path replacement which is to not insert the callsign, but still preserve the previously used path. This would be done with just a ! (no ID) in the <DigiXForm>, although I really can't imagine this being used in the field. <DigiXForm>FL3-3=!FL3-2</DigiXForm> <DigiXForm>FL3-2=!FL3-1</DigiXForm> <DigiXForm>FL3-1=!FL3*</DigiXForm> KJ4ERJ-7>APTT4,FL3-2: KJ4ERJ-7>APTT4,Digi1*,FL3-1: KJ4ERJ-7>APTT4,Digi1*,Digi2*,FL3*: