[aprssig] IGate to APRS-IS data transfer delays
Robert Bruninga
bruninga at usna.edu
Mon Jul 17 13:46:24 EDT 2006
>>> tim_cunningham at mindspring.com 07/17/06 11:27 AM >>>
>This discussion is not for DCD problems it is for what
>the title suggests. DCD delay is a separate problem
>with digipeaters.
I agree 100% with your assessment and with what you are
trying to do. And I am sorry if I sound like a broken record,
but it seems that going and looking for Igate delays, without
figuring out a method to eliminated the DCD delays from
the process first, is trying to battle one set of unknowns
with a known problem mixed in randomly...
It is extremely tedious to look at every case. I guess what
I am asking, is that someone needs to write an algorithm
that uses a known set of rules to try to separate these two
problems so that energies are not wasted jilting at the
wrong windmill?
Again, I am only kibitzing, and may have missed a break-through,
but without a tool to separate the two problems, it seems
too tedious to do it by hand. I welcome Tim's suggestions
to try to reduce the potential problem on the IGate side. What
are the suggestions for nailing it all down?
Again, here are the facts as I understand them. Correct me
if I am wrong:
1) Delays are seen. These delays could be at DIGIS with DCD
problems or they could be at IGates.
2) The DCD problem has been around over 20 years, is well
known, is well explained, is very very common and is
very easy to accidently cause by wrong setups at the digi
3) There are no known IGate long delay processes other than
the seconds or so inherrent in the internet.
Other than those 3 facts, it seems like jumping the gun
to go looking for IGate delays when it appears to me
(could be wrong) that DCD could still be the problem.
ANd I agree, it is very hard to isolate the two... but since
RF DCD delays are so common, and long delays can perfectly
be described by that process, it just seems like we have
to find a way to eliminate that first.
My guess on an algorithm would be the following:
1) Look for all NMEA sentences (time stamped)
2) Compare times of arrival in APRS-IS
3) If a long delay is observed, then go look
for other data to corroborate whether it is a DCD delay
or not.
Only thing I can thinkn of is to have to then be lucky
enough to get TWO different stations NMEA through
the same digi within the "delay" time. Either, they
are both delayed and come "out" at the same time
(though different going in)...(proving a DCD delay)
Or if you can find one NMEA that is long delayed
and another one that got into-and-out of the
same digi within the time period of the first one's
delay. Then and only then, can you prove it was
not a DCD delay...
Good luck
Bob
Thanks Bob
>>> tim_cunningham at mindspring.com 07/17/06 11:27 AM >>>
This posting has been renamed from "Unreasonable xmission delay" to "IGate
to APRS-IS data transfer delays".
This discussion is not for DCD problems it is for what the title suggests.
DCD delay is a separate problem with digipeaters.
I am posting some discussion to this message to provide the background that
was discussed on the topic of IGate to APRS-IS data transfer delay to
explore why it happens. There has been discussion in the past pointing to
certain APRS gateway software as the problem with no convincing data to
clearly support this suggestion. The problem is position reports oscillate
back and forth when using the Internet feed for APRS data. We have seen data
deays from 1min 11sec to over 10min. Findu cannot filter out these delays
because of the lengthy delay. The end result is oscillating position reports
because they are delayed significantly in reaching the APRS-IS from various
IGates.
We need some basic guidelines for IGates to help reduce this data delay
problem.
After looking at a load of data, the one thing I see that could lead to
delay is the port an IGate uses to connect to an APRS-IS server. Generally,
a true IGate really does not care about what happens 2 digipeater hops
outside the IGate location (this can vary depending on the location). So,
one recommendation would be to use port 14580 and limit your range to say
200 kilometers or less for your Internet feed. If I am in Alabama with an
IGate and I have no reason to see a world feed or a USA feed. All I am
concerned about is what is within a 2 hop path in my area. This greatly
reduces the amount of processing power my computer needs and focuses its
strength in the area it needs to serve.
One correlation I see with IGates that have a large data transfer delay to
the APRS-IS is they are processing large amounts of data when using an
unfiltered feed for their area. Depending on the processing power of their
IGate CPU and I/O speed I think using a filtered feed can help speed up
IGates that seem to have significant delays in transferring what they hear
to the APRS-IS.
We use the "r/34/-86/200 t/n" filter option on port 14580 with the core
servers to limit the amount of data our IGate needs to process. This was
implemented because our IGate less responsive running on a P166 CPU under
Windows 95B. This filtered port dramatically increased the responsiveness on
our IGate. Why? The IGate now has less unnecessary data to process. We do
not care what happens all over the world and find it unnecessary to process
data that is meaningless for our IGate. Our data still gets to the APRS-IS
faster. Our local users still receive their APRS messages from any station
in the world that is directed to them and we still get our weather
bulletins. We do not seem to lose anything that is important using the
filtered port strategy. What we gained in speed was significant.
I am merely suggesting that IGates utilize port 14580 and limit the amount
of data your IGate processes on the incoming feed. You should see a
significant throughput when you implement this change to handle data
applicable to your area of concern. The port an IGate connects is a large
variable that exists in our environment today that can make a significant
impact to the transfer speed of data to the APRS-IS.
I apologize in advance if I am offending anyone by attaching some of the
history on the discussion. That is not the intention. The intention is to
understand and get a grasp on why we see some much variability in the time
between IGates feeding data to the APRS-IS. It is only my opinion that using
filtered port 14580 and limiting data to 200 kilometers or less would make
some significant improvements on existing and future IGates. If you have a
super powered computer, then the improvement by utilizing port 14580 may not
show such dramatic results as it would for a P166 CPU.
73's
Tim - N8DEU
Huntsville, Alabama
<snip> history
On Saturday Jul 15, 2006, at 8:37 PM, KQ4TV wrote:
KQ4TV-JS is the javAPRSSrvr and KQ4TV-1 is the (KISS) TNC-Radio
connected to it. KQ4TV-3 is the xastir (on Mac) station with radios
on 144.39 and 144.34. Both machines at my house. While time sync was
working fine on the KQ4TV-3 station, there was a problem with the
javAPRSSrvr but I think I have fixed it in the last hour or so.
Bruce, KQ4TV
On Jul 15, 2006, at 5:22 PM, Tim Cunningham wrote:
> Here is some additional data from the FINDU server I pulled just to
> see what type of delays were happening closer to the KQ4TV-1 IGate.
> The following data shows something is wrong between KQ4TV-1 and the
> APRS-IS in respect to delays. If you follow the packets you will
> see KQ4TV-3 gates a packet and then KQ4TV-1 gates the same packet
> from the same digipetaer at NT4UX-3, but KQ4TV-1 seems to always be
> lagging significantly and it varies up to 10 minutes. So, this is
> just another piece of data that suggest this problem is not a
> digipeater holding the packets.
>
> If you see the same packet from the same digipeater at 2 separate
> IGates, then the data should not have this type of delay. I could
> not tell how KQ4TV-1 and KQ4TV-3 are connected to the APRS-IS.
> Although I see KQ4TV-JS show up as connected to the server at
> tennessee.aprs2.net using a filtered feed on port 10141.
>
> 20060715204545,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.08N/08644.51Wj204/000/A=000000
> 20060715205225,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.19N/08644.47Wj022/005/A=000000
> 20060715205516,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.08N/08644.51Wj204/000/A=000000
> 20060715210932,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.12N/08644.43Wj220/005/A=000665/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715212237,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.16N/08644.59Wj346/020/A=000557
> 20060715212432,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.45N/08645.03Wj033/013/A=000593/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715212738,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.16N/08644.59Wj346/020/A=000557
> 20060715212947,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.45N/08645.03Wj033/013/A=000593/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715213045,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.50N/08645.13Wj340/016/A=000636
> 20060715213056,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.54N/08645.14Wj059/011/A=000623
> 20060715213136,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715213252,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.14N/08644.56Wj125/019/A=000511
> 20060715213725,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.50N/08645.13Wj340/016/A=000636
> 20060715213917,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715214040,KE4PJW-9>APT202,NT4UX-3,NT4UX-2,WIDE2*,qAR,KQ4TV-1:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715214241,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.14N/08644.56Wj
>
> KQ4TV-1 accounted for the largest delay in my initial posting but
> we see that KG4PID-15 also has some delays not related to a
> digipeater from the data I posted. There are delays taking place
> between the IGates and the APRS-IS. What we need to know is where
> does it happen. Is it the IGate or is it the server the IGate
> connects that delays the packet?
>
>
> 73's de Tim - N8DEU
> Huntsville, AL
>
>
>
>
>
> ----- Original Message ----- From: "Tim Cunningham"
> <tim_cunningham at mindspring.com>
> To: "Robert Bruninga" <bruninga at usna.edu>;
> <brent.hildebrand at gmail.com>
> Sent: Saturday, July 15, 2006 1:47 PM
> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>
>
>> Bob,
>>
>> How can I tell these are the same packet when they are un-
>> numbered? There is a way to tell.
>>
>> In the first example, my mobile was moving and only transmitted
>> this packet one time from that location. It is the only location
>> in a 48 hr period that was transmitted. There is only one match
>> for that packet in that time frame. One packet from one beacon
>> from one location. So, I can only conclude there was one packet
>> and it is the same packet. As I mentioned earlier, there are
>> numerous examples of this problem, but I only listed two examples.
>> Since I manage the configuration at W4GPS-7 I know it operates and
>> digipeats packets instantly with no delay. I can confirm this with
>> my local system and there are NO DCD delays on this digipeater or
>> I would see the problem locally. Here is the packet, a single
>> packet, that was beaconed from one location only.
>>
>>> 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,KG4P
>>> ID-15:'rEll"9j/]"7+}
>>> 20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4T
>>> V-1:'rEll"9j/]"7+}
>>
>> The first was heard direct by N8DEU-4.
>> The digipeated packet via W4GPS-7 and KU4WW-1 are picked up by
>> KG4PID-15 and put on the APR-IS at 1min 13sec later.
>> The digipeated packet via W4GPS-7 and NT4UX-2 are picked up by
>> KQ4TV-1 and put on the APR-IS at 10min 33sec later.
>>
>> Now, it is possible for KU4WW-1 and NT4UX-2 to delay the packets.
>> I confirmed with Bruce that NT4UX-2 seems to be working correctly.
>> So, yes there could be a DCD delay somewhere. This is possible and
>> without some hard data from those location this cannot be confirmed.
>>
>>
>> In the second example, I can confidently confirm it is the same
>> packet because the digi will not send a second beacon in the time
>> frame documented. So, if you imply that DCD is a problem, this
>> example will erase that thought by the first direct packet:
>>
>>> 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
>>
>>
>> The first direct beacon from the W4GPS-7 digipeater is picked up
>> by N8DEU-4 and KG4PID-15 IGates AT THE SAME TIME. The data from
>> KG4PID-15 arrives to the APRS-IS 1min 11sec later. This is very
>> similar to the time delay in the previous example. However,. I
>> could infer that there is probably only an additional 2sec delay
>> at KU4WW-1 in the first example. Again, the data from numerous
>> packets also suggest this same delay direct or via a digipeater.
>> However, this example clearly shows a delay to the APRS-IS from
>> the same direct packet heard by 2 separate IGates. So now if you
>> say how can you be sure these are the same packet, then I would
>> say the problem is far more serious if there were not because that
>> packet is only transmitted every 29 minutes. So, I surmise that it
>> must be the same packet in that sequence or the problem is far
>> worse because the specific beacon in question is on a 29 minute
>> cycle. These are only facts that I can confirm and each example I
>> pull from the FINDU server support the same results when they can
>> be confirmed and classified as the same packet.
>>
>> While there may be DWAIT=0 or PPersistance = 255/SlotTime = 1
>> issues out there. I think the examples I provided point to a
>> secondary problem that happens on the data transfer from the
>> IGates to the APRS-IS. In my examples we can confirm there is an
>> data delay on the APRS-IS in the case between N8DEU-4 and
>> KG4PID-15. There are some similarities at KQ4VT-1, but there could
>> be some variables at NT4UX-2 and NT4UX-3 that I cannot see from
>> here, but from what Bruce has explained it does not seem likely
>> that this is a DCD delay issue. I am sure I can pull a ton of
>> examples on the issue, but since I have no control of how fast
>> data gets from every IGate to the APRS-IS, this one is out of my
>> hands.
>>
>>
>> 73's de Tim - N8DEU
>> Huntsville, Alabama
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: "Robert Bruninga"
>> <bruninga at usna.edu>
>> To: <brent.hildebrand at gmail.com>; <tim_cunningham at mindspring.com>
>> Sent: Saturday, July 15, 2006 11:57 AM
>> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>>
>>
>>>>> tim_cunningham at mindspring.com 07/15/06 11:00 AM >>>
>> Tim,,
>> bear with me. Im just tyrying to see the picture. But two things
>> confuse me. How can you tell these are the same packet, but
>> delayed? Why are they not simply the next beacon? There is no
>> serial number or time stamp in them, so there is no way to tell...?
>>
>>> This is not a DCD issue in the examples I provided.
>>
>> And how can you tell that? If the packet is delayed on RF
>> it is going to be delayed getting to an IGate and FINDU.
>>
>>> 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.
>>
>> The exmaples below are all -from- W4GPS-7, no indiciation
>> of a digi -by W7BPS-7.... Maybe I am looking at the wrong packets.
>>
>> Anyway, I dont want to waste your time, but from what I see,
>> I dont see how one can rule out an RF delay through a digi
>> that is hearing too much and it's swuelch just wont close so it
>> can transmit for minutes at a time... Its a simple cause,
>> and a simple fix...
>>
>> Bob
>>
>> 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,KG4P
>>> ID-15:'rEll"9j/]"7+}
>>> 20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4T
>>> V-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
More information about the aprssig
mailing list