m/ filter and positions reports on RF

[Matthieu F4ACU]

Hello all,

New in this group, I live near Tours (Center of France) and I am really APRS fan :
- VHF APRX digi F4ACU-3
- Mobile and portable VX8-GE F4ACU-7
- Robust-Packet (Xastir and SCS Tracker on 10147.3) F4ACU-1
- APRSDroid F4ACU-5

Using APRS for several monthes (after years with the great Digi_Ned), I was disappointed without any "courtesy" result (position report on RF after message sent via APRS-IS).
So I have suspected and just modified the APRS-IS filter like this to allow positions reports from TCP/IP to RF :

Before :
filter t/mq

Now :
filter t/pmq

I was afraid of a avalanche of positions from APRS-IS but nothing happened.

Can someone tell me what is APRX behaviour with this filter parameter without any range limit ?

I proceeded 2 tests :

1- Position report at the same place as APRX from Android device via APRS-IS was just tarnsmitted on RF but nothing else.
2- Courtesy looks functional after a test with a german station to which I have sent a message.

Thanks in advance for your help !

73 de F4ACU
Matthieu

[Patrick Domack]

There are two issues, there is the filter you send to the aprsis
server from aprx, and then there is the filter of what aprx repeats
from aprsis to your different transmitters. We would need to know all
of them. Not sure what one that is and where you applied it.

Quoting Matthieu F4ACU <m.lapad...@gmail.com>:

> Hello all,
>
> New in this group, I live near Tours (Center of France) and I am really
> APRS fan :
> - VHF APRX digi F4ACU-3
> - Mobile and portable VX8-GE F4ACU-7
> - Robust-Packet (Xastir and SCS Tracker on 10147.3) F4ACU-1
> - APRSDroid F4ACU-5
>
> Using APRS for several monthes (after years with the great Digi_Ned), I was
> disappointed without any "courtesy" result (position report on RF after
> message sent via APRS-IS).
> So I have suspected and just modified the APRS-IS filter like this to allow
> positions reports from TCP/IP to RF :
>

> *Before : *
> *filter t/mq*
>
> *Now : *
> *filter t/pmq*

>
> I was afraid of a avalanche of positions from APRS-IS but nothing happened.
>
> Can someone tell me what is APRX behaviour with this filter parameter
> without any range limit ?
>
> I proceeded 2 tests :
>
> 1- Position report at the same place as APRX from Android device via
> APRS-IS was just tarnsmitted on RF but nothing else.
> 2- Courtesy looks functional after a test with a german station to which I
> have sent a message.
>
> Thanks in advance for your help !
>
> 73 de F4ACU
> Matthieu
>

> --
> You received this message because you are subscribed to the Google
> Groups "Aprx software" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to aprx-softwar...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matthieu F4ACU]

From APRX I have filter t/pmq set in <source> section :

    <source>
      source APRSIS
      relay-type third-party
      via-path WIDE2-2
      msg-path WIDE2-2
      filter t/pmq
    </source>

And nothing set in <aprsis> section.

Hope it is the information you expect.
Thanks Patrick for your help.

73

Matthieu F4ACU

[Patrick Domack]

Hmm, the code supports that filter, not sure what is going on.

If you define no filter there, you will digipeat everything from
aprsis server, and it's default filter will only send you packets for
messages and positions of going to stations that it hears coming in
from you. So removing that filter command should give you what you
want. It will remove the t/q function, but as it is now, you shouldn't
be receiving any q type messages from aprsis anyways.


Quoting Matthieu F4ACU <m.lapad...@gmail.com>:

> From APRX I have *filter t/pmq *set in <source> section :

>> > send an email to aprx-softwar...@googlegroups.com <javascript:>.

[Matthieu F4ACU]

So, with your explanations, I could find the pages for more details in the manual and "aprx-requirement-specification" documents. Thanks !

As you said, removing the t/pmq filter makes same results.
Any explicit filter was not necessary in addition in my case.

Now, I have to make tests to find rights filter(s) to :
- reduce APRS-IS range for Tx-Igate (no more 50 km) EXCEPT courtesy capability (no limit) ;
- do not apply any range limitation on RF.

73 de F4ACU
Matthieu

[Matthieu F4ACU]

Hello all,

After few days observing my APRX VHF digi/igate, I noticed explicit filter t/p is necessary to transmit a position report on RF (for instance to make "courtesy"), without it only messages are considered.

But with this explicit filter, I am not able to say when APRX transmit a position from APRSIS to RF or not.
For example, in the last mornings, many stations around me (further than 200 km) are transmitted from APRIS to RF but all stops in the afternoons.
So I have thought about good tropospheric conditions and positions reports from my digi igated far away after longer RF jumps.
So my hypothese is : if APRX igate "A" can read from APRSIS is own position igated by another igate "B" it transmit from IS from RF the next "B" position report.

Can anyone tell me if I am true ?

Thanks and 73 de F4ACU

Matthieu

[kd0...@gmail.com]

If you are trying to gate F4ACU-5 from APRSdroid to RF, try the sections below:

Use this section to gather positions, objects, items & weather packets from APRSIS within a 128.75 km (80 mile) radius of your digipeater-igate.
I am using the coordinates of your digi F4ACU-3.

<aprsis>
        passcode    12345                           # use YOUR own passcode for APRS-IS
        server      central.aprs2.net    14580      # T2MCI Kansas City US  (use your recommended server-port)
        filter      r/47.28583/0.794/128.75         # obtain all packets within 128.75 km radius of igate
