What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Wacky Trakkin'

petehowell

Well Known Member
Need some help from the guys that understand digis/igates better than I do.

I have been trying to understand an issue all of the guys up here in the local area have been seeing with their tracks lately. It appears that we have a Igate that is posting points out of sequence, leading to a track that looks like this:

Location%20of%20N527DB%20-%20Google%20Maps%20APRS%20-%20Google%20Chrome%2010302010%2054846%20PM.jpg


It seems whenever we see a recursive track like this, it either has gone directly thru the Igate in question or has be digipeated to that Igate. Does the point posted to the internet pick up its timestamp from the Igate?

Any thoughts appreciated - I'll contact the Igate owner, but I thought I'd learn as much as possible before I just tell him or her their baby is broken.
 
Last edited:
Does the point posted to the internet pick up its timestamp from the Igate?

Pete,

No, the APRS-IS server assigns a timestamp when the position report is received from the Igate (e.g. the Igate does not need a correct time setting). So this clearly appears to be an Igate delaying packets, which can happen for a variety of reasons.

You plan of action (to contact the Igate owner) is the right one but don't be surprised if he doesn't understand the problem, much less the solution. This is a frustrating, on-going problem.

--
Joe
 
HI Joe

Thanks for weighing in! I will contact the owner and see if we can work it out.

I always check my track on your site and it seems to have the same issue, so I reasoned it might be the igate.
 
Thanks for weighing in! I will contact the owner and see if we can work it out.

I always check my track on your site and it seems to have the same issue, so I reasoned it might be the igate.

Pete,

Yep, looks like you are dealing with a flaky iGate that is buffering beacons. Buffering usually results in a collision of duplicate beacons at the APRS server that creates the dreaded Red Error, but in this case the buffering must be particularly severe.

Hopefully your impressive persuasive skills :D will be sufficient to convince the iGate owner to make the necessary changes (or shut down). It would be frustrating to have your local tracking goofed up by one operator.

And some hams claim it is the airborne trackers that are the problem children.................;)
 
Pete,

snip

Hopefully your impressive persuasive skills :D will be sufficient to convince the iGate owner to make the necessary changes (or shut down). It would be frustrating to have your local tracking goofed up by one operator.

snip

