Date   
Re: Filters

Julian
 

Re 'kill'. Sorry to hear that.

Using a software modem aka SoundModem by UZ7HO is much more rewarding. It also decodes many more packets than a regular TNC (see the DireWolf manual on how this is achieved). AGW is also there.
You have got to install SoundModem preferably on your APRSIS32 PC and ditch the TNC. The Audio to/from radio now goes through the PC soundcard , PTT via RTS or DTR with the help of a  serial port. Other variants are also possible, SignaLink, external or rig soundcard etc.

Re KISS, https://www.scc-ares-races.org/data/packet/docs/NOSintro.pdf pages 39 (44 in the PDF) and 42 (47 in the PDF) can shed light upon the matter.

73 de J


M     Y
0     O
I      3
P    F
U    C
      A

Re: Digipeater path

Lynn Deffenbaugh
 

I don't think Timothy is running AS  digipeater, but is referring to what path to use to REQUEST digipeater support.

The general rule is WIDE1-1,WIDE2-1 for mobile stations that might need the assistance of a low-level (read: WIDE1) digipeater.  For a fixed station, WIDE2-1 is more likely, unless you're fixed way down in a hole somewhere and need the local WIDE1 digipeater's boost to get out to the rest of the world.

In some more remote areas, WIDE1-1,WIDE2-2 (mobile) or just WIDE2-2 (fixed station) might be appropriate.

The specific answer would require a more complete knowledge of your local RF infrastructure and topology.

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

On 3/26/2020 3:06 PM, AE5IB (Kip) wrote:
If you are a digipeater you should not be running WIDE1-1 because that
is for stations that cannot hit a regular WIDE2 digipeater. Since you
are already a digipeater you are not useful if you cannot hit a WIDE2
digipeater.

Again since you are a Digipeater you do not need your signal repeated
multiple times. You should be just WIDE2-1.

So you are close to being correct.

Kip
AE5IB

On Thu, Mar 26, 2020 at 1:35 PM Timothy Bonnell via Groups.Io
<w9ntn=yahoo.com@groups.io> wrote:
Hello,
What should I be using for my digipeater path?
I’m currently using wide1-1,wide2-1
Tyia

W9ntn
Timothy Bonnell


Re: Digipeater path

AE5IB (Kip)
 

If you are a digipeater you should not be running WIDE1-1 because that
is for stations that cannot hit a regular WIDE2 digipeater. Since you
are already a digipeater you are not useful if you cannot hit a WIDE2
digipeater.

Again since you are a Digipeater you do not need your signal repeated
multiple times. You should be just WIDE2-1.

So you are close to being correct.

Kip
AE5IB

On Thu, Mar 26, 2020 at 1:35 PM Timothy Bonnell via Groups.Io
<w9ntn=yahoo.com@groups.io> wrote:

Hello,
What should I be using for my digipeater path?
I’m currently using wide1-1,wide2-1
Tyia

W9ntn
Timothy Bonnell


Re: Filters

Arnold Harding. - KQ6DI
 

Now I understand where 'Kill' is.  It is in YOUR own Object.  When you remove it (from yourself), do you want it to just time-out from others screens, or be removed instantly (Kill).  So it only works on Objects you make.
Arnold, KQ6DI

On March 26, 2020 at 11:25 AM Julian <iulianp@...> wrote:

Hi Min. No shouting - no worries! He he.
Hi agn Arnold.

For some unknown reason I was going more into digipeat blocking rather than showing or not stuff on the APRSIS32 screen. I don't know abt 'kill'. I have never used it. There are some features in APRSIS32 I have never used, sat, DFs etc. The manual states, "Kill Flag. Selecting this tick box, will send out a kill request and remove the object from all receiving stations maps". Object, hmm. Could be.

Arnold, 'kill', as far as I remember is on a Left or Right Click on an object etc. I haven't used APRSIS32 for few months now.

TNC in KISS won't block anything. It has to be a software modem which provides some sort of intelligence, SoundModem or DireWolf.

Pigeons. Roger on the GPS fact, however you've still got to teach them to dive into that antenna, at high speed! ;)

73 de J, M zero IPU/M, YO three FCA.


 

Re: Filters

KE6BB
 