</aprsis>

To gate F4ACU-5 from APRSIS to RF try this:

    <source>
        source        APRSIS
        relay-type    third-party

        #msg-path                                     # Use no digis for message packets
        #via-path                                     # Use no digis for 3rd party packets
        filter        -r/47.28583/0.794/-24.14        # do NOT gate positions outside 24.14 km radius of igate
        filter        b/F4ACU-5                       # gate smartphone app (internet)
    </source>

In the example above, F4ACU-5 will be gated to RF until it travels outside of the 24.14 km (15 mile) radius limit.  Because I am not using any digipeaters, the gated packets are equivalent to a repeated WIDE1-1 from a mobile station using RF.  I am not fond of using digipeaters in this section to relay gated packets.  In my vision of a perfect world, your neighboring digipeaters would be set up in a similar way so that gating only occurs inside the coverage area of their digipeater.

You'll notice there is mismatch between the radius circles between  the two subsections.....I purposely do this so that I can tweak the radius limit in the <source> subsection without changing it in the <aprsis> subsection.  I start off 'big' at the top and slice away using filters in the sections below.

There are probably multiple ways to accomplish the task, but this is what I use to get packets onto RF locally without forcing my packets into areas where my station has no value.

[Matthieu F4ACU]

Thanks for yuor interesting example with a first large filter en precise cut after un "source" section.
It is really an interesting to try and fix good rules for each digipeater.

However, I don't want to stop "courtesy" from everywhere on earth so I probably must not apply any range filter.
It is my working configuration at this moment and it works well.

So only thing missing for me is "what do APRX with position reports from APRSIS to RF without any explicit filter" ?

Have a nice Sunday.
73 de F4ACU

Matthieu

[kd0...@gmail.com]

I am not sure if the courtesy position report which follows message packets is a requirement or merely a recommendation at this point.

As an experiment, I sent a message to WXBOT for my local weather forecast last night using the 128 km filter in my <aprsis> section.  Because that filter is additive, it doesn't filter out anything APRSIS would normally send me.  In addition, I set up a filter in the <aprsis> section to block incoming position packets from APRSIS.

filter -t/p

After receiving the message, the sending station sent it's next position report approximately 20 minutes later, which appeared in my aprx-rf.log as arriving from APRSIS.  The delay leads me to believe that not all originating messaging software (if any) will send a position report immediately after message packets.  After examination of WXBOT's raw log on aprs.fi, the time stamp of the first position packet sent after my message arrived matches the time stamp in my log.  Even though there was a long delay between the message packet and position packet, APRSIS did not fail to deliver it to me, despite the originating station being well beyond my local area.   The experiment also revealed that even though I had a filter in place to block incoming position packets, the courtesy position packet bypassed that filter.

The filter above should help reduce or eliminate the avalanche of position reports gated from APRSIS to RF, but it also eliminates the possibility of gating a smartphone, or laptop.

I can see the need for a courtesy position report to aid in routing packets to the nearest RF-gate, but for the average end user, I don't see the need for it.

[Lynn W Deffenbaugh (Mr)]

The so-called "courtesy" position packet following a directed message has nothing to do with APRS-IS routing, nor is there any concept in APRS of the "nearest RF-gate".  The APRS-IS has no "routing" implementation and considers each incoming port on its own merit with no cross-port considerations (aka routing) being considered.

In fact, EVERY IGate that has delivered packets from a station will receive messages directed to that station (even if that IGate wasn't "first" to deliver a packet) and the next posit from the originator of that message for some time after the station was last heard through that IGate.  Each IGate decides on its own whether or not to put any particular packet to RF.  IGates should NOT simply gate every packet received from the APRS-IS to the local RF, but packets are supplied so that the IGate software can decide based on local information whether or not to transmit each individual packet.

The "courtesy" in this case is a courtesy to the RECEIVER of the message.  The following posit from the originator allows the message receiver to have some situational awareness of the location of the message sender that, in many cases, would not otherwise be available on the local RF.

Message origination software (at least, I can speak for my own APRSISCE/32) doesn't force a position packet just because a message was sent.  This would end up generating LOTS more posits than necessary if a lengthy, quick QSO is in progress.  The "courtesy" logic exists in the IGate port support of the APRS-IS servers and assists in determining which packets to deliver to which clients.  In point of fact, non-RF-supporting APRS-IS clients still receive messages directed to them and the following courtesy posits via this exact same logic.  The server really doesn't care (AFAIK) if the client has RF capability or not, it simply watches the source stations coming in from a port to determine which messages and posits to send back out that port.

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

[Lynn W Deffenbaugh (Mr)]

And to answer your initial line, http://www.aprs-is.net/IGating.aspx states:

An IGate (Internet Gateway) has two functions: ...and to pass all message packets destined for local stations to RF (if a bidirectional IGate).

and then the definition of "all message packets" (emphasis mine):

Passing all message packets also includes passing the sending station's position along with the message. When APRS-IS was small, we did this using historical position packets. This has become problematic as it introduces historical data on to RF. The IGate should note the station(s) it has gated messages to RF for and pass the next position packet seen for that station(s) to RF.

So the APRS-IS servers need to forward the next posit of the originating station because the IGate is supposed to forward it onto the local RF.  The time delay is because historical posits are no longer used, but the server waits for the sender's next posit packet.  This also implies that a posit doesn't need to be forced by a client after a message is sent because one will (eventually) be forthcoming anyway.

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


On 8/8/2018 10:13 AM, kd0...@gmail.com wrote: