[aprssig] Re: Unreasonable xmission delay

Tim Cunningham tim_cunningham at mindspring.com
Sat Jul 15 11:00:05 EDT 2006 

Bob,

This is not a DCD issue in the examples I provided.

In my second example, you can clearly see that two separate IGates hear the 
same direct transmission from W4GPS-7 (UIDIGI IGate with a WX station 
attached). W4GPS-7 digipeats quickly, but in this example the transmission 
is a direct beacon from the digipeater. What captured my attention was when 
I went to FINDU to list particular stations that had already been IGated 
from N8DEU-4. I would observe that the typical "find.cgi" on FINDU would 
display the N8DEU-4 IGate as the gateway station and then a minute to 10 
minutes later the delayed packets would enter the system and FINDU would 
then show a neighboring IGate as the gateway station for the same duplicate 
packets that are delayed. This delay seems to be taking place after the 
IGate hears it. There are numerous examples of this issue.

> 20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama
> 20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama
> 20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama

I was beginning to wonder why we needed an IGate in my area when FINDU is 
showing the neighboring IGate was the gateway median. The reality is the 
N8DEU-4 IGate is gating the local transmissions first, but the delayed 
packets from neighboring IGates appear to be the gating system only because 
they are delayed by over 1 to 10 minutes at which point FINDU does not treat 
them as duplicate packets due to the extended delay. Now, the problem that 
Coe, K4COE, originally reported is that these delays are unreasonable. If 
you are watching APRS through the APRS-IS, no wonder we see mobile beacons 
oscillating between reported locations on the map. The delays are really 
huge and thus could not be treated as duplicates because the originating 
packets are not numbered to identify there sequence.

Typically, N8DEU-4 (APRS+SA 2.21) connects to the core servers such as 
first.aprs.net, second.aprs.net, and third.aprs.net using a filtered feed on 
port 14580.
It looks like the KQ4TV-1 (javAPRSIgate) gate appears to be connected as or 
through KQ4TV-JS connected through a javaAPRSSrvr server at 
tennessee.aprs2.net using a filtered feed on port 10141.
It looks like KG4PID-15 (UI-View32 V2.03) connects through one of the core 
server such as third.aprs.net using a filtered feed on port 14580.

There is clearly a problem and it appears to happen somewhere between the 
IGates and how the data makes it to FINDU.



73's de Tim - N8DEU
Huntsville, AL





----- Original Message ----- 
From: "Robert Bruninga" <bruninga at usna.edu>
To: <brent.hildebrand at gmail.com>; <aprssig at lists.tapr.org>
Sent: Saturday, July 15, 2006 7:04 AM
Subject: Re: [aprssig] Re: Unreasonable xmission delay


I have not been following this closely, but could it be
a DIGI that is not set to true DCD?  If the digi is not
set to "software" in the KPC3, but is left set for
"channel busy", then at some digi sites, the squelch
will never close due to continutous QRM and so the
packets get held off for minutes at a time?  WB4APR

>>> brent.hildebrand at gmail.com 07/15/06 2:10 AM >>>
I see delays of 2-4 minutes on duplicate reports frequently.  Here is
a sample; you can the RMC time, and the time the packet was received,
and the path data.  I don't think it is the Igate program per se.
N7WLC and N6EX-3 are running the same program javAPRS, with EX-3 being
one version newer.  W9IF is running APRSD.  KB6JAG is running UIView.
In this example, reports from N6EX-3 are running 2 to 2.5 minutes
behind the original report, with the first instance of each report
being very soon after the packet was generated.  I saw the same type
of delay in the Bay area coming from a UIView station.  So is it the
IGate, or the APRS-IS?   I don't know.  I do know, this delay problem
is common for the stations I observe.

KH2JB-9 2/$RMC:150551,A 2006/07/15 05:52:26
I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N6EX-3
KH2JB-9 1/$RMC:150550,A 2006/07/15 05:52:06 I:GPSC17,N6EX-4*,qAR,N6EX-3
KH2JB-9 2/$RMC:150551,A 2006/07/15 05:50:59 
I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N7WLC
KH2JB-9 1/$RMC:150550,A 2006/07/15 05:49:59 
I:GPSC17,W6SCE-10*,WIDE2-1,qAR,W9IF
KH2JB-9 2/$RMC:150546,A 2006/07/15 05:48:17
I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N6EX-3
KH2JB-9 2/$RMC:150545,A 2006/07/15 05:47:09
I:GPSC18,WB6JAR-10,W6SCE-10*,qAR,N6EX-3
KH2JB-9 2/$RMC:150546,A 2006/07/15 05:46:59 
I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N7WLC
KH2JB-9 1/$RMC:150544,A 2006/07/15 05:45:53
I:GPSC17,WB6JAR-10,W6SCE-10*,qAR,N6EX-3
KH2JB-9 2/$RMC:150545,A 2006/07/15 05:44:59
I:GPSC18,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
KH2JB-9 1/$RMC:150544,A 2006/07/15 05:43:58
I:GPSC17,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
KH2JB-9 1/$RMC:150542,A 2006/07/15 05:43:20 
I:GPSC17,WIDE1-1,WIDE2-1,qAR,N6EX-3
KH2JB-9 2/$RMC:150541,A 2006/07/15 05:42:40 I:GPSC18,N6EX-4*,qAR,N6EX-3
KH2JB-9 1/$RMC:150542,A 2006/07/15 05:41:58
I:GPSC17,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
KH2JB-9 2/$RMC:150541,A 2006/07/15 05:40:58
I:GPSC18,WB6JAR-10*,WIDE2-1,qAO,KB6JAG



