UIDIGI EPROM

Programming Information for APRS®


Setting the UIDIGI firmware parameters for version 1.9 beta 3

AuxDestination Beacon2Path EastPath PreemptAdd UIDigiCall
AuxPath Beacon3Path Frack PreemptCalls UIDIGICallSubstitution
AuxRate Beacon1Text FullDuplex PreemptedDigipeat UIFloodCall
Beacon1Interval Beacon2Text HandleUISSID ReplyToQuery UIFLOODOptions
Beacon2Interval Beacon3Text InfoText Retry UIMessage
Beacon3Interval BeaconDestination LinkCheck SlotTime UIOnly
Beacon1Offset BudList LoopSuppression SouthPath UIPID
Beacon2Offset DigipeaterAlias Maxframe RespTime UITraceCall
Beacon3Offset DigipeaterCallsign NorthPath SysopPassword UITRACEOptions
Beacon1Path DuplicateSuppression PPersistance TxDelay WestPath

 

This page was intended to help those programming UIDIGI firmware with APRS friendly settings that conform with the New APRS Paradigm change suggested by Bob Bruninga, WB4APR (aka "the father of APRS"). Since the firmware settings can be very confusing to many of us, I decided to make an attempt to explain each of the settings. If you see anything I have done that needs to be corrected, please send me a message at [email protected]. These settings are by no means the final word in every installation. They are settings we use on our UIDIGI systems in North Alabama and others who have requested UIDIGI firmware burned into an EPROM. These settings best implement the objectives of the and the  

UIDIGI is firmware designed for the TNC2 (or TNC2 clone) packet controllers by Marco Savegnago, IW3FQG. This firmware converts a TNC2 into a powerful maintenance free APRS packet digipeater with advanced functions not found on other TNC's. The UIDIGI firmware really breathes new life into an old TNC2 Packet Node Controller and transforms it into a modern day APRS digipeater.

APRS ® is a registered trademark of Bob Bruninga, WB4APR.

The UIDIGI.BIN  supplied with the UIDIGI distribution contains some artifacts that will not allow you to program blank entries for Beacon2Path or Beacon3Path. I have modified the original UIDIGI.BIN file to make these entries blank so they will remain blank if you need a blank path without any hops. Click on the UIGOLD.BIN to download this modified BIN file.

If you need help programming an EPROM, please consult free programming offers at UIDIGI

 

    


DigipeaterCallsign

// Set the digipeater ax.25 address callsign (with SSID if necessary)

DigipeaterCallsign = N8DEU-4

 

The DigipeaterCallsign should be set to the callsign that will identify your digipeater. If you have multiple digipeaters using your callsign, then you may choose to use a unique SSID settings from 1 to 15. In our case we have multiple digipeaters and only use N8DEU-4 as an example. You would use your own callsign for this setting. This is the parameter to assign the callsign to your digipeater. * Try to avoid using SSID's of -12 and -15 if possible.

 


 

DigipeaterAlias

// Set the digipeater address alias (without SSID if necessary)

DigipeaterAlias = UIDIGI

 

This default setting can be left unchanged. The standard digipeater aliases handled with the UIDigiCall later in the configuration file. If you have a specific need or want to give the digipeater an alias associated with its location (ie MTSANO, HSV, etc) you can program that information using this parameter. Please understand that no callsign substitution will be employed on this setting. I have yet to see UIDIGI digipeat a parameter in this setting beyond one hop. This means if you use a path of UIDIGI,UIDIGI only one hop will be digipeated as the second hop will be ignored.

 


 

InfoText

// Digipeater Info Text up to 80 char

InfoText = UIDIGI 1.9 BETA 3

 

The default setting is fine unless you prefer to customize it. See the tip on text formatting in the Beacon1Test parameter on how we format our messages to fit the Kenwood TH-D7 and TM-D700 displays.

Below is a sample of the InfoText setting for our local digipeater:

InfoText = Huntsville Alabama  Madison Co - UIDIGI 1.9 Beta 3

 


 

NorthPath

// North Path

NorthPath =

 

* Not used in the New-N Paradigm.

 


 

SouthPath

// South Path

SouthPath =

 

* Not used in the New-N Paradigm.

 


 

EastPath

// East Path

EastPath =

 

* Not used in the New-N Paradigm.

 


 

WestPath

// West Path

WestPath =

 

* Not used in the New-N Paradigm.

 


 

BudList

// BudList Calls (up to 8, default none)

BudList =

 

The buddy list is a misnomer. It should really be called the nuisance list, because the digipeater will ignore packets from a callsign in this list. This includes all SSID's of the callsign. We do not have these kind of buddies in our area, so we do not use this setting. If you have a need to ignore packets from any station, then you can add them to this list

 


 

UIDigiCall

// UI Generic Calls (up to 8)

UIDigiCall = WIDE7-7, WIDE6-6, WIDE5-5, WIDE4-4, WIDE3-3, WIDE3-2

 

