Re: 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

Join APRSISCE@groups.io to automatically receive all group messages.