Date   

Re: Blocking a digipeater from digi'ing my beacon

Arnold Harding - KQ6DI
 

There is also a problem of not using WIDE1-1.  In Northern California, a majority of the digipeaters do not respond to anything more than WIDE1-1,  So if your mobile has a path of WIDE2-1, you will get very few of your position reports ever being heard.  I realize that is contrary to the desired plan, but that's the way it is in this entire area.
Arnold, KQ6DI

On October 24, 2019 at 12:39 PM James Ewen <ve6srv@...> wrote:

And to clarify another point, no fixed station should be using WIDE1-1 as a hop request. 

WIDE1-1 is intended to be used as a request from low powered stations for an extra helping hand from home stations to get heard by the main digipeaters (if required). 

Improper use of WIDE1-1 as a first hop request by high powered stations such as mobiles and home stations causes excessive local digipeats by home stations, and possible dupes by main digipeaters. 

People using WIDE1-1 improperly can make others attempting to act on WIDE1-1 to improve the digipeater network shut down their home WIDE1-1 digipeaters because of abuse and interference, thereby ruining the network for all. 

All digipeaters *should* respond to their assigned callsign/alias if implemented properly. 

Furthermore, if you are attempting to observe whether the RF network is working properly, you should observe the activity of the RF network directly by looking at what you can hear/see on the RF network. 

Don’t attempt to observe the RF network by looking at what you can see on APRS-IS connected sites like APRS.fi or other online sites. The data available there is heavily filtered, and provides only a minor portion of the information available. 

Listen to and observe the packets being delivered by the RF network. If you are trying to observe operation of a digipeater outside of your local reception range, you can set a path that will go out to the far digipeater and back. If you hear the packet come back, then it was successfully handled by the digipeaters in the used portion of the digi path segment of the packet. 

Note that the APRS network is unconnected, and may not always deliver your packets successfully. Also most APRS networks are heavily overloaded and cannot reliably handle the normal day to day traffic on them. Also long paths are not recommended for normal use as it causes heavy network loads, leading to that heavy network load that makes the networks unreliable. 

Having said all that, yes, you can do things to test and observe exactly what you want to do. 

 


Re: Blocking a digipeater from digi'ing my beacon

K3RWN
 

Now I am curious what is the proper WIDE X-X setting for fixed stations?

From your comments I assume WIDE1-1, WIDE2-1 for a fixed station is not proper?

Most stations in my area are set this way.

Rich

On 10/24/2019 15:39 PM, James Ewen wrote:

Having said all that, yes, you can do things to test and observe exactly what you want to do. 
_._,_._,_

Groups.io Links:

You receive all messages sent to this group.


Re: Blocking a digipeater from digi'ing my beacon

Vince A <vince@...>
 

@James
Thank you for this info. I have learned something from your post. I did not know this?
73 KD7TWW Vince

On Oct 24 2019, at 1:39 pm, James Ewen via Groups.Io <ve6srv@...> wrote:
And to clarify another point, no fixed station should be using WIDE1-1 as a hop request. 

WIDE1-1 is intended to be used as a request from low powered stations for an extra helping hand from home stations to get heard by the main digipeaters (if required). 

Improper use of WIDE1-1 as a first hop request by high powered stations such as mobiles and home stations causes excessive local digipeats by home stations, and possible dupes by main digipeaters. 

People using WIDE1-1 improperly can make others attempting to act on WIDE1-1 to improve the digipeater network shut down their home WIDE1-1 digipeaters because of abuse and interference, thereby ruining the network for all. 

All digipeaters *should* respond to their assigned callsign/alias if implemented properly. 

Furthermore, if you are attempting to observe whether the RF network is working properly, you should observe the activity of the RF network directly by looking at what you can hear/see on the RF network. 

Don’t attempt to observe the RF network by looking at what you can see on APRS-IS connected sites like APRS.fi or other online sites. The data available there is heavily filtered, and provides only a minor portion of the information available. 

Listen to and observe the packets being delivered by the RF network. If you are trying to observe operation of a digipeater outside of your local reception range, you can set a path that will go out to the far digipeater and back. If you hear the packet come back, then it was successfully handled by the digipeaters in the used portion of the digi path segment of the packet. 