The UIDigiCall setting contains the basic path identifiers that will be recognized and repeated by the digipeater. You can add any specific path identifiers that may be unique to your area in this list in addition to those listed by the default setting.

The WIDEn-n settings in this list are utilized to trap paths of WIDEn-n greater than WIDE2-2. This is an effective filter to limit the abuse of long paths on the network from propagating through long digipeater paths beyond WIDE2-2. Support for RELAY and WIDE was dropped in support of the APRS April 2005 Paradigm changes to help reduce dupes on the network. Please refer to http://www.aprs.org/fix14439.html

The settings shown above are what we use in our area. UIDIGI acts on these calls before processing UIFloodCalls and UITraceCalls and gives us some leverage in limiting long WIDEn-n paths. With this in mind, the best settings might be area dependent and subject to change in your immediate area. While it does not stop all WIDEn-n paths beyond WIDE2-2, it does limit most long paths.

WIDE1-1 is not required in this list under the new paradigm. UIDIGI handles WIDE1-1 in the packet path properly with UITraceOptions=2 and no extra hops are created. There is an issue with KPC3+ systems using version 8.2 firmware that will not digipeat a packet from a UIDIGI or KPC3+ version 8.3 firmware if these systems digipeated the WIDE1-1 call in the path. This is an issue with the KPC3+ version 8.2 firmware and these units must include WIDE1-1 in their alias list. UIDIGI and the KPC3+ version 8.3 firmware handle the path in the form DIGI1,WIDE1*,WIDE2-2, whereas, a KPC3+ version 8.2 firmware will handle the same packet as DIGI1*,WIDE1,WIDE2-2 and it dies after the first hop. UIDIGI and KPC3+ version 8.3 will continue the path of each packet but the KPC3+ version 8.2 firmware will not handle the same from a UIDIGI or KPC3+ version 8.3 firmware. UIDIGI and the KPC3+ version 8.3 firmware handle it the correct and desired way. The KPC3+ with version 8.2 firmware requires WIDE1-1 to be programmed in their alias list.

 


 

UIFloodCall

// UI Flood Call

UIFloodCall = SS

 

Where SS represents the two letter designator of your state or SSS or longer ARRL section. 

We use AL for the state of Alabama.

This setting will support the SSn-n  packet paths and subtract 1 from the SSID until the SSID reaches 0. The digipeater keeps track of what it digipeated for the period specified by the DuplicateSuppression setting (28 seconds by default) and will not digipeat a duplicate of this packet if it is heard within the specified time frame. The reduces the number of unnecessary digipeats in an area with several digipeaters within radio range. 

For example, if a packet were sent via AL2-2 or WIDE1-1,AL2-1 and "UIFloodOptions=6" and "UIFloodCall=AL", the following would result:

original packet: N8DEU>APRS,AL2-2:
1st hop: N8DEU>APRS,W4GPS-7*,AL2-1:
2nd hop: N8DEU>APRS,KE4ROC-7,AL2*:

 

original packet: N8DEU>APRS,WIDE1-1,AL2-1:
1st hop: N8DEU>APRS,W4GPS-7*,AL2-1:
2nd hop: N8DEU>APRS,W4GPS-7,KE4ROC-7,AL2*:

In each of the above examples for UIFloodCall=AL and UIFloodOptions=6, the digi callsign is inserted before the SSn-n call. When the SSn-0 is encountered the digipeat flag is placed on the SSn-0 instead of the digi callsign. This is the correct method for the new APRS Paradigm or at least the best UIDIGI can do. There is a bug in UIDIGI that prevents subsequent SSn-n paths to be added to the list after the first entry.

 

More information on the APRS paradigm changes can be found at http://www.aprs.org/fix14439.html

 


 

UITraceCall

// UI Trace Call

UITraceCall = WIDE

 

UITraceCall works much like the UIFloodCall  algorithm with the exception that the UITraceCall routine will insert it's DigipeaterCallsign assignment in the path in front of the WIDEn-n entry as it subtracts 1 from the SSID until it reaches 0.

For example,  if a packet is sent via WIDE3-3 and "UITraceCall=WIDE" and "UITraceOptions=2", the following would result:

original packet: N8DEU>BEACON,WIDE3-3:
1st hop: N8DEU>BEACON,W4GPS-7*,WIDE3-2:
2nd hop: N8DEU>BEACON,W4GPS-7,W4SBO-7*,WIDE3-1:
3rd hop: N8DEU>BEACON,W4GPS-7,W4SBO-7,W4OZK-7,WIDE3*:

This is the desired and correct handling under the new paradigm.

 


 

TxDelay

// Txdelay (default 30 = 300)

TxDelay = 30

 

TxDelay specifies the length of time to wait to send data after the PTT (Push-to-Talk) line has been activated. The purpose is to give the radio enough time to come up to power and stabilize on the frequency before actually sending the data. Flags are transmitted during the delay period prior to data.

