KD0TLS: Christmas Eve update 2021

  Is it a Christmas miracle? Probably not, but the Hopkins digipeater AE0KW-1 and the Welch (south-east of Hastings) KC0FKY-2 TX gateway/digi are both back on-air. Also, the RX-only gateway in Shakopee, AE0RF-10, is back in action. 

It might be nice, in the spirit of the season, to take a closer look at these "unsung heroes" of the local APRS community.

 I've mentioned AE0KW-1 before: a true "fill-in" digi in Hopkins that easily reaches the big local gateways and digipeaters. It transmits its ID at a very considerate rate using Mic-E compression. It has only about 180 packets under its belt this month, but it's gated packets from over 20 miles away. Obviously it has decent RX, but it faces stiff competition from a (welcome) plethora of other gateways in the metro.

AE0KW-1 coverage 12/21

While outside of the metro freeway loop, AE0RF-10 is an RX-only gateway with only a small direct coverage radius. But it leverages its proximity to the south-west metro's KF0ZH digipeater to reliably gate several hundred digipeated packets each month. Having an RX-only gateway near a digipeater is always a huge benefit to the community. The gateway relies on the superior RX of the digipeater, while providing a reliable path to gateway for everything the digi hears.

AE0RF-10 digipeated coverage 12/21

 While being located outside of the metro altogether, KC0FXY-2 is a conduit for traffic from its local area (and eastern WI, southern MN) to the metro. It has proven its ability to pick up packets from some of the metro gateways, and its TX capability allows it to handle messages from distant areas entirely over RF. Given Wisconsin's penchant for digipeaters, KC0FXY-2 provides an alternate path to gateway for several cross-border digis. The Faribault gateway N0QVC-1 provides only baseline coverage in this part of the state, so KC0FXY-2 adds reliability and redundancy to our APRS infrastructure.

KC0FXY-2 direct coverage 12/21

What these "unsung heroes" also represent are members of the amateur community with proven experience in APRS. They have hands-on expertise that elevates the knowledge pool of their respective local areas.

KD0TLS: metro APRS update 12/19/21

 While there has been a little "churn" in the infrastructure across Minnesota since my last update, things have largely returned to their previous state. 

A brief look outside the metro:

• The K0KGW-10 RX-only gateway in Isle has gone down again.
• In Knife River, the NARC digipeater is operating normally again.
• The KC0FXY-2 TX gateway in Welch has been down for two weeks.
• W0AZR-2, the digipeater in Ellendale, has gone deaf for over three weeks. 
• The TX-gateway in Rochester, N0HZN, is back on-air.

As far as the metro goes, much is unchanged. 

• K0YTH-13, the long-standing digipeater in Robbinsdale, continues its near-death struggle. It only operates for part of the hour around 3 AM, and remains down the rest of the time. 
• In Hopkins, the AE0KW-1 fill-in digipeater has gone down for a short time. Hopefully, this is just a temporary outage.
• The new gateway/digi in Brooklyn Park, W3JF, seems to have become a digipeater only. It's established solid coverage from Anoka to Golden Valley. 
• The TX gateway in Minnetonka, K0GV-10, has expanded its western coverage compared to previous months. It now regularly reaches places like Orono, Mound, and even Waconia.
• N0ALE-10, operating from West St. Paul, has expanded it's northern coverage, and has gated an outstanding 11.9k packets already this month. 
• In Woodbury, the K0JDD-1 TX gateway has seen its fringe coverage move further east into Minneapolis proper. It's also broken the 1k packet-handling mark.
• W0YC-5, the core gateway for the metro operating from the University of Minnesota campus, has seen a slight decline in its western baseline coverage. It no longer picks up the big KD0JOU-2 digipeater near Litchfield, for example. It still has gated a stellar 11.4k packets so far in December, though. 

 In Medina, the HCEM's big digipeater/gateway W0PZT-1 continues to display my email address in its STATUS field for some reason. It seems to have slightly reduced its transmission rate of DMR repeater objects to every fifteen minutes (down from ten minutes). It's own ID has also been dialed back to a 14/2 minute rate. I applaud these measures.

 In my opinion, a station as big as W0PZT-1 -- and one run by communications professionals -- should set a good example for the amateur community in terms of its own operating standards. It's very hard to convince smaller elements of the metro infrastructure to adhere to a responsible use of the simplex frequency when they can simply point to a big station's behavior as a justification to continue their own practice. 

 In contrast, the KC0LDH-1 digipeater near Becker has actually increased its ID rate from every two minutes to every minute. This station easily reaches the metro, which has its own congestion issues. Is there anyone in the amateur community that wonders if a fixed digipeater near Becker has changed its location in the last 60 seconds? I'd be highly skeptical of that. Nearly all mobile APRS operators are more considerate of their use of the limited simplex frequency than this digipeater. The purpose of an ID is to identify the station, show that it's on-air, and make its location known. No one is confused about this digipeater on any of those points. 

 KC0LDH-1 is providing service in an area that barely maintains baseline coverage. This digipeater has already handled 1.3K packets this month. It's existence is valuable to the expansion of the APRS network. Why undermine that with poor operating practices? The operator should simply reduce the ID rate to ten minutes and take their place as a responsible participant in something that we all enjoy.

