APRS - Ontario


The Revamp of APRS - A Guide to Implementing the "APRS Fixes" from Bob Bruninga, WB4APR

Updated May 18, 2005 (See highlighted text)

The North American APRS frequency is 144.390MHz.  This frequency is a shared simplex frequency used to transmit APRS data.  If you’ve ever listened to this frequency, you will know that it can be extremely busy and simultaneous transmission from 2 or more APRS stations is quite common.  Thus since there is no ‘data cop’ to direct transmission, the frequency is an asynchronous channel.  As APRS gains in popularity this asynchronous channel is getting extremely busy.

Before jumping to the conclusion of a second APRS frequency, there is a major need to clean up the existing frequency.  For example, is a station in Mississauga interested in seeing APRS traffic from Michigan every minute?  Do we need to transmit our beacon every 10 seconds?  Do we need digipeaters (APRS repeaters) to re-transmit our beacon with a path so that it can be seen in Sudbury?  So as you can see with some good housekeeping, we can clean up the existing APRS frequency by keeping traffic local to our area (and not adding to the congestion in other areas!) and keeping our beacon intervals to a sensible value.

In certain US states where APRS is extremely popular, there has been a pressing need to address the congested APRS network problems.  Bob Bruninga, the original developer of APRS has come up with a North American recommendation on how the 144.390 frequency congestion issue can be addressed.  Bob has a web page dedicated to this issue, and I encourage all APRS users to read it (http://www.ew.usna.edu/~bruninga/aprs/fix14439.html).

Now earlier on I mentioned the word path.  Path in the context of packet and APRS is the route through which a packet will travel.  The conventional approach was to use a path of RELAY,WIDE or RELAY,WIDE,WIDE, and more recently a smarter approach was to use RELAY,WIDEn-N.  The n-N quantified the number of hops through which a packet would travel.  More on this in a moment.

So some of you may be wondering why is this an issue in our local area.  The US has a much larger concentration of APRS users, so they are the ones with a problem not us.  Well unfortunately this is not true.  The problem that we have here is that we are seeing duplicate beacons and these are often after new beacons have been received from an alternate path.  To illustrate this, if we track an APRS mobile on a map, and the mobile is traveling north, we may receive beacon #1, #2, #3 and then all of a sudden a delayed (duplicate) beacon #1.  Optically this looks like the mobile changed course and started to head south.  Then we receive beacon #4 (a correct beacon) now north of beacon #3.  So again optically this looks like another change in direction, now heading north again!

Furthermore, there are several APRS stations and I am sorry to say even digipeaters in the area that broadcast with a path of RELAY,WIDE7-7.  So let me illustrate this WIDEn-N concept to show the total number of re-transmissions via digipeaters for a single transmission from a mobile or a fixed station:











































































The above table assumes that for every single transmission, a total of 3 digipeaters will receive the transmission direct as well as receiving the original transmission – so a total of 4 copies of the same transmission.  In the Toronto and surrounding area where we have a good APRS digipeater coverage, the above table will apply.  Obviously in remote locations the above table will need to be adjusted to show the total number of copies per digipeater.

So referring back to my example of the digipeater that re-broadcasts with a path of WIDE7-7, from the above table we see that this results in a total of 196 (yes, that’s one hundred and ninety six) re-transmissions of a mobile’s APRS beacon.  Now it’s my belief that folks are not aware of the total number of hops.  Instead folks have become frustrated with the busy and asynchronous APRS frequency and in order to increase their chances of getting a packet through, they have increased the number of hops.  While this certainly yields the required result, it is at the expense of every single APRS user out there.  By using multiple hops, this not only results in congestion in our immediate area, it also contributes to unwanted traffic and congestion outside of our immediate area.  

Hence the conventional routing of packets via legacy paths must be addressed and contained before the problems magnify by an order of magnitude.

Earlier on I referred to a problem of duplicate beacons.  The issue here is the use of “RELAY,WIDE” in the packet path.  Bob, WB4APR, explains the problem on his webpage (http://www.ew.usna.edu/~bruninga/aprs/relaypaths.txt).  Using Bob’s example, if a mobile transmits an APRS beacon with a path of “RELAY,WIDE” and the transmission is received and re-transmitted by a single digipeater; then that single digipeaters transmission is heard and re-transmitted by 3 other digipeaters, then we have a total of 4 copies of the same APRS beacon (one for each digipeater) plus the original one from the originating mobile.  Now this is fine so far, although we have 4 copies of the same beacon, these are not officially duplicates or dupes.

Lets explore this using Bob’s raw packet data:

MOBILE>APRS,RELAY*,WIDE  (this is the first RELAY digipeater)

MOBILE>APRS,RELAY,DIGI1*  (this is the first wide area digi)

MOBILE>APRS,RELAY,DIGI2*  (this is the second wide area digi)

MOBILE>APRS,RELAY,DIGI3*  (this is the third wide area digi)


Now when these digipeaters re-transmit the beacon, the resulting packets will be:

MOBILE>APRS,DIGI1*,WIDE  (this is the first wide area digi’s re-transmission)

MOBILE>APRS,DIGI2*,WIDE  (this is the second wide area digi’s re-transmission)

MOBILE>APRS,DIGI3*,WIDE  (this is the third wide area digi’s re-transmission)

MOBILE>APRS,DIGI1,DIGI2*  (this is the first digi’s packet being heard direct, and re-transmitted by digi 2)

MOBILE>APRS,DIGI1,DIGI3*  (this  is the first digi’s packet being heard direct, and re-transmitted by digi 3)

MOBILE>APRS,DIGI2,DIGI1*  (this is the second digi’s packet being heard direct, and re-transmitted by digi 1)

MOBILE>APRS,DIGI2,DIGI3*  (this is the second digi’s packet being heard direct, and re-transmitted by digi 3)

MOBILE>APRS,DIGI3,DIGI1*  (this is the third digi’s packet being heard direct, and re-transmitted by digi 1)

MOBILE>APRS,DIGI3,DIGI2*  (this is the third digi’s packet being heard direct, and re-transmitted by digi 2).


So what we now have are 9 copies of the original transmission.  The first 3 are the desired re-transmission of the original mobile’s RELAY,WIDE beacon.  However, by way of example, notice how digi 1 is actually transmitting the same beacon 3 times (the very first response to the mobile’s RELAY,WIDE; then a second time in response to digi 2’s “WIDE”, and then a third time in response to digi 3’s “WIDE”).  So we have each digipeater transmitting the same packet three times, or two “dupes” of the same packet for each digipeater – making a total of 6 “dupes”.

Now imagine how much unnecessary congestion is being caused on an asynchronous simplex channel.  The use of RELAY,WIDE and more so with RELAY,WIDE,WIDE is a big problem… a recipe for “dupes”, causes excessive band congestion, and therefore the use of these paths must be eliminated!

The use of a more smarter packet path such as “WIDEn-N” (where n should be no greater than 2 in our area…. Let me repeat that, “no greater than 2”) is a much better approach since the WIDEn-N algorithm has built-in ‘dupe suppression’ which eliminates a wide area digipeater from re-transmitting the same beacon more than once.  This is exactly what we want – one transmission, no dupes, and no band congestion!

In light of the above, based on testing with 5 mobiles In Halton, Peel, Markham and  Newmarket, the preferred and recommended path settings for the Toronto and surrounding area are:

WIDE1-1 for fixed stations (or better still to specify the callsign of the nearest digi);

WIDE2-1 or WIDE2-2 for mobile stations (Note, if you find that a “RELAY” is required, then you can substitute “RELAY” with “WIDE1-1” thus the conventional “RELAY,WIDE2-2” will look like “WIDE1-1,WIDE2-2”).


Notice how the use of “RELAY” in either path is no longer recommended!

This then brings me to the 10 recommendations from Bob, WB4APR, to ‘fix’ the APRS network:


#1: Phasing out RELAY and WIDE paths…

From the above examples, you can see how the use of RELAY,WIDE results in dupes from the same digipeater tying up valuable bandwidth.  The WIDEn-N paradigm has a perfect dupe suppression algorithm as it is a one-way path – i.e., packets will not fold back on themselves.  So a digipeater will never transmit a previously digipeated packet.  If you feel that a relay or a boost is required from a local digi, please replace “RELAY” with WIDE1-1.  This will ‘contain’ the number of hops to 1, which is ideal – very efficient, low overhead, and preserves valuable bandwidth!

#2:  The use of WIDEn-N

Although the WIDEn-N paradigm is more efficient than a simple WIDE or a WIDE,WIDE, the problem with WIDEn-N is that it is still dependent upon user settings.  High values of n can cause havoc on the network (please refer to the table earlier showing how a WIDE7-7 path can result in 196 packets for a single transmission.  In case you think this is an extreme case, it is not, we have someone not too far from us using RELAY,WIDE7-7).

So early this year, the WIDEn-N paradigm has evolved to a point where it removes the reliance on user settings (i.e., for high values on n).  Digipeaters are now able to “trap” large n abuse.  My digipeater and I-Gate has been converted to a “WIDEn-N flooding firewall”.  This means that if I receive a packet with a path anywhere from WIDE7-7 to a WIDE4-1, I will provide ONE hop for that packet and that’s it.  Unlike a conventional digipeater where the path would normally be decremented from a say WIDE5-5 down to a WIDE5-4, and then the packet would continue to be digipeated until the path was exhausted, the new “traps” break up the path so that it can not be digipeated any further – i.e., we provide one hop and that’s it – game over!

By way of example, if I receive a WIDE7-7 packet, I will digipeat the packet once, and instead of decrementing the path to a WIDE7-6, I break up the packet and digipeat as WIDE7*.  WIDE7* is not a recognized alias and therefore this will not digipeat 196 times.  It is important to note though that until all of the digipeaters in our area get converted there will still be some duplication in packets.  The same goes for mobiles using RELAY,WIDE, WIDE – until everyone converts there will still be some duplication and hence unnecessary burden on the network.

#3:  The New State (or Provincial) SSn-N Path

There are situations where APRS stations are located very close to a provincial or a federal boundary.  The stations, when using WIDEn-N, may have to use a high value on ‘n’ so that their packets can be digipeated into a larger provincial network.  However, since these stations are located close to a provincial or federal boundary, the use of a large ‘n’ in the WIDEn-N paradigm will cause unnecessary QRM in neighbouring provinces, and in our case, the US!

So the SSn-N path aims to address the need for a state or provincial net in which users may need to use high values on ‘n’ to get their beacons digipeated into a larger, or a distant area.

For the SS parameter, in Canada, we are using the RAC section.  So for Southern Ontario, the designation is "SONT" and Northern Ontario is "NONT".  Again until all digipeaters convert, the implementation of the “SS” path has a limited footprint.  Prefixing “SS” with “RELAY” defeats the whole idea of the SSn-N paradigm.  As outlined earlier, the use of “RELAY” is now being phased out and is no longer recommended.  My personal recommendation at this point is to go with “WIDE2-2” as I have with my mobile station (or WIDE1-1,WIDE2-1 if you happen to live near a fill-in digi).

#4: Labelling the New n-N Paradigm Digi’s

To identify the new ‘smart’ digi’s five new labels have been introduced:

L – this identifies a digipeater supporting a limited number of hops for stations that abuse the WIDEn-N paradigm with large values of ‘n’ (these "L" digis do not support the SSn-N paradigm);

S – digipeaters supporting the new SSn-N paradigm as well as the WIDEn-N paradigm (e.g., mine!);

P – PacCom digipeaters that have been converted to support WIDE2-2;

F - The early v8.2 KPC-3 digis that can only support WIDEn-N in the UIFLOOD parameter.  They can support SSn-N in the UITRACE parameter.  (Note where possible, I suggest upgrading the KPC-3+ ROMs to v8.3 and hence identifying as an "S" digi);

1 – used to identify one hop digi’s supporting WIDE1-1 (i.e., fill-in digi’s that were previously responding to ‘RELAY’)  

Now in addition to the new overlays, we would like to encourage / emphasize the importance for all sysops to include the capabilities of the digi in the beacon text - i.e., along with the PHG information.  For example, my digi beacon text message includes: "PHG5535/W3,SONTn,VA3UV".  We'll cover PHG information codes later in this document.  The "W3" tells users that I support the WIDEn-N format with a limit of n=3 (anything higher will be trapped and will only be digi'd once).  The "SONTn" tells users that I support 'SONTn-N'.  Finally, by inserting my callsign, this tells users that I will also digi on my callsign.  In light of the changes being proposed here, I think this is an excellent approach as the beacon text clearly advises users of the configuration (and limitations) of the digi.

#5: The ALOHA Circle

The ALOHA circle is an imaginary RF boundary around you that contains the number of users contributing and resulting in 100% bandwidth occupancy.  Most APRS software will calculate and overlay an ALOHA circle on a map.  The idea of the ALOHA circle is that it identifies your ALOHA neighbourhood and the digipeaters in your neighbourhood with which you need to communicate.  You are responsible for making sure that your packets are not being sent outside of your ALOHA neighbourhood.  By viewing your ALOHA circle and that of digipeaters in your ALOHA neighbourhood, you can then determine the number of hops needed to get your beacon from point A to point B - i.e., the value of "n" for the WIDEn-N paradigm.

The APRS protocol uses the PHGd (Power, Height, Gain and directivity) extension in a station's packet to determine the radio range circle for a given station.

The PHG codes are listed in the table below:


PHGd Code 0 1 2 3 4 5 6 7 8 9 Units
Power 0 1 4 9 16 25 36 49 64 81 Watts
Height 10 20 40 80 160 320 640 1280 2560 5120 feet
Gain 0 1 2 3 4 5 6 7 8 9 dB
Directivity omni 45 NE 90 E 135 SE 180 S 225 SW 270 W 315 NW 360N



The height is the height of the antenna above average local terrain, not above ground or sea level.  The height code can also be any ASCII character from 0 to 9 and above e.g., in the case of balloons and aircraft.  Examples are ":" for a height code of 10,240 feet, and ";" for 20,480 feet.

The Directivity offsets the PHG circle by 1/3 in the given direction.  The directivity code can also be used to indicate a favoured direction or a null, even where an omni directional antenna is used.

Examples of PHG codes follow...

PHG5130 Means ....

A power of 25 Watts;

An antenna height of 20 feet (above local terrain);

An antenna gain of 3dB;

An omni directional antenna.


PHG3232 Means ... 

A power of 9 Watts;

An antenna height of 40 feet (above local terrain);

An antenna gain of 3dB;

Maximum directivity to the east.

To calculate your phgd code, you can either use the above table or use an online calculator such as:  http://www.nashvilleaprs.net/apps/phgcalc.php


The Range Circle

The APRS protocol uses the p, h, g and d codes to determine the usable radio range circle (in miles) around a given station.  The radio range circle diameter is calculated as follows:

Power = P2

Height-above-average-terrain (haat) = 10 x 2h

Gain = 10(g/10)

Range = Sqrt (2 x haat x Sqrt((Power/10) x (gain/2)))


Example, for a phgd of 5560:

Power = 52 = 25 Watts;

haat = 10 x 25 = 320 feet

gain = 10(6/10) = 3.98

range = Sqrt (2 x 320) x Sqrt (25/10) x (3.98/2))) ..... Approx., 38 miles (or 58kms).

