N0ALE: FT-5DR - A Viable Sidekick for APRS

    Recently I picked up the new FT-5DR mainly for working APRS and to have as another combo analog/digital Fusion handheld.  I have to say that I'm quite impressed thus far with the functionality of the radio itself.  Having never owned an FT-3DR or similar handheld, there was a bit of learning to do as far as saving memories and setting up basic functions.  The touch screen is fairly responsive and for being a Yaesu I feel the menus aren't too elaborate.  I also discovered that the radio has a built in wideband receiver that can receive multiple different bands including the AM/FM broadcast band which is something you might have seen in cheaper handhelds (think Baofeng).  One thing I want to focus on for this article is packet routing and the ease of selecting different routes on the fly.  The FT-5DR comes pre-programmed with common routes such as WIDE 1-1, WIDE 1-1 WIDE 2-1 etc.  

    You can also save custom routes into available memory slots for quick recall.  Living in the Metro, a WIDE 1-1 or WIDE 1-1 WIDE 2-1 is more than sufficient.  It all comes down to the number of hops that a packet is allowed to take enroute to a I-Gate.  It's important to understand that choosing the proper routing path increases your chance of getting gated while helping not crowd an already busy frequency space.  I have the luxury of being within spitting distance of my I-Gate while at home and so I can transmit using the lowest power and a WIDE 1-1 path.  This conserves airtime and still has my packets get gated.  When you choose a route the format you use is WIDE n-N, WIDE n-N WIDE n+1-N or WIDE n-N WIDE n+1-N+1.

    The first WIDE designation is usually something like WIDE 1-1.  Inside of the APRS network this allows smaller fill-in stations to be able to work your packet after transmission.  As you increase "n" you're basically allowing your packet to move up the hierarchy.  A WIDE 1-1 WIDE 2-1 designation allows both smaller fill-in stations and medium sized stations to be able to work your packet.  The "N" value is the number of hops allowed before your packet times out.  Typically at each station this "N" value will be decremented by 1.  However some stations depending on their configuration will not decrement this value allowing for longer propagation than intended.  As you move outside the Metro area you might even see some wide area WIDE 3-N designations but understandably so.  In those areas there is generally less in the way of APRS infrastructure so a WIDE 3-N is just a little bit of insurance your packet reaches a far away I-Gate.

KD0TLS: APRS update 11/27/21

  There are a few developments that have arisen since the last update. The landscape is constantly changing, but the metro scene seems to be stabilizing. 

The only development of note since my last local update is that the Robbinsdale digipeater K0YTH-13 continues to struggle. It transmits a flurry of packets around 3:30 AM, and then goes dead until the next day. 

 Some strangeness for those who follow the local scene closely: the Medina gateway W0PZT-1 has appropriated my email address in a STATUS packet. As always, click on the image to enlarge it.

I'm not the contact for this station

 This is undoubtedly some glitch where W0PZT-1 picked up one of the STATUS packets from the KD0TLS-1 gateway and transmitted it (either RF or -IS) as its own. I've looked through a lot of the raw packets from the Medina station, but I haven't found when this happened. 

 I've never seen W0PZT-1 (or its previous incarnation, N0AGI-1) transmit a STATUS packet before this. I had always believed the station didn't have that capability. The solution is for whoever runs the W0PZT-1 gateway/digi to simply transmit an updated status message that will replace my email address. 

 I suppose I should clarify that I am not the contact person, trustee, operator, etc. for this gateway run by HCEM/AUXCOMM. I have never laid eyes on the station, and I have no access to it. It's hardly an insult to be associated with HCEM, but I'm afraid that I don't merit that distinction. 

Greater MN:

The big news is that the Isle gateway W0KGW-10 is back up and running. This RX-only gateway was once a major hub, gating mostly digipeater traffic from about a quarter of the State. This was back in the day when the Aitkin digipeater AITKIN was a powerhouse station, and before the WB0VGI-1 and KE0OPK-13 gateways to the south and north existed. It still pulls in digipeater traffic from distant digis up to the North Shore, make no mistake. It's just that there are alternatives now to handle that traffic, and that's a good thing. The new role is more of providing local coverage in an area with very little direct coverage. I'm hopeful that some enterprising amateurs around the Milaca/Ogilvie/Mora area would put up a digipeater to feed W0KGK-10 and provide some sorely-needed coverage. 

 