Kill shows up when in the pop-up menu that appears when you click on the station you want to kill.  It really says “Kill Station”.  I have used that in the past, but I **THINK** the station shows up again when it sends a new beacon.  You might want to test that because my memory isn’t what it used to be.  I believe it doesn’t care if the station came from RF or the IS.

 

I think what Arnold is asking for is something possibly like this:

 

A button on the VIEW>CHOOSER menu, possibly in the “Space 4 Rent” spot, that says something like “Don’t View”.  When clicked, it would open up a menu where station calls/SSID’s that the user DOESN’T want to show up on the screen could be listed, along with an “ENABLE” checkbox.  When enabled, that station/ssid would NOT show on the screen.  This is similar to the way you can screen what symbols you want to see or not using the VIEW menu.  It would not block other APRSIS32 functions such as IGATE and Digi.  It would not remove the station/ssid from internal APRSIS32 lists so that it could immediately be disabled and the stations would reappear.  That way the program would continue to maintain conformance to the APRS specification but be more flexible.  That would be a feature request, NOT a bug report.

 

Just my thoughts.  They are free, so take them for what they are worth.

 

Mark,

KE6BB

 

 

 

From: Arnold Harding. - KQ6DI
Sent: Thursday, March 26, 2020 11:08 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Filters

 

Where is "Kill" ?  And does this work on received RF?  or just on IS feed?

Arnold, KQ6DI

On March 26, 2020 at 10:50 AM "Min via Groups.Io" <mins@...> wrote:

If I'm wrong don't shout. 

 

Does Kill not block a receiving a station ?

Min G0JMS

 

On 26 Mar 2020 17:26, Julian <iulianp@...> wrote:

Hi Arnold. You may be in luck, depending on how you're feeding the packets into APRSIS32. SoundModem for ex has a blocking feature in its ini file, just enter callsigns etc the in the appropriate field. Packets from those stns will be discarded before reaching APRSIS32.  RF blocking is considered unethical and the best solution is to liaison with the other party. It also depends on your initial/subsequent approach(es). Some people get easily offended. I am aware that in some cases a shrink may be needed and there is almost nothing you can do... Possibly sending an army of trained pigeons to target the offending antenna?.... He he.
73 and good luck de J.     M zero IPU, YO three FCA.

 


 

 

Digipeater path

Timothy Bonnell
 

Hello,
What should I be using for my digipeater path?
I’m currently using wide1-1,wide2-1
Tyia

W9ntn
Timothy Bonnell

Re: Filters

Julian
 

Hi Min. No shouting - no worries! He he.
Hi agn Arnold.

For some unknown reason I was going more into digipeat blocking rather than showing or not stuff on the APRSIS32 screen. I don't know abt 'kill'. I have never used it. There are some features in APRSIS32 I have never used, sat, DFs etc. The manual states, "Kill Flag. Selecting this tick box, will send out a kill request and remove the object from all receiving stations maps". Object, hmm. Could be.

Arnold, 'kill', as far as I remember is on a Left or Right Click on an object etc. I haven't used APRSIS32 for few months now.

TNC in KISS won't block anything. It has to be a software modem which provides some sort of intelligence, SoundModem or DireWolf.

Pigeons. Roger on the GPS fact, however you've still got to teach them to dive into that antenna, at high speed! ;)

73 de J, M zero IPU/M, YO three FCA.

Re: Filters

Arnold Harding. - KQ6DI
 

Where is "Kill" ?  And does this work on received RF?  or just on IS feed?
Arnold, KQ6DI

On March 26, 2020 at 10:50 AM "Min via Groups.Io" <mins@...> wrote:

If I'm wrong don't shout. 

Does Kill not block a receiving a station ?

Min G0JMS


On 26 Mar 2020 17:26, Julian <iulianp@...> wrote:

Hi Arnold. You may be in luck, depending on how you're feeding the packets into APRSIS32. SoundModem for ex has a blocking feature in its ini file, just enter callsigns etc the in the appropriate field. Packets from those stns will be discarded before reaching APRSIS32.  RF blocking is considered unethical and the best solution is to liaison with the other party. It also depends on your initial/subsequent approach(es). Some people get easily offended. I am aware that in some cases a shrink may be needed and there is almost nothing you can do... Possibly sending an army of trained pigeons to target the offending antenna?.... He he.
73 and good luck de J.     M zero IPU, YO three FCA.



 

Re: Filters