It is recommended that all fixed stations include their phgd code in their beacon comment.  APRS software can then use the phgd code to plot the range circle around each station.

In fact, it is my personal recommendation, as an attempt to enforce the use of PHG and the range circle, that all stations (including mobiles) insert their phgd code in their beacon comment or status message.

The following is a listing (in no particular order) of some of the local area digi's, their reported phgd values and pre-calculated range circle radius:


Digipeater phgd Code Range Circle (kms)
VE3NEC 5560 58
VE3YAP 5760 116
VE3OAK 4430 31
VE3VWD 4520 41
VE3ZRD 3220 12
VA3BAL 5650 77
VE3RPT 4641 65
VE3LSR 5530(4) 49
VA3OPS 4430 31
VA3UV1 5535 49

1:  VA3UV digi' reports a phgd code of 5535, which equates to a range circle of 49kms.  The height code has been adjusted to yield the actual range circle obtained via tests with local mobiles..


Once you know the range circle of surrounding digi's, you can then determine the value of "n" in the WIDEn-N protocol (you shouldn’t need to go any greater than 2 – yes, this is a sore point with some people!).  Now bear in mind that the  range circle, as plotted by most of the APRS software packages, will be quite conservative.  In fact the plotted range circle has been de-rated by approximately 50% to compensate for mobile flutter.  Thus the 50% range circle is considered to be a "sure bet" for mobiles.  In the case of a fixed station, with a decent antenna, you can probably double the range.  However, I'd encourage some experimentation.