KD0TLS: General-target APRS messaging

  APRS allows an operator to send "broadcast" messages over RF or the -IS (Internet Service). In some parts of the world, such as Australia, these general messages are sent over the internet to be re-transmitted by amateur radio operators, and non-hams "listen" to these messages in more remote areas (e.g. Western Australia). These messages run from agricultural (frost, sheep, crop disease) to marine warnings (high winds, storms). Strictly speaking, this would be a more appropriate use of the "bulletin" or "announcement" functions of APRS. Amateurs in Spain also frequently use APRS bulletins to send weather warnings over wide areas.

 You can see all of the current bulletins and announcements on this aprs.fi page. You will also find some APRS services listed there, such as satellite pass predictions or weather forecasts for your location. 

 When I learned about the ways amateurs in other countries use APRS general messaging, I wanted to try it out here. My primary interest was in how these messages would be propagated. How far could these messages reach? Who would see them? Would they be gated, or just digipeated? The answers surprised me, and I slowly discovered that a lot of amateurs weren't familiar with these tools. I had to explore on my own, and some aspects are still a mystery to me. 

 There are four ways to send these messages, depending on your purpose and the nature of your message. All four can be used by any station that can send APRS messages, though bulletins would require some kind of specialized capability to keep re-transmitting them on a regular schedule. 

 None of these four types of messages will allow an "ack" -- an acknowledgement of reception. It should be clear that this would clog the network with dozens (or hundreds) of "ack" messages. However, without an "ack", gateways have no idea if the message was ever received. Any of these messages can, therefore, be re-sent three or four times by a gateway that believes it has failed to reach the recipient in its previous transmissions. In the Big Picture, this is a feature rather than a bug. APRS messaging in general is designed to be robust, rather than efficient. At some point, I'll go into some depth on how messages are handled on the network. For the moment, though, my point is that seeing a general-target APRS message transmitted multiple times is not a case of some operator sending multiple copies of the same message.

 I should probably note one very important limitation of these messages: they are only available to APRS stations that are "messaging-capable". This excludes a lot of trackers, most digipeaters, and even some gateways. You can create a filter on aprs.fi to show only stations that are messaging-capable. Some software, such as APRSIS32, has native filtering to show "messageable" stations as well.

Here is a screenshot of the current metro message-capable world:

metro-area message-capable stations 12/12

 Also note that some of these message-capable stations are unattended and will never see a message, such as W0PZT-1 or W0YC-5. Digipeaters and gateways that aren't messaging-capable will still handle messages; either gating them, re-transmitting them to RF-based operators, or simply digipeating them as "normal" packets would be handled. You just can't send messages directed to a specific station that isn't "messaging-capable". 

 I'm still not clear as to how the -IS propagates these general-target messages. The RF side is pretty straightforward: the message is received by anyone within simplex range of the station, and within the range of any digipeaters passing that message on. I suspect that the range of an internet-based message is determined by the filter radius of the receiving station. Any -IS station must set up a radius in which packets received will be shown. Otherwise, you would see all of the traffic from the entire planet at once, like trying to drink out of a firehose. But it also seems possible to me that some gateways could transmit an -IS general-target message over RF to reach RF-based operators.

Let's look at the four ways to send general-target messages:

ALL: 

 Sending a message to "ALL" (rather than typing in a specific callsign and SSID) sends a message to all amateur radio operators currently on APRS -- but only those with messaging capability, of course. Messages sent to ALL will be gated and digipeated just like any other traffic. Gated messages will be stored on aprs.fi for two weeks. In a way, it's like calling CQ. In another way, it could easily be abused. I've avoided the use of "ALL" in my explorations, though I can see obvious uses for EmComm-related purposes. For example, imagine sending a message noting an HF frequency for a disaster-related net, or even a SkyWarn activation.