TxDelay is specified as " n x 10mS". The default setting of 30 is actually 300mS (30 x 10mS). This setting is very dependent on the radio equipment you are using. If the transmitter uses a mechanical relay, then it will probably need set between 30-50 (300-500mS). A relay makes a clicking sound when you activate the transmitter. Most of today's equipment do not use mechanical relays. Instead, they use electronic switching that is much faster. For this type of equipment, you can set TXDelay between 10-30 (100-300mS). Be very careful with this setting. If the delay is not set long enough for the transmitter to activate, your digipeater will not work reliable because packets will be dropped. The default setting is good in most cases. If you are not sure, use the default.

Do not set TxDelay too low, because some people use squelched audio on their radio's. They need enough TxDelay from your digipeater for their squelch to open and allow data to be decoded. If your TxDelay is too fast, they may never decode packets from your digipeater because their squelch circuit is slow. Again, the default setting helps avoid this problem.

 


 

FullDuplex

FullDuplex = 0

 

FullDuplex should never be used on a simplex channel as utilized in the APRS application. FullDuplex should only be used when separate or crossband channels are utilized. This parameter would be used only for special applications.

We use the default setting as shown.

 


 

PPersistance

PPersistance = 255

 

This is an AX.25 link layer parameter. This setting in conjunction with SlotTime allows the digipeater to immediately transmit a digipeated packet without waiting for a clear channel. Any other setting could cause your digipeater to digipeat in a sluggish manner waiting for traffic to clear on the channel before attempting to transmit..

A discussion on the APRS SIG in September 2003 dictated some adjustment should be made to reduce dupes in adjacent digipeater nodes. It was highly recommended that DWAIT or UIDWAIT be set to 0. Since UIDIGI does not implement a DWAIT or UIDWAIT parameter, we had to set PPERSISTANCE=255 and SlotTime=1. These settings will in effect make the digipeater very aggressive in seizing the channel. These settings are as close as a UIDIGI can get to be equivalent for DWAIT=0 or UIDWAIT=0.

PPersistance and SlotTime work together and are related to the Kantronics Persist, SlotTime, UIDwait, and DWAIT parameters. Under Bob Brunninga's APRS Paradigm changes, the digipeater should not wait to digipeat a packet. Basically, a waiting packet should be digipeated immediately without any wait period. The setting of PPersistance = 63 and  SlotTime = 10 equate to a timing sequence whereby you have a random number generated between 0 and the number specified for PPersistance.

When a packet frame is queued or waiting to be transmitted, and the DCD is not active, a decision to transmit is based on a random number between 0 and 255 to the value of PPersistance. If the random number selected is less than the PPersistance value, the channel is seized by the packet controller. If not, the delay of SlotTime is executed and another random number is generated to start the process again. This continues until the random number is less than the value of PPersistance. Large values of PPersistance and small values of SlotTime produce the most aggressive channel access, while small values for PPersistance and large values for SlotTime exhibit a more civilized channel access. Bob Bruninga has recommended a DWAIT setting of 0 where the digipeater seizes the channel immediately. PPersistance=255 and SlotTime=1 is the closest we can program the UIDIGI settings to match the DWAIT=0 performance.

On the probability scale a PPersistance setting of 127 provides a 50% chance the controller will seize the channel where a setting of 63 provides a 25% chance the controller will seize the channel. When PPersistance=255, the probability that the controller will seize the channel is 100% and equivalent to DWAIT=0.

 


 

SlotTime

SlotTime = 1

 

This is an AX.25 link layer parameter. There should be no need to change the default unless you have a specific application.

This is an AX.25 link layer parameter. This setting in conjunction with PPersistance allows the digipeater to immediately transmit a digipeated packet without waiting for a clear channel. Any other setting could cause your digipeater to digipeat in a sluggish manner waiting for other traffic to clear on the channel before attempting to transmit..

A discussion on the APRS SIG in September 2003 dictated some adjustment should be made to reduce dupes in adjacent digipeater nodes. It was highly recommended that DWAIT or UIDWAIT be set to 0. Since UIDIGI does not implement a DWAIT or UIDWAIT parameter, we had to set SLOTTIME=1 which is the lowest setting that will in effect make the digipeater very aggressive in seizing the channel. This parameter is used in conjunction with PPersistance=255 to configure a setting close to DWAIT=0 or UIDWAIT=0.

PPersistance and SlotTime work together and is related to the Kantronics Persist, SlotTime, UIDwait, and DWAIT parameters. Under Bob Bruninga's APRS Paradigm changes, the digipeater should not wait to digipeat a packet. Basically, a waiting packet should immediately be digipeated without any wait period. The setting of PPersistance = 63 and  SlotTime = 10 equate to a timing sequence whereby you have a random number generated between 0 and the number specified for PPersistance.

