Why are APRS RX only iGates bad ?

Every now and then I keep on reading on social networks or forums how people set RX only igates up. RX only igates are just bad, really bad. I could just leave you with the following statement “APRS is a bidirectional network and RX only igates are not bidirectionnal. Period” But let me expose how they are breaking the network.

For most of the people setting up RX only igates the initial premise is to “see their track” on aprs.fi. They completely miss the point that APRS is a tactical two way network and not just icons on a map. APRS has a SMS like messaging capability, which relies on the internet and the APRS-IS system to convey messages between stations that are out of range of the same digipeater. This is this messaging capability which is being broken by RX only iGates.

Consider following scenario where we have two igates in the same area.

  • RX only igates N0RX which has a high speed connection.
  • Full TX/RX igate N0FULL which has a slower sonnection than N0RX
  • N4ABC, a mobile station which can be heard by both igates

Thanks to its good internet connection N0RX is able to push packets faster to the APRS-IS servers. N4ABC packets will be gated through N0RX and N0FULL but since the packets coming through N0FULL will be dropped and marked as duplicates.

Now we have N5DEF which is 1000km away and wants to message N4ABC. N5DEF sends a message from his radio, this will be gated at some point. Now the APRS-IS server have to decide which igate to use to bring back the message back to RF so it can reach its recipient, in our case N4ABC. Since N0RX is the igate “assigned” to N4ABC this is the igate that will be used. Maybe you start now to understand the issue, since N0RX is not TX capable the message aimed at N4ABC will never make it through.

In the example above the RX only igate has a faster internet connection than N0FULL, but if both igates have similar internet connection speed it might also break the network but more randomly. We all want a 100% working network.

The RX only igate use case has never been foreseen, and there is no way for APRS-IS to detect that and igate is not TX capable.  Do not be a jerk, do not run a RX only igate.

August 15th 2019 Update: in a blog post Hessu, author of aprs.fi and aprsc APRS-IS software explains that igates might be benefitial to the network, if and only if there is a TX igate nearby. This makes sense, yet does not reflect my experience. I might post about it in the near future. Also see Hessu’s comment below.