Up further north, the K9MLD-11 and COOKMN digipeaters (in Virginia and Cook, respectively) continue to struggle. They're only up for about an hour a day. To make matters worse, the Ely gateway ELYMN hasn't heard any traffic for five days now. It's still connected to the -IS, however. This is a fairly common thing that I've termed "going deaf". A simple reset, such as rebooting the computer/TNC or the transceiver, usually fixes things.

EDIT: Last night (11/27) the TX gateway in Soudan K0VRC-2 came back on-air around 8 PM. At nearly the same time, the K9MLD-11 digipeater near Virginia returned to operation. Again, at nearly the same time, the digipeater in Cook COOKMN flickered back to life. And the Ely TX gateway ELYMN seems to be stable and operating normally again.

 

On the North Shore, the NARC digipeater run by NA0RC in Knife River seems to have also "gone deaf". This is becoming a somewhat unreliable machine, though it has decent coverage along the North Shore when it's up. 

 

To the east, the Battle Lake digipeater KC0ZZQ-5 is down again. This entire East Central area has struggled for years due to the loss of gateways in Hoffman and Wadena. 

EDIT: KC0ZZQ-5 is transmitting again, but is hearing nothing. Just this morning (11/28), it went for a few hours without transmitting an ID at all. Seems fair to class this machine as "struggling", at least for now.

 

The KE0VUL-10 TX gateway in Gonvick (midway between Bemidji and Thief River Falls) has dialed back its ID rate to a considerate 20-minute cycle. This is an area that really needs a TX gateway for messaging, but mostly to gate the big Lengby digipeater. 

 

EDIT: The TX gateway N0AWA-2 in Badger went off-air at about 8 AM this morning (11/28).

EDIT: The Rochester TX gateway N0HZN went down yesterday afternoon (11/27). Looking at its raw packets, the station is using the unrecognized device code "GPS", causing its packets to be rejected by the -IS servers. It seems to be using UI-View, which APRS recognizes as "APU25N". In spite of being near two big and active digipeaters, it hasn't heard anything since yesterday afternoon.

That's it for this week. Hope you found it interesting.

KD0TLS: This is KD0TLS-7

This is all you need

 Above, you see most of my "laptop station" for APRS, known as KD0TLS-7. It consists of a monoband Puxing PX-777 plugged in to a Mobilinkd TNC2. The radiometer has nothing to do with the station; I just like having it in the windowsill. 

 The Mobilinkd TNC connects with my laptop via Bluetooth. The laptop is connected to the internet, so I have both RF and -IS available. The laptop is running APRSIS32 on Windows 10. 

 As you can see, it's a pretty simple station. I live in a condo, but I can put an HT in a windowsill and reach at least three local gateways/digipeaters with just 5W. This allows me to, for all intents and purposes, reach the world. But also the metro. 

 Back when K0YTH-13 was working in Robbinsdale, it was much easier for me to make a station like this work effectively. But I can still reach the Medina gateway (W0PZT-1) and the U of M W0YC-5 gateway. Lately, W3JF in Brooklyn Park has turned out to be a suitable replacement for the Robbinsdale digi -- at least for this particular station. 

 Note that I'm just using a "stock duck" antenna. Certainly, an indoor J-pole or mag-mount whip would be more effective. The point is that this works just fine. Virtually all hams have an HT with a stock duck. The vast majority of hams within the freeway loop are within eight miles of a gateway or digipeater, which is how far W0PZT-1 is from me... on the opposite side of the building from this windowsill. 

 While I'm using a Windows laptop running APRSIS32, this same station could operate equally well with an Android smart-phone or tablet running APRSDroid. Or a Linux box running YAAC or Xastir. Or an IPhone running the aprs.fi app. 

 The only thing that a lot of hams might lack is the Moblinkd TNC. The older (and much cheaper) TNC1.0 and TNC2 used to be available, but no longer. Instead, your choice is the much-improved $120 TNC3 (plus whatever cable you need to connect to the radio). They even will sell you a TRRS connector for $1.25 to make your own cable. The Mobilinkd TNC runs for two days on a single charge. I know, because I've tested it. And it charges with a standard USB cable, so most laptops or phone chargers can handle it. 

 A Microsat TNC with Bluetooth will run you about $180, and allow you to run very reliable gateways and digipeaters. A Kantronics KPC-3+ will cost $250 plus cable, and allow you to do WinLink packet, too. There are always more expensive options. But if you just want to get on the air with APRS, the cheapest option is the Mobilinkd TNC. 

 And if you don't particularly care about RF operation, it's a whole lot cheaper. Like, free.