Arnold Harding. - KQ6DI
 

I always try nice, plus education, plus the understanding that I don't know the true goal of any APRS operator.  Maybe it's something being attempted that isn't obvious.  But (for example) when it's a simple programming error of a tracker, and the owner could care less, then it becomes a problem.  And it takes a while to exchange emails to fix the issue.  Fixing is the preferred method, but what if it happens "today"?
When someone has a home station, or simply forgets to turn off a tracker, and just happens to be next to a checkpoint that desired stations/trackers stop at, then everybody gets lost in the "noise" on the screen at that spot.  Shrieks work here, but only after ALL desired stations are entered.  So I may have 20 to enter into Shrieks, or one to block.  Pick the quicker...
Arnold, KQ6DI

On March 26, 2020 at 10:41 AM Justin Cherington <huntjlc@...> wrote:

I would agree a contact attempt should be made to nicely educate. Once that fails, I vote block. Especially if they are using one way trackers or not monitoring aprs. That’s the antithesis of the system and has a demonstrably negative impact on others. 

 

Re: Filters

Min
 

If I'm wrong don't shout. 

Does Kill not block a receiving a station ?

Min G0JMS


On 26 Mar 2020 17:26, Julian <iulianp@...> wrote:

Hi Arnold. You may be in luck, depending on how you're feeding the packets into APRSIS32. SoundModem for ex has a blocking feature in its ini file, just enter callsigns etc the in the appropriate field. Packets from those stns will be discarded before reaching APRSIS32.  RF blocking is considered unethical and the best solution is to liaison with the other party. It also depends on your initial/subsequent approach(es). Some people get easily offended. I am aware that in some cases a shrink may be needed and there is almost nothing you can do... Possibly sending an army of trained pigeons to target the offending antenna?.... He he.
73 and good luck de J.     M zero IPU, YO three FCA.


Re: Filters

Justin Cherington
 

I would agree a contact attempt should be made to nicely educate. Once that fails, I vote block. Especially if they are using one way trackers or not monitoring aprs. That’s the antithesis of the system and has a demonstrably negative impact on others. 

Re: Filters

Arnold Harding. - KQ6DI
 

Julian,
I've used a KPC-3 in the past, and it has the LList command which blocks listed stations.  (I'm not sure if it blocks with KISS.)
I use Direwolf either in the PC with APRSIS32 or external in a Raspberry Pi (and local network), but Direwolf won't block anything in the KISS path.
So we do see that the KPC-3 and SoundModem have blocking ability...  But not APRSIS32...
RF blocking is considered unethical only when it is in an IGate configuration.  I'm just trying to keep it off of my personal screen, and not need to jump through too many hoops at the same time.

