UIDIGI EPROM
Programming Information for APRS®
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 n8deu@arrl.net. 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.
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.
If you need help programming an EPROM, I have the capability to burn EPROM's. Drop me a message and I will try to help you get started or program an EPROM with your specific settings. I am not in this to make money, but I do want to recover any expenses. Programmed EPROMS are typically $5.00 plus $1.00 for shipping and handling. If you need an EPROM, drop me a note and I will try to help you get started.
Setting the UIDIGI firmware parameters for version 1.9 beta 3
// 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 my case I have multiple digipeaters, so I have decided to use N8DEU-4 for this example. You would use your own callsign for this setting. This is the parameter to assign the callsign to your digipeater.
// 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.
// 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
// North Path
NorthPath =
This path is used when the destination field of a packet contains the special SSID routing information. Set the path that will direct traffic to the northern direction. We do not use the North, South, East, or West settings at this location, but you may want to set them accordingly in your specific area.
We do not utilize this feature.
// South Path
SouthPath =
This path is used when the destination field of a packet contains the special SSID routing information. Set the path that will direct traffic to the southern direction. We do not use the North, South, East, or West settings at this location, but you may want to set them accordingly in your specific area.
We do not utilize this feature.
// East Path
EastPath =
This path is used when the destination field of a packet contains the special SSID routing information. Set the path that will direct traffic to the eastern direction. We do not use the North, South, East, or West settings at this location, but you may want to set them accordingly in your specific area.
We do not utilize this feature.
// West Path
WestPath =
This path is used when the destination field of a packet contains the special SSID routing information. Set the path that will direct traffic to the western direction. We do not use the North, South, East, or West settings at this location, but you may want to set them accordingly in your specific area.
We do not utilize this feature.
// 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
// UI Generic Calls (up to 8)
UIDigiCall = WIDE7-7, WIDE6-6, WIDE5-5, WIDE4-4, WIDE4-1, WIDE5-2, WIDE6-3, WIDE7-4
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 WIDE3-3. This is an effective filter to limit the abuse of long paths on the network from propagating through long digipeater paths beyond WIDE3-3. 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://web.usna.navy.mil/~bruninga/aprs/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 WIDE3-3, 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.
// 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 AL3-3 and "UIFLoodCall=AL" and "UIFloodOptions=4", the following would result:
| original packet: | N8DEU>BEACON,AL3-3: |
| 1st hop: | N8DEU>BEACON,AL3-2: |
| 2nd hop: | N8DEU>BEACON,AL3-1: |
| 3rd hop: | N8DEU>BEACON,AL3*: |
Of course, the above example shows the method called NOID where the digipeater call sign is not added to the path as it is digipeated. This is a benefit of the UIDIGI firmware since it conforms to the original idea of the UIFlood routing correctly.
More information on the APRS paradigm changes can be found at http://web.usna.navy.mil/~bruninga/aprs/fix14439.html
// 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 (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 (default 0)
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 (default 64)
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 (default 10)
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 (default 5)
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.
Use the default setting.
// Maxframe (default 4)
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.
Use the default setting.
// Retry (default 10)
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.
Use the default setting.
// RespTime 2 (default 100)
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.
Use the default setting.
// Link Check (default 18000)
LinkCheck = 18000
This parameter specifies the time-out for the sysop mode if no activity is heard within the period specified.
We use the default setting.
// Duplicate Packet Suppression Interval second (default 28)
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.
// Loop Packet Suppression Interval Mask (default 3)
// 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.
We use the default setting.
// Treat different SSID in destination call (default 1)
HandleUISSID = 0
Unless you use SSID directional routing in your network there is no need to set this parameter to anything other than 0.
// Reply to Query (default 1)
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 |
We use the default setting.
// UIFLOOD Algorithm flag (default 0)
// 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
// Eg:
// With bit 2 reset:
// IW3FQG>APRS,RELAY,WIDE2-2
// IW3FQG>APRS,DIGI1*,WIDE2-1
// IW3FQG>APRS,DIGI1*,WIDE2
// With bit 2 set
// IW3FQG>APRS,RELAY,WIDE2-2
// IW3FQG>APRS,DIGI1*,WIDE2-1
// IW3FQG>APRS,DIGI1,WIDE2*
// UIFLDfl [n]
UIFLOODOptions = 4
UIFloodOptions=4
This parameter controls how the UIFloodCall is processed. The setting of 4, emulates the NOID process. This means the SSn-n SSID is decremented and no call sign substitution is performed on the SSn-n path. On a Kantronics KPC, this setting would be equivalent to UIFLOOD SS,28,NOID.
For example if a packet were sent via AL3-3 and UIFloodOptions=4" and "UIFloodCall=AL", the following would result:
| original packet: | N8DEU>BEACON,AL3-3: |
| 1st hop: | N8DEU>BEACON,AL3-2: |
| 2nd hop: | N8DEU>BEACON,AL3-1: |
| 3rd hop: | N8DEU>BEACON,AL3*: |
In the above example, the path does not grow and no call sign substitution is performed. This is the preferred process using the SSn-n path as it reduces the amount of bandwidth utilized on a simplex channel. This is a benefit of the UIDIGI firmware. The advantage of the NOID method is that the digipeater system does not alter the path that the packet has taken through its travels and no callsign substitution is invoked from a SSn-n perspective.
For example, if a packet were sent via WIDE1-1,AL2-1 and UIFloodOptions=4" and "UIFloodCall=AL" and "UITraceOptions=2", the following would result:
W4GPS-1>S4TT1U,WIDE1-1,AL2-1/1:'rC>l#Cj/]"6+}Send
reports to pb@w4gps.com
W4GPS-1>S4TT1U,W4GPS-7,WIDE1*,AL2-1/1:'rC>l#Cj/]"6+}Send reports to
pb@w4gps.com
W4GPS-1>S4TT1U,W4GPS-7,WIDE1,AL2*/1:'rC>l#Cj/]"6+}Send reports to pb@w4gps.com
The second example shows how a simple WIDE1-1,AL2-1 packet would travel. Note, that there is no callsign substitutions taking place for a path that only contains a UIFLOOD callsign. The portion of the path that utilizes a UITraceCall does make the path grow by substituting its callsign and the TRACEN-0 in the forms of WIDE1* as it is digipeated.
This is the correct and desired performance under the new paradigm.
Settings for UIFloodOptions are:
1 - bit 0 SSn-0 will be repeated
2 - bit 1 insert callsign before SSn-n
3 - bit 2 put has been repeated flag on SSn-0
4 - bit 3 make call substitution on SSn-0 and has been repeated flag
The UIDIGI documentation does not address the last 2 settings except in the "Changes.txt" file that comes with the UIDIGI distribution. Bit 3 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 UIFloodOptions. I created a program called UIDPDC.EXE that will set UIFloodOptions = 4 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.
// UITRACE Algorithm flag (default 0)
// 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 that will set UIFloodOptions = 4 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.
// Make call substitution when repeat frames addressed to UIDIGI Callsign
// default (1)
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.
// Preempt calls (default none)
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.
// Preempt add (default none)
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.
// Preempt Digipeater (default 0)
PreemptedDigipeat = 0
We use the default setting.
// Don't change SSID (decrement) to UI Message (frame with info that start
// with char '~' default (1)
// 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.
We use the default setting.
// Process only UI Frame (default 1)
// 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.
We use the setting shown above.
// PID of processed frames (default 240)
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 24o (F0h).
// Sysop Password up to 80 char
SysopPassword = qazwsxedcrqazwsxedcrqazwsxedcrqazwsxedcrqazwsxedcrqazwsxedcrqazwsxedcrqazwsxedcr
I highly recommend that you change the SysopPassword setting unless you like unsuspecting people changing the settings on your UIDIGI for you.
// Beacon 1 interval (default 600)
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.
// Beacon 2 interval (default 1800)
Beacon2Interval = 1800
This parameter determines how often the Beacon2Text is transmitted via the Beacon2Path. The default setting of 1800 seconds equates to 30 minutes.
Beacon #2 is 30 minutes since this beacon will be transmitted via surrounding digipeaters and is not needed as often for distance locations.
// Beacon 3 interval (default 3600)
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.ew.usna.edu/~bruninga/localinfo.html
// Beacon 1 offset (default 0)
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.
// Beacon 2 offset (default 0)
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.
// Beacon 3 offset (default 0)
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.
We use the default setting.
// Digipeater Beacon 1 Text up to 70 char
Beacon1Text = !0000.00N/00000.00W.PHG0000/APRS DIGIPEATER (APRS DIGI UIDIGI 1.9B3) 1
The default has a couple issues that need to be resolved so that your Digipeater symbol and overlay appear properly.
The "!" character on the front of the line indicates this system has no messaging capability. Simply stated, there is nobody at the end of this system that can respond to messages since it is a standalone digipeater.
The "/" between the latitude and longitude (ex. !0000.00N\) needs to be changed to an "S" (ex. !0000.00NL). Please refer to http://www.ew.usna.edu/~bruninga/aprs/n-n-overlays.txt to find the proper overlay character to use on your specific digipeater setup. Some APRS software packages may not display the overlay character properly. The letter "U" overlay was obsoleted in the 12-JAN-05 paradigm changes and will no longer be utilized to identify a UIDIGI system.
The "." following the longitude and prior to the PHG identifier (ex. !0000.00NU00000.00W.PHG) needs to be changed to a "#" character (ex. !0000.00NU00000.00W#PHG) so that a Digipeater Star symbol will be displayed on the maps.
An example of my Beacon1Text follows:
Beacon1Text = !3424.30NS08648.02W#PHG5670/W3,ALn-n Wilson Mtn Alabama 1360ft
Note that the "/" after the latitude has been changed to a "S".
Note that the "." after the longitude has been changed to a "#".
These 2 changes will meet the APRS Protocol to display a Digi Star with the letter "S" overlayed 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:
http://cadigweb.ew.usna.edu/~bruninga/aprs/n-n-overlays.txt
// Digipeater Beacon 2 Text up to 70 char
Beacon2Text = !0000.00N\00000.00W.PHG0000/APRS DIGIPEATER () 2
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.
// 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.940-H*111111z3444.27N/08631.98Wr T100 R45m Mg3rdTu
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 meeting or net information. The information shown above conveys there is a meeting on the 3rd Tuesday of each month.
The repeater object format can be:
;FFF.FFF+x*111111zDDMM.hhN/DDDMM.hhWrAAAAAAAAAABBBBBBBBBBCCCCCCCC....
| Formats supported | where: |
| ;FFF.FFF+x | repeater frequency, (+/-) is the offset, and "x" is an optional local unique character |
| ;FFF.FF+xy | "xy" is one of over 3600 unique characters A-z, 0-9 |
| ;FFF.FF+SS | "SS" is your state (if you are first to use it, otherwise use something else) |
| ;FFF.FFFss | "ss" is your state (if you are first to use it, otherwise use something else) |
| *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 |
| AAAAAAAAAA, | 10 characters. Contains tone frequency and range of repeater |
| BBBBBBBBBB, | 10 characters, Contains optional information |
| CCCCCCCC, | 8 characters. Contains optional information |
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.
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 about the APRS Local Info Initiative see: http://www.ew.usna.edu/~bruninga/localinfo.html
// 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.
// 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.
// 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.
// AX.25 Beacon 3 path
Beacon3Path = NONE
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 = NONE
The path of NONE should not be digipeated by any local digipeater via this path. This is path for local information only. See the Beacon3Interval and Beacon3Text parameters to support this setting
For more information about the APRS Local Info Initiative see: http://www.ew.usna.edu/~bruninga/localinfo.html
// 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.
// 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
// Aux Beacon interval (default 0)
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 180 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 3 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.
We use the following setting when a weather station is connected to the digipeater to beacon every 3 minutes:
AuxRate = 180
This page was last updated on 10-Dec-2007