When a packet frame is queued or waiting to be transmitted, and the DCD is not active, a decision to transmit is based on a random number between 0 and 255 to the value of PPersistance. If the random number selected is less than the PPersistance value, the channel is seized by the packet controller. If not, the delay of SlotTime is executed and another random number is generated to start the process again. This continues until the random number is less than the value of PPersistance. Large values of PPersistance and small values of SlotTime produce the most aggressive channel access, while small values for PPersistance and large values for SlotTime exhibit a more civilized channel access. Bob Bruninga has recommended a DWAIT setting of 0 where the digipeater seizes the channel immediately. PPersistance=255 and SlotTime=1 is the closest we can program the UIDIGI settings to match the DWAIT=0 performance.

 


 

Frack

Frack = 5

 

This parameter controls the Frame Acknowledgment timeout. It does nothing for UI frames. It comes into the picture for timing when you are remotely connected to the digipeater in the sysop mode which is a connected mode of operation versus UI.

 


 

Maxframe

Maxframe = 4

 

This parameter sets the limit of unacknowledged frames. It does nothing for UI frames. It comes into the picture for control when you are remotely connected to the digipeater in the sysop mode which is a connected mode of operation versus UI.

 


 

Retry

Retry = 10

 

This parameter sets the number of retries for unacknowledged frames. It does nothing for UI frames. It comes into the picture for control when you are remotely connected to the digipeater in the sysop mode which is a connected mode of operation versus UI.

 


 

RespTime

RespTime = 100

 

This parameter sets the minimum response time for acknowledgement frames. It does nothing for UI frames. It comes into the picture for control when you are remotely connected to the digipeater in the sysop mode which is a connected mode of operation versus UI.

 


 

LinkCheck

LinkCheck = 18000

 

This parameter specifies the time-out for the sysop mode if no activity is heard within the period specified.

 


 

DuplicateSuppression

// Duplicate Packet Suppression Interval second

DuplicateSuppression = 30

 

The setting specifies the time period to ignore duplicate packets. 

We use the above setting for this parameter, in case somebody has their beacon rate set to an aggressive rate under 30 seconds. The setting meets the New APRS Paradigm suggestion.

DuplicateSuppression is a value specified in seconds and sets limits on how often a duplicate packet can be digipeated. If a packet is digipeated, this timer setting will not allow the same packet to be digipeated again if it arrives at the digipeater another instance before the time specified. Basically, if you had somebody transmitting the same packet every 15 seconds and your DuplicateSuppression was set to a value of 30 seconds, then that packet would not be retransmitted if it looks the same at the digipeater. Your digipeater would only allow this packet to be digipeated every 30 seconds even though it is heard every 15 seconds. There could be instances where this would slip through the digipeater if the packet path were modified by another digipeater.

 


 

LoopSuppression

// Loop Packet Suppression Interval Mask

// 0x01 = Do not repeat frame with source address equal to digipeater call or alias

// 0x02 = Do not repeat frame with the digipeater call in the already digipeated via list

LoopSuppression = 3

 

This parameter is used to activate 1 or 2 UI loop suppression techniques. The default setting activates both loop suppression features to prevent duplicate digipeating of the same packet.

 


 

HandleUISSID

// Treat different SSID in destination call

HandleUISSID = 0

 

* Not used under the New-N Paradigm

 


 

ReplyToQuery

// Reply to Query

ReplyToQuery = 1

 

This parameter controls whether the digipeater responds to the general ?APRS? query. The default setting enables the digipeater to respond to the ?APRS? query. UIDIGI will respond to a general ?APRS? query, but it will not respond to a directed ?APRS? message query. Basically, if you send a message format such as sending ?APRS? in a message from a Kenwood TMD-700 radio, UIDIGI will not respond to this directed message based query.

The difference is this:

General Query Format N8DEU-4>APRS:?APRS? UIDIGI will respond to a general query
Directed Query Message Format N8DEU-4>APRS::WB4FAY-5 :?APRS? UIDIGI will not respond to a directed message query

 


 

UIFLOODOptions

// UIFLOOD Algorithm flag
// bit 0 WIDEN-0 will be repeated
// bit 1 insert callsign before WIDEN-n
// bit 2 put has been repeated flag on WIDEN-0
// bit 3 make call substitution on WIDEN-0

UIFLOODOptions = 6

 

UIFloodOptions=6

This parameter controls how the UIFloodCall is processed. The setting of 6 emulates the ID process with bit 1 and bit 2 set. This means the SSn-n SSID is decremented, the digis's call sign is inserted before SSn-n path, and the digipeat flag is placed on inserted callsign until SSn-0 is reached. At this point the digipeat flag is placed on the SSn-0 entry instead of the inserted digi callsign.

For example, if a packet were sent via AL2-2 and "UIFloodOptions=6" and "UIFloodCall=AL", the following would result:

original packet: N8DEU>APRS,AL2-2:
1st hop: N8DEU>APRS,W4GPS-7*,AL2-1:
2nd hop: N8DEU>APRS,KE4ROC-7,AL2*:

 

