Date   

Re: Internet only stations

Brian Webster
 

Thanks guys. That’s the answer we needed.

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Monday, November 23, 2020 10:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

Oh, and to filter for only APRS-IS direct packets, add a +d/TCPIP which restricts the matching packets to only those with TCPIP in their "digipeater" path.

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

On 11/23/2020 10:44 AM, Lynn Deffenbaugh wrote:

And if you want to only include position packets (likely), add a "+t/p" to the buddy filter, separated by a space.  Otherwise you'll end up gating ALL packets from the buddy stations which is probably more than you're interested in if those stations happen to generate telemetry or inject objects to the APRS-IS.

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

On 11/23/2020 10:25 AM, Rob Giuliano via groups.io wrote:

That question was answered as part of the thread (slightly edited):

 

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

 

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up

 or just find see if you hit a limit.

 

Robert Giuliano
KB8RCO

 

 

On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:

 

 

The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Lynn Deffenbaugh
 

Oh, and to filter for only APRS-IS direct packets, add a +d/TCPIP which restricts the matching packets to only those with TCPIP in their "digipeater" path.

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


On 11/23/2020 10:44 AM, Lynn Deffenbaugh wrote:

And if you want to only include position packets (likely), add a "+t/p" to the buddy filter, separated by a space.  Otherwise you'll end up gating ALL packets from the buddy stations which is probably more than you're interested in if those stations happen to generate telemetry or inject objects to the APRS-IS.

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


On 11/23/2020 10:25 AM, Rob Giuliano via groups.io wrote:
That question was answered as part of the thread (slightly edited):

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up
 or just find see if you hit a limit.

Robert Giuliano
KB8RCO


On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:


The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Lynn Deffenbaugh
 

And if you want to only include position packets (likely), add a "+t/p" to the buddy filter, separated by a space.  Otherwise you'll end up gating ALL packets from the buddy stations which is probably more than you're interested in if those stations happen to generate telemetry or inject objects to the APRS-IS.

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


On 11/23/2020 10:25 AM, Rob Giuliano via groups.io wrote:
That question was answered as part of the thread (slightly edited):

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS +t/p" ... . 
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS +t/p

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up
 or just find see if you hit a limit.

Robert Giuliano
KB8RCO


On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:


The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Rob Giuliano
 

That question was answered as part of the thread (slightly edited):

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS" ... . 
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up
 or just find see if you hit a limit.

Robert Giuliano
KB8RCO


On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:


The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Firenet connection types noted

Lynn Deffenbaugh
 

The original question is probably better asked directly in the firenet support group.  See https://groups.io/g/aprsfirenet

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


Re: Firenet connection types noted

Glenn O'Connor
 

Anyone care to respond to the above?


Re: Internet only stations

Brian Webster
 

The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Christopher Rose <kb8uih88@...>
 

