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

Show IS station on RF

Expand Messages
  • Jess
    In light of the recent snow storm that has caused me to hunker down, I decided to dust off some of my extra APRS gear and start playing around with I-gating
    Message 1 of 34 , Jan 10 1:02 PM
      In light of the recent snow storm that has caused me to hunker down, I decided to dust off some of my "extra" APRS gear and start playing around with I-gating and Digi-peating. Well with just a little bit of effort I managed to get both Digi and Igate configured and seems to be working without a hitch.

      One question that I cannot seem to find the answer to is how do I enable an IS station to be seen over the RF side? For instance, if I have an APRS enabled smartphone that uses the call sign of KC9QEA-7, how can I make APRSIS32 transmit those packets out over RF.

      I know we don't want every IS packet going out over the RF side, but under special circumstances it may be a necessity.

      Thanks and 73's

      Jess - KC9QEA
    • Lynn W Deffenbaugh (Mr)
      ... My implementation of this is to apply an enhanced APRS-IS filter specification to select packets from the APRS-IS stream and gate them from the -IS to
      Message 34 of 34 , Jan 11 11:00 AM
        Per the APRS-IS IGate spec from http://www.aprs-is.net/IGateDetails.aspx:

        Gate all packets to RF based on criteria set by the sysop (such as callsign, object name, etc.).

        My implementation of this is to apply an enhanced APRS-IS filter specification to select packets from the APRS-IS stream and gate them from the -IS to local RF using 3rd party packets and a path to be configured by the IGate operator (currently the IGate's Beacon path).  While the spec doesn't provide for any limits on these packets, I've seen enough bad stuff on the APRS-IS that I want to provide the ability for the IGate operator to protect themselves from the unexpected.

        And it's not a precedent with APRSISCE/32.  UI-View, and I suspect others, support the specification of packets that should be gated from the APRS-IS to RF outside of messages and courtesy posits.  That's how NWS weather alerts get from the -IS to RF in some affected areas.  I just chose to do it with an APRS-IS filter specification rather than explicit specification of "callsign, object name, etc" as the spec calls it.

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



        On 1/11/2014 11:30 AM, Robert Bruninga wrote:
        Nothing should go back from the IS to RF except for messages and the associated "courtesy" posit.  ANything else is a mess just waiting to happen.  We have idiots that listen to 144.39 and say, "Im only hearing one packet every 20 seconds"... how boring, Ill open this spigot here and let all my friends see all this stuff."  ANd he just KILLS aprs functionality in that and surrounding areas.

        With 40,000 users and even if only 1% of us idiots, then that can pollute 400 local areas and cities, and with some of them doing 2 hops, that is the entire planet!  And Sometimes I think the percent of idiots may be greater than that ;-)

        Glad you are aware, that this is a dangerous precedent.

        Thanks
        Bob, WB4APR





        On Sat, Jan 11, 2014 at 11:01 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:


        The throughput limiting will only affect arbitrarily filtered gating of APRS-IS packets onto the local RF.  This is to prevent a run-amok APRS-IS client from saturating someone's RF environment if their packets happen to match an IGate's -IS to RF filter setting.

        Rest easy, I'm only talking about limiting speed on additional, enhanced IGating.  Not anything in the "mainstream" APRS.  I believe UI-View even has simplistic throttles of packets per minute or some-such.

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




        On 1/11/2014 10:09 AM, Robert Bruninga wrote:
        > ... and is why I still need to get throughput limiting implemented.

        I have not been following thsi thread at all but that caught my eye.  Forgive me if this is out of context, but "thgoughput limiting" is what nearly broke APRS in the beginning of the century when every digipeater owner and IGate owner were setting up their own algorithms to throw away packets to throttle throughput.  That is a nightmare to APRS consistency and reliability.

        Throughput control was not the solution.  It was attacking the problem at the source (too many packets, with too many hops).  We simply outlawed anything more than 2 hops (1 hop in some places).  Every packet on the air was treated the same.

        Just 2 cents into the mix...

        bob, wb4apr


        On Sat, Jan 11, 2014 at 9:55 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

        On 1/11/2014 9:42 AM, James Ewen wrote:
        > On Sat, Jan 11, 2014 at 7:30 AM, Lynn W Deffenbaugh (Mr)
        > <kj4erj@...>wrote:
        >
        >> Yes, arbitrary (filtered) -IS to RF IGating is only in the development
        >> version
        > A controlled and defined filter would not be arbitrary*, but rather
        > reliable and steady...
        >

        Arbitrary as in left up to the choice of the IGate operator.  As opposed
        to the message gating that is basic IGate functionality.

        And even a controlled and defined filter is arbitrary because it's still
        up to the whim of the stations which can manage to match the filter
        terms, which can be anything but reliable and steady and is why I still
        need to get throughput limiting implemented.


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



        ------------------------------------

        Yahoo Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/aprsisce/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/aprsisce/join
            (Yahoo! ID required)

        <*> To change settings via email:
            aprsisce-digest@yahoogroups.com
            aprsisce-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            aprsisce-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo Groups is subject to:
            http://info.yahoo.com/legal/us/yahoo/utos/terms/







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