original packet: N8DEU>APRS,WIDE1-1,AL2-1:
1st hop: N8DEU>APRS,W4GPS-7*,AL2-1:
2nd hop: N8DEU>APRS,W4GPS-7,KE4ROC-7,AL2*:

In each of the above examples for UIFloodCall=AL and UIFloodOptions=6, the digi callsign is inserted before the SSn-n call. When the SSn-0 is encountered the digipeat flag is placed on the SSn-0 instead of the digi callsign. This is the correct method for the new APRS Paradigm or at least the best UIDIGI can do. There is a bug in UIDIGI that prevents subsequent SSn-n paths to be added to the list after the first entry.

UIFloodOptions=6 is the correct and desired performance under the new paradigm for UIFloodOptions. 

 

UIFloodOptions=2

Some digipeater owners my still be using the setting UIFloodOptions=2. While it is close to meeting the New Paradigm objectives it falls short in placing the digipeat flag on the SSn-0 entry in the list. For example, if a packet were sent via AL2-2 and "UIFloodOptions=2" and "UIFloodCall=AL", the following would result:

original packet: N8DEU>APRS,AL2-2:
1st hop: N8DEU>APRS,W4GPS-7*,AL2-1:
2nd hop: N8DEU>APRS,KE4ROC-7*,AL2:

The important distinction here is the digipeat flag is placed on the last digi callsign substitution instead of the SSn-0 entry or in this case AL2. The use of this setting is discouraged as it can severely affect the behavior in how other TNC firmware deals with this behavior.

 

The UIDIGI documentation does not address the bits 2 and 3 except in the "Changes.txt" file that comes with the UIDIGI distribution. Bits 1 and 2 are the preferred setting for UIDIGI to support the new APRS Paradigm. Unfortunately, there is no setting in UIDIGI that will make this function work like the setting UITraceOptions=2 for the UITraceCall.

Note: There is a bug in an early version of the UIDIGI 1.9 beta 3 UIDGCFG.EXE program that programs the wrong value in the UIFloodOptions. I created an updated program called UIDPDC.EXE version 1.01 that will set UIFloodOptions = 6 and UITraceOptions = 2 in the BIN file so they will be programmed correctly. This program will reduce the time required to manually make the change in the BIN file with a hex editor and also make it error free. The UITraceOptions setting in the BIN file seems to be set to the same as the UIFloodOptions value no matter what the UITraceOptions has instructed. If you would like a copy of this program it is free for the asking to help make sure your EPROM is programmed with what you intended. NOTE: Marco has fixed this problem in the updated UIDFCFG32.EXE and if you use UIDFCFG32.EXE you will not need to use the UIDPDC.EXE program.

 


 

UITRACEOptions

// UITRACE Algorithm flag

// bit 0 make call substitution after the last TRACEn-n digied

UITRACEOptions = 2

 

With the default setting the UITRACEOptions routine will insert it's digipeater call in the path in front of the TRACEn-n as it subtracts 1 from the SSID until it reaches 0. The packet path will grow with the digipeater substituting its callsign, showing all the digipeaters that have responded along the path.

This setting must be changed to UITraceOptions=2 to meet the new APRS Paradigm changes

For example if a packet is sent via WIDE3-3, the following would result:

original packet: N8DEU>BEACON,WIDE3-3:
1st hop: N8DEU>BEACON,W4GPS-7*,WIDE3-2:
2nd hop: N8DEU>BEACON,W4GPS-7,W4SBO-7*,WIDE3-1:
3rd hop: N8DEU>BEACON,W4GPS-7,W4SBO-7,W4OZK-7,WIDE3*:

This is the correct and desired performance under the new paradigm. 

 

Settings for UITRACEOptions are:

1 - bit 0 TRACEN-0 will be repeated
2 - bit 1 put has been repeated flag on TRACEN-0
3 - bit 2 make call substitution on TRACEN-0

 

The UIDIGI documentation does not address the last 2 settings except in the Changes.txt file that comes with the UIDIGI distribution. Bit 1 is the preferred setting to support the new APRS Paradigm changes.

Note: There is a bug in an early version of the UIDIGI 1.9 beta 3 UIDGCFG.EXE program that programs the wrong value in the UITraceOptions. I created a program called UIDPDC.EXE version 1.01 that will set UIFloodOptions = 6 and UITraceOptions = 2 in the BIN file so they will be programmed correctly. This program will reduce the time required to manually make the change in the BIN file with a hex editor and also make it error free. The UITraceOptions setting in the BIN file seems to be set to the same as the UIFloodOptions value no matter what the UITraceOptions has instructed. If you would like a copy of this program it is free for the asking to help make sure your EPROM is programmed with what you intended. 

 


 

UIDIGICallSubstitution

// Make call substitution when repeat frames addressed to UIDIGI Callsign

UIDIGICallSubstitution = 1

 

Whenever a packet is digipeated from the UIDigiCall list, the value defined in DigipeaterCallsign setting will be substituted in the digipeater path to identify what digipeater acted on the packet.

 


 