KD0TLS: MN update 11/2021

 A few new developments have arisen across Minnesota over the past week, and these often impact the metro due to its importance in gating and handling traffic over a wide area. 

 First, locally: 

• Hopkins digipeater AE0KW-1 has made a re-appearance. This is an interesting addition to the metro, because it is a true fill-in digipeater: it only repeats packets with WIDE1-1 in the N-path. This digi operates irregularly, and often disappears. But it's currently on-air.
• WA0FW-5 in Plymouth is showing up on aprs.fi as a gateway, but a check of it's stats shows that it only gates packets from it's own station.
• W3JF in Brooklyn Park continues it's testing, but has added digipeater capability and has gated over 700 packets in a few short weeks. This station uses a DRAWS HAT, running on Raspberry Pi. It's obviously working well, and largely taking the place of the absent K0YTH-13 in Robbinsdale as both a source of traffic and reliable path to gateway for my own station. 
• Minnetonka gateway K0GV-10 has passed the 15k mark in packets handled so far this month. This is yet another example of a Raspberry Pi (RPi) gateway making an impressive local impact, while providing messaging capability to the west metro.
• Southwest metro digipeater KF0ZH has broken the 1k packet threshold, handling 1.5k packets so far this month. While its core coverage area is Chaska, Bloomington, and Burnsville, it has fringe coverage out as far as Woodbury.
• Likewise, the Gem Lake digipeater K0LAV-8 has passed that same mark, handling 1.6k packets so far this month.

Next, outside the metro: 

• Northwest of Becker, KC0LDH-1 has appeared as a digipeater. It's still too early to draw any conclusions about its coverage, but it's IDing at an inconsiderate rate of every two minutes. It also easily reaches the Medina W0PZT-1 gateway, so this compounds the problem by adding significant congestion for no apparent benefit. Often, new stations do this to establish their coverage, but I sincerely hope that KC0LDH dials it back to 20 minutes or more sooner than later. 
• Near Maple Lake, the N0GEF-15 digipeater seems to be back in the game. This machine often goes a week or more without hearing anything, but it's working again. It's also transmitting its ID at less than 10 minute intervals. It's there, we get it. 
• Last week, the Big Lake digipeater BIGLKWX was down. It's back on-air now, with a vengeance. I'm surprised it can hear anything, though, since it's IDing every three minutes.
• The Battle Lake digipeater KC0ZZQ-5 made a brief re-appearance, but went off-air this morning around 10:30. 
• The Fargo RX-only gateway KK0TT-15 has passed the 2K packet handling threshold this week. 
• Outside of Bemidji, the Lengby W0BJI-2 digipeater has handled 1.8k packets this month. It's stats have greatly improved with the addition of the KE0VUL-9 TX gateway in Fosston -- which IDs over RF every three minutes. 
• The COOKMN (Cook) and K9MLD-11 (Virginia) digipeaters came back on the scene after dropping off unexpectedly last week. Both are now seemingly off-air again. On the plus side, the gateway/digi ELYMN in Ely is back in action. 
• The Cloquet "digipeater" N0ZRD-10 hasn't heard a station in well over two weeks, yet it transmits every five minutes. 
• The relatively new KE0OPK-13 TX gateway outside of the Duluth area (Otter Creek) has passed the 5k packet handling threshold. Oddly, it manages to function using only a 30/10 minute ID interval.
• Way up in Badger, MN the N0AWA-2 gateway is on track to break the 4k packet handling barrier this month. While its primary "customer" is the N0AWA-6 digipeater in Warroad, it also is handling significant amounts of Canadian traffic.
• The Duluth RX-only gateway KB1YTR has handled an impressive 25.5k packets so far this month. Gateways are few and far between in this part of the State, and a lot of that traffic is from Wisconsin -- which seems to have some kind of aversion to gateways in general. 
• The Brainerd W0UJ TX gateway has surpassed 13k packets handled so far this month. Surprisingly, it hasn't handled any messaging at all in November. 
• In the south, Mountain Lake TX gateway MTLAKE is back on-air. This is yet another station with an overly-frequent RF ID rate of four minutes. 
• The relatively-new TX gateway KE0YJJ in Pine Island is still hanging in there. I have high hopes for this station providing reliable coverage of MN-52, and also providing an alternate path to gateway for the big Rochester-area digipeaters.
• Outside of Winona, the W0NE-3 TX gateway has handled an astounding 53.2k packets so far in November. While it provides baseline coverage to SE MN, it's major impact is to gate digipeated packets across at least a third of Wisconsin. It does all of this while only transmitting an RF ID every 30 minutes.