QST: 

  Much like "ALL", this sends a message to all amateur radio operators that are capable of receiving messages. The difference is that "QST" has a specific meaning in amateur radio: information of interest to all amateur stations. I've used "QST" to send HF propagation reports at irregular intervals for a few months now, and I've closely watched how these messages are handled by the network. Frankly, I had expected that at least one curmudgeon would get upset by my use of this tool, but no one has expressed their aggravation to me yet. Some find it to be (somewhat) interesting information, while others are curious how this tool works. I've found that most APRS operators are kind of hazy on the issue of APRS messaging, and receiving an APRS message is intriguing -- even if it is just a report on the current MUF. Again, a QST is sent by an APRS client substituting QST for the recipient callsign/SSID. All gated QST messages are stored on aprs.fi for two weeks. 

BULLETIN: 

 Bulletins are slightly more complicated. Some APRS clients have a specific bulletin capability, repeating a bulletin at some set interval. There are also specific bulletin "groups" to target bulletins at only a specific group of operators. Examples would be "PROP" (propagation), "LOCAL" (local-interest only), "MUF" (current MUF), or "SYDWX" (Sydney weather). You can send a LOCAL bulletin, for example, by designating the recipient as "BLN0LOCAL". 

 Bulletins are intended to be repeated until they are no longer relevant, such as a tornado warning. But they can certainly be "one-time" affairs. This is the primary distinction between a "bulletin" and an "announcement" -- in other words, not much of a distinction at all. 

 While bulletins can be filtered by the recipient, they rarely are. A bulletin sent to "BLN0LOCAL" will generally go to the same stations as one sent to "BLN0" or "BLN1" -- in other words, all stations capable of receiving messages.

 There are some fairly outdated rules for bulletins, which are widely ignored today. For example, "BLN0" -- BLN with a zero at the end -- is supposed to be for one-time messages. Some clients, such as the aprs.fi app, only allow "BLN0" messages to be sent.

 Bulletins can be multi-line. There might a be reason to send more information than can be expressed in a single line of text. You would then increment each line, like BLN1, BLN2, BLN3, etc. Here's an example:

 Again, if you are sending a single-line bulletin, there's no distinction between using "BLN0" compared to "BLN4".

 A typical bulletin can be a severe weather warning, road closures, propagation reports, etc. Mostly, though, it's more mundane. Is your Field Day event, Hamfest, club meeting, new repeater, new gateway, etc. more properly a "bulletin" or an "announcement"? Who cares?

ANNOUNCEMENT: 

 Much like a bulletin, an announcement goes to all hams capable of receiving APRS messages. The difference is that an announcement is sent to BLN plus a letter, rather than a number in the case of bulletins. Sending an APRS message to "BLNA", instead of a callsign/SSID, will send an announcement to all amateur operators capable of receiving APRS messages. Multi-line announcements are incremented like bulletins: BLNA, BLNB, BLNC, etc. As with bulletins, you can send a single-line announcement to "BLNA" just as easily as to "BLNC". Announcements, like bulletins, are stored on aprs.fi for only 24 hours.

 W0ILO sends a multi-line announcement as follows:

Multi-line announcement

 Previously, I've sent an announcement using "BLNA" to advertise this blog. A few people far outside the local area have seen the announcement on aprs.fi and checked it out. I justify this by noting that the blog is specifically aimed at APRS operation. Still, I've stopped sending these announcements as it may be considered as something resembling spam. I'm unsure who would make the determination that an announcement for an APRS blog is acceptable, while an announcement for a car wash is not. I really don't care to find out. 

How far can you reach? 

 The answer depends on your N-path. If you are in the metro, you have several wide-coverage digipeaters available to you. A WIDE2-2 path will offer two hops. This means that, for example,  W0PZT-1 can re-transmit your message to another digipeater, who will re-transmit it again. W0PZT-1 has a large coverage area, and several smaller "dumb" digipeaters will re-transmit it as a matter of course. Reaching Aitkin, Faribault, Litchfield, Mankato, or eastern Wisconsin is easy on a single hop. Digipeaters in those areas will re-transmit your message to cover places like Willmar, Winona, Worthington, Duluth, Brainerd, etc. 