A screen shot taken from my UI-View controlled digipeater and I-Gate is shown below:

So with the range circles of all digi's displayed (digi range circles are in green, and Gates are shown in blue), we can determine the value of "n".  So lets take an example of a mobile travelling from Cambridge to Newcastle;  She wishes for her friends and family in Cambridge to be able to watch her beacon and receive messages while she's travelling.  So what value of "n" would she need to satisfy her need?

First of all, I deliberately chose Newcastle as an end-point in her journey.  As you can see, Newcastle is not directly covered by a digipeater.  The RPT digi' just misses Newcastle (note how the range circle for RPT is offset due to RPT's directivity bias to the North East).  So the mobile in Newcastle has to make her beacon "heard" within the range circle of RPT.  A 10 or 20W mobile should not have any difficulty in achieving this.  So once the beacon is "heard" by RPT, she needs to get her beacon over to Cambridge.  Cambridge is within the range circle of YAP.  OK, so now we know the two end-points and the 2 digi's involved.  By looking at the above screen capture, we can see that the range circle of BAL will allow our mobile to "hop" between RPT and YAP.  Our mobile therefore needs 2 hops.  One from RPT to BAL, and the other from BAL to YAP.  Thus a path of WIDE2-2 will accomplish this effectively without generating any excessive traffic.