That should do for now. The landscape is constantly changing. Transmitting your ID more frequently, even if you are in a rural area, does not make your station more important or useful. A lot of these packets end up in the metro, finally gated by an infrastructure that is challenged to handle its own local traffic. There's no APRS "authority" to take you to task over inconsiderate behavior. This entire infrastructure relies on individual operators using their best judgment as to how much resources they can justify using.

KD0TLS: The packets all end up in Apple Valley

  The N9MEC gateway in Apple Valley is a somewhat unusual element of the metro APRS infrastructure. While it's ostensibly a TX gateway, it actually seldom transmits. It's direct coverage isn't particularly impressive; anything north of Burnsville is fringe coverage for this gateway. It's more than 10 miles outside of the metro freeway loop -- further than the Medina W0PZT-1 gateway, in fact -- but it handles the bulk of the metro packet traffic (and beyond). 

Let's look at the stats for packets handled so far this month (11/21): 

• W0PZT-1 (Medina): 19.3k 
• W0YC-5 (Minneapolis): 16.8k 
• N0HOY-10 (Arden Hills): 9.9k 
• N0ALE-10 (West St. Paul): 6.3k 
• N9MEC (Apple Valley): 47.4k 

 Personally, I consider any element of the metro infrastructure that handles over 1k packets a month to be "big". It would create a gap in either coverage or gating capacity if such a "big" element were to be lost. And this isn't a competition, it's a network where each element has a niche. 

 I have no idea what makes the Apple Valley gateway such an effective magnet for digipeated packets. Even the IDs of the metro digipeaters seem to mostly end up at the N9MEC gateway. Here are a few examples I pulled off the aprs.fi site this morning (11/20/21). Again, you can click on any of these screenshots to enlarge them. 

K0LAV-8 to N9MEC

K1LEO-10 to N9MEC

N0HOY-10 to N9MEC

W0YC-5 to N9MEC

AE0KW-1 to N9MEC

W0PZT-1 to N9MEC

 Here is a recent path from my own gateway KD0TLS-1, bouncing off two digipeaters (which are also gateways) to end up in Apple Valley:

KD0TLS-1 to N9MEC

 Even the relatively-distant KC0QNA-1 digipeater in Green Isle sees it's ID packet bounced off the metro digipeaters to be gated in Apple Valley: 