Pete may need more than persuasive skills - the owner seems to be pushing daisies for the last few years... (Pete, I couldn't resist, besides, you told me about it..):eek:
 
Buffering

Pete,

No, the APRS-IS server assigns a timestamp when the position report is received from the Igate (e.g. the Igate does not need a correct time setting). So this clearly appears to be an Igate delaying packets, which can happen for a variety of reasons.

You plan of action (to contact the Igate owner) is the right one but don't be surprised if he doesn't understand the problem, much less the solution. This is a frustrating, on-going problem.

--
Joe

Joe,

What is the suggested way of resolving this kind of problem.

There is an I-Gate near Augusta that is always buffering my packets....
I have conversed with them and they don't think the issue is theirs to resolve.
 
What is the suggested way of resolving this kind of problem.

There is an I-Gate near Augusta that is always buffering my packets....
I have conversed with them and they don't think the issue is theirs to resolve.

Steve,

Perhaps a summary of report times vs. position on the map will convince him that your tracker couldn't possibly be at those places at those times. aprs.fi raw data may be useful here although occasionally it throws away a good packet after erroneously displaying a delayed one. The next step is to implement the "fix" for the specific Igate software in use (I can give you one for UIView-32). But I'm afraid I don't have a good answer for you if you can't get the errant Igate owner to work with you.

This is one of the reasons I created my own APRS tracking site (http://www.mail2600.com/cgi-bin/everyone.cgi). I've tweaked my filtering algorithm (as has aprs.fi) and often our results differ -- for example, the bogus point at 2010-10-24 18:02:13z on aprs.fi (http://aprs.fi/?call=N42AH&mt=m&z=14&timerange=86400) does not appear on http://www.mail2600.com/cgi-bin/tra...0-24+17:57:00&stop=2010-10-24+18:06:00&elim=0

Occasionally the filtering algorithms miss something that the human eye catches and on my site I manually delete those points if I come across them in casual viewing. I'd always be happy to do that for you (or anyone) in response to Email with the specific timestamps of bad packets. Small consolation, I know, but at least the track is viewable after you land.

--
Joe
 
Operator has vanity call sign

I believe that the owner's son applied for his late father's call, and is very much alive. This from a search of the FCC ULS database--Google turned up the obituary but ULS sheds more light on the situation.

Adam
 
Well, you could take a 10 mW continuous carrier transmitter and mount it next to his receive antenna......But that would be wrong....


Allen
VHS
 
Fixed

Through some creative googling, I finally tracked down the owner of the bad Igate tonight and sent him an email. He called me back and initially tried to tell me that APRS was never intended for airplanes, but I had done my homework and told him I suspected that his KPC3+ TNC was running in KISS mode (a known issue in most javAPRSSrvr installs), resulting in delayed packets to the web. When he heard that - something clicked and he said - "yes, that is it."

He said he would fix it right away - and emailed back to confirm he had ordered new hardware already last night. I ponied up an airplane ride to thank him.

Might be back to smooth trackkin' by the weekend!
 
Through some creative googling, I finally tracked down the owner of the bad Igate tonight and sent him an email. He called me back and initially tried to tell me that APRS was never intended for airplanes, but I had done my homework and told him I suspected that his KPC3+ TNC was running in KISS mode (a known issue in most javAPRSSrvr installs), resulting in delayed packets to the web. When he heard that - something clicked and he said - "yes, that is it."

He said he would fix it right away - and emailed back to confirm he had ordered new hardware already last night. I ponied up an airplane ride to thank him.

Might be back to smooth trackkin' by the weekend!

Very smooth, Pete!

KISS, eh........must remember that one. :)
 
Another Example

Rick,

The last (rogue) position report at 21:31:06 UTC appears to be a duplicate of a legitimate one at 20:35:10. The mail2600.com filtering algorithm checks (among other things) for duplicates in the previous 55 minutes and this one is just outside that window [drat!].

Mail2600.com is my site and when I spot something like this I manually delete the errant position report. I'll leave this one alone to illustrate your example. But I'm always willing to delete a points or points in response to an Email (preferred) or PM here.

Thanks for the PIREP on your Microtrak-RTG -- that's good to know.

73,
Joe, K7JD
 
RE:My Wacky Track 9/2/2010

Hi

Another data point of a wacky track out west. On the way back from KSLC the track had the problems shown......9/2/2010 .... The problem happened just out of KSLC on the way to Delta (KDTA) After closer review the problem happened just after t/o from KSLC. The actual flight path placed us east of I-15 all the way to Provo where ATC turned us loose, which is not shown because of no crumds laid down. I then flew KDTA-KMLF-KSGU......Then on to IL8. I noted that the crumbs on the trip to KSLC were there as expected but on the way back no crumbs after t/o at KSLC until just south of Minersville in Southern Utah. All My tracks since then have been OK......!!!!!!!???????

http://aprs.fi/?call=n74bz&dt=1283385600&mt=roadmap&z=11&timerange=3600

Frank @ 1L8 ... RV7A ... Flying & Tracken (MT-RTG)
 
Last edited:
Rick,

The last (rogue) position report at 21:31:06 UTC appears to be a duplicate of a legitimate one at 20:35:10. The mail2600.com filtering algorithm checks (among other things) for duplicates in the previous 55 minutes and this one is just outside that window [drat!].

Mail2600.com is my site and when I spot something like this I manually delete the errant position report. I'll leave this one alone to illustrate your example. But I'm always willing to delete a points or points in response to an Email (preferred) or PM here.

Thanks for the PIREP on your Microtrak-RTG -- that's good to know.

73,
Joe, K7JD

Joe, first of all, thank you for providing this system as I really find it useful. This flight on Thursday was a "fall colors photo flight" and my wife really enjoys going online and seeing where we were on a map after the flight.

The one thing that I noticed about that rogue point was that it was repeated by a site quite a bit to the west of me. All the other points went through the usual repeater in east Memphis.

Since I have a (shudder) wooden airplane, I am using the Byonics rubber ducky antenna on the RTG, mounted aft of the baggage compartment in the fuselage. It seems to work great. I had good coverage all the way to and from OSH10 and around the local area. Great little unit.
 
Back
Top