| |
ZL3AI > APRDIG 18.07.06 11:31l 98 Lines 4066 Bytes #999 (0) @ WW
BID : 8404-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 25 #15, 2/2
Path: DB0FHN<DB0MRW<DK0WUE<7M3TJZ<ZL2BAU
Sent: 060718/0858Z @:ZL2BAU.#87.NZL.OC #:59211 [Waimate] $:8404-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 8
Date: Fri, 14 Jul 2006 23:29:48 -0700
From: BH <brent.hildebrand_at_gmail.com>
Subject: Re: [aprssig] Re: Unreasonable xmission delay
Ben Jackson wrote:
>Could these just be packets that are sent as 'current' (no timestamp
>from the tracker) reaching stations that tag them with a local clock
>whose time is not synchronized properly?
No. I have the original packets, and clearly the packets are delayed. The
tracker is also putting out NMEA data with GPS time.
------------------------------
Message: 9
Date: Sat, 15 Jul 2006 08:04:05 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
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
------------------------------
Message: 10
Date: Sat, 15 Jul 2006 10:00:05 -0500
From: "Tim Cunningham" <tim_cunningham_at_mindspring.com>
Subject: Re: [aprssig] Re: Unreasonable xmission delay
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/WA
3,Ln
>Huntsville Alabama
>20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!3438.07NS08630.74W#PHG56303
/W,ALn
>Huntsville Alabama
>20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!3438.07NS08637
0.4W#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
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 25, Issue 15
Read previous mail | Read next mail
| |