PreemptCalls

PreemptCalls =

 

If Preempt is enabled, call signs added to this list will be preempted. This is not used for most APRS applications unless there is a specific need to route traffic. If any call signs appear in this list, the digipeater can digipeat it even if it is not the next path to be digipeated in the sequence of events.

This is an experimental parameter. We do not use the Preempting feature.

 


 

PreemptAdd

PreemptAdd =

 

If Preempt is enabled, paths added to this list will be appended to the preempted call sign processed. This is not used for most APRS applications unless there is a specific need to route traffic.

This is an experimental parameter.

We do not use the Preempting feature.

 


 

PreemptedDigipeat

PreemptedDigipeat = 0

 

We use the default setting.

 


 

UIMessage

// Don't change SSID (decrement) to UI Message (frame with info that start 
// with char '~' 
// 0 disables
// range 0-1
// UIMessage [n]

UIMessage = 1

 

This was an option added in v1.8 beta 7 to support packets from UI-View software station message.

 


 

UIONLY

// Process only UI Frame 
// Enable processing of UI frame only 
// 0 disables
// range 0-1
// UIOnly [n]

UIOnly = 0

 

UIONLY can be utilized to turn on/off the digipeating of UI-only frames (default 1). This feature allows us to use UIDIGI as a normal L2 digipeater.

This option was added in v1.8 beta 7 to support specific handling of UI-only frames.

UIOnly is a parameter that controls what type of packets can be digipeated. When it is set to a value of 1, the digipeater will only digipeat UI (Unnumbered Information) AX.25 frames. Setting the value to 0 allows others packets to be digipeated through the digipeater that are not UI AX.25 frames. We use UIOnly=0 because we do not want to restrict our digipeaters to UI-only AX.25 frames. We use our APRS digipeaters in a connected mode to communicate with other digipeaters in our network so we can digipeat through them in a connected mode to access distant remote sites. This allows us to change settings and control distant digipeaters from anywhere in our immediate network.

 


 

UIPID

// PID of processed frames

UIPID = 240

 

Do not change this setting unless you have a specific reason or requirement. The only settings that will works for APRS are 240 (F0h) and 0 (00h).

UIPID enables frame filtering based on the PID (Protocol Identifier). The default setting of 240 filters packets with a PID of 240 (F0h). A Protocol Identifier of 240 defines a packet as "No layer 3 protocol implemented". A setting of 0 disables frame filtering.  Any other settings will not work with APRS as these frames utilize a PID of 240 (F0h).

 


 

SysopPassword

SysopPassword =youruniquepasswordgoeshere 

 

I highly recommend that you change the SysopPassword setting unless you like unsuspecting people changing the settings on your UIDIGI for you.

 


 

Beacon1Interval

Beacon1Interval = 600

 

This parameter determines how often the Beacon1Text is transmitted via the Beacon1Path. The default setting of 600 seconds equates to 10 minutes.

Beacon #1 is 10 minutes because it is defined as a direct beacon path for the immediate coverage area.

 


 

Beacon2Interval

Beacon2Interval = 1790

 

This parameter determines how often the Beacon2Text is transmitted via the Beacon2Path. The default setting of 1800 seconds equates to 30 minutes and 1790 equates to 29 minutes 50 seconds so that the beacon does not clobber or or get clobbered by one of the other settings by keeping a  decreasing 10 seconds from be fired at the top of the minute.

Beacon #2 is roughly 30 minutes since this beacon will be transmitted via surrounding digipeaters and is not needed as often for distance locations.

 


 

Beacon3Interval

Beacon3Interval = 601

 

This parameter determines how often the Beacon3Text is transmitted via the Beacon3Path. the default setting needs to me modified

Use the following setting to support the APRS Local Info Initiative:

Beacon3Interval = 601 

This beacon is utilized for local repeater information every 10 minutes to inform visitors where to tune in the local area of the digipeater. See the Beacon3Path and Beacon3Text parameters that support this setting

For more information about the APRS Local Info Initiative see: http://www.aprs.org/localinfo.html

 


 

Beacon1Offset

Beacon1Offset = 0

 

Consult the documentation for the use of this feature.

This function does not work properly. Instead of offsetting the BeaconxInterval, it simply adds this time to the BeaconxInterval time. Thus, if you set BeaconxInterval=600 and BeaconxOffset to 300 the result would be a 900 second interval instead of a 600 interval offset by 300 at the start. Since this feature does not work as advertised, please be careful with your settings. It is highly recommended that this setting be avoided until it is working properly. Adjust the times in the BeaconxInterval rather that confusing the settings.

We use the default setting.

 


 

Beacon2Offset

Beacon2Offset = 0

 

Consult the documentation for the use of this feature.

