Thursday, August 15, 2019

RX-only igates considered beneficial to the network

As probably most of you know by now, besides running the aprs.fi web site, I'm also one of the two main authors of the aprsc server software. aprsc runs on most of the APRS-IS servers where iGates usually connect.

There have been recent and strong claims saying that receive-only (rx-only) iGates destroy the two-way messaging feature of APRS. This has been claimed in blog posts and facebook threads. Some people ask me if this is true.

No, it is not true. Receive-only iGates do not break messaging if there are transmit-capable igates nearby, and those transmit-capable iGates are connected to an APRS-IS server which has a full APRS feed. All aprs.net and aprs2.net servers, where iGates normally connect, do have a full feed. No problem!

Messaging would work from 1650m / 5400 ft above Vihti, even in the presence of
RX-only iGates, as long as there is at least one TX-capable iGate.

If there are no transmit-capable (TX) iGates around, two-way messaging will not work, of course. Having a transmit-capable iGate would therefore be better, but receive-only iGates are easier to set up technically, they are cheaper (receivers are practically free now), and licensing for automatic transmitters is difficult in many countries. Where transmit-capable (TX) iGates are present, receive-only iGates do not break the TX iGates, they just improve reception coverage. For messages, too.

Just to make it perfectly clear: If there are TX iGates present, additional RX-only iGates improve messaging performance. For the RF-to-IS direction (and ACKs for the IS-to-RF messages).

The common incorrect claim is that the APRS-IS server sends the message only to the latest iGate which heard a station. In fact, the APRS-IS servers (both javaprssrvr and aprsc) send the messages to all iGates which heard the station recently. In aprsc, "recently" means "within 3 hours", and I believe javaprssrvr uses something similar.

The server maintains a list of recently heard callsigns independently for each iGate client. There's a separate list of heard stations for each iGate client. When the server has a packet to pass on, it will look at all connected clients, and for each client, if the recipient of the message is found from the list of recently heard stations, the message will be sent. The scanning will not stop; the message will be given to all clients which heard the station.

I can confirm that we have written the software to do it like this, and since it is open source, you can see the code yourself. The automatic test case also validates that the server keeps working that way, so that there won't be a bug creeping in the future to break it accidentally. I've also tested that javaprssrvr behaves like this – I've run the test cases against it to confirm compatibility.

There may be problems when there is a server with a filtered feed involved (possibly a server software running at the "client" without having a full feed), but those are rare and known to be problematic. All Tier2 servers have a full feed (aprs2.net ones), and so do the core servers.

The real problem is that a user, seeing one-way beaconing to the APRS-IS works, may well 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! I wouldn't be so harsh against them, since the step from RX-only to TX-capable may be a bit difficult for many.

Bottom line:

In each area, there should be one TX igate, maybe two. More may create QRM as the same messages will be transmitted from APRS-IS to RF many times. RX igates will not break messaging if there are TX igates around – they just improve RX coverage.

This picture may at first seem irrelevant, but it does show me working VHF in AM (122.825 MHz),
and Flarm on 868 MHz to OGN (which runs aprsc). Flarm antenna visible in top left corner.

5 comments:

  1. Thanks for explaining what actually happens. Although I never believed that RX-only IGates were bad, it's good to know that they are usually a positive addition to the network.

    73 Richard G3CWI

    ReplyDelete
  2. This is all good, and I am happy to be proven wrong, really! However this does not reflect my parctical experience.

    2 or 3 weeks ago I was hiking in the black forrest. Two igates were in reach, one RX only in the next village near the hiking spot (2 or 3km from me) and the other was our club full TXRXdigipeater/igate 50km away.
    From the peak I was hiking I had clear view to our club igate, and my posits packet were also digipeated by it.
    At some point I had some 4g coverage and decided to conduct some tests.

    I configured my phone to connect to euro.aprs2.net using my US callsign and tried to message from my HT to my phone and vice versa.

    I could receive the messages from my HT on my phone yet i did not receive any acks from the phone nor did any message from the phone make it to the HT.

    ReplyDelete
  3. F4FXL: Your practical experience does indicate that there is a problem somewhere, but it does not mean that it's caused by the RX igate. This claim is a bit similar to the fairly common health-related claims where someone says his flu is cured in 2 weeks because he ate a lot of honey/chili/homeopathy, while in fact the flu cured itself in 2 weeks anyway, due to completely different things. Correlation and causality are different things.

    There may different reasons than the one described in your original blog post, and it is quite likely, since the original post describes the server functionality very differently from how it actually works.

    We'd have to look more closely at the configuration of the TX/RX capable igate to see why it did not get or transmit the packets. Could you publish the config files of the igate somewhere for download, so that we could look at it and try to replicate the situation? Also, if the TX/RX igate keeps log files of packets it receives from the APRS-IS, and it's transmit decisions, that would be useful too.

    ReplyDelete
  4. Hi,
    I just conducted a test similar to F4FXL's i.e. using my Greek Callsign SV1UY-6 in my Android Phone running U2APRS and my English callsign M0SUY-1 in my Desktop PC running APRSIS32 connected to my TH-D7 on 144800 KHz. Despite having both an RX-Only APRS IGATE (M0WJW-10) and a TX/RX APRS IGATE (MB7UXX) operating near me on 144800 KHz, I managed to send an APRS text message from U2APRS APRS program running in my Android Phone to my APRSIS32 APRS program running in my Desktop connected to my TH-D7 with success in the 1st go. The opposite (i.e. sending from my radio to my phone) also worked FB, also in the 1st go.

    I think Hessu is correct in his statement that RX-Only IGATES present no problems in APRS MESSAGING because my messages went through without problems. Perhaps many years ago, what F4FXL says was correct. Not now!
    Perhaps his beacon was never received by his club's IGATE because a 50Km path between your portable APRS Radio and the TX/RX IGATE is too far to make sure assumptions! If your BEACON is not received by the IGATE, the IGATE does not know you are on the air so it will never attempt to send anything addressed for you! Also due to the hidden transmitter syndrome, which is notorious in all PACKET RADIO NETWORKS, your APRS packets were lost.
    I think more tests should be made!
    73 de Demetre M0SUY/SV1UY

    ReplyDelete
  5. The problem is too few people doing RX igates instead of two way. Almost none in our area.

    ReplyDelete