KD0TLS: MN APRS update 7/23/23

  It's been a month since I did a state-wide update, and there are some promising developments here and there. 

South 

 A new TX gateway has appeared east of Rochester. KE0WWG-10 is about 12 miles from Rochester, and well within range of the two big digipeaters in the area -- WB0MPE-7 and W0MXW-3. Its direct coverage remains to be seen, but I'm hopeful it will gate mobile stations on nearby I-90. The primary role will be to gate digipeated traffic from those two big stations, though. While W0STV-10 has served the same role for over a year, there seems to be some issue with its RX. I've certainly seen my (and others') packets rejected by W0STV-10 frequently as "unsupported packet format". The very same packet that bounces off digipeaters to be gated in St. Cloud or Knife River will often show up as "unsupported" by W0STV-10. So, a second gateway in the Rochester area should be a benefit to the state infrastructure. 

 KD0TGF-1, the TX gateway north of Ellendale, is showing some signs of life. More like "stirrings", actually, but we've seen this before. I've learned not to get excited at these indications. W0AZR-2, the nearby digipeater, has been deaf for two weeks now. This duo has become perpetually unreliable. 

 Southwest 

 The big TX gateway MTLAKE (in Mountain Lake) has returned to service. It's the only TX gateway in the area, so it's a loss when it goes down. However, a new RX-only gateway has appeared just across the border in South Dakota, and it seems capable of handling some of the digipeater traffic in the area. KE0WPC-10 is located about 16 miles north of Brookings, SD. Both the Chandler, MN (KD0MC-2) and Tyler, MN (W0DRK-2) digipeaters have strong TX, and can reach distant gateways if need be. But it would be quite welcome to see the Windom (KD0BXJ-3) and Tyler (KB0NLY-2) gateways return to service to cover the area when MTLAKE takes a break. 

 The Mankato digipeater N0PBA-1 is showing improved coverage to its west this month, and that's also bolstering the southwest. I doubt anything has changed with the station itself, and it may just be a sign of increased APRS activity in the area. 

N0PBA-1 western coverage

 Northwest 

 The AE5E-5 digipeater near Thief River Falls is showing some signs of life. It's been deaf for months, though it continues to transmit an RF beacon. It used to be a quite reliable supplement to the AE5E-7 RX-only gateway in Thief River Falls -- the only gateway in that part of the state now that the Karlstad gateway has long since faded away. The W0RFP-1 TX gateway in Bemidji continues its solid performance, and links the area with distant digipeaters far to its east.

 North 

 The KE0OPK-13 TX gateway near Cloquet has been deaf for well over a week now. It maintains an -IS connection, but gates nothing and transmits no RF ID. This was one of the paths to gateway for the big Askov digipeater (AD0MI-1). 

 The Duluth RX-only gateway KB1YTR-1 has put up solid numbers once again. For a while, it looked as if the new Knife River TX gateway (KNFRVR) would take the majority of its traffic. Still, KNFRVR has handled a stunning 55.3k packets so far this month compared to KB1YTR-1's 33.3k load. Both seem to be working hand-in-hand in this digipeater-heavy part of the state, and one with a great deal of digipeated traffic from WI. 

 The new N0MR-11 digipeater near Wales, MN continues to be a critical player in the north. Not only does it link the Lutsen, Maple Hill, and Silica digipeaters with the KNFRVR gateway, it provides impressive coverage of northern WI.

 While the Lutsen K9MLD-10 digi struggles with poor RX, the Maple Hill MAPLEH digipeater to its north is showing great coverage all along the North Shore down to Silver Bay. And the remote Gunflint Trail KD0BDN-10 TX gateway is gating a lot of that traffic: 8.7k packets handled so far this month. 

 The digipeater in Cook, COOKMN, continues with its irregular operation. On the other hand, the Virginia digipeater K9MLD-11 has become much more stable recently, and is linking with the Silica digi more frequently. 

 Speaking of that digipeater in Silica, the WB0MPE-15 digipeater has been very reliable and shown promising coverage since its recent return to service. It has no trouble with its strong TX, reaching Duluth, Brainerd, Bemidji, Knife River, and Askov easily. It's pairing with the Wales digi in particular shows promise in covering the Iron Range -- rather than just the North Shore. It's covering areas like Floodwood, which have long gone without APRS service. The addition of a TX gateway in Grand Rapids would leverage WB0MPE-15 nicely, and be a big step forward for the area. 

 Metro 

 While Elk River isn't, strictly speaking, part of the metro it's worth mentioning the new digipeater there. N0OQA was formerly only a weather station; now it's added digipeater functionality. This is another of those Kenwood D710 digipeaters we are seeing crop up, and they seem to be very reliable. With the Big Lake (BGLKWX) digipeater down for a month now, N0OQA is filling in a big gap. It easily reaches the St. Cloud and W0YC-5 gateways, and is providing coverage along Hwy 169 that the Big Lake station never covered. If we can ever get solid coverage in Anoka County, I expect this new digi will prove even more valuable. 

• The digipeater formerly known as AE0KW-1 has switched its callsign to N0RUA-1, and continues its role supplementing coverage in the western metro suburbs. 

• N0KGK-3, the Burnsville digipeater, has been off-air entirely for two weeks now. This is a disappointment, because we need additional coverage in those south metro fringes. 

• W0MHR-2, the TX gateway in Centerville (and the only gateway in Anoka County), has put up some staggering traffic numbers this month: 36.7k packets handled so far. Not sure what's causing this, but other metro gateways are also seeing sharply increased digipeated traffic handled since W0PZT-1 switched to digipeater-only operation recently. Not on the scale that W0MHR-2 is seeing, however. 

• The mystery digipeater N0UK-9 continues to transmit an RF ID every two minutes, though it's been deaf for 11 days now. It's difficult to see what value this "digipeater" adds to the local infrastructure, since it's only two miles from the big W0YC-5 gateway/digi, and only four miles from the big K0YTH-13 digipeater. The two stations it's handled this month are both less than two miles away from it, so it's extremely local. 

• The Medina digipeater, W0PZT-1, is putting up substantially less impressive numbers since it went digipeater-only. Where it once handled 20k packets/month, it now is at 10.8k -- still a large amount, though. I once again question why we need a massive "dumb" (non-networked) digipeater in the metro. We have several fine digipeaters in the metro already (probably too many), and no need (in my opinion) to re-transmit metro traffic across a third of the state. 

• KG0E has set up KG0E-Y, a YSF gateway for Fusion traffic on UHF. We are seeing more of these DGPS (digital APRS) gateways appearing, on both D-Star and DMR. I'm unsure of how they work, and what demand there is for them. I've long believed that there should be some UHF APRS capacity for metro areas to off-load some of the traffic from the VHF simplex 144.39 frequency. Once it's gated to the APRS-IS servers, it doesn't matter which band the packets came from. If some reader has more information on these gateways, I'd welcome a post on the topic. 

KD0TLS: MPAD APRS service

  MPAD (Multi Purpose APRS Daemon) has been around for a couple of years, and is an interesting Python-based APRS service that works over APRS messaging. 

 Like other such services (WXBOT, WXYO, W0CHP) you can get weather info and forecasts for your location by sending a message. MPAD also allows you to request weather info for other locations, however. And, like WA1GOV-10, MPAD will provide you with satellite pass information. Unlike WA1GOV-10, MPAD can provide you with the next few passes (up to five), and provide you with the frequency that satellite operates on. 

 MPAD can also tell you things about the local area. You can find the nearest repeater, even specifying band (70cm, 2m) and mode (e.g. c4fm, dmr, dstar, etc.). Sending "osm fuel" to MPAD will get you the location, distance, and bearing to the nearest gas station from your current location. I haven't been able to figure out the proper word to use to find the nearest restaurant, however. Though "osm pub" works to find the nearest bar, I found. 

 The service includes the ability to send a page to a DAPNET user, as well. I've been seeing a few DAPNET nodes around the state on the aprs.fi map, so it's good to see that there's some kind of bridge to that service using APRS. 

 If you're wondering when the moon will rise, sending "riseset" to MPAD will give you the rise and set times for both the sun and moon. You can even get that information days in advance (e.g. "riseset Thursday"). Times are in UTC, however. Subtract 5 hours for DST, 6 hours for CST.

 Another useful tool is finding out how far you are from another APRS station, and which direction it is. This works on APRS objects, too. Sending "whereis HAMSPARK" will tell you how far away you are, the lat/long, and the bearing of the Hams In The Park event location, for example. In other cases, you might need to know how far you are from a particular digipeater or gateway. You would just need to include the callsign+SSID (e.g. N0HOY-10) after "whereis", in that case. In a field setting, you might need that information to aim a Yagi properly, and MPAD will provide the proper bearing from your location. 

 There's even a whimsical Magic 8 Ball function. Sending "m8b" to MPAD will provide you with a reply (e.g. Yes - definitely). You can't actually send a question; you just get a reply. 

 What you need 

 In order to access MPAD, you need to be able to send and receive APRS messages. It's much the same as with APRSThursday. 

 This means that you need a messaging-capable APRS station. Things like trackers aren't messaging-capable. If you are using apps like APRSDroid and aprs.fi, you're good to go. APRS client software like UI-View, APRSIS32, YAAC, Xastir, etc. are all messaging-capable. If you're running DireWolf as a stand-alone station (in other words, without an additional client), then you can't send or receive APRS messages. The SharkRF OpenSpot has -IS messaging capability, if you use the web interface. Radios with internal TNCs (native APRS), such as the Yaesu FTM-400 or Kenwood D710, have messaging capability -- although entering text might be a pain. Fortunately, the MPAD commands are short. 

 If you are operating an -IS (Internet Service) station, you are all set. Those operating on RF will need to be able to reach a TX gateway, either directly or through a digipeater, to receive a reply. While there are several TX gateways in the metro, you may struggle to reach one in rural areas. For example, the W0UJ gateway in Brainerd in RX-only. There are TX gateways in Faribault, Winona, St. Cloud, Paynesville, Bemidji, Knife River, and Cloquet. If you're operating in a more remote location, you may need to adjust your N-path to allow for more "hops" to get a reply.

 Digipeaters have their purpose, but it's TX gateways that really open the full potential of APRS. Fortunately, big digipeaters like AD0MI-1 in Askov can access multiple TX gateways. 

 Using MPAD 

 Exactly the same as other APRS services, you access MPAD by sending an APRS message to MPAD, rather than to a callsign/SSID. The text of that message is the request for the desired information. If you have the option, you should use the "ack" function in your message. A lot of clients just automatically include an acknowledgement ("ack") request in all messages. 

 A very helpful list of examples (and the expected result) of MPAD commands can be found here. There are a few other services MPAD provides that I haven't mentioned, and you can find them at that link. The abbreviations used in the replies are also explained there, and familiarizing yourself with those examples will probably be useful. 

 Feel free to experiment with the parameters. That's how I figured out that "fuel" is the magic word to find gas stations. If you find something cool, please share it in the comments.

 It should be obvious, but I'll state it: the info that MPAD provides is only as accurate as the public data available. Repeaters often go off-air, or change without updating a database. Businesses may exist, but be closed. The ISS repeater might be temporarily shut down for EVAs. A satellite pass may be technically "visible", but too low to work from your location.

 More information 

 The GitHub page for MPAD is here. You can find information there about installing your own instance of MPAD, if you are digitally-inclined. From the page, it looks as if it can run on newer Raspberry Pi (RPi) boards. 

 You don't need to install MPAD if you just want to use it. Having MPAD running on a local TX gateway would likely speed up response time and provide redundancy, however.