Note that the APRS network is unconnected, and may not always deliver your packets successfully. Also most APRS networks are heavily overloaded and cannot reliably handle the normal day to day traffic on them. Also long paths are not recommended for normal use as it causes heavy network loads, leading to that heavy network load that makes the networks unreliable. 

Having said all that, yes, you can do things to test and observe exactly what you want to do. 
Sent from Mailspring


Re: Blocking a digipeater from digi'ing my beacon

James Ewen
 

And to clarify another point, no fixed station should be using WIDE1-1 as a hop request. 

WIDE1-1 is intended to be used as a request from low powered stations for an extra helping hand from home stations to get heard by the main digipeaters (if required). 

Improper use of WIDE1-1 as a first hop request by high powered stations such as mobiles and home stations causes excessive local digipeats by home stations, and possible dupes by main digipeaters. 

People using WIDE1-1 improperly can make others attempting to act on WIDE1-1 to improve the digipeater network shut down their home WIDE1-1 digipeaters because of abuse and interference, thereby ruining the network for all. 

All digipeaters *should* respond to their assigned callsign/alias if implemented properly. 

Furthermore, if you are attempting to observe whether the RF network is working properly, you should observe the activity of the RF network directly by looking at what you can hear/see on the RF network. 

Don’t attempt to observe the RF network by looking at what you can see on APRS-IS connected sites like APRS.fi or other online sites. The data available there is heavily filtered, and provides only a minor portion of the information available. 

Listen to and observe the packets being delivered by the RF network. If you are trying to observe operation of a digipeater outside of your local reception range, you can set a path that will go out to the far digipeater and back. If you hear the packet come back, then it was successfully handled by the digipeaters in the used portion of the digi path segment of the packet. 

Note that the APRS network is unconnected, and may not always deliver your packets successfully. Also most APRS networks are heavily overloaded and cannot reliably handle the normal day to day traffic on them. Also long paths are not recommended for normal use as it causes heavy network loads, leading to that heavy network load that makes the networks unreliable. 

Having said all that, yes, you can do things to test and observe exactly what you want to do. 


Re: Blocking a digipeater from digi'ing my beacon

zl1vfo
 

To expand upon the above, try putting the callsign of the digi you want to digipeat you, and then NOGATE in the path after. i.e. LARES,NOGATE Then no-one who hears you should gate you to the internet. (Using TCPIP in place of NOGATE should also work to, but it is intended for other circumstances..) -Ian ZL1VFO


Re: Blocking a digipeater from digi'ing my beacon

Arnold Harding - KQ6DI
 

Rather than using WIDE1-1 as a path, try putting in just the callsign of the digi you are trying to reach.  For example, just put in LARES for the path.  HOWEVER, if the nearest digi is also an IGate, nothing can stop your being picked up there.  You should be able to see if LARES digipeated you.
Arnold, KQ6DI

On October 23, 2019 at 9:37 PM "KP3FT via Groups.Io" <kp3ft@...> wrote:

Is there a way, on my end, to temporarily stop a specific digipeater from digipeating my RF beacon (and also stop iGating me if possible)?  I'm testing out a yagi and an amp/preamp setup to see if I can hit some digis via RF in the north, west, and northwest directions, but there's a digi to the east that is in a prime location so it hears my digi no matter what direction I point the yagi.  I can't tell if the other digis hear me because the eastern digi could be TX'ing right on top of theirs after I beacon.  I can always ask the owner to temporarily block my station, but I thought there might be a way to do it from my end.

 


Blocking a digipeater from digi'ing my beacon

KP3FT
 

Is there a way, on my end, to temporarily stop a specific digipeater from digipeating my RF beacon (and also stop iGating me if possible)?  I'm testing out a yagi and an amp/preamp setup to see if I can hit some digis via RF in the north, west, and northwest directions, but there's a digi to the east that is in a prime location so it hears my digi no matter what direction I point the yagi.  I can't tell if the other digis hear me because the eastern digi could be TX'ing right on top of theirs after I beacon.  I can always ask the owner to temporarily block my station, but I thought there might be a way to do it from my end.