Finally, before leaving this topic (which is an extremely important concept to grasp and hence the reason why I have spent a lot of time discussing it!), one final screen shot that I'd like to show is my ALOHA neighbourhood.  Again this is taken from my digipeater and I-Gate (located in NW Mississauga):

The red circle encompasses my ALOHA neighbourhood.  This is my imaginary RF boundary, and of course it will differ from station-to-station.  The idea here is that we are all responsible for ensuring that our beacon is not routinely heard outside of our ALOHA neighbourhood.  In my case, this means that my beacon should not be heard any further west of Woodstock, no further east than Newcastle; and not in New York, nor in Wasaga.  So with the boundary defined, I can then look at the range circles of my surrounding digi's and see that all I can *afford* is a maximum of 2 hops (i.e., no more than WIDE2-2).


#6: An alternate input channel on 144.990

Under the current situation, with the congested APRS frequency (144.390), until everyone switches over to using the smarter WIDEn-N paradigm, and ensures that their beacon does not routinely travel outside of their ALOHA neighbourhood, our digipeaters are, for the most part, being 'bombarded' with QRM from outside of our local ALOHA neighbourbood.  Therefore, due to the asynchronous nature of the network, we now have to compete for bandwidth hoping that our beacon will 'squeeze' in between the out-of-area QRM.