KC0QNA-1 to N9MEC

 It seems obvious that, for whatever reason, this RX-only gateway in Apple Valley is a critical hub for the amateur community. It's also gated over 1k ID packets from the Faribault N0QVC-1 gateway/digi this month. That Faribault gateway is a critical hub on it's own, providing baseline coverage for much of southern Minnesota. Having an alternate path to gateway for Faribault is important if we want a robust infrastructure in the State. 

 

 The N9MEC gateway is not without flaws, however. As others have pointed out, it seems to have a problem with delays in gating. This often shows up in tracking, where one or two packets from a mobile station appear to go backwards. What has happened is the N9MEC gateway has held on to the digipeated packet from the mobile station for a significant amount of time, and newer packets have already been gated by the time N9MEC sends that retained packet to the APRS servers. It's a minor annoyance, in my view, but it points to the possibility that N9MEC is operating beyond it's capacity. 

 

 Other elements in the metro infrastructure play different, but equally crucial roles. For example, they might pull in traffic from 'distant' areas of Wisconsin or places like Aitkin, Duluth, Mankato, Hinckley, etc. This connects us to the wider world via RF, allowing a metro operator with an HT to message far-flung stations without the internet. Other elements provide "fill-in" coverage in a congested environment. Yet other elements transmit messages from places like Turkey to RF-based operators here in the metro. 

 

 Even relatively minor gateways like mine still pull in several hundred digipeated packets over the course of a month, from Mankato to Rochester to Duluth. You can explore the world of APRS while making your own contribution to the amateur community's success by adding a gateway to the metro landscape. It won't grant you the glory and status of operating a repeater, but it's a lot easier and cheaper. 

KD0TLS: Local update 11/14/21

 A few things have been stirring on the local scene this week.

• The Apple Valley gateway N9MEC is back, now gating over 19k packets so far this month.
• The Robbinsdale digipeater K0YTH-13 appears to be struggling, only transmitting for a few hours a day (at best).
• W3JF has appeared as a new TX gateway in Brooklyn Park. This edges the RF messaging capacity of the metro further north.

Further afield, the Barnesville digipeater N0CBV-1 seems to be truly dead, and now replaced by N0CBV-2 in Wolverton -- closer to Fargo.

On the Iron Range, several digipeaters have dropped out of service including COOKMN, K9MLD-11, ISABEL, and others. Only the gateway ELYMN remains in an area that once had a robust micro-network. 

The Isle RX-only gateway has now been down for two weeks.

KB0NLY-2 is pretty much the only gateway covering SW MN, and it's dropped off the map lately. Also in the south, the big TX gateway run by NG0E is down.

KD0TLS: web-based APRS services

  APRS.fi is, in my opinion, the primary APRS website today. There are others, such as findu.com or aprsdirect.com that take data from the APRS/CWOP servers and display it on a map. 

Findu.com has an unwieldy method of getting data and accessing the site's functions: creating URLs. It allows sending APRS messages from the website, which is novel, but you need to create a URL with the sender's and receiver's callsign + SSID. For example, if I wanted to send an APRS message from my laptop station (KD0TLS-7) to James' gateway (N0ALE-10), I would create the URL: 

https://www.findu.com/cgi-bin//entermsg.cgi?fromcall=KD0TLS-7&tocall=N0ALE-10

