Topics

Proportional beaconing feature request


James Ewen
 

Justin,

I can see that I got so distracted by the weird paths that I forgot to look for the "has-been-digipeated bit" in the packets.

2020-02-03 17:42:42 MST: KD1ELK>SSRPQU,KE7JVX-3*,WIDE1,WIDE2-1,qAO,K7EIR-12:`'Fmo4u>/`"8/}Justins Tacoma_% 

This first packet with the incorrect mark up got me going down the wrong path.

Just about every packet after that was heard direct by W7JET-10 and gated. Because the packets all had the exact same content, I incorrectly assumed that they were duplicate packets that had been handled by a variety of digipeaters. I didn't catch the missing "has-been-digipeated bit", and incorrectly assumed the digipeaters had filled in the path elements, and not that you were manually setting fixed path elements.

I'm sure glad that your local digipeater network was not handling the packets incorrectly so as to add in hops by themselves. There are software digipeaters that can be configured to modify paths to cause this type of issue, but most of the digipeaters are Kantronics, and don't support that type of operation.
 
However, I stand by my first statement... user education, courteous operations, and a well planned and executed digipeater network are a better solution than trying to brute force your way into a network.

Proportional pathing can be a component of courteous operations if implemented properly.



James
VE6SRV


On Wed, Feb 5, 2020 at 10:02 AM James Ewen via Groups.Io <ve6srv=gmail.com@groups.io> wrote:
Justin,

If you are going to be doing tests, one of the best things you can do is to send test packets with time stamps. 

This shows the time that the packet was sent in the packet itself, and then each digipeat will have a time stamp as well. 

The list of all the packets sent from your station show identical content, which makes it look like it’s the same packet being handled multiple times. You are using a compressed packet which makes it harder for human readability. 

If you were sending the same compressed packet multiple times, and using hard coded path elements, that might explain some of what I was so confused about. 

Observing only partial results that are available on the APRS-IS can make for erroneous assumptions. 

The packets I was able to see made for a very confusing observation. I was at a loss to figure out how those various digipeaters were able to screw up handling the packet so bad. 



On Wed, Feb 5, 2020 at 9:54 AM Justin Cherington <huntjlc@...> wrote:

Thanks for the write up! Very informative. I’m aware of the state specific digipeating but need to test it out to see if it’s in place here. 

The paths that show me going to El Paso was intentional, I knew one of them was corrupting packets but didn’t know which. So I kept adding them over time until I found the culprit. 

--
James
VE6SRV


James Ewen
 

Justin,

If you are going to be doing tests, one of the best things you can do is to send test packets with time stamps. 

This shows the time that the packet was sent in the packet itself, and then each digipeat will have a time stamp as well. 

The list of all the packets sent from your station show identical content, which makes it look like it’s the same packet being handled multiple times. You are using a compressed packet which makes it harder for human readability. 

If you were sending the same compressed packet multiple times, and using hard coded path elements, that might explain some of what I was so confused about. 

Observing only partial results that are available on the APRS-IS can make for erroneous assumptions. 

The packets I was able to see made for a very confusing observation. I was at a loss to figure out how those various digipeaters were able to screw up handling the packet so bad. 



On Wed, Feb 5, 2020 at 9:54 AM Justin Cherington <huntjlc@...> wrote:

Thanks for the write up! Very informative. I’m aware of the state specific digipeating but need to test it out to see if it’s in place here. 

The paths that show me going to El Paso was intentional, I knew one of them was corrupting packets but didn’t know which. So I kept adding them over time until I found the culprit. 

--
James
VE6SRV


Justin Cherington
 

Thanks for the write up! Very informative. I’m aware of the state specific digipeating but need to test it out to see if it’s in place here. 

The paths that show me going to El Paso was intentional, I knew one of them was corrupting packets but didn’t know which. So I kept adding them over time until I found the culprit. 


James Ewen
 

On Mon, Feb 3, 2020 at 8:38 PM, Justin Cherington
<huntjlc@...> wrote:
I’d love to see proportional beaconing as an option. Something like being able to set an interval for DIRECT, WIDE1-1, WIDE2-1, WIDE2-2 with a customizable timer for each. It would really help in a place like AZ where blasting at WIDE1-1, WIDE2-1 can easily put your RF across state lines, but you still want to increase your chances of being gated a few times an hour. Thanks Lynn, we spoke on FB about this today and you asked that I post it here. 

I've cc'ed a couple email addresses for some of the groups operating the digipeaters in the area.

The best way to keep your packets within state lines is to use the SSn-N alias. 

If your digipeater operators have configured the digipeaters properly, this alias will be supported in your area. If you are in Arizona, the alias will be AZ2-2 for a 2 hop path. 

A better means of being gated on a regular basis is to work on educating APRS users on proper path selection, courteous operations, and ensuring that the digipeater network is set up properly, including proper locations for digipeaters. This is not an easy task, many people are not receptive to advice from others. Trying to show people that there are issues with their equipment is very difficult. Digipeater owners can be some of the most challenging to work with as they will look at the packets sourced by their digipeater, and tell you there's nothing wrong. Unfortunately the majority of issues with digipeaters can only be seen by observing packets from others that have been handled by the digipeater.

Misconfigured digipeater aliases, and known hardware issues with various digipeater hardware are the majority of the problems. Delayed packet delivery is a known issue in the Kantronics equipment.

Brute force operations to try and muscle your packets out over top of other users is just a recipe for more problems. 

Looking at your packets, it looks like there’s something seriously wrong with the local digipeater configurations. 

It looks like you are running a WIDE1-1,WIDE2-1 path which works for the most part. 