On 7/14/06, Tim Cunningham <tim_cunningham at mindspring.com> wrote:
> The problem is not the W4GPS-7 digipeater. The problem is deeper.
>
> I do not think this is a digipeater delay problem. It is likely an APRS-IS
> or FINDU problem. The delays on the network are horrific. Lately, I have
> been watching FINDU to see how things are working on the network. I 
> noticed
> that all the local traffic here was showing up on FINDU as being relayed 
> by
> KG4PID and KQ4TV internet gates. Since we just repaired the N8DEU-4 
> gateway
> and put it back on the air in place of the temporary N8DEU-2 gateway, I 
> was
> watching the activity and scratching my head on how the remote IGates 
> could
> be passing the direct and local traffic before the N8DEU-4 IGate. Then I
> seen Coe's message and realized something else was seriously wrong.
>
> The following sample packets pulled from FINDU show how much delay is 
> being
> encountered. There is over 1 minute from one gateway and 10 minutes from
> another gateway. I doubt this is a digipeater issue from what I can seen
> happening repeatedly in different directions.
>
>
> 20060714194906,N8DEU-12>S4TX1X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:'rEll"9j/]"7+}
> 20060714195019,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,KU4WW-1*,WIDE2,qAo,KG4PID-15:'rEll"9j/]"7+}
> 20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1:'rEll"9j/]"7+}
>
> 20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama
> 20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama
> 20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!3438.07NS08630.74W#PHG5630/W3,ALn
> Huntsville Alabama
>
>
> KG4PID-15 hears the same packet as N8DEU-4 in the second example, but yet
> there is a 1min 11sec delay. Now, NT4UX-2 digipeater hears the packet
> directly and NT4UX-3 picks it up for KQ4TV-1 where there is a 9min 20sec
> delay before it gets to the FINDU system. FINDU cannot remove these
> duplicate packets, because of the amount of time that has passed.
>
> What in the world is happening here?
>
> We know that W4GPS-7 digipeats packets immediately. N8DEU-4 is not a high
> speed rocket ship computer. It is a measly P166 running APRS+SA under
> Windows.
>
>
>
>
>
> 73's de Tim - N8DEU
> Huntsville, AL
>
>
> ----- Original Message -----
> From: "Richard Montgomery" <kb4ytm at gmail.com>
> To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>
> Sent: Friday, July 14, 2006 10:02 PM
> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>
>
> > Hey Bruce,
> >
> > Considering he (K4COE) is beaconing every 30 seconds, in 5 minutes time 
> > he
> > has sent an additional 10 packets. That would be really strange for a 
> > digi
> > to hold that particular packet for 5 minutes, when he has sent that many
> > more.
> >
> > Looks like W4GPS-7 is a UIDigi firmware digi with a WX station 
> > connected.
> > Possibly a problem with a tnc2 doing both? Too much data from K4COE?
> >
> > Let me know if you need any logs or anything from down this way.
> >
> > Richard
> > KB4YTM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Bruce W. Martin, KQ4TV wrote:
> >> I received the following information today.
> >> NT4UX-2 is a UIdigi v1.93 using N8DEU's reccomended settings.
> >> KQ4TV-1 is a javAPRSSrvr 3.11b03 Igate.
> >>
> >> Can anyone shed light on what can be done to eliminate 5 minutes of 
> >> delay
> >> for 100 miles of 3 hops.
> >>
> >> Bruce, KQ4TV
> >>
> >>
> >> On Jul 14, 2006, at 1:57 PM, Case, Coe wrote:
> >>
> >>> Bruce:
> >>>
> >>> Please evaluate the following raw data from FINDU.
> >>>
> >>> 20060714122325,K4COE>S4TS1V,WIDE1-1,WIDE2-1,qAo,N8DEU-4:`rAf!hW>/]"3r}
> >>> 20060714122427,K4COE>S4TR9X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:`rB\nsF>/]"3r}CERT,SkyWarn,RACES,ARES
> >>> ....
> >>> 20060714122815,K4COE>S4TS1V,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1:`rAf!hW>/]"3r}
> >>> 20060714122941,K4COE>S4TR9X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1:`rB\nsF>/]"3r}CERT,SkyWarn,RACES,ARES
> >>> It appears there is a 5 minute delay in nt4ux-2 and kq4tv-1
> >>> retransmission and igate posting to the internet.  It is causing FINDU
> >>> to overwrite current data with data and locations that are 5 minutes
> >>> old.  Two hops should be a worst case 20 sec delay, not 5 minutes.
> >>>
> >>> If you are working/Tracking vehicle to vehicle (not via the internet),
> >>> then getting to the first i-gate means nothing, you still need to 
> >>> wideN
> >>> to get to the other vehicle's mobile APRS.  Besides, as you can see 
> >>> from
> >>> my track displays over the last 3 weeks, I travel through area's that
> >>> even three hops do not get to any digi/igate.  (Colorado, South
> >>> Carolina, Louisianna as endpoints)
> >>>
> >>> Thanks,
> >>>
> >>> K4coe
> >>
> >>
> >> _______________________________________________
> >> aprssig mailing list
> >> aprssig at lists.tapr.org
> >> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >>
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

More information about the aprssig mailing list