Two hops is a lot when you consider our local infrastructure. And, if you add a WIDE1-1, you can get into Canada, down into Iowa, or over to Madison, WI. This is probably further than you need, and a WIDE2-1 or even WIDE1-1 path will cover the metro and the surrounding areas. 

 My experience has been that a WIDE2-2 path will get you a response from an area including Little Falls, Willmar, Rochester, and Rice Lake in Wisconsin. While I haven't tried it, using a satellite digipeater can easily cover 700 miles.

 In practical terms, this means that even an HT within range of a big digipeater can reach outside the metro on one hop. And don't forget that a a lot of those smaller digipeaters (NOGEF-15, KE0CRR-10, K0KGK, and KC9NVV-3) will also be re-transmitting your message in their local areas.

 

 In summary, I think that having access to these general-target messages is something that's at least potentially beneficial to most ham radio operators. This could be something as simple as running APRSDroid on your smart-phone, and finding that someone has sent a message. Nearly all messaging-capable clients will inform you in some way that you have received a message, even if you aren't glued to the screen every moment. HTs and mobiles that have native APRS capability will also generate a tone when this kind of message comes in, and save it until the user clears it. 

 Obviously, there's potential for annoyance as well. You may very well believe that sending "Let's go Brandon" every day is cute, clever, and of interest to amateur operators everywhere. You may find out that it is not. You may make a special point of daring someone to stop you. Alternatively, you might send inane greetings like "Hello world" on a regular basis. In reality, all that you are doing is deprecating the value of APRS messaging in general. 

N0ALE: Fine Tuning My Gateway

     Recently I've discovered that I can run my gateway with the radio's squelch at zero.  Microsat devices have a setting called Analog/Digital Detect.  When my set up the gateway initially I had programmed this setting for Analog Detect and with squelch engaged.  Basically what happens is it listens for a signal to open the squelch and for it to contain AX.25 packet traffic.  I've been trying to get the signal from the radio to the gateway to be able to include weak and distant stations to be decoded.  Part of this is because I'm using a radio with separate speaker/microphone connections (Yaesu FT-2980R) increasing the signal entails turning up the speaker volume.  However the gateway also has the ability to amplify signals inside of the unit itself, but I tend to play with signal strength solely at the radio side. 

    I initially tried turning down the squelch to help facilitate the above.  However doing so in Analog Detect mode tended to wreak havoc with the gateway's beacon time and the ability to deliver message ACK packets to local stations given it's a bidirectional system.  After much experimenting I found that if I selected Digital Detect, it would only wait for AX.25 packet traffic ignoring everything else including white noise from running the radio un-squelched.  This in concert with turning up the radio output level just a tad has had a profound impact on detection range and decoding abilities of the gateway.  I plan on tracking the gateway metrics over time to monitor the long term impacts on overall packet processing.  Of course I also acknowledge that minor adjustments may be needed in the future as the local APRS network structure changes.

KD0TLS: The KD0TLS-1 gateway

 I've been having some troubles with my gateway recently. Tracking down the cause is not so easy; there are a lot of "variables". There's the computer itself, the software and OS on it, the internet connection, the radio, the TNC, the cabling and coax, and the antenna. Any one of these things can render my beloved gateway useless. 

 And I do love my gateway. It's opened up the world of APRS to me, and allowed me to participate in that world in a minor way. Since I started running a gateway, I've gained a much deeper appreciation of the complex, robust (and at times, mysterious) system that all amateurs potentially have at their fingertips. So, when that gateway goes down, I feel a responsibility to deal with whatever issue has created that situation. That problem, I eventually determined, was the Mobilinkd TNC2 -- exacerbated by a Windows 10 update.

 

