[aprssig] Improper Balloon Paths...

[Tim Cunningham]

---- Bob Burns W9RXR <w9rxr_ at rlburns.net> wrote: 
> At 08:40 AM 4/25/2010, Jason KG4WSV wrote:
> 
> > > "Can't fix stupid."
> >
> >too true.
> 
> But, you can use appropriate tools to mitigate the problem.
> 
> Such as a tracker that has switchable profiles. Have one profile with 
> a short path or no path at all that the tracker uses above a certain 
> altitude, then switch to a profile with a more hops in the path at 
> low altitude.
> 
> Bob...
> 

In defense of the balloon paths that are being utilized, many are missing an opportunity that they provide. That opportunity provides invaluable data about our APRS RF and Internet Gateways. I am not advocating long packet paths. What I am advocating and encouraging Digipeater and IGate operators is to take a look at the data from a balloon launch to see if their systems are operating efficiently.

I pull and review the logs using the CGI’s provided on FINDU after a balloon flight to see what paths a packet takes to get to the internet. Too many times I see packets delayed by Digipeaters and IGates that “DELAY” packets by up to 2.5 minutes or longer. Just take a look at the FINDU database and pull the data using one of the CGI’s from a balloon launch to study and understand what I am conveying. If we put more energy in reviewing this type of data and resolving our known issues, we would appreciate balloon activity carrying APRS payloads as they provide a wealth of information about our network.

The reason I got interested in this type of data was I thought something was wrong with my IGate when packets seemed to take a different route to another IGate some distance away on FINDU. Then I discovered nothing was wrong with my IGate or area digipeaters. The problem was distant digipeaters configured incorrectly and IGates that are very slow to move traffic to the Internet. After contacting a couple IGate stations I found that they were not using filters to limit the amount of data processed by their computer. In most cases using the appropriate filter instead of looking at the entire pipe on the APRS-IS corrected the issue.


73’s,
Tim – N8DEU