Date   

Re: Blocking a digipeater from digi'ing my beacon

KP3FT
 

"If however high powered stations use WIDE1-1, there’s a potential for many home stations to hear the request and act upon it, causing lots of potential noise on the channel. The solution then is to shut down the home WIDE1-1 digipeaters, thereby removing the ability for low powered stations to get help from a nearby home station."

"I sent an email to Bob Bruninga asking him if what I was seeing was what was to be expected. His response was 'I don’t know, I’ve never seen a properly implemented APRS network at work.'"

It sounds like a "proper" APRS network is actually just theoretical; not possible in reality?  Or is it possible but needs the perfect geography with the perfect number and spacing of digipeaters with associated perfect paths?  Is that what you have in Alberta?  If so, what are the "proper" settings you use?

I'm not being flippant, just genuinely curious.  There's an abundance of conflicting information on the internet.  WIDE1-1 is good... WIDE1-1 is bad.  Never use WIDE2-2... it's good to use WIDE2-2.  Use WIDE3-3... never, ever, ever use WIDE3-3.  Never use RX-only iGates... RX-only iGates are wonderful.  And so on.

Also, is part of the problem too much internet integration?



Re: Blocking a digipeater from digi'ing my beacon

James Ewen
 

That’s a loaded question as you can see from Arnold’s reply. 

How do you define proper? Is proper what the original intent was, or is it what people have decided the intent should have been, or what people have done because others don’t know what the original intent was, and still others have tried to correct the mess by doing something else to make it “proper”?

APRS has always been a hodge-podge of “kludges”. Bob Bruninga built a concept and protocol on top of hardware and routines that were never meant to do what he implemented. I love it. He took what was available and made it do something totally different. 

Packet digipeaters all had unique callsigns and aliases, and the packet radio operator had to explicitly define a route to send packets from point a to point b. 

Bob came up with the idea of using the same alias in all digipeaters which would allow a flood of packets outwards from the source in all directions. In the early days, a path of WIDE,WIDE,WIDE was proper, when all digipeaters responded to the alias WIDE. 

When UIFLOOD and UITRACE routines came along, WIDE3-3 or TRACE3-3 were proper paths to use. 

In the Pacific Northwest, a bunch of us started playing with UIFLOOD WIDE,30,ID as a setting which made the WIDE3-3 path a traceable path. It ended up becoming the defacto standard APRS proper digipeater setting across the continent. 

Around that time the concept of setting home stations up to act on only WIDE1-1 was promoted so that low powered stations could get a helping hand to get into the main digipeaters. The main digipeaters were not that plentiful, and could be a fair distance away. 

The popularity of APRS increased a whole bunch, which brought more users, and more digipeaters. People started having problems getting heard by the digipeaters, so as a solution, many people set up digipeaters closer to where the users were located. Others resorted to using high power to get heard. The noise floor on 144.390 in some areas became so high it was almost impossible to be heard. 

APRS runs on a simplex channel, and uses a store and forward concept to move packets around. Every station on the channel has a unique coverage area that it can hear. When your station wants to send a packet, it listens for a clear channel. It then sends a packet which takes up x amount of airtime. If a digipeater is able to successfully decode the entire packet, it should immediately resend the packet into its coverage area. The digipeater may not be able to successfully decode the packet because of a collision with another packet. This collision is caused by what is known as the hidden station issue. Your station and the colliding station cannot hear each other, but the digipeater can hear both stations. 

People see their station transmit, which can only happen when the channel is “clear”, but they don’t get digipeated. Obviously the problem was that the digipeater didn’t hear their station, so the solution is to increase the TX power. In fact, if the problem was a hidden station collision, the answer isn’t more power, but rather retry later and hope for no collision. 

Many people opt for the more power solution. Also adding digipeaters within the coverage area of other digipeaters fixes the “problem” of being heard for those close by, due to FM capture effect, but overall it increases the hidden station issue, and crowds the channel by having multiple digipeaters that cover the same area all needing to digipeat the packet all on the same channel. 

In some instances, the WIDE1-1 alias was acted upon by a different routine than the WIDEn-N alias, which then meant a digipeater could act upon the same packet twice. 

A way to combat that issue was to reduce the maximum number of hops used. Around this time a suggestion to use a path of WIDE2-2 was put out there. With a large digipeater network out there, and lots of I-gates around, 2 hops was deemed more than sufficient. Those low powered stations needing help and then one more hop were asked to use WIDE1-1, WIDE2-1 for a total of 2 hops. 

In severely overloaded areas where big digipeaters covered too much area, and dozens of smaller digipeaters were set up inside the large digipeater coverage areas, with far too much overlap with each other, and too many stations using too much power and sending too many packets per hour existed, digipeater operators started implementing bastardized rules in their digipeaters to force users to use non-standard paths in an effort to combat the poor infrastructure implementation, and poor user practices. 

Fractured APRS networks abound where the mobile APRS user has to change settings in their station to match local settings. This breaks the fundamental underlying concept of APRS where the end user can set up their station and go where ever and it just works. 

So, what is “proper”?  WIDE1-1 was defined to be used by low powered stations that could not get to the main digipeaters directly. Every home station should be set up to act on the WIDE1-1 alias. Because the only stations using WIDE1-1 as a hop request, there isn’t any problem with having a lot of stations respond to the digipeat request. If however high powered stations use WIDE1-1, there’s a potential for many home stations to hear the request and act upon it, causing lots of potential noise on the channel. The solution the is to shut down the home WIDE1-1 digioeaters, thereby removing the ability for low powered stations to get help from a nearby home station. 

Which is the proper implementation?

Sometimes being the old curmudgeon that’s been around since the beginning of time is a curse. What the heck do I know about APRS implementation? The PNWAPRS Group was on the forefront of experimenting with APRS digipeater implementations before 99% of the current APRS users were even on APRS. 

I set up a network of 5 APRS digipeaters in my shack one day with the brand new WIDEn-N configuration, and fired packets into it and recorded what happened. I sent an email to Bob Bruninga asking him if what I was seeing was what was to be expected. His response was “I don’t know, I’ve never seen a properly implemented APRS network at work. “  At that time the APRS network in Maryland was a mish-mash of random digipeater rules, each digipeater doing things a little differently. 

I was able to build a fairly large homogenous APRS network in northern Alberta. All digipeaters programmed identically, using the “proper” settings. We have a low user count, the network isn’t overloaded, and we see excellent reliability and can send packets over multiple hops with high reliability. 

Your mileage may vary. 

James
VE6SRV

On Oct 24, 2019, at 10:34 PM, K3RWN <rwnewbould@...> wrote:



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. 


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
 

@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

1541 - 1560 of 35335