2020-02-03 17:40:39 MST: KD1ELK>SSRPQS,WIDE1-1,WIDE2-1,qAR,AG7GK-1:`'H6n>}>/`"7{}Justins Tacoma_%

  The packets above show your position packet being picked up directly by AG7GK-1.  

2020-02-03 17:42:42 MST: KD1ELK>SSRPQU,KE7JVX-3*,WIDE1,WIDE2-1,qAO,K7EIR-12:`'Fmo4u>/`"8/}Justins Tacoma_%

The packet above was digipeated by KE7JVX-3, but the digipeater has not marked the used path properly. It has inserted it's callsign which is marked as used (*), and then put an unused WIDE1 alias into the path.

When a digipeater handles a packet, it should insert the digipeater call, and then mark the alias acted upon as used as seen below.

2020-02-02 12:53:34 MST: VE6PS-4>USQUYQ,EDMNTN,WIDE1*,WIDE2-1,qAO,VE6REF-10:`)?+m@}>/";s}/TinyTrak4 Alpha

You can see that the EDMNTN digipeater acted upon a WIDE1-1 alias, and has marked the WIDE1 as used up as signified by the * after WIDE1.

What follows in your raw data is a serious mess...

If we assume that KE7JVX-3 digipeated your packet and passed it along with the next path element as WIDE1, then no digipeater should handle the packet again as WIDE1 is not a valid digipeat alias. Yet below, we see a number of copies of your packet being handled by a number of digipeaters.

GREENS picks up the packet and digipeats it, which is then digipeated by ALPAZ, and then gated by W7JET-10. No evidence of any used paths are evident.

2020-02-03 17:55:07 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%

If the packet had path elements of WIDE1,WIDE2-1, and the digipeaters were misconfigured to act upon WIDE1, then its possible to see three hops when there was only 2 hops initially requested.

But look below...

2020-02-03 17:57:58 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%
2020-02-03 18:01:10 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%

We see five and seven hops in these packets... where are the extra path elements coming from? Why are these digipeaters acting upon the packet? Why is there no evidence of path elements showing?

It gets worse... somewhere along the line, a digipeater is also corrupting the packet... quite possibly K7TUS and MULE.

2020-02-03 18:03:14 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,K7TUS,qAS,W7JET-10:<0xf0>`'E>l"Y>/`"82}Justins Tacoma_% [Unsupported packet format]
2020-02-03 18:04:50 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,MULE,qAS,W7JET-10:<0xf0>`'E>l"Y>/`"82}Justins Tacoma_% [Unsupported packet format]
2020-02-03 18:05:29 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,MULE,qAS,W7JET-10:<0xf0>`'E>l"Y>/`"82}Justins Tacoma_% [Unsupported packet format]

Look below... this same packet using the same path was seen at 18:01:01, 5 minutes and 25 seconds before.

2020-02-03 18:06:26 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%

Actually if you look closer, the original packet went out around 17:55:07, and every packet after is a duplicate of that original packet that has been delayed in delivery.

2020-02-03 18:11:46 MST: KD1ELK>SSQWXS,W7MOT-10,W7MOT-8,MINGUS,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%
2020-02-03 18:14:14 MST: KD1ELK>SSQWXS,KE7JVX-3,GREENS,ALPAZ,LUERA,CABALL,JACKPK,HELIO,qAS,W7JET-10:`'E>l"Y>/`"82}Justins Tacoma_%
2020-02-03 18:15:50 MST: KD1ELK>SSQWXS,KE7JVX-3*,WIDE1,WIDE2-1,qAO,K7EIR-12:`'E>l"Y>/`"82}Justins Tacoma_%

How many digipeats, copies of the original packet, and digipeats of all those copies bounce around the area? We see evidence of this one packet bouncing around the network for 20 minutes.

These digipeaters stretch between Phoenix and El Paso.


Adding proportional pathing is not going to solve these network issues. You may find you have better luck in being heard by the local i-gates if you use no path at all. The digipeater network in your area appears to be so badly misconfigured and broken that it's lucky you can get anything through.

As a caveat, I am basing all of this on the data available to me via the APRS-IS stream. As you know, the APRS-IS stream filters out the majority of the packets on the local RF network using dupe filters. There are most likely hundreds of copies of the same packet being bounced around the area for minutes at a time due to the systemic issues in the area. Only the packets that are delayed longer than the dupe filters end up showing in the APRS-IS stream, and then only the first of each of those are shown.

You could try building a new proper APRS network on an alternate frequency... it might be easier than trying to convince people that their digipeaters are seriously broken.

There is so much going on here that it is almost impossible to know exactly what is happening. Being able to see all the packets as they bounce around the network might help shed some clues into what is going on.

James
VE6SRV


George Smith <n7jjy@...>
 

Could not agree more.  Between northern Colorado and southern Wyoming seems like we (in Wyoming) get beacons from 100 plus miles at times. hhmmmm
De N7JJY 



On Mon, Feb 3, 2020 at 8:38 PM, Justin Cherington
<huntjlc@...> wrote:
I’d love to see proportional beaconing as an option. Something like being able to set an interval for DIRECT, WIDE1-1, WIDE2-1, WIDE2-2 with a customizable timer for each. It would really help in a place like AZ where blasting at WIDE1-1, WIDE2-1 can easily put your RF across state lines, but you still want to increase your chances of being gated a few times an hour. Thanks Lynn, we spoke on FB about this today and you asked that I post it here. 


Justin Cherington
 

I’d love to see proportional beaconing as an option. Something like being able to set an interval for DIRECT, WIDE1-1, WIDE2-1, WIDE2-2 with a customizable timer for each. It would really help in a place like AZ where blasting at WIDE1-1, WIDE2-1 can easily put your RF across state lines, but you still want to increase your chances of being gated a few times an hour. Thanks Lynn, we spoke on FB about this today and you asked that I post it here.