( Pigeons wouldn't need much training when we have GPS coordinates.)
Arnold, KQ6DI

On March 26, 2020 at 10:26 AM Julian <iulianp@...> wrote:

Hi Arnold. You may be in luck, depending on how you're feeding the packets into APRSIS32. SoundModem for ex has a blocking feature in its ini file, just enter callsigns etc the in the appropriate field. Packets from those stns will be discarded before reaching APRSIS32.  RF blocking is considered unethical and the best solution is to liaison with the other party. It also depends on your initial/subsequent approach(es). Some people get easily offended. I am aware that in some cases a shrink may be needed and there is almost nothing you can do... Possibly sending an army of trained pigeons to target the offending antenna?.... He he.
73 and good luck de J.     M zero IPU, YO three FCA.


 

Re: Filters

Julian
 

Hi Arnold. You may be in luck, depending on how you're feeding the packets into APRSIS32. SoundModem for ex has a blocking feature in its ini file, just enter callsigns etc the in the appropriate field. Packets from those stns will be discarded before reaching APRSIS32.  RF blocking is considered unethical and the best solution is to liaison with the other party. It also depends on your initial/subsequent approach(es). Some people get easily offended. I am aware that in some cases a shrink may be needed and there is almost nothing you can do... Possibly sending an army of trained pigeons to target the offending antenna?.... He he.
73 and good luck de J.     M zero IPU, YO three FCA.

Re: Filters

Randy Love
 

You can filter what you show locally on your screen by the use of Tactical Nicknames.
These can be set in your instance and shared over-air to others in your group.

This is all done on your computer... no need to have operators in your event that already have APRS set up re-configure for the event.

I can't dig up all the details now, but you can set them in Screen > Labels > Nicknames.
When you set up a Nickname, you can add a Shriek to it ( !MYEVENT!, we use !MS150! for our MS bike events ) 
then filter your display based on the Shriek by choosing it in View > Shrieks

That's the overview, Lynn probably has a canned message to send out that details more specifics.

73,
Randy
WF5X



On Thu, Mar 26, 2020 at 10:06 AM Greg Andal via Groups.Io <captgrega=yahoo.com@groups.io> wrote:
cken cry babby




On Wed, Mar 25, 2020 at 23:15, Arnold Harding. - KQ6DI
<kq6di@...> wrote:
Lynn,
Please, Please provide some way to filter stations on RF.  At the moment there is no way to ignore a station sending garbage on RF all day long with WIDE1-1, WIDE2-2.  I have tried sending polite emails to the owner of the stations, and he does reply basically to say he will ignore my request.  I have contacted Official Observers who are also having the same issue from the station only to have it turned off for one month. 
I don't need random objects, shapes and all other sorts of things appearing on my map when I'm trying to use APRSISCE/32 to support an event, but without a way to ignore a station, APRSIS32 just displays the garbage on my screen.
APRSIS32 works great in the field, not able to connect to the internet, EXCEPT for anyone spewing garbage onto the screen.

Please, please consider this a BUG in APRSIS32, and provide us some way to ignore anything coming from a station.

Arnold, KQ6DI

On March 25, 2020 at 8:22 PM Lynn Deffenbaugh <kj4erj@...> wrote:

See http://aprsisce.wikidot.com/doc:automatic-filters for a full description of APRSIS32 automatic filters.

The m/ and r/ filters are automatic, but the 9 comes from your Configure / General / Range which is specified in 1/10 miles, but goes out in the filter as kilometers.

Rest easy, the filter only applies to what the APRS-IS will be sending to you, not what you will be gating to the APRS-IS.  APRSIS32 adheres to the IGate specification at http://www.aprs-is.net/IGateDetails.aspx, specifically:

 

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

  1. (AX.25 RF) The packet does not have a control field of 0x03 or a PID of 0xf0.
  2. The TNC has PASSALL turned on.
  3. 3rd-party packets (data type } ) with TCPIP or TCPXX in the 3rd party header.
    3rd-party packets without TCPXX or TCPIP mnust have the RF header and the 3rd party data type stripped before passing to APRS-IS.
  4. generic queries (data type ? ).
  5. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).
Note that there is no provision for "black-listing" stations.  If you copy it on an RF-type port and none of the above conditions are true, then the packet will be gated to the APRS-IS.  Assuming, of course, that you have the appropriate enables on both the RF and APRS-IS port.

 

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

On 3/25/2020 8:44 PM, Justin Cherington wrote:
Ok, I have used filters in Direwolf but am trying it in aprsis32 for the first time.  I entered two -b filters for two calls signs that involve pilots just swamping the area almost daily with 30 second beacon rates and WIDE1-1, WIDE2-1 paths.  I entered them in the Configure>General>add filters box.  I wish to ignore these guys and not gate them in either direction.

I then surprisingly got a pop up box (attached) that showed what I entered but also what looks like a 9 mile range filter around my location.  We have mountain top digis here with 80 mile ranges, (I decode them 50+ miles away all day) so I want to make sure I am not neglecting to gate some packets needlessly.  Or does the m/9 filter mean something altogether different?  I did not enter that so I assume it is one of the auto filters.  Thanks!


 

Re: Filters

Greg Andal <captgrega@...>
 

cken cry babby




On Wed, Mar 25, 2020 at 23:15, Arnold Harding. - KQ6DI
<kq6di@...> wrote:
Lynn,
Please, Please provide some way to filter stations on RF.  At the moment there is no way to ignore a station sending garbage on RF all day long with WIDE1-1, WIDE2-2.  I have tried sending polite emails to the owner of the stations, and he does reply basically to say he will ignore my request.  I have contacted Official Observers who are also having the same issue from the station only to have it turned off for one month. 
I don't need random objects, shapes and all other sorts of things appearing on my map when I'm trying to use APRSISCE/32 to support an event, but without a way to ignore a station, APRSIS32 just displays the garbage on my screen.
APRSIS32 works great in the field, not able to connect to the internet, EXCEPT for anyone spewing garbage onto the screen.