Re: Block specific ssid

Lynn Deffenbaugh
 

Yes, -b/call* will block all -SSIDs for the specified callsign. But again, only in the Additional Filter for the APRS-IS.  If you receive a packet via RF, it will be processed and displayed.

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

PS.  I'd like to know the specific station(s) so I can check them out if you don't mind.  Sending privately to KJ4ERJ@arrl.net is fine by me.

On 10/23/2019 11:51 AM, R. Patrick Ryan wrote:
On Tue, Oct 22, 2019 at 06:39 PM, rickvolle wrote:

-b/call
Question - would -b/call* command in Filters block all SSID from APRS-IS for a callsign?
There is one callsign sending a non APRS position that makes an altitude ring, not unlike a balloon or aircraft. Dang nuisance, and the position is off by a whole state!

Currently, all I can do is select and KILL from map when checking for balloons or aircraft to track with the MT feature.
Unfortunately, this station with multiple -SSIDs returns when it beacons again.

73 de Pat KC6VVT



Re: Block specific ssid

R. Patrick Ryan
 

On Tue, Oct 22, 2019 at 06:39 PM, rickvolle wrote:

-b/call
Question - would -b/call* command in Filters block all SSID from APRS-IS for a callsign?
There is one callsign sending a non APRS position that makes an altitude ring, not unlike a balloon or aircraft. Dang nuisance, and the position is off by a whole state!

Currently, all I can do is select and KILL from map when checking for balloons or aircraft to track with the MT feature.
Unfortunately, this station with multiple -SSIDs returns when it beacons again.

73 de Pat KC6VVT


Re: Triggers (was: KAM-XL symbol)

R. Patrick Ryan
 

Made me laugh, reminded me of a feature on APRSdos program version that Bob WB4APR had included.
Basically, the program allowed the user to set a range ring and it would generate an alarm if the area defined was entered by any APRS mobile user.
Then Bob wrote that he would quit playing with APRSdos programming and return to his chores. :)
That took care of the wife, mother-in-law, pesky visitors, too, I imagine.

73 de Pat KC6VVT


Re: Block specific ssid

rickvolle
 

Thank you Lynn. I’ll give it a try. 


On Oct 22, 2019, at 8:26 PM, Lynn Deffenbaugh <kj4erj@...> wrote:

Please define "unfollow"?  I suspect you have configured a nickname that is set to bring up a MultiTrack or you told it to remember a MultiTrack when you closed it.

For the former (nickname), locate it and either delete it or remove the checkboxes on the automatic MultiTrack.

For the latter (remembered MultiTracks), simply close the MultiTrack and restart APRSIS32.  It will only re-remember it if the MultiTrack is open when you close APRSIS32.

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

On 10/22/2019 7:39 PM, rickvolle via Groups.Io wrote:
Thank you.  Another question then. I keep seeing a specific rfid that I need to unfollow. How do I do that?



On Oct 22, 2019, at 6:30 PM, Lynn Deffenbaugh <kj4erj@...> wrote:

RF or -IS?  On -IS, you can add -b/call-SSID which is a negated buddy filter.  On RF, there is no blocking.

Note that this doesn't block an -SSID, but a specific callsign-SSID.

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

On 10/22/2019 7:25 PM, rickvolle via Groups.Io wrote:
Hello all,

how owe do you go about blocking a specific ssid. 

Thanks 

Rick
N9NWI


Re: Block specific ssid

Lynn Deffenbaugh
 

Please define "unfollow"?  I suspect you have configured a nickname that is set to bring up a MultiTrack or you told it to remember a MultiTrack when you closed it.

For the former (nickname), locate it and either delete it or remove the checkboxes on the automatic MultiTrack.

For the latter (remembered MultiTracks), simply close the MultiTrack and restart APRSIS32.  It will only re-remember it if the MultiTrack is open when you close APRSIS32.

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

On 10/22/2019 7:39 PM, rickvolle via Groups.Io wrote:
Thank you.  Another question then. I keep seeing a specific rfid that I need to unfollow. How do I do that?



