| |
ZL3AI > APRDIG 20.07.06 11:50l 630 Lines 28139 Bytes #999 (0) @ WW
BID : 8411-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 25 #17, 1/2
Path: DB0FHN<DB0MRW<OK0PPL<DB0RES<DK0WUE<7M3TJZ<ZL2BAU
Sent: 060720/0941Z @:ZL2BAU.#87.NZL.OC #:59545 [Waimate] $:8411-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Fwd: Re: [amsat-bb] PCSAT2 (Robert Bruninga)
2. xastir vs. oziexplorer (Laidlaw, Andrew)
3. Re: xastir vs. oziexplorer (James Washer)
4. Re: xastir vs. oziexplorer (Jason Winningham)
5. IGate to APRS-IS data transfer delays (Tim Cunningham)
6. Re: Delayed packets (Curt Mills)
----------------------------------------------------------------------
Message: 1
Date: Sun, 16 Jul 2006 14:04:25 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: [aprssig] Fwd: Re: [amsat-bb] PCSAT2
>Hi to the list, just a minute ago I heard the PCSAT2.
>Can anybody tell me how it works?
>I mean where to TX and where to RX?
>I've tried to hear on 29.400 but nothing heard.
The uplink is on 29.401 MHz PSK31 or CW and we hope stations with lots of
power can try it..
>I can hear only packets on 70cm 435.275.
>Sent a connection ( C PCSAT2 ) via the 70 cm but no connection.
>Where I am missing?
The packet uplink is the APRS satellite frequency of 145.825 and the packet
downlink is 435.275. So you should try your connection on uplink 145.825
and downlink on 435.275.
The 29.401 uplink is not on unless triggered. To trigger the 29.401 uplink
and 435.275 donlink, you simple send a normal 1200 baud AX.25 connnect
request to PCSAT2 on the 145.825 uplink. The CONNECTED LED in the
satellite is what turns on the 10m to 435 transponder. ANd it will time
out after 1 minute.
Please experiment. We only have 1 month left for PCSAT2 and we hope
someone has enough power to get into the 10m uplink (which is very deaf)...
See the PCSAT2 operations page:
http://www.ew.usna.edu/~bruninga/pec/pc2ops.html
PCSAT2 also responds to 9600 baud digipeating and also you can sent the
connect request via 9600. THis is useful for some grond stations who use
9600 all the time to monitor the APRS downlink and so this way they do not
even have to change baudrate to trigger the 10m to 435 MHz transponder.
Bob, WB4APR
US Naval Academy Satellite Lab
------------------------------
Message: 2
Date: Sun, 16 Jul 2006 16:01:39 -0400
From: "Laidlaw, Andrew" <Andrew.Laidlaw_at_Woolpert.com>
Subject: [aprssig] xastir vs. oziexplorer
Hi All,
I'm looking at using APRS as an addition/supplement to some of my
activities. After doing some Internet research, it looks as if I would be
trying to use APRS inside either Xastir or OziExplorer. I would like to
hear some feedback from people who have experience with both programs as to
the good and bad points of each program. I realize that: Xastir is free,
and can be problematic to get running initially; OziExplorer and
OziAPRS/NETAprs cost money, but installs easier. I guess I'm looking for
feedback dealing more with daily operation, program crashes, etc (the after
it's up and running phase).
Thank you
------------------------------
Message: 3
Date: Sun, 16 Jul 2006 13:25:05 -0700
From: James Washer <washer_at_trlp.com>
Subject: Re: [aprssig] xastir vs. oziexplorer
Perhaps I'm just lucky... but I've never had any trouble with Xastir, nor
did I find it any trouble to download,build,install, or use.
------------------------------
Message: 4
Date: Sun, 16 Jul 2006 16:28:47 -0500
From: Jason Winningham <jdw_at_eng.uah.edu>
Subject: Re: [aprssig] xastir vs. oziexplorer
On Jul 16, 2006, at 3:01 PM, Laidlaw, Andrew wrote:
>Xastir is free, and can be problematic to get running initially
How much trouble depends a lot on how much experience you have building
Unix applications from source, and how many of the extra features (mostly
map formats) you wish to build with xastir. I find it pretty easy to deal
with, but I've been doing unix support for over 15 years, so I may not be
the best judge on how much trouble you'll have. (:
Building Xastir itself is borderline trivial, as long as you are satisfied
with APRSdos maps. Xastir depends on other libraries for reading other map
formats, and how much trouble it is to get these libraries compiled depends
on which platform/distribution you use. A "generic" linux distro will
typically be the least trouble to build.
After it's up and running, xastir is as reliable as anything I run on my
systems, and I have high standards. I've had over a year of uptime on
various systems (including an NFS/NIS/email server that serves ~1000
users). I consider any application or OS that needs restarting/rebooting
in order to maintain reliable operation to have serious flaws.
I keep two copies of xastir running (one at home and one at work) 24x7x365,
and they perform well. I have had occasional crashes in the past, but that
was with a bleeding edge release. Even xastir's latest development release
is typically _very_ stable.
-Jason
kg4wsv
------------------------------
Message: 5
Date: Mon, 17 Jul 2006 10:27:54 -0500
From: "Tim Cunningham" <tim_cunningham_at_mindspring.com>
Subject: [aprssig] IGate to APRS-IS data transfer delays
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
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
------------------------------
Read previous mail | Read next mail
| |