Findu.com web-based APRS messaging

 This is a case where you don't even need an APRS client to message amateur operators around the world. You would simply use a web browser, something found in any OS. But as I said, the method is unwieldy. Still, if you are in the habit of messaging a certain operator regularly, a bookmark can be created to spare you a lot of this trouble. While this messaging uses the -IS (Internet Service), any RF-based amateur operator within range of a TX gateway (e.g. W0PZT-1, W0YC-5, N0ALE-10, KD0TLS-1, etc.) will have that message transmitted over RF to them.

 Aprs.fi also has a service called a "web station" that allows operators to use their web browsers to create an icon on the aprs.fi site. I should emphasize that this is not actually APRS. Your location, callsign, icon, and comment field will not appear on any APRS server, nor will it be broadcast over RF. It will only appear on the aprs.fi website. But, if you find installing and configuring an actual APRS client to be too daunting (or too much work to simply try out APRS), then it's a reasonable substitute. 

 To use this service, you should first create an account on aprs.fi, and I strongly recommend using your callsign as the username, since this will be what the site posts on the map. Creating an account will also allow you to make and save filters for the map views, which is very useful and will be covered in the future. 

 Again, the site has specific instructions on how to upload your position and edit your icon, etc. I won't duplicate them here, other than to say that you right-click on your location and choose "Upload my position". 

 While this isn't real APRS, the aprs.fi site is used by so many amateurs world-wide that it becomes "real enough" for some hams. It's also a compromise method of creating objects -- though far from the real thing. I should also point out that other amateurs won't be able to message you through this service, as you are not actually on the APRS servers. 

 Overall, I see these web-based APRS services as a way to get amateurs exposed to APRS in a painless way. The barriers to real APRS operation are so low currently, that anyone who is even mildly interested in these services should seriously consider getting an app or client to take part in the actual APRS service. Putting APRSDroid on your smart-phone or installing APRSIS32 on your Windows PC is relatively simple, and either will allow an amateur to participate in APRS without a radio or antenna.

KD0TLS: Introduction to objects

  I've mentioned objects in a few times in other posts without explaining them. You have to start somewhere, after all. Objects are remotely-created icons, meaning that they don't originate from the icon itself. They can exist on either RF or -IS, or both. 

 Common examples that you'll see on aprs.fi are:

• Repeaters, along with frequency, offset, PL tone or CC
• Rest areas and medical aid stations in marathons
• severe storm cells

Examples of repeater objects in northern MN

 Some other potential EmComm-related uses of APRS objects could be relief stations, impassable roads, EOCs, volunteer sand-bagging locations, tornadoes, or field stations for search-and-rescue operations. 

 Other more mundane uses could be Hams In The Park locations, club meeting locations, Field Day stations, Hamfests, etc. In all of these cases, information can be attached (e.g. times, club callsigns, talk-in repeaters, etc.) to the object using COMMENT or STATUS fields when the object is created. And they can be created in advance of the event to inform the amateur community better.

 Objects save an operator from setting up a station (whether RF or -IS based) at that particular spot. They are usually renewed on a regular basis to keep them visible. If a repeater object is re-transmitted every two hours, it will not be visible at times to people who have their aprs.fi map set for a one-hour time period. RF-based objects usually need to be gated (i.e. the packet needs to be received by a gateway), though it's certainly possible to set up an object using the BEACON field and have it only appear to RF-based stations. Obviously, some consideration is called for here. You don't need to broadcast a repeater's location/existence every ten minutes -- yet at least one prominent local station does exactly that. 

 Repeater objects can be very useful to amateur operator travelers, informing them of local repeaters or repeaters they will encounter further down the road.

 The only way I know of to create an object is by using APRSIS32 or UI-View, but that's just a limitation of my experience. I'm not familiar with the more obscure capabilities of (for example) Linux-based APRS clients. It's entirely possible that Xastir or YAAC can create objects. And, as I've previously mentioned, an Android version of APRSIS32 is in beta stage right now. Once that's ready for prime time, most anyone with an Android smart-phone or tablet could create objects easily.

 KC0CAP has operated a gateway near Litchfield for several months that was used to maintain several repeater objects in the area. Unfortunately, it's been down for well over a week and seems to have been replaced by an iOS-based station incapable of generating objects. If you'd like to try your hand at creating objects, those repeaters might be a useful starting point. 

 It might also be good publicity for a club project to create an object for their repeater, possibly adding the URL of the club's website. Knowing how to do this is a useful skill for marathons, parades, and other public service events. 

 I (or the other contributors) will undoubtedly cover the "how-to" details of object creation in the future. This post is just intended to be an introduction to the topic, making the reader aware of the potential for this mostly-overlooked APRS packet tool. But there are enough local operators already familiar with APRSIS32 or UI-View for someone to experiment with objects on their own. Please feel free to write up your experiences and send them to kd0tls@amsat.org -- or any of the other contributors.