On Oct 22, 2019, at 6:30 PM, Lynn Deffenbaugh <kj4erj@...> wrote:

RF or -IS?  On -IS, you can add -b/call-SSID which is a negated buddy filter.  On RF, there is no blocking.

Note that this doesn't block an -SSID, but a specific callsign-SSID.

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

On 10/22/2019 7:25 PM, rickvolle via Groups.Io wrote:
Hello all,

how owe do you go about blocking a specific ssid. 

Thanks 

Rick
N9NWI


Re: Block specific ssid

rickvolle
 

Thank you.  Another question then. I keep seeing a specific rfid that I need to unfollow. How do I do that?



On Oct 22, 2019, at 6:30 PM, Lynn Deffenbaugh <kj4erj@...> wrote:

RF or -IS?  On -IS, you can add -b/call-SSID which is a negated buddy filter.  On RF, there is no blocking.

Note that this doesn't block an -SSID, but a specific callsign-SSID.

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

On 10/22/2019 7:25 PM, rickvolle via Groups.Io wrote:
Hello all,

how owe do you go about blocking a specific ssid. 

Thanks 

Rick
N9NWI


Re: Block specific ssid

Lynn Deffenbaugh
 

RF or -IS?  On -IS, you can add -b/call-SSID which is a negated buddy filter.  On RF, there is no blocking.

Note that this doesn't block an -SSID, but a specific callsign-SSID.

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

On 10/22/2019 7:25 PM, rickvolle via Groups.Io wrote:
Hello all,

how owe do you go about blocking a specific ssid. 

Thanks 

Rick
N9NWI


Block specific ssid

rickvolle
 

Hello all,

how owe do you go about blocking a specific ssid. 

Thanks 

Rick
N9NWI


Re: Triggers

Lynn Deffenbaugh
 

I wish!  Then I could just release it!  The current development version is same one that I run here and represents the latest version of the source.

APRSISMO, on the other hand, is very out of date, but you can get the latest "TestHost" from http://tinyurl.com/Get-APRSISMO and using the "2019 Ride for Ronald" link instead of the "Tap here to download".  I really need to get that straightened out too!

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

On 10/22/2019 6:17 PM, Julian wrote:
I bet you are using an enhanced APRSIS version, with all triggers, bells and whistles, leaving the rest of us in peril! He he.
Regards,  J,  M0IPU YO3FCA


Re: Triggers (was: KAM-XL symbol)

Julian
 

I bet you are using an enhanced APRSIS version, with all triggers, bells and whistles, leaving the rest of us in peril! He he.
Regards,  J,  M0IPU YO3FCA


Re: Map fading

patrick lambert
 

Wow thanks so much, now the map its really showing.

Télécharger Outlook pour Android


From: APRSISCE@groups.io <APRSISCE@groups.io> on behalf of Randy Love <rlove31@...>
Sent: Tuesday, October 22, 2019 1:10:08 PM
To: APRSISCE@groups.io <APRSISCE@groups.io>
Subject: Re: [APRSISCE] Map fading
 
Press and hold your right arrow key.
That should 'darken' your map.
Pressing the left arrow key makes it lighter, or 'faded'

73,
Randy
WF5X


On Tue, Oct 22, 2019 at 12:55 PM patrick lambert <lambertinos@...> wrote:
Guys my map is fading. The object on the map are ok but in the background, the map is fading. I can see it but its almost all white. Any one have this problem? Thanks.

Télécharger Outlook pour Android


Re: Map fading

Randy Love
 

Press and hold your right arrow key.
That should 'darken' your map.
Pressing the left arrow key makes it lighter, or 'faded'

73,
Randy
WF5X


On Tue, Oct 22, 2019 at 12:55 PM patrick lambert <lambertinos@...> wrote:
Guys my map is fading. The object on the map are ok but in the background, the map is fading. I can see it but its almost all white. Any one have this problem? Thanks.

Télécharger Outlook pour Android


Map fading

patrick lambert
 

Guys my map is fading. The object on the map are ok but in the background, the map is fading. I can see it but its almost all white. Any one have this problem? Thanks.

Télécharger Outlook pour Android

1701 - 1720 of 35493