31 Comments:

  1. I’m not sure if that is true. Have you checked it in the real life?

    I have just done some small simulation. I have opened 3 telnet windows and connected to different servers using my call and different SSIDs. Then I sent a position packet (using my call and different SSID), in the format IGates use to forward radio traffic to the Internet, first using one telnet connection and after few seconds using second connection, so it was a simulation of two IGates, one with slower and one with faster connection, that uploaded the same packet heard via RF with a small delay.

    Then in last telnet window I sent a message packet directly to the server, addressed to the station, which position I have just sent using these two other connections. And this message packet was forwarded from the server to BOTH IGates (both telnet windows). It didn’t matter which IGate was first with uploading the beacon I had sent before.

    I was using NO server filters.
    All servers used for this test use aprsc software. Servers using javaprssrv don’t want to send any packet to client without using filters. These servers don’t forward any message packet addressed to the station, which beacon was received by them. I have no idea why.

    • OK, in the last part I was wrong. Javaprssrvr correctly forwards packets addressed to the station which postion was uploaded to the network by the client. I made a small mistake in a message frame.

      But my thesis remains: it doesn’t matter which IGate was first. I have just done the same test with other callsign and the message was sent to both IGates. So APRS-IS doesn’t choose the IGate which first received the frame before. It send packet to every IGate which received the packet from a destination station.

      • Geoffrey F4FXL

        Thank you for your constructive comment.
        That’s interesting. Did you do the same test when both igates are connected to the same server? How long did you wait between sending the two initial position packets?

      • Geoffrey F4FXL

        I guess all of your connections had the same IP ?

        • The delay between sending packets to the IGates was about 1-3 seconds.
          I have just checked that with three different IPs (first “IGate” connected with my home network, second with cellural network and the message was sent using findu website (other IP)). First IGate was using SQ8L-2 call, second was SQ8VPS, the message addressee was SR8NDR and the sender was TEST. So every callsign was different and every connection had different IP. The effect was still the same. All IGates forwarded the message, no matter which one first received a packet from the addressee.
          With both IGates connected to the same server the effect was also the same.

          I’m not a fan of RX only IGates, but according to my tests they have no negative influence on the RF network. Additionally, APRS-IS specification says that “All core servers and most javAPRSSrvr servers […] support port 14580 as a user-defined filter port. This port begins by only sending message packets addressed to the client or addressed to stations gated to APRS-IS by the client.” I understand “stations gated to IS” as every station gated including duplicates, but in the next stage of processing by a server dupes are filtered. The rule of “first IGate” and that a duplicate frame isn’t a gated frame is not mentioned anywhere.

          I think the best idea is to ask an APRS-IS admin or aprsc or javaprssrvr developer. I will write an e-mail to one of these guys.

          • Geoffrey F4FXL

            It looks like your finding are proving me. I made a similar tests a couple of years ago and my messages never went through. I also once read a post from the developer of javAPRSServer and he was mentionning the dup thing as being a real headache thing.

            • But in my test every message got through. To both IGates.

              Anyway, I contacted AE5PL with the results of the test I did and he didn’t deny it, but he rather gave me an example of another situation, when message will not be forwarded. When an IGate use server-based software, so it creates it’s own local IS server, the problem can appear. When another IGate receives a packet and uploads it to the uplink server, it’s immediatly forwarded to the local server used by the first IGate. Then if that first IGate receives a packet with some delay the local server will drop this packet, because it’s duplicate. In this case an uplink server will know only that the frame was received with that second IGate, so it will forward message packets only to that IGate.
              But because he didn’t deny, that the problem doesn’t exist with IGates both connected directly to the APRS-IS, I may think that standard IGate softwares (not server-based) are not affected by this problem at all. Although I will be intensively observing it.

            • Here I also found some good explanation: https://robust-packet.net/yahoo.html
              Lynn KJ4ERJ wrote there: “Consider if a Receive-Only IGate continuously delivers packets to the APRS-IS faster than the local transmitting gate. The packets gated by the transmitting gate will always be dupe-suppressed at the point of entry and that may cause messages destined for the gated stations to never be delivered to that IGate. […] It actually works fine as long as all IGates are directly connected to an APRS-IS server that is being fed from a full feed. But if an IGate is connected to a filtered APRS-IS server (some are), then dupe suppression can prevent that IGate’s APRS-IS server from ever hearing messages addressed to stations that the IGate may have heard but were gated to the APRS-IS quicker by some other IGate.”. And it’s the same explanation as I wrote a couple of minutes ago, but using different words. So in conclusion, it depends on the area, or more strictly on the software. If you have many RX only IGates and one server-based TX-IGate, messaging may work very poor or even don’t work at all.

              • Geoffrey F4FXL

                This is one of the messages the message I was refering! What he is refering to is that it can lead to issues when the APRSIS server the igates connects to (typically a tier 2 server) has a filtered connection to the tier 1 server. Maybe this is what you meant with “local” APRS-IS server.
                My explanation is far more simplistic and Lynn’s message clearly shows that the issue is actually more complex and the current APRS-IS cannot relilably work with RX-Only igates.

                Some people on social network are arguing “it could be easy to add a flag for the igate to signal as a RX only igate”. IMHO this is not practical as some igates were setup and left untouch for years by their sysops and are not likely to be updated until they break. People just stick to their RX only igates and I am afraid at some point APRS-IS will need to deal with them. Killing messaging one RX igate at a time …

                • Yes, you’re right. We also have some guy in our area, who installs lots of RX only IGates and he also wrongly uses “I” overlay in his stations’ symbols.
                  AE5PL explained “local server” to me as an IGate software which creates it own, very local, APRS server and then this server is connected to some Tier2 server using filtered connection. I think connections between Tier2 and Tier1 server are almost always full feed.

      • WILLIAM KILLION

        As an avid aprs user/infrastructure developer here in southern Illinois i’m going to disagree for this reason,
        The aprsis software when you set it up properly has traffic select rf to is, is to rf, and gateway. When you set these settings in the software the aprs system recognizes the difference between the Igate only and the rf capable and will send the message via the rf capable station. Tested and confirmed over 490 mile messaging between myself KD9IWV and KD9GSX. The igates do remove the fast set beaconing operater from the system faster freeing up the actual rf carrying digipeaters to move the messages.

        • Geoffrey F4FXL

          Hi, thank for your input. Which aprs-is software are you talking about? Server software like aprs?

  2. Walter R Francis

    So your opinion is that large gaps with zero APRS coverage at all are better than receive-only iGates? RX-Only iGates are often used to fill missing coverage and let’s be realistic, 99% of the traffic on APRS is just people tracking their cars anyway. But it doesn’t really matter; if there’s nothing to receive the packet at all I feel that’s worse than your hypothetical situation you’ve outlined.

    Not everyone can put up a RX/TX iGate. Either they don’t want the interference to their own stations, don’t have the hardware to dedicate to it, or any other number of reasons. I feel you’ve grossly over simplified and exaggerated your personal opinion and only represented one single aspect of APRS.

    • Geoffrey F4FXL

      Hi Walter,

      Thank your for your comment.

      Bob WB4APR, the father of APRS, says this about RX only iGates

      RX-only IGates kill the functionality of the APRS-IS as a universal system!
      And they give casual observers the impression that APRS has global
      connectivity, when in fact, that view has lots of invisible holes because of
      RX-only IGates

      (source: https://groups.yahoo.com/neo/groups/APRS/conversations/messages/9468)

      As you mentioned “holes”, but holes created by RX only igates are more detrimental than holes caused by the lack of igates. As Bob has written, they give the person observing the network through the prism of APRS-IS that the network is fully operational but it is actually not. It is not because most people have a wrong idea of what APRS is that the others, using it to its full extent have to suffer from a half working network.

      I run a fill-in digi and igate, it is running on a 30 years old HT, a 30 years old TNC and Raspberry pi. Let’s be honest, I am not 24/7 in my shack nor is any ham. If I want to use my station I just flick the switch and the igateis off, no interference. I leave the shack I turn it back on. When I am at work or away from home it is bringing real value to the netowrk.

      • Walter R Francis

        So take away all of the iGates and you’re left with a lot of digipeaters with NO IS capability at all and hundreds of miles of gaps between them to even digipeat. No, sorry, that does not sound better.

        • Geoffrey F4FXL

          When there is a gap it is better practice to put up a digipeater than an igate. A RF user in a zone where only an igate is available will have the false impression he is moving in a complete APRS less zone. Moreover, adding a digipeater might allow RF users to reach a distant igate. APRS is meant to be a bidirectionnal local and tactical awareness network.

  3. A low-level/low-power iGate might as well be considered RX-only to all but aircraft. I’m looking at my station info & my ≤5W has never made it out to any digipeaters, iGates, and the only station I’m certain it has made it to, is my portable/mobile.

    Due to San Diego’s varied terrain, some are using amplifiers with their beaconing HTs, and others are using well over 5W with their mobiles, otherwise they wouldn’t have made it into my iGate’s RX antenna from the coordinates they were at.

    So really, the argument should be nobody should be running iGates at all without meeting minimum HAAT & power levels.

    • Now Raspbian GNU/Linux 9 (stretch) isn’t playing Direwolf 1.5’s packets in their entirety, only a split second of flat tone, through the RPi 3B+ internal soundcard. I plugged in earbuds to confirm this instead of just listening for the packets through another radio, like I successfully did when I set it up.

      Back to RX-only, not being given any choice by external forces.

  4. Posting to follow the discussion. I just put up an RX only iGate and immediately realized the dilemmas. This is the debate I was looking for!

    • Geoffrey F4FXL

      Welcome to the debate :). What is your motivation behind an RX igate? My original assumption is that people tend to see APRS only through aprs.fi but I’d be interested in what were your reasons.

      • I picked up an HT with APRS support, and while learning and experimenting I wanted to reduce the output power required, and contention for the channel. For messaging reliability, especially with winlink as it’s a lot of back-and-forth to login, do mail, logout.

        I don’t have the hardware for a full iGate or I might look into that, but I think I wouldn’t keep it on the air as I’d have so little footprint as to be effectively an RX only. As others in the discussion noted, this is probably even worse than those that are known to be RX only. It’s a shame that fact isn’t known to the network, though. With the proliferation of rpis+SDRs it’s a 20m job to set up an RX only iGate using direwolf, instructions for how to do it abound, and its something that needs to be accommodated in the APRS architecture rather than discouraged, IMO.

        I’ve tried all I could to prevent sinking TX traffic using filters, but it doesn’t seem to help. Traffic still comes my way to be sent to the null interface 🙁 So, it’s off for now.

        I think that’s the thing that I found most perplexing and frustrating. I set a filter of u/N0BODY and still traffic for other stations comes my way. Why isn’t the server-side filter respected? I’ve confirmed I’m connected to port 14580, which is the port I understand that should allow for these filters, and the logs and the server dashboard shows the filter in place, yet still the traffic comes.

        • Geoffrey F4FXL

          I had lots of spam issues those last days, I tighten up my spam filters and your comment ended up as false positive.

          The server sends whatever data it thinks is relevant to your igate, regardless of the filter. The filtering is only there to make sure you get those packets whatever the server thinks is relevant, e.g. our local igate has a filter so our club members will be gated to RF wherever they are in thee world.
          I also experienced an aprs server which was arbitrarily adding m/1000 filter. I found myself gating to RF half of Europe. This was a misconfiguration on the server.

          Because it is easy to do it does not mean it should be done ;). It took me an old TNC, an old HT and some small soldering to have a full digipeater/igate. IMHO addressing this on the APRS architecture will definitely push the network into an internet only thing which is a huge waste.

          • I’m considering building a full iGate, and possibly a digipeater, but then I see people building projects like this http://hamlabs.no/2019/05/13/first-round-of-tracker-project/ and I figure I’ll just wait it out. Eventually something turnkey that will be like an “APRS hotspot” will come to market, I’m sure.

            If I had the license necessary to run something on the air full time (I think a wide coverage permanent Digi or iGate would require rights to operate a repeater, which I don’t have), I might be more interested. But for now something like a “hotspot” that doesn’t ruin it for others, but helps me learn about APRS is what I’d like to see. And I can’t imagine how lowering the barrier to entry and providing a means to learn and find utility is in anyway a bad thing. Philosophies aside, I’m not getting a full iGate on the air without an Advanced ticket, so it’s not like I’m “giving less than 100% of what I can” in support of the growth of the network.

  5. Philipp, OE5PJN

    In my opinion, expecting an iGate to be Rx+Tx, is more or less a design flaw of the system.
    In OE, automatic transmission without presence of the operator (Beacons, Relays) is not allowed by law, with exception to radio clubs. Thus, only radio clubs are allowed to operate Rx+Tx APRS iGates.
    This leads to a poor coverage in areas where radio clubs do not operate APRS.

    • Geoffrey F4FXL

      Hi Philipp, thank you for your input.
      What if the OM asks for a repeater call for the gateway? Isn’t a RX only coverage even more bad as no coverage? As WB4APR states, this gives the wrong impression that the network is ok where it is actually not.

  6. Hi, I can confirm OE5PJN’s thoughts. For example in Germany receiving a callsign for an automatic working station costs EUR 200,- and you have to wait up to 6 Months to get the license. Otherwise TX is only allowed at the presence of the callsign owner. Well the most people have to work or so …
    I don’t get it why NO-COVERAGE should be better than “R-ONLY”. Amateurs who are driving through the area are happy to be heard anyway. To loose a (rare) message or to loose the complete APRS coverage .. well the decision is easy. 73 Attila

    • Your claim is based the fact that you are approaching the APRS from the Internet side of things. What you mean with NO-COVERAGE must be rephrased into NO-ONE-WAY-TO-INTERNET-COVERAGE. The APRS network is RF, the primary original purpose of igates was to … send messages accross the globe! When you are traveling with your radio, even if you do not have a digipeater around you still have coverage and will hear all the stations directly, you always have coverage.
      There are lot of services which gets broken because of RX only gates SMSGATE, WXBOT, WINLINK …. Last Weekend I was playing with messages, and the RX only igates right accross the german boarder were just swallowing my messages despite, me being fully heard by our local igate.

  7. “In my opinion, expecting an iGate to be Rx+Tx, is more or less a design flaw of the system” [OE5PJN]. He’s right surely? This “problem” is due to an unforeseen weakness in the APRS network design. Given that RX-only iGates will not go away, the network design needs fixing. Here in the UK there are restrictions on running digipeaters that make them unattractive to most people. Other than for a test I have never seen anyone use APRS messaging here. It’s too poorly implemented on any handy to be remotely useful.

    • I do not think it is an unforseen weakness of the network. Your statement just adds to the point that most people think APRS-IS is THE APRS network, whereas the network is actually the RF part of it. Bob Bruningsa defined APRS as a local tactical amateur radio system. The APRS network started RF only and it is still an RF based network. Igates only came very later and were first thought to convey messages on a global scale.

      Lots of people bring the excuse that having an unattended TXing station at home requires an additional license bringing aditional costs, I bet most of them run FT8 WSPR etc unattended.

  8. Hi, I’m Hessu, OH7LZB. I run the aprs.fi web site, and I’m also one of the two main authors of the aprsc server software, which runs on most of the APRS-IS servers where igates connect.

    As has been pointed out in other comments, this blog post is factually incorrect. The post claims that the APRS-IS server sends the message only to the latest igate which heard a station. As others pointed out, the APRS-IS servers (both javaprssrvr and aprsc) send the messages to *all* igates which heard the station recently, so an rx-only igate won’t cause a problem.

    The server maintains a list of recently heard callsigns independently for all igate clients on filtered connections. There’s a separate list of heard stations for each igate client. When it has a message to pass on, it will look at the heard list for each igate client, and send it to all igates which have heard the recipient recently. Not the latest one.

    I can confirm that I have written the software to do so, and since it is open source, you can see it yourself: https://github.com/hessu/aprsc/blob/master/src/filter.c#L2467

    The automatic test case also validates that the server keeps working that way: https://github.com/hessu/aprsc/blob/master/tests/t/40messaging.t#L192

    There may be problems when there is a server with a filtered feed involved (possibly a server software running at the “client” without full feed), but those are rare and known to be problematic; a t/m filter on the filtered connection may help. All Tier2 servers have a full feed (aprs2.net ones).

    I suppose the real problem is that a user, seeing one-way beaconing to the APRS-IS works, would expect two-way messaging to work too. And when it doesn’t work, there’s only a timeout, no immediate feedback saying “sorry, this won’t work now”, which is what a sensible system would do today.

    Even in that case, an rx-only igate is better than nothing, and it’s much easier to set up. Technically, financially and licensing-wise in many places. So, I wouldn’t be so harsh against them.

    I would ask the author to kindly update the blog post to reflect the facts. TX-capable igates would be better, but not for the reasons stated in the post.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.