One of Bob's recommendations is to move local users to an alternate frequency.  One suggestion is 144.990 (600kHz above the standard APRS frequency) with the intent that local digi's can listen on 144.990 and repeat on 144.390 where everyone listens.  Personally, I'd rather see us concentrate on the real problem rather than come up with a band-aid solution to address the symptom.  If we all work together to  'respect' our ALOHA neighbourhood, and encourage all APRS stations to do the same, then our digi's should not be overly burdened with out-of-area traffic.

There has been some previous discussion re., the use of this second frequency for the weaker mobile and portable stations.  This may have some merit, but again, lets work on cleaning up the existing frequency and see where we are before adding a second layer.


#7: Disable the HID identifier in the Digi's

The HID identifier is an identification beacon, which was previously used in packet radio.  HID is not an APRS format, and if enabled will beacon every 10 minutes.  Furthermore this "irrelevant" packet will also propagate with the default path.  Bob illustrates that for a path of WIDE,WIDE,WIDE, the HID identifier can generate approximately 100 packets per hour per digi.

APRS was not intended to be used on a 24/7 basis as most of us have come to know it today.  The original intent of APRS was a tactical emergency communication and response system.  Imagine a large number of APRS stations arriving on a disaster scene.  Firstly, we need to make sure that the network has the bandwidth to accommodate a sudden influx of activity, and secondly, under distress conditions, we need to make sure that all of these APRS stations (and the agencies that they may be supporting under the distress), are updated with local information within 10 minutes of arrival.  This takes us to fix #8.


#8:  Digi Beacon Rate

The recommended digi beacon rate for the WIDEn-N paradigm is:

Every 10 minutes a local direct position
Every 30 minutes a 1 hop area position
Every 60 minutes a 2 hop regional position

Bob has provided sample settings for the KPC-3+ digi's as follows:

UNPROTO APN383 <== no via for direct BTexts announcing local info
BEACON EVERY 10 <== but ONLY for direct BTexts with local info
BLT 1 EVERY 00:30:00 START 00:00:00
BLT 2 EVERY 00:30:00 START 00:10:00
BLT 3 EVERY 01:00:00 START 00:20:00
BLT 4 EVERY 01:00:00 START 00:50:00
LTP 1 APN383 
LTP 2 APN383 
LTP 4 APN383 VIA WIDE2-2 <==equivalent to a user path of WIDE3-3>