Behold KD0TLS-1!

 First, I'll describe the station. Above, you see a Leixen VV-898 dual-band transceiver, some custom cabling to connect that transceiver to a Mobilinkd TNC, and a Mobilinkd TNC modem with a USB cable running to a phone charger in the wall behind the table. 

  Did I select the Leixen radio because it was the best for this purpose? Nah. I picked it because I wasn't using it for anything else. It has a very sensitive receiver (but marginal RX filtering), but only about 8W of TX power. This allowed me to use a 12v switching power supply that came with an air mattress I discarded years ago, rather than using a dedicated linear PSU. Generally, any monoband receiver will have a stronger front-end than a dual-band. But I didn't have a spare monoband rig sitting around, so I used the VV-898. Using this radio meant that I had to go to hammadeparts.com and order a special cable. I found a decent variety here, and at least one of these choices fit the Mobilinkd TNC. If you look around that site, you'll find suitable cabling to connect most radios to most TNCs. If you don't find it, they can make it for you. So you can use pretty much any mobile/base transceiver for your APRS station. 

 In that same picture above, you will see a Mobilinkd TNC3. This is what I replaced my defective Mobilinkd TNC2 with. It costs twice as much as the (now discontinued) TNC2, but it really is twice as good. One particularly nice feature is that it has an LED that blinks green when it receives a packet. Beyond that, it has buffered inputs and outputs to ensure that the audio levels are consistent within the device itself. 

 Next, let's look at the "computer" end of things. 

The tablet that serves as "the brains" of the station 

 This is a Windows 10 tablet that I bought on Amazon for $250. It replaced the Win7 tablet that KE0NA (Dave) graciously gave me, but the hard drive filled up. The new tablet has Bluetooth (like they all do), but no GPS. You don't really need GPS for a gateway because APRSIS32 allows you to designate a location on the map for your station. The tablet connects to the Mobilinkd TNC over Bluetooth, and installing APRSIS32 on the tablet was simple. I use my DSL connection for wi-fi to connect to the internet, allowing me to see -IS traffic and gate received RF packets to the -IS. 

 I should note that APRSIS32 will run on XP, Win7, 2000, etc. If you have an old laptop/tablet with an obsolete OS, this is a great way to put it to use. Just avoid web browsing and email, and keep it behind a router (obviously). If you don't particularly care about running a gateway, any old Android phone/tablet running APRSDroid will connect to the Mobilinkd TNC over Bluetooth. One of the nice improvements with the TNC3 is that it's compatible with Apple devices, too. And you can use any Linux software (DireWolf, YAAC, etc.) with the TNC3 -- just do a bind on Channel 6 for the Bluetooth connection. 

 If you look closely at the first picture, you'll see coax running through the wall behind the station. I used a one foot length of LMR-400 with SO-239 (female) connectors to run through the wall to the balcony. I bought this from onlinecables.com some time ago. From there, I use a magnetic PL-259 mount on the steel cap of the balcony wall to hold a Comet SBB2 whip. Using an outdoor antenna makes the most of my marginal 8W TX, and allows me to receive more distant traffic from digipeaters outside the freeway loop.  

 As you can guess, this is far from a power-house APRS node. But it's all that is needed inside the freeway loop, and can serve quite nicely in rural/exurban cases if you have a digipeater within 10 miles. Replacing the Leixen with a 25W radio (or even a 50W mobile) is quite simple. I've just decided that I don't want a "real" PSU for this station.

 So... back to the gateway going down.

 I had noticed that the gateway stopped receiving RF traffic. For a while, it gated a few messages, but no other packets. It transmitted well, allowing me to send my usual QST HF propagation messages, and continued to transmit the usual ID and STATUS packets. But its had stopped gating digipeated packets, and stations that were even within a mile of the gateway. Then, it stopped transmitting ID, STATUS, and QST messages.

 What had changed? Well, the building (fiber) wi-fi had gone down, leaving me with just my DSL connection and the wi-fi from my router. My router was old, and it was hard to configure port-forwarding. I assumed that packets were reaching the tablet, but were unable to be gated to the -IS due to the firewall. 

 This was incorrect, though it seemed to be an easy answer. Yet another variable was the Windows OS, which had just recently endured yet another update. As I dug into the nature of the most recent update, I learned that the audio level of Bluetooth connections had changed as an improvement. Soon, I discovered that the Mobilinkd TNC2 was transmitting audio at an absurdly loud level. Further, I discovered that the TNC2 was disconnecting from the tablet at random, only to reconnect immediately.

 With this piece of the puzzle in hand, I connected the TNC2 up to my "laptop station". This is where I learned the true nature of the problem: the TNC2 passed on audio to the transmitter, but failed to send any audio from the receiver to the computer. Thanks to WA0RA (Ron) for helping me diagnose this. 

 The next obvious step was to replace the TNC2, and see if that fixed the problem. Fortunately, I had a TNC3 sitting unused. My hazy plan was to upgrade my mobile rig with the latest and greatest technology, but I used this new TNC3 on my gateway. 

 Configuring the TNC3 with the Android app was simplicity itself. In the process, I found that the audio levels from the radio were set at extremely high levels to accommodate the TNC2's lack of buffering. I was able to bring the audio from the Leixen VV-898 down to reasonable levels and set up the TNC3 to receive and transmit at the proper volume level. 

 Immediately, I could see the green LED on the TNC3 indicate that it was receiving packets. I could once again see RF traffic on my tablet's APRSIS32 app. I could again transmit both ID and STATUS packets.

 I re-started the APRSIS32 app on the tablet. In the past, this has meant that it takes about three days for the network and servers to figure out that my station is, in fact, a functioning gateway. I've gated a few packets from nearby stations, and a smattering of digipeated packets. I've successfully sent a few QST messages. The APRS server shows that I'm providing messaging capability to 73 stations at the moment. 

 Soon, I expect that my humble KD0TLS-1 gateway will once again be busy gating packets for the metro's amateur population -- who will scarcely realize that there was ever an issue at all. 

 

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

