Loading ...
Sorry, an error occurred while loading the content.

NoGateME - Why?

Expand Messages
  • Lynn W Deffenbaugh (Mr)
    (Wiki fodder follows) The latest DEV release includes a feature to allow configuring an RF port with No Gate ME . Why would this be necessary? Well, I ve
    Message 1 of 7 , Sep 25, 2013
    • 0 Attachment
      (Wiki fodder follows)

      The latest DEV release includes a feature to allow configuring an RF
      port with "No Gate ME". Why would this be necessary? Well, I've
      learned something new (yet again) about the APRS-IS server behaviors.
      Here's my original question to Pete, AE5PL, and his subsequent answer:

      > I'm trying to understand how a packet gated from RF to the -IS had its
      > RFpath,qAR,KJ4ERJ-1 replaced with TCPIP*,qAC,KJ4ERJ-5 before being
      > propagated using the q algorithm fromhttp://www.aprs-
      > is.net/qalgorithm.aspx KJ4ERJ-1 was the source of the packet as well as the
      > IGate of the packet and the verified login to the javAPRSSrvr server which is
      > running as KJ4ERJ-5.
      >
      > The situation is that an IGate is transmitting beacons only via RF. A
      > digipeated copy of that packet is received by the same IGate and is gated to
      > the APRS-IS with the qAR construct. But when the packet propagates
      > through the -IS, the fact that it was received via RF has been replaced with a
      > qAC construct.
      >
      > Note: this example is from my own KJ4ERJ-1 IGate, but the real world issue
      > that I'm tracking down is an operator beaconing via the ISS (RF-Only) and
      > gating the received digipeat of his own packet which is exhibiting the same
      > behavior. This is why Mark, MM1MPB is copied on this message.

      Pete's answer:

      > That is because an IGate is not supposed to pass its own packets to APRS-IS as gated packets without passing them directly to the upstream server. It has nothing to do with the q algorithm and everything to do with server operation.
      <source code snippet removed>
      > This is done before any q algorithm operation because there are clients out there that couldn't figure out how to place a TCPIP* as the only thing in the path. Pain in the butt but that is how it works to compensate for noncompliant clients.

      So, if you're transmitting packets on RF only (type disabled on the
      APRS-IS port), and you hear your own packet digipeated back and gate it
      to the APRS-IS, that packet will not show the RF received path, but will
      only show TCPIP*,qAC,<yourcall> making it appear to have been directly
      injected to the APRS-IS. This obviously is non-desired behavior for
      satellite operations.

      With the new "No Gate ME" option on the RF port, APRSISCE/32 will not
      pass received copies of it's own packets back to the APRS-IS allowing
      remote IGates the opportunity to gate the packet preserving the received
      RF path.

      Note that this does not change the fact that the APRS-IS is decidedly
      NOT a good vehicle for doing APRS RF coverage analysis because the dupe
      filters are still in place. Only the first copy of any packet is
      propagated and all other copies are summarily discarded as unnecessary
      duplicates, even if received via different RF paths and/or different IGates.

      Also, please note Pete's follow-up warning if you do decide to use "No
      Gate ME":

      > Absolutely use the login for the client's callsign, whether it is an IGate or not! The q algorithm depends on it! What you don't do is only originate packets to RF. The reason you don't do that is you break how an IGate regulates who it gates messages to on RF. It is important that an IGate always send all -originated- packets to APRS-IS. RF is the part that is optional.

      So, if you're using "No Gate ME", don't expect APRS-IS-side messaging to
      function correctly with remote IGates. If you're trying to be an
      RF-only station with an -IS connection, you better understand ALL of the
      ramifications of that operating style. You MAY be introducing more QRM
      on the RF channel because remote IGates will not be aware of your
      -IS-conneccted status and may be gating messages from -IS to RF for your
      station because the remote IGate will believe you're on RF only and will
      be "helping".

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
    • Lee D Bengston
      I must be missing something. Why would an IGate not beacon both on RF and Internet - in other words, why beacon on RF only and thus rely on gating yourself
      Message 2 of 7 , Sep 26, 2013
      • 0 Attachment
        I must be missing something.  Why would an IGate not beacon both on RF and Internet - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

        Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.

        Regards,
        Lee - K5DAT



        On Wed, Sep 25, 2013 at 5:03 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
         

        (Wiki fodder follows)

        The latest DEV release includes a feature to allow configuring an RF
        port with "No Gate ME". Why would this be necessary? Well, I've
        learned something new (yet again) about the APRS-IS server behaviors.
        Here's my original question to Pete, AE5PL, and his subsequent answer:

        > I'm trying to understand how a packet gated from RF to the -IS had its
        > RFpath,qAR,KJ4ERJ-1 replaced with TCPIP*,qAC,KJ4ERJ-5 before being
        > propagated using the q algorithm fromhttp://www.aprs-
        > is.net/qalgorithm.aspx KJ4ERJ-1 was the source of the packet as well as the
        > IGate of the packet and the verified login to the javAPRSSrvr server which is
        > running as KJ4ERJ-5.
        >
        > The situation is that an IGate is transmitting beacons only via RF. A
        > digipeated copy of that packet is received by the same IGate and is gated to
        > the APRS-IS with the qAR construct. But when the packet propagates
        > through the -IS, the fact that it was received via RF has been replaced with a
        > qAC construct.
        >
        > Note: this example is from my own KJ4ERJ-1 IGate, but the real world issue
        > that I'm tracking down is an operator beaconing via the ISS (RF-Only) and
        > gating the received digipeat of his own packet which is exhibiting the same
        > behavior. This is why Mark, MM1MPB is copied on this message.

        Pete's answer:

        > That is because an IGate is not supposed to pass its own packets to APRS-IS as gated packets without passing them directly to the upstream server. It has nothing to do with the q algorithm and everything to do with server operation.
        <source code snippet removed>
        > This is done before any q algorithm operation because there are clients out there that couldn't figure out how to place a TCPIP* as the only thing in the path. Pain in the butt but that is how it works to compensate for noncompliant clients.

        So, if you're transmitting packets on RF only (type disabled on the
        APRS-IS port), and you hear your own packet digipeated back and gate it
        to the APRS-IS, that packet will not show the RF received path, but will
        only show TCPIP*,qAC,<yourcall> making it appear to have been directly
        injected to the APRS-IS. This obviously is non-desired behavior for
        satellite operations.

        With the new "No Gate ME" option on the RF port, APRSISCE/32 will not
        pass received copies of it's own packets back to the APRS-IS allowing
        remote IGates the opportunity to gate the packet preserving the received
        RF path.

        Note that this does not change the fact that the APRS-IS is decidedly
        NOT a good vehicle for doing APRS RF coverage analysis because the dupe
        filters are still in place. Only the first copy of any packet is
        propagated and all other copies are summarily discarded as unnecessary
        duplicates, even if received via different RF paths and/or different IGates.

        Also, please note Pete's follow-up warning if you do decide to use "No
        Gate ME":

        > Absolutely use the login for the client's callsign, whether it is an IGate or not! The q algorithm depends on it! What you don't do is only originate packets to RF. The reason you don't do that is you break how an IGate regulates who it gates messages to on RF. It is important that an IGate always send all -originated- packets to APRS-IS. RF is the part that is optional.

        So, if you're using "No Gate ME", don't expect APRS-IS-side messaging to
        function correctly with remote IGates. If you're trying to be an
        RF-only station with an -IS connection, you better understand ALL of the
        ramifications of that operating style. You MAY be introducing more QRM
        on the RF channel because remote IGates will not be aware of your
        -IS-conneccted status and may be gating messages from -IS to RF for your
        station because the remote IGate will believe you're on RF only and will
        be "helping".

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


      • James Ewen
        ... Who says the station is an i-gate? The operator may only be listening to the APRS-IS to hear more activity than is available on the local RF channel. - in
        Message 3 of 7 , Sep 26, 2013
        • 0 Attachment
          On Thu, Sep 26, 2013 at 5:00 PM, Lee D Bengston <kilo5dat@...> wrote:

          > I must be missing something. Why would an IGate not beacon both on RF and
          > Internet

          Who says the station is an i-gate? The operator may only be listening
          to the APRS-IS to hear more activity than is available on the local RF
          channel.

          - in other words, why beacon on RF only and thus rely on gating
          > yourself after a digipeat in order for those packets to get to the Internet?

          There's no requirement for a packet to be digipeated before being
          i-gated. If your next door neighbour is running an i-gate, and you
          send a packet, the neighbour will send the packet to the APRS-IS upon
          hearing it directly.

          This also brings up a reason for NOT acting as an i-gate... why would
          you have 2 i-gates side by side? There's no reason for it, yet why
          should you not be able to listen into the APRS-IS stream just because
          the neighbour is running an i-gate?

          --
          James
          VE6SRV
        • Lynn W Deffenbaugh (Mr)
          ... Because the station wants to ensure that his RF is operating as desired without the interference of direct APRS-IS delivery of his packets. ... Because
          Message 4 of 7 , Sep 26, 2013
          • 0 Attachment
            On 9/26/2013 7:00 PM, Lee D Bengston wrote:
            I must be missing something.  Why would an IGate not beacon both on RF and Internet

            Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.

            - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

            Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.


            Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.

            How (or if) you use it is completely up to you, but at least now the option is there.  But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:

            Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

            1. 3rd-party packets (data type } ).
              3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
            2. generic queries (data type ? ).
            3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).

            Nothing in there about not gating your own packets that you might have heard back via a digipeater.  Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

            But the REAL reason for this sort of operation is when working an APRS satellite like the ISS.  You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS.  But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

            Lynn (D) - KJ4ERJ -Author of APRSISCE for Windows Mobile and Win32

          • Lee D Bengston
            ... I was referring to Lynn s example that said, The situation is that an IGate is transmitting beacons only via RF. A digipeated copy of that packet is
            Message 5 of 7 , Sep 26, 2013
            • 0 Attachment

              On Thu, Sep 26, 2013 at 7:33 PM, James Ewen <ve6srv@...> wrote:
               

              On Thu, Sep 26, 2013 at 5:00 PM, Lee D Bengston <kilo5dat@...> wrote:

              > I must be missing something. Why would an IGate not beacon both on RF and
              > Internet

              Who says the station is an i-gate? The operator may only be listening
              to the APRS-IS to hear more activity than is available on the local RF
              channel.
               
              I was referring to Lynn's example that said, "The situation is that an IGate is transmitting beacons only via RF. A digipeated copy of that packet is received by the same IGate and is gated to the APRS-IS with the qAR construct."

              Yes, a station doesn't need to be an IGate to be on both RF and Internet - no disagreement there.

              - in other words, why beacon on RF only and thus rely on gating
              > yourself after a digipeat in order for those packets to get to the Internet?

              There's no requirement for a packet to be digipeated before being
              i-gated. If your next door neighbour is running an i-gate, and you
              send a packet, the neighbour will send the packet to the APRS-IS upon
              hearing it directly.

              Didn't say there was such a requirement.  I was only referring to Lynn's scenario where an IGate was gating it's own packet after it was digipeated.  I agree that if there is another IGate nearby, an IGate that is sending beacons via RF only could be gated by that other IGate without a digipeat.  If an IGate is going to gate its own RF beacons to the IS, however, then the packet needs to be digipeated.

              > This also brings up a reason for NOT acting as an i-gate... why would
              > you have 2 i-gates side by side? There's no reason for it, yet why
              > should you not be able to listen into the APRS-IS stream just because
              > the neighbour is running an i-gate?

              I'm not aware that I said anything that should be interpreted as being in favor of implementing 2 IGates side by side.  In fact, I was thinking in the context that there was not another IGate nearby when I asked about the concept of an IGate beaconing on RF only and gating itself to the APRS-IS.

              Regards,
              Lee - K5DAT

            • Lee D Bengston
              ... OK, but I know that when I beacon to both RF and IS, I can check a list of raw packets from aprs.fi and typically see some small minority of beacons on RF
              Message 6 of 7 , Sep 26, 2013
              • 0 Attachment

                On Thu, Sep 26, 2013 at 9:10 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
                 

                On 9/26/2013 7:00 PM, Lee D Bengston wrote:
                I must be missing something.  Why would an IGate not beacon both on RF and Internet

                Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.

                OK, but I know that when I beacon to both RF and IS, I can check a list of raw packets from aprs.fi and typically see some small minority of beacons on RF - enough to give me a warm fuzzy that the RF is working as desired.

                 - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

                Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.

                OK, but I would think the chances of that are pretty small given we're talking about beacons as opposed to messages. 
                Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.
                How (or if) you use it is completely up to you, but at least now the option is there.  But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:

                Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

                1. 3rd-party packets (data type } ).
                  3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
                2. generic queries (data type ? ).
                3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).

                Nothing in there about not gating your own packets that you might have heard back via a digipeater.  Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

                Yes, I understand the rules, and I understand the reasons for not wanting IGates to do dupe filtering in general, but in this specific case, it seems simple and harmless for an IGate that is beaconing to the APRS-IS to ignore it's own packet coming back through a digipeater.
                 
                But the REAL reason for this sort of operation is when working an APRS satellite like the ISS.  You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS.  But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

                Cool stuff!

                > So, if you're transmitting packets on RF only (type disabled on the 
                > APRS-IS port), and you hear your own packet digipeated back and gate it 
                > to the APRS-IS, that packet will not show the RF received path, but will 
                > only show TCPIP*,qAC,<yourcall> making it appear to have been directly 
                > injected to the APRS-IS.

                By the way, I forgot to mention in my original reply that I had also noticed the described phenomenon above - a couple of years ago actually, but I misunderstood it to be the IGate software actually transmitting some beacons to the IS even though it was configured not to.  I became further perplexed when I saw this behavior with more than one IGate application.  I concluded (incorrectly) that the IGate software authors were purposely having their software send some beacons to the IS for exactly the reason that Pete L described as quoted below:

                > What you don't do is only originate packets to RF. The reason you don't
                > do that is you break how an IGate regulates who it gates messages to on RF.
                > It is important that an IGate always send all -originated- packets to APRS-IS.

                LOL - I had no idea that those beacons that looked like they were sent directly into the IS were actually self-gated digipeats of the RF beacons.  The reason they were the minority is that other IGates were gating my RF beacons faster, so most of the time I would see the ones that still showed as originated on RF.

                Thanks for the great information.

                Lee - K5DAT


              • Steve Daniels
                Well when this comes out of the Dev version into release I will re write the Sat Ops section of the WIKI. Gives me an excuse to play ISS again Steve Daniels
                Message 7 of 7 , Sep 27, 2013
                • 0 Attachment

                  Well when this comes out of the Dev version into release I will re write the Sat Ops section of the WIKI.

                  Gives me an excuse to play ISS again

                   

                   

                  Steve Daniels

                  Amateur Radio Callsign G6UIM

                  Torbay Freecycle  Owner

                  http://uk.groups.yahoo.com/group/torbay_freecycle

                  APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

                   


                  From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Lynn W Deffenbaugh (Mr)
                  Sent: 27 September 2013 02:10
                  To: aprsisce@yahoogroups.com
                  Subject: Re: [aprsisce] NoGateME - Why?

                   

                   

                  On 9/26/2013 7:00 PM, Lee D Bengston wrote:

                  I must be missing something.  Why would an IGate not beacon both on RF and Internet


                  Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.


                  - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?


                  Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.


                   

                  Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.


                  How (or if) you use it is completely up to you, but at least now the option is there.  But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:


                  Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

                  1. 3rd-party packets (data type } ).
                    3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
                  2. generic queries (data type ? ).
                  3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).


                  Nothing in there about not gating your own packets that you might have heard back via a digipeater.  Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

                  But the REAL reason for this sort of operation is when working an APRS satellite like the ISS.  You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS.  But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

                  Lynn (D) - KJ4ERJ -Author of APRSISCE for Windows Mobile and Win32

                Your message has been successfully submitted and would be delivered to recipients shortly.