In the case of UIDIGI roms, we have modified Bob's recommendations to overcome the fact that all 3 paths would beacon on the hour, and a missed beacon every 30 minutes past the hour.  Our revised settings for UIDIGI roms are:

#1 DIRECT every 10 mins starting at 0
#2 VIA WIDE every 30 mins starting at 17
#3 VIA WIDE2-2 every 60 mins starting at 5

The above settings provide a local packet every 10 minutes; A WIDE packet every 30 minutes, and then a WIDE2-2 every hour. 

Finally, for all digi sysop's, please remember to move all WIDEn-N digipeating to the UITRACE parameter.  This enables tracking and traceability of all digipeated packets.  During the past few months while we have been troubleshooting local APRS activity, it has been extremely frustrating to find digipeated packets without callsign substitution.  It is vital that all sysop's implement these few basic rules (WIDEn-N digipeating, timed (or phased) beaconing via local, WIDE, and WIDE2-2 paths, and UITRACE).


#9:  Updating PacComm "T" Digi's to support WIDE2-2 and change them to "P" digi's

As I mentioned earlier, it is so frustrating trying to decode and trace back data packets to see who digipeated.  The early PacComm TNC's supported callsign substitution and were hence referred to as "Trace" digi's and labelled with the letter "T" for Trace.  At the time, these early TNC's did not shave room to support the WIDEn-N paradigm.  The PacComm TNC's could only support 4 aliases.  Historically these were "RELAY", "WIDE", "TRACE" and "SS" (or "PP") for state or provincial nets.

Under the current proposal, these 4 legacy paths are now obsolete.  This now enables PacComm TNC's to support the following 4 paths:  WIDE1-1, WIDE2-1, WIDE2-2, and WIDE3-3.  Bingo! we can now get the older PacComm TNC's to support the WIDEn-N paradigm.

Further details on the exact setup procedure is provided on Bob's site:  http://www.ew.usna.edu/~bruninga/aprs/PacComm-settings.txt

Finally, please don't forget to identify your 'converted' PacComm digi as a "P" digi, and don't forget to advise all of your local mobiles that RELAY and WIDE will no longer be supported!


#10:  Update the very-high, hear-too-much digi's

In order to accommodate growth, the "cell size" must get smaller to keep within the ALOHA limits of an RF network.  A high digipeater could introduce excessive traffic into a local network.  Bob offers 4 recommendations for high digi's.  Without performing a full survey of all digipeaters in the area, I'm not too sure if this is a problem in South Western Ontario.  I'm inclined to recommend that we leave this for future discussion.


Finally, the recommended rollout and implementation plan for South Western Ontario

At this time, I am conducting an online survey to review the TNC hardware and firmware level of the various digipeaters in South Western Ontario.  In parallel, I am encouraging all mobile operators to change from the legacy paths (RELAY,WIDE, etc.) to the smarter WIDEn-N paradigm.

Once, I have gauged the reaction from both digi sysop's and mobiles alike, we'll come up with a plan to phase out RELAY and WIDE aliases across the board.

If you do change your path as a result of this article, I'd like to hear from you re., your experience and the path that you changed from and what you changed to.  Please drop me an email.

To date, I am aware of approx 25 local APRS users that have changed over to the WIDEn-N paradigm.  In parallel, I have converted my own digi over to an "S" digi (i.e., one that supports WIDEn-N and the SSn-N paradigms - note I no longer support RELAY nor WIDE).  I have also been working on preparing 2 templates for the KPC-3+ (v8.3) and UIDIGI (v1.9 Beta 3) ROMs.  I have reviewed these setting files with Bob Bruninga (WB4APR).  If you would like for your digi to be a beta test site for the new settings, please contact me.  Note that there is a bug with the UIDIGI firmware i.e., the UIFLOOD and UITRACE parameters.  The work around is available on Ron Stordahl's website (3) - or please contact me for further details.


Acknowledgements and References

  1. Bob Bruninga's Website:  http://www.ew.usna.edu/~bruninga/aprs/fix14439.html;

  2. APRS Protocol Reference Document v1.0; The APRS Working Group

  3. Shoehorning the 'New n-N Paradigm' into UIDIGI v1.9 Beta 3 by Ron Stordahl, N5IN:  http://dxspots.com/FIX14439_UIDIGI-ROM.html 

  4. NWAPRS WIDE Digipeater Settings:  http://nwaprs.org/widen-n.htm 

  5. Tim Brown, VE3TMB (mobile test station)

  6. David Haw, VA3TRK (mobile test station)