ANTENNA WORK

 I have been a ham radio operator for a while, before my dad became a silent key we were 

pretty active on 2 meter and minimal hf.  But once my kids were born the hobby was used but mostly on 

the  low priority list.  once my baby was old enough where he started to do and think for himself i started

to get back in the hobby.  I was amazed at how many new ham radio oppurtunities  there were.  One of 

those  was aprs , when a fellow ham(Todd kd0tls) told and helped me get started and to 

get the bugs out of my system i was hooked on aprs.  think of the possibilities from  emergency 

communications to sending weather info and messages for ham fests and other events, it is an amazing 

tool that more people could use.

                                                   Robert  ka0rxu

KD0TLS: Intro to -IS only operation

 Perhaps decades ago, the distinction between RF and internet-based operators was stronger. But nowadays, most people move seamlessly between RF and -IS (Internet Service) operation without a thought. There are extremes on both ends, but little of the existential angst you might find between, say, analogue FM and digital FM operators. 

Operators that use the internet exclusively often do so because they don't want to install a mobile rig in their car, or can't set up a home RF station. In other cases, people have specific objectives that don't need RF-based operation, such as weather station reporting, telemetry, maintaining objects, etc. The CWOP (Civilian Weather Observer Program) has servers in amateur IP space, although most stations aren't run by amateur radio operators. 

 

Even operating exclusively on -IS, there's a lot of cross-over. For example, if you set up APRSDroid to run on your wi-fi, you'll be able to see the raw packet data and watch RF traffic being gated in real-time. So, you're not completely insulated from the RF world. Certainly other software does the exact same thing. Once you understand how to read the raw packet data, you'll start to see the ebb and flow (as well as the huge reach) of our local APRS network. 

 

Some people operate on -IS to conserve our resources. Keep in mind that 144.39 MHz is a shared simplex channel. It's highly doubtful that this single frequency could accommodate all of the metro APRS traffic. If you intend to broadcast your home location every three minutes (as some do), then maybe APRS-IS would be a considerate alternative that wouldn't consume vast amount of limited RF resources. This is also why objects (e.g. repeater locations/info) are run on the -IS, and OpenSpot stations maintain an APRS presence without creating congestion for RF-based operators. 

 

You may also find your APRS-IS station information being broadcast over RF. For whatever reason, the Faribault gateway (N0QVC-1) takes a lot of internet-based traffic and transmits it over RF as a STATUS packet -- which means it won't be re-gated, thankfully. I'm not sure what the radius is on this "service", but I've seen -IS stations as far from Faribault as Hugo being re-transmitted. With this "service", RF-only operators over a wide area can be made aware of the existence of your station, provided they are watching real-time raw packet data... because it's just packaged as STATUS packets from N0QVC-1. 

 

I've never heard any -IS only operators make disparaging remarks about RF-only operation, though that's a favour that is often not reciprocated by RF-only operators. A lot of it has to do with EmComm, and the false idea that the internet is unreliable in emergencies. Whatever disaster that wipes out the metro internet would be quite likely to take out a lot of the RF-based network as well. In fact, the RF-based network would most useful in such a case to connect to internet-based traffic outside the affected area -- so the two work hand-in-hand. 

 

All of this is just to emphasise that you should never feel apologetic about being limited to an -IS only APRS station. For years, I kept an -IS station active so that I could receive messages. If more of our local operators did that, APRS messaging would be much more compelling.