This function was found not to be work properly. Instead of offsetting the BeaconxInterval, it simply adds this time to the BeaconxInterval time. Thus, if you set BeaconxInterval=600 and BeaconxOffset to 300 the result would be a 900 second interval instead of a 600 interval offset by 300 at the start. Since this feature does not work as advertised, please be careful with your settings. It is highly recommended that this setting be avoided until it is working properly. Adjust the times in the BeaconxInterval rather that confusing the settings.

We use the default setting.

 


 

Beacon3Offset

Beacon3Offset = 0

 

Consult the documentation for the use of this feature.

This function does not work properly. Instead of offsetting the BeaconxInterval, it simply adds this time to the BeaconxInterval time. Thus, if you set BeaconxInterval=600 and BeaconxOffset to 300 the result would be a 900 second interval instead of a 600 interval offset by 300 at the start. Since this feature does not work as advertised, please be careful with your settings. It is highly recommended that this setting be avoided until it is working properly. Adjust the times in the BeaconxInterval rather that confusing the settings.

 


 

Beacon1Text

Beacon1Text = !0000.00NS00000.00W#PHG0000/W3,ALn-n Wilson Mtn Alabama

 

An example of my Beacon1Text follows:

Beacon1Text = !3424.30NS08648.02W#PHG5670/W3,ALn-n  Wilson Mtn Alabama 1360ft

 

