[aprssig] Weird Behavior on the APRS-IS

[Steve Dimse]

On Feb 17, 2014, at 8:39 PM, Stephen H. Smith <WA8LMF2 at aol.com> wrote:

> This has nothing to do with digipeaters
> 
That was only an example of a cause of long delay that is occasionally seen. There are others, like buffer dumps that have been seen, but as I said they are less common than simple errors in object transmission.

> The ISS object I am using is generated by KJ4ERJ-15 and is injected directly into  fourth.aprs.net.    In turn, I have been taking the same object off two other servers to plot on two separate displays.
> 
> On one map (the 30-meter HF APRS display), where I am also plotting the NWS watches and warnings, I am taking the feed off  firenet.us  in order to get the full NWS feed.
> 
> On the satgate map, I am taking the feed off a "normal" APRS-IS server to avoid unnecessary loading on the firenet servers.    (I have two separate connections because the port 14580 filtering requirements are different for the two applications; else I would re-distribute a single connection to both apps.)
> 
> Normally the station is received within a second or two of the same time, in the same place, on both maps,as one would expect.  This is why the TWENTY MINUTE delay in the appearance of the identical object on second is so strange.
> 
Something that I'm still not clear on. Is the ONLY indication of this 20 minute delay that an ISS icon appears on a map display, or do you have the identical packet documented coming with a 20 minute delay? An object with the name of ISS is common. Anyone can plot it and many have over the years, some manually and some automatically. In other words, an object may be transmitted from two different stations. For example, these two packets will display the identical object:

K4HG>APRS:;ISS      *091234z4903.50N/07201.75W>
WU2Z>APRS:;ISS      *091234z4903.50N/07201.75W>

and although the timestamp and position match the two object PACKETS are not identical because they come from different stations. Furthermore these two reports

K4HG>APRS:;ISS      *091234z4903.50N/07201.75W>
WU2Z>APRS:;ISS      *091234z4903.51N/07201.76W>

are not identical positions but are still for the same object, and the second report will move the object a tiny amount. 

If the objects (position and timestamp) are identical but appear delayed and the object packets (meaning callsign of originator) are different, you are likely facing an error caused by clock setting, old keps, or manual position entry. There is nothing sacred about the object name ISS, anyone can transmit it, and their position may be right or it may be wrong! You say you get the object from KJ4ERJ-15, but if you are just looking at objects plotting as ISS, it might be sent by anyone. When I look through the raw packets

http://www.findu.com/cgi-bin/raw.cgi?call=KJ4ERJ-15&time=1

the timestamps all appear to be in order at first glance.

If you have object PACKETS that identical (same timestamps, positions, AND same senders) but with the 20 minute offset then please share the exact packets so I can look at findU's timestamps and see if there are any clues there.

> [If I had a Windows app that could generate the ISS track locally from keps, and emulate an APRS-IS server on   localhost:portwhatever  I wouldn't bother with the Internet ISS feed at all.]
> 
There is an open source app on the AMSAT web site that I use (predict), it runs on Mac and Linux, but there are also Windows apps that I haven't looked through. It is in C so it could be made to run on Windows. Certainly none will directly emulate APRS IS, but if you can grab data from APRS IS you can grab data from a local program, predict can send data to a socket or produce results through a command line call. In my experience depending on objects sent via the APRS IS for satellite tracking is not going to give you reliable results, especially if you are just looking for objects called ISS. If KJ4ERJ-15 is producing reliable values and you are willing to depend upon it then you need to be sure whatever parsing you are doing ignores objects sent by all others, either within the parser or through APRS IS filtering.

Steve K4HG