|
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?
|
|
|
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.
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?
|
|
|
Control i will open the gate function to send to rf.
KB3KBR Greg.
Sent from my Samsung Galaxy smartphone.
toggle quoted messageShow quoted text
-------- 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.
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?
|
|
|
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:
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)
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?
|
|
|
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.
toggle quoted messageShow quoted text
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.
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?
|
|
|
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...
toggle quoted messageShow quoted text
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.
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?
|
|
|
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
toggle quoted messageShow quoted text
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...
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.
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?
|
|
|
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...
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.
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?
|
|
|
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.
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?
|
|
|
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... 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. 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?
|
|
|
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... 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. 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?
|
|
|
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
toggle quoted messageShow quoted text
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
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...
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.
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?
|
|
|
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
toggle quoted messageShow quoted text
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
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...
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.
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?
|
|
|
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 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... 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. 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?
|
|
|
I am not sure that iPhones running the APRS.FI application will be available on APRS-IS which is where the filters work. You will need to verify before depending on it. You might be able to check this by changing your call sign to one from an iPhone. http://www.findu.com/cgi-bin/find.cgi?call=N2KGC-3 Don’t check with APRS.FI. I believe it may give you a false positive. When you find out, please post the results. Fred N7FMH
From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Brian Webster via groups.io
Sent: Monday, November 23, 2020 11:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations 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 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... 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. 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?
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|
|
|
My son-in-law has the aprs.fi app on his cellphone. It delivers
packets to the APRS-IS, but only if you have the subscription
upgrade. At least, I THINK it does. I didn't actually verify
this when we were together last week. Maybe sometime over
Christmas I'll have another chance.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
toggle quoted messageShow quoted text
On 12/5/2020 10:17 AM, Fred Hillhouse
wrote:
I
am not sure that iPhones running the APRS.FI application
will be available on APRS-IS which is where the filters
work.
You
will need to verify before depending on it.
You
might be able to check this by changing your call sign to
one from an iPhone.
http://www.findu.com/cgi-bin/find.cgi?call=N2KGC-3
Don’t
check with APRS.FI. I believe it may give you a false
positive.
When
you find out, please post the results.
Fred
N7FMH
Thanks
guys. That’s the answer we needed.
Brian
N2KGC
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
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...
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.
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?
|
|
This email has been checked for
viruses by Avast antivirus software.
www.avast.com
|
|
|
|
Hi group , aprs.fi ios application for i-phone report the position direct to aprs.fi server without passing though the aprs-is network tier2 .
you can see ve2se-i ( my iphone) on aprs.fi but not on findu.com for example
Jean-Pierre ve2se
|
|
|