Please, please consider this a BUG in APRSIS32, and provide us some way to ignore anything coming from a station.

Arnold, KQ6DI

On March 25, 2020 at 8:22 PM Lynn Deffenbaugh <kj4erj@...> wrote:

See http://aprsisce.wikidot.com/doc:automatic-filters for a full description of APRSIS32 automatic filters.

The m/ and r/ filters are automatic, but the 9 comes from your Configure / General / Range which is specified in 1/10 miles, but goes out in the filter as kilometers.

Rest easy, the filter only applies to what the APRS-IS will be sending to you, not what you will be gating to the APRS-IS.  APRSIS32 adheres to the IGate specification at http://www.aprs-is.net/IGateDetails.aspx, specifically:

 

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

  1. (AX.25 RF) The packet does not have a control field of 0x03 or a PID of 0xf0.
  2. The TNC has PASSALL turned on.
  3. 3rd-party packets (data type } ) with TCPIP or TCPXX in the 3rd party header.
    3rd-party packets without TCPXX or TCPIP mnust have the RF header and the 3rd party data type stripped before passing to APRS-IS.
  4. generic queries (data type ? ).
  5. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).
Note that there is no provision for "black-listing" stations.  If you copy it on an RF-type port and none of the above conditions are true, then the packet will be gated to the APRS-IS.  Assuming, of course, that you have the appropriate enables on both the RF and APRS-IS port.

 

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

On 3/25/2020 8:44 PM, Justin Cherington wrote:
Ok, I have used filters in Direwolf but am trying it in aprsis32 for the first time.  I entered two -b filters for two calls signs that involve pilots just swamping the area almost daily with 30 second beacon rates and WIDE1-1, WIDE2-1 paths.  I entered them in the Configure>General>add filters box.  I wish to ignore these guys and not gate them in either direction.

I then surprisingly got a pop up box (attached) that showed what I entered but also what looks like a 9 mile range filter around my location.  We have mountain top digis here with 80 mile ranges, (I decode them 50+ miles away all day) so I want to make sure I am not neglecting to gate some packets needlessly.  Or does the m/9 filter mean something altogether different?  I did not enter that so I assume it is one of the auto filters.  Thanks!


 

Filters

Arnold Harding. - KQ6DI
 

Lynn,
Please, Please provide some way to filter stations on RF.  At the moment there is no way to ignore a station sending garbage on RF all day long with WIDE1-1, WIDE2-2.  I have tried sending polite emails to the owner of the stations, and he does reply basically to say he will ignore my request.  I have contacted Official Observers who are also having the same issue from the station only to have it turned off for one month. 
I don't need random objects, shapes and all other sorts of things appearing on my map when I'm trying to use APRSISCE/32 to support an event, but without a way to ignore a station, APRSIS32 just displays the garbage on my screen.
APRSIS32 works great in the field, not able to connect to the internet, EXCEPT for anyone spewing garbage onto the screen.

Please, please consider this a BUG in APRSIS32, and provide us some way to ignore anything coming from a station.

Arnold, KQ6DI

On March 25, 2020 at 8:22 PM Lynn Deffenbaugh <kj4erj@...> wrote:

See http://aprsisce.wikidot.com/doc:automatic-filters for a full description of APRSIS32 automatic filters.

The m/ and r/ filters are automatic, but the 9 comes from your Configure / General / Range which is specified in 1/10 miles, but goes out in the filter as kilometers.

Rest easy, the filter only applies to what the APRS-IS will be sending to you, not what you will be gating to the APRS-IS.  APRSIS32 adheres to the IGate specification at http://www.aprs-is.net/IGateDetails.aspx, specifically:

 

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

  1. (AX.25 RF) The packet does not have a control field of 0x03 or a PID of 0xf0.
  2. The TNC has PASSALL turned on.
  3. 3rd-party packets (data type } ) with TCPIP or TCPXX in the 3rd party header.
    3rd-party packets without TCPXX or TCPIP mnust have the RF header and the 3rd party data type stripped before passing to APRS-IS.
  4. generic queries (data type ? ).
  5. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).
Note that there is no provision for "black-listing" stations.  If you copy it on an RF-type port and none of the above conditions are true, then the packet will be gated to the APRS-IS.  Assuming, of course, that you have the appropriate enables on both the RF and APRS-IS port.

 

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

