[aprssig] Re: aprssig Digest, Vol 24, Issue 8

[mconner at aer.com]

> > This is true to conclusively prove that an IGate is the 
> > problem.  However, this buffering would probably be invisible 
> > to the IGate owner unless a duplicate system was running 
> > right next to it that did not have these issues.  Because 
> > this problem tends to come and go, I don't see this as a 
> > viable diagnostic alternative. 
> 
> Then you didn't read what I said.  It does not require a duplicate
> system.  It does require a _knowledgeable_ use of network monitoring
> software on the IGate and proper comparisons with the server that the
> IGate is attached to.  The problem does not come and go.  Once it is
> identified, it is usually in existence until rectified.

Your requirement may exceed the knowledge base and time generally available by an IGate operator.  Not in all cases, but for many.  Feel free to prove me wrong here.

> 
> > I really think any internet user of the APRS-IS, whether it's 
> > FindU users, IGates, or whatever, should be concerned about 
> > this.  If an duplicate report is the last one received, FindU 
> > reports that old position as the "latest" one.  Similarly, 
> > APRS clients who use the APRS-IS for their data will also 
> > display an old position.  This has happened to me relatively 
> > frequently where I check FindU for a mobile station and have 
> > to go to the "raw data" display to make sure what I'm seeing 
> > is truly the latest position sent out by that mobile.
> 
> And how do you do this with Mic-E?  There is no timestamp in Mic-E.

You don't do this with Mic-E because there is no timestamp to determine when the packet was transmitted.

> Most of the timestamps in non-Mic-E position packets tend to be
> inaccurate, as well.  

The time stamps for TinyTraks are sufficiently accurate for this purpose, since they are hooked to a GPS and the delay between getting the data formatted within the PIC and transmission is a few seconds at most.  I doubt I'd use other time stamps because of the inaccuracy.

> Your case for your "solution" is based on a 
> number of invalid assumptions about the data, the architecture of 
> APRS-IS, and
> what is available to use for diagnostics.

Do you mean my solution to fix the problem of duplicates on APRS-IS, or my methodology to diagnose what is introducing the problem in the first place?  Both, I suppose.  If the latter, apparently I'm not explaining myself well enough, or you're not open to alternative methods.  Please explain why, in detail, this will not work without resorting to simple assertion and saying "you don't understand, it just won't".

>To isolate these problems, determine the APRS-IS entry point (if
>multiple entry points for the problem, then look to common occurrences
>in the RF network), and work _with_ the IGate operator to determine
>whether his system is delaying packets into the network, is seeing the
>packets late (you can always telnet into the server the IGate is
>attached to and see when APRS-IS first sees the packet), or if there is
>some other issue.

If I could do this in near-real-time while the problem was occurring, I would - if I could contact the operator and he/she is ready/willling/able to perform the diagnostics and the problem-causing packets continued to flow long enough to get the diagnostics done.  I submit this is less feasible than my method, but you might prove me wrong.

I have not seen enough to dissuade me from attempting the diagnostics as I outlined.  When (and more importantly, if) I get time to work on this, I'll report the results and the group can feel free to attack the methodology, assumptions, or my mother's choice of footwear.

73 de Mark N9XTN