KD0TLS: When packets collide...

  APRS, and packet operation in general, suffers from a phenomenon called "packet collisions" on RF. Essentially, this is a situation in which two stations transmit simultaneously  on the same frequency. Due to the FM "capture effect", only one will dominate, but that "dominant" packet is very likely to be rendered unreadable. Nearly all TNCs, modems, and trackers have some means of avoiding this by checking the frequency for activity before transmitting. In some cases, this is known as DCD (Digital Carrier Detection). If you are operating on RF with the squelch turned off (as is usually the case), you should take the time to ensure that this function is engaged. 

 While this is generally sufficient, it only works for stations that your receiver can actually hear within simplex range. Given our robust metro infrastructure, it's entirely possible for two stations on opposite sides of the metro to fail to hear the other. And it's also very possible for large gateways, which hear stations over a wide area, to pick up two stations transmitting at once with each outside of simplex range of the other. And it's not uncommon for big digipeaters, which can transmit across half the State, to fail to hear traffic from smaller stations in that coverage area. This is, in fact, one of the main purposes of digipeaters -- to extend coverage between stations that otherwise would not be able to maintain simplex communication. 

 This phenomenon is why "mega-stations", such as W0PZT-1 and W0YC-5, can't bear the load of covering the metro on their own. Below is a map of the current coverage of the Medina gateway/digipeater W0PZT-1. You can click on it to enlarge the image, if you wish. 

Direct coverage of W0PZT-1 as of 11/13/21

 As you can see, this single gateway hears stations over virtually all of the metro. You may easily conclude that W0PZT-1 makes all of the other metro gateways, and even metro digipeaters, redundant. This, however, would be false. 

 Both Forest Lake and Bloomington are in the direct reception of W0PZT-1, and it's not uncommon for mobile stations to run low power (like 5W). These mobile stations can rely on the digipeater network to make their operation viable. But in my experience, gateways like W0PZT-1 are quite capable of hearing these low-power stations on their own in these areas. So, what happens when two stations, each out of simplex range of the other, transmit their packets? Neither can hear the other, so they both believe the frequency is clear. But W0PZT-1 can hear both. A packet collision is what happens. Now consider all of the digipeaters in that coverage area IDing and re-broadcasting distant traffic. Each of these stations is trying to be considerate and only transmitting when the (local) frequency is clear, but they can't hear what they can't hear. 

 To a certain extent, these gateways attempt to hold on to packets that they can't directly gate, and instead digipeat them. But that only goes for packets that aren't rendered unreadable from packet collisions. The end result is that these "mega-stations" drop packets. 

 In a practical sense, these "mega-stations" (e.g. W0PZT-1 and W0YC-5) only provide baseline coverage for the metro. It's up to smaller gateways and digipeaters to pick up the traffic that the "mega-stations" miss due to their wide coverage areas. That isn't a flaw; it's the nature of a network. No single element does it all. Instead, they work together to meet the objective of providing reliable, redundant coverage to amateur operators.

 An operator may set up a modest RX-only gateway in their home to provide a service to the local amateur community, but they become disappointed when they look at their station's statistics and see that they "only" gated 20 directly-received packets over the course of a month. That's not a failure on the part of the gateway operator; it's how the network functions. That's 20 packets that otherwise would have been dropped. And that modest gateway is very probably picking up digipeated packets from far outside the metro that our overwhelmed "mega-stations" missed. 

 As one moves outside of the RF-congested metro, packet collision obviously becomes less of a concern. But it can still happen in the case of wide-coverage digipeaters, such as KD0JOU-2 near Litchfield. That modest RX-only gateway suddenly becomes the sole source of direct coverage for the local area, providing message services and propagation data to the wider amateur community. Because it's a collective effort.

KA0RXU APRS DISTANCE

 Hello, i just wanted to ad to my other story a little, i am amazed at the distance  you can

travel.  with a 3 foot antenna i have  been communicating with another ham radio operator in

north dakota.  that is one of things fascinating about aprs is  how far your signal can travel.

                                                 Have a great day

                                                 Robert  KA0RXU