On 3/25/2020 8:44 PM, Justin Cherington wrote:
Ok, I have used filters in Direwolf but am trying it in aprsis32 for the first time.  I entered two -b filters for two calls signs that involve pilots just swamping the area almost daily with 30 second beacon rates and WIDE1-1, WIDE2-1 paths.  I entered them in the Configure>General>add filters box.  I wish to ignore these guys and not gate them in either direction.

I then surprisingly got a pop up box (attached) that showed what I entered but also what looks like a 9 mile range filter around my location.  We have mountain top digis here with 80 mile ranges, (I decode them 50+ miles away all day) so I want to make sure I am not neglecting to gate some packets needlessly.  Or does the m/9 filter mean something altogether different?  I did not enter that so I assume it is one of the auto filters.  Thanks!


 

Re: Fun with filters (Really just some questions)

Justin Cherington
 

Ok thanks for the info. I was hoping that I could blacklist, we’ve got lots of people who abuse aprs and aren’t interested in learning. The -b filter was helpful in the past but I like your software enough to get over it. 


sounds like RF to IS isn’t really customizable, but IS to RF is? I thought I saw in the docs that creating a satgate was possible. In that scenario you wouldn’t want to gate directly heard RF, only that which was digipeated by the sat. 

Re: Fun with filters (Really just some questions)

Lynn Deffenbaugh
 

See http://aprsisce.wikidot.com/doc:automatic-filters for a full description of APRSIS32 automatic filters.

The m/ and r/ filters are automatic, but the 9 comes from your Configure / General / Range which is specified in 1/10 miles, but goes out in the filter as kilometers.

Rest easy, the filter only applies to what the APRS-IS will be sending to you, not what you will be gating to the APRS-IS.  APRSIS32 adheres to the IGate specification at http://www.aprs-is.net/IGateDetails.aspx, specifically:

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

  1. (AX.25 RF) The packet does not have a control field of 0x03 or a PID of 0xf0.
  2. The TNC has PASSALL turned on.
  3. 3rd-party packets (data type } ) with TCPIP or TCPXX in the 3rd party header.
    3rd-party packets without TCPXX or TCPIP mnust have the RF header and the 3rd party data type stripped before passing to APRS-IS.
  4. generic queries (data type ? ).
  5. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).
Note that there is no provision for "black-listing" stations.  If you copy it on an RF-type port and none of the above conditions are true, then the packet will be gated to the APRS-IS.  Assuming, of course, that you have the appropriate enables on both the RF and APRS-IS port.

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

On 3/25/2020 8:44 PM, Justin Cherington wrote:
Ok, I have used filters in Direwolf but am trying it in aprsis32 for the first time.  I entered two -b filters for two calls signs that involve pilots just swamping the area almost daily with 30 second beacon rates and WIDE1-1, WIDE2-1 paths.  I entered them in the Configure>General>add filters box.  I wish to ignore these guys and not gate them in either direction.

I then surprisingly got a pop up box (attached) that showed what I entered but also what looks like a 9 mile range filter around my location.  We have mountain top digis here with 80 mile ranges, (I decode them 50+ miles away all day) so I want to make sure I am not neglecting to gate some packets needlessly.  Or does the m/9 filter mean something altogether different?  I did not enter that so I assume it is one of the auto filters.  Thanks!

Fun with filters (Really just some questions)

Justin Cherington
 

Ok, I have used filters in Direwolf but am trying it in aprsis32 for the first time.  I entered two -b filters for two calls signs that involve pilots just swamping the area almost daily with 30 second beacon rates and WIDE1-1, WIDE2-1 paths.  I entered them in the Configure>General>add filters box.  I wish to ignore these guys and not gate them in either direction.

I then surprisingly got a pop up box (attached) that showed what I entered but also what looks like a 9 mile range filter around my location.  We have mountain top digis here with 80 mile ranges, (I decode them 50+ miles away all day) so I want to make sure I am not neglecting to gate some packets needlessly.  Or does the m/9 filter mean something altogether different?  I did not enter that so I assume it is one of the auto filters.  Thanks!

Re: Map Opacity (was: Maps)

ve6frc@...
 

Thanks for the instructions on the maps and options that will show on the screen.



Thanks again.
Fred