There is a program or app for android phones call aprs droid. Subscription serv8ce I think. That will use data from your phone to cell towers to send position reports to internet, and to aprs.fi. Don't know it it works on I phones or if there is also an I phone app to do the same thing




Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Greg Depew <goatherder_4891@...>
Date: 11/22/20 2:37 PM (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

Control i will open the gate function to send to rf. 



KB3KBR Greg.
Sent from my Samsung Galaxy smartphone.



-------- Original message --------
From: "Rob Giuliano via groups.io" <kb8rco@...>
Date: 11/22/20 12:35 (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Arnold Harding - KQ6DI
 

I keep most non-APRS stations off my map with
-u/APBM*/APDG*/APWL*/APJI*
This also prevents my IGate from sending positions from these stations (even though it's DireWolf).
 
I hadn't thought about eliminating weather as well.
Arnold, KQ6DI

On 11/22/2020 2:05 PM Lynn Deffenbaugh <kj4erj@...> wrote:
 
 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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


On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
 
PS.  Here's some of the packets you would probably NOT want to gate to RF:
 
WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz
 
And during that short time span, this is the only one that MAYBE you'd want to pass along...
 
WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com
 
On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
 
PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:
I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.
 
One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.
 
I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 
 
On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:
 
 
On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Not Receiving Reports from WXSVR-AU

Peter VK3PYE
 

On Sun, Nov 22, 2020 at 11:11 PM, Lynn Deffenbaugh wrote:
But of course, we expect your only answer to come from WHO-15, not WHO-IS.
Correct. I tried that, and only got a response from WHO-15.

I have learnt a little more about this hobby of ours.

Thanks for your help and the very nice APRSIS32 program. 
--

7 3 de Pete VK3PYE / VK3YPE


Re: Internet only stations

Lynn Deffenbaugh
 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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


On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

PS.  Here's some of the packets you would probably NOT want to gate to RF:

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

And during that short time span, this is the only one that MAYBE you'd want to pass along...

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:
I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Lynn Deffenbaugh
 

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

PS.  Here's some of the packets you would probably NOT want to gate to RF:

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

And during that short time span, this is the only one that MAYBE you'd want to pass along...

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:
I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Lynn Deffenbaugh
 

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:
I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Lynn Deffenbaugh
 

The aprs.fi app on the iPhone platform is aprs.fi ONLY!  It does not (last I knew) pass any traffic through to the APRS-IS.  As it says in the app store listing at https://apps.apple.com/us/app/aprs-fi/id922155038

• Beacon your position on aprs.fi

Read that CAREFULLY!  And as one review stated:

MrWzrd2,

Not what I consider APRS

Wasted my money on an app calling itself aprs.... that does not talk to any aprs not using aprs-fi.

Packets are NOT transmitted into the aprs network so you can not be heard by hams monitoring. This fact is buried derp in the about section of the app. It should be stated plainly on the app store page. Would never had purchased it if this fact was known.

Lake of this ability completely destroys all the features it has. ( like a Cadillac without wheels... all the plush in the world but the deal breaker is it cannot move)

Developer Response,

I’m sorry it got you by a surprise. The app description on the store does say it beacons to aprs.fi specifically.


Version 2.0 adds a new Extra Features subscription package which includes APRS-IS beaconing, APRS text messaging and a DSP audio modem, and a few smaller things!

But apparently this IS now included in the subscription package where it does say:

• APRS-IS beaconing, with up to 10 callsign profiles

So, presuming your "but the cellphone only stations while showing on aprs.fi" were actually iPhone users using the aprs.fi app, there is nothing to be done for it.

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



On 11/22/2020 11:51 AM, John Rudolph wrote:
On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Greg Depew
 

Control i will open the gate function to send to rf. 



KB3KBR Greg.
Sent from my Samsung Galaxy smartphone.



-------- Original message --------
From: "Rob Giuliano via groups.io" <kb8rco@...>
Date: 11/22/20 12:35 (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Internet only stations

Rob Giuliano
 

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.
  <Ctrl>G   and set a filter to limited what goes from IS to RF
This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO



On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:


On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Internet only stations

John Rudolph
 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?


Re: Not Receiving Reports from WXSVR-AU

Lynn Deffenbaugh
 

As expected, the one to WHO-15 received a response and WHO-IS did not.  To simplify the test, don't include the "f", but go for the single line response.  And it's only a callsign, but a true amateur radio callsign, that you send, not a full callsign-SSID.  So just sent "VK3YPE" or "VK3PYE" and you should get something like:

07:09:47  New Chat Between KJ4ERJ and WHO-IS on 2020-11-22
07:09:54> VK3YPE
07:09:55< Peter J Edrupt/Australia (*2-07:09:55)
07:10:01> VK3PYE
07:10:01< Peter J Edrupt/Australia (*2-07:10:01)

But of course, we expect your only answer to come from WHO-15, not WHO-IS.

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



On 11/22/2020 12:07 AM, Peter VK3PYE wrote:
I have sent off two APRS messages, one to each callsign. Here are the results ...



:-)
--

7 3 de Pete VK3PYE / VK3YPE


Re: Not Receiving Reports from WXSVR-AU

Peter VK3PYE
 

I have sent off two APRS messages, one to each callsign. Here are the results ...



:-)
--

7 3 de Pete VK3PYE / VK3YPE


Re: Not Receiving Reports from WXSVR-AU

Lynn Deffenbaugh
 

To talk to WHO-IS and/or WHO-15, just send an APRS message to that callsign-SSID with a single callsign in the body.  It will respond with information about that call's owner.  If you precede the call with "f " (F space) it will return "full" information. For instance:

23:11:37  New Chat Between KJ4ERJ and WHO-IS on 2020-11-21
23:11:40> VK3PYE
23:11:41< Peter J Edrupt/Australia (*2-23:11:41)
23:11:43> f VK3PYE
23:11:44< VK3PYE:Peter J Edrupt (*2-23:11:44)
        < VK3PYE:Melbourne Australia (*2-23:11:44)

Just do one message to WHO-IS and another to WHO-15.  My suspicion is that WHO-15 will be answered and WHO-IS will not be.

Ask the custodian what software/hardware their VK3RSA-1 IGate is running and where one can get support for said IGate functionality.  And you could ask them to run the same RF test through their IGate so that they themselves see the issue.

The easiest way would be with a Kenwood APRS radio while watching their IGate logs, if it has any with requests sent to WHO-IS and WHO-15.

Of course, as you know, Yaesu APRS radios can only send to AX.25 -SSIDs, so they would never see any issues with WHO-IS (or WXSVR-AU) because they could never initiate the original request.

As for VK3RMD-1, your Direwolf simply heard your own packet digipeated by that station over RF.   The messages are being injected into the APRS-IS by VK3RSA-1 with no paths used, so any other digipeated copies of the same packet will be dropped by the APRS-IS duplicate suppression.

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


On 11/21/2020 9:59 PM, Peter VK3PYE wrote:
Hi Lynn.

Correct on the station setup. The radio is just doing the RF part. My station is capable of using APRS-IS, but I have it disabled while trying to figure out why I'm not receiving return packets from WXSVR-AU. And yes, I have added the "dash 15" to my station callsign. I thought that it may have been why I was not receiving those packets, but it has not made any difference. Still nothing back via RF.

I had also asked the same question to the Australian APRS Users group, and received this reply from "the custodian of the VK3RSA-1 iGate".

-- VK3RSA-1
APRS-!S messages to local RF:
Gate messages to local RF: = Yes
Message path: = WIDE2-1
Local RF heard max. digi-hops: = 2
Local RF heard buffer timeout (m): = 30


Regarding your request : " try sending a callsign lookup to WHO-15 and WHO-IS.", how do I go about doing that



For a quick test, I just enabled APRS-IS and sent a request to the WXSVR-AU server and received this reply ...




So, I can receive the replies via the Internet, but that would not be much use for anyone that is camping away from the city with no Internet available to them.

One other thing that I have just noticed, and I am trying to understand the direwolf output, is that, while the requests to the WXBOT server were returned via VK3RSA-1, and I received those request responses via RF OK, the requests to the WXSVR-AU server, are showing in my screen grabs as coming via VK3RMD-1, so maybe it is VK3RMD-1 that has the issue? Just my thoughts ...

Thanks for your help. 
-----
7 3 de Pete VK3PYE / VK3YPE

661 - 680 of 35661