This beacon meets the APRS Protocol to display a Digi Star (#) with the letter "S" overlaid on the symbol. This will identify your UIDIGI system as operating under the new APRS Paradigm change and signifies the digipeater supports both SSn-n (State) and limited WIDEn-n routing. The W3 signifies the digi attempts to limit WIDEn-n for most settings above 3 hops.

Both Beacon1Text and Beacon2Text should be identical to prevent consumption of many clients LOG files which considered unlike beacons to be a different position and save each entry into the LOG.

 

A tip on text formatting:

I have a few comments about the formatting of the text that follows the last "/" in the string. The Kenwood D7A and D700 both have 10 character displays that show incoming data from the message field. The D7A has 2 lines and the D700 has 3 lines of 10 characters that can be displayed on the screen for incoming data. With this in mind, I typically try to pad the text with spaces so the data looks nice for these displays. 

 

For more information on overlay symbols, please consult the following link:

 


 

Beacon2Text

// Digipeater Beacon 2 Text up to 70 char

 

We use the following settings:

Beacon2Text = !3424.30NS08648.02W#PHG5670/W3,ALn-n  Wilson Mtn Alabama 1360ft

Please refer to the notes for Beacon1Text.

Both Beacon1Text and Beacon2Text should be identical to prevent consumption of many clients LOG files which considered unlike beacons to be a different position and save each entry into the LOG.

 


 

Beacon3Text

// Digipeater Beacon 3 Text up to 70 char

 

We use the following beacon text setting to support the new APRS Local Info Initiative:

Beacon3Text = ;146.94HSV*111111z3444.27N/08631.98WrT100 R45m Net Th730 Mtg FRI

This beacon data places a local repeater object on the APRS map and a message on mobile displays to give local travelers information on local voice repeaters for the local area. This is local information, so the information should not be digipeated. Thus, you should not set a beacon path that will be acted upon by a nearby digipeater. The leading ";" character makes the message an object.  See the Beacon3Path and Beacon3Interval parameters to support this setting.

The packet identifies the repeater frequency as an object, the general location of the repeater, the tone required, the range of the repeater in miles or KM, and net or meeting information. The information shown above conveys there is a net that meets each Thursday at 7:30pm and there is a  meeting on Fridays.

The repeater object format can be:

;FFF.FFxyz*111111zDDMM.hhN/DDDMM.hhWrTnnn Rnnm Net...... Mtg....

Formats supported where:
;FFF.FFxyz "xyz" is one of over 3600 unique characters A-z, 0-9     
;FFF.FF5yz for 5khz repeaters "yz" is one of over 3600 unique characters A-z, 0-9     
*111111z pseudo default null Date-Time field for the OBJECT format (fixed)
DDMM.hhN/DDDMM.hhWr   LAT/LONG and "r" symbol for a voice repeater 
Tnnn tone frequency specified by 3 digit number (no tenths), start with 0 is less than 100hz (ex. T088)
Rnnm repeater range specified wth a 2 digit number (ex. R45m) m=miles or k=kilometer
Net...... 9 characters. Contains weekly net information (if any)
Mtg.....  7 characters. Contains regular club meeting information (if any)

The object name field (frequency) following the ";" must be nine characters in length. If not, you must pad the remaining field with spaces to insure there are 9 characters between the ";" and the "*" in the object string. This is a 9 character fixed field in the APRS specification. For example, if you specified ";146.94-*" as your object you would need to add 2 spaces at the end of the object name to make it valid as ";146.94-  *". Otherwise, many APRS software programs will not recognize it.

If there are no meetings or nets the "Net" and "Mtg" fields can contain optional information.

The free-text field can actually be 37 bytes long, but only the first 20 bytes are viewable on the D7 and Hamhud and only the first 28 bytes are visible on the D700. This provides the best visual presentation for those displays.

For detailed information and formatting please see  


 

BeaconDestination

// Destination ax.25 address of beacon

BeaconDestination = APNU3B

 

The BeaconDestination is the AX.25 destination address field. It is typically set to represent a particular software package and version number that makes it identifiable on the network. APNUxx is used to identify the UIDIGI controllers.

 The APRS Protocol Reference manual is available at www.tapr.org

We utilize APNU3B to represent UIDIGI 1.9 beta 3 version.

 


 

Beacon1Path

// AX.25 Beacon 1 path

Beacon1Path = 

 

The user has the flexibility to change the default settings for the 3 beacon paths available. I chose to use no path for this setting so the Beacon1Text is only transmitted locally at an interval specified by the Beacon1Interval parameter.

Leave this entry blank so that the digipeater only transmits to its local coverage area without being digipeated by other area digipeaters. To insure that a blank entry is programmed, you must insure the BIN file you are modifying with the UIDIGI configuration software also contains a blank entry in the source file at this location.

 


 

Beacon2Path

// AX.25 Beacon 2 path

Beacon2Path = WIDE2-1

 

The user has the flexibility to change the default settings for the 3 beacon paths available. This new setting also reduces the area covered by the digipeater to reduce the congestion on the network in distance areas. The Beacon2Text is transmitted via this path as specified by the Beacon2Interval parameter. Settings for your specific area may vary. We use the above setting for a one hop beacon. It is tempting to use WIDE1-1 but do not do that because home relay stations will digipeat a path with WIDE1-1.

 


 

Beacon3Path

// AX.25 Beacon 3 path

Beacon3Path = 

 

This setting reduces the area covered by the digipeater to reduce the congestion on the network in distance areas. The Beacon3Text is transmitted via this path as specified by the Beacon3Interval parameter.

 

We use the following setting to support the APRS Local Info Initiative:

Beacon3Path =  

The blank path will not be digipeated by any local digipeater. This is path for local information only. See the Beacon3Interval and Beacon3Text parameters to support this setting. 

 

Note:

There is an issue with the UIDIGI.BIN supplied in the UIDIGI distribution with Beacon2Path and Beacon3Path as they are filled with WIDE and TRACE7-7 respectively. Therefore, if you use the UIDIGI.BIN with the UIDIGI distribution you cannot set the Beacon2Path and Beacon3Path to a blank entry. If you leave them blank, the default WIDE and TRACE7-7 entries will remain. If you want Beacon2Path and Beacon3Path to have blank entries please download the UIGOLD.BIN I have prepared so these entries can be programmed with a blank path.

 

For more information about the APRS Local Info Initiative see: http://www.aprs.org/localinfo.html


 

AuxPath

// AX.25 Aux path

AuxPath =

 

Please consult the UIDIGI documentation supplied with the firmware. The AUXxxx parameters are used to support and route a raw string received on the serial port (i.e. GPS, Weather Station, etc)

We use the following setting for our digipeaters that have an external weather station connected to the serial port of the TNC. Since AL conforms to the SSn-n routing within the state of Alabama, we can create a LAN network that segments the traffic and keeps it with in the boundaries of the state. We have requested that all weather stations in our state use the ALn-n routing to confine traffic within the state boundaries. This setting insures that a weather station will reach an internet gateway.

We use a setting of AuxPath = AL2-2. Simply substitute your 2 letter state identifier for this setting.

 


 

AuxDestination

// Destination ax.25 address of aux input device string

AuxDestination = APNUxx

 

Please consult the UIDIGI documentation supplied with the firmware. The APNUxx parameters are used to support and route a raw string received on the serial port (i.e. GPS, Weather Station, etc).

We use the following setting for our digipeaters that have an external weather station connected to the serial port of the TNC to identify a UIDIGI network node with a weather station attached. 

AuxDestination = APNUWX

 


 

AuxRate

// Aux Beacon interval

AuxRate = 0

 

Please consult the UIDIGI documentation supplied with the firmware. The AUXxxx parameters are used to support and route a raw string received on the serial port (i.e. GPS, Weather Station, etc). We typically set this parameter to 420 when a weather station is connected to a UIDIGI system. All of our UIDIGI digipeaters in North Alabama have a weather station attached and beacon at a 7 minute interval with weather information. The AuxRate was a compromise setting in working with our local weather office team. In fact, most of the weather stations have been provided by our local weather team and they have helped us with obtaining sites for our digipeaters. Transmitting more often than 15 minute intervals will not increase the weather data that is transferred to NOAA. All weather data is throttled by the FINDU server at 15 minute intervals when it sends data to NOAA MADIS. The 15 minute limitation is a response to MADIS processing limitations.

We use the following setting when a weather station is connected to the digipeater to beacon every 7.4 minutes to insure at least 1 weather packet gets to the APRS-IS in a 15 minute window:

AuxRate = 444

 


 

This page was last updated on 21-Aug-2013