| |
ZL3AI > APRDIG 31.08.03 22:33l 281 Lines 10397 Bytes #999 (0) @ WW
BID : 1839-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 27, 1/7
Path: DB0FHN<DB0RGB<DB0IGL<DB0FSG<IN3TRX<OE7XBB<DB0PV<DB0MRW<OK0PKL<DB0GRL<
SR6BBA<OK0PCC<OK0NAG<OK0PPL<DB0RES<ON0BEL<ZL2BAU<ZL3VML
Sent: 030829/1340Z @:ZL3VML.#80.NZL.OC #:7295 [Chch-NZ] FBB7.00i $:1839-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, August 27, 2003.
1. Re: Live Satellite Status page
2. Re: Live Satellite Status page
3. HT for APRS on sailboats
4. List of speeders
5. Re: List of speeders
6. RE: New fourth.aprs.net
7. RE: New fourth.aprs.net
8. ATTN users in Bowling Green, KY
9. Re: ATTN users in Bowling Green, KY
10. RE: New fourth.aprs.net
11. Re: ATTN users in Bowling Green, KY
12. Rules Question... Was Re: ATTN users in Bowling Green, KY
13. Re: ATTN users in Bowling Green, KY
14. Re: ATTN users in Bowling Green, KY
15. RE: New fourth.aprs.net
16. Re: BEACON RATES
17. RE: New fourth.aprs.net
18. EEPROM Burners
19. RE: New fourth.aprs.net
20. RE: New fourth.aprs.net
21. RE: New fourth.aprs.net
22. APRSWest.net ISP Switch
23. RE: New fourth.aprs.net
24. RE: New fourth.aprs.net
25. RE: New fourth.aprs.net
26. Re: Pleasantville (WAS: Path Police Idea)
27. RE: New fourth.aprs.net
28. Re: Pleasantville (WAS: Path Police Idea)
29. Re: HT for APRS on sailboats
30. Pleasantville, revisited...
31. RE: New fourth.aprs.net
32. Re: Pleasantville, revisited...
33. Re: Pleasantville, revisited...
34. Re: EEPROM Burners
35. Filling the gaps
36. Re: ATTN users in Bowling Green, KY
37. Re: EEPROM Burners
----------------------------------------------------------------------
Subject: Re: Live Satellite Status page
From: "Andrew VK4TEC" <vk4tec@hotmail.com>
Date: Wed, 27 Aug 2003 16:39:28 +1000
X-Message-Number: 1
Do you have a server with php and mysql ?
Andrew vk4tec
----------------------------------------------------------------------
Subject: Re: Live Satellite Status page
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 27 Aug 2003 07:54:07 -0400 (EDT)
X-Message-Number: 2
On Tue, 26 Aug 2003, Wes Johnston wrote:
>Would it be possible to rake thru APRS IS data for hits from ISS or other
>bird? Point being to get data auto instead of manually from user entry...
>user's will tire of qsl reports by hand. Of course, a cookie storing the
>callsign would be nice and speed things along.
That is already done automatically on www.ariss.net
though not in the same format.
Bob
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
ISS-APRS FAQ: http://www.ew.usna.edu/~bruninga/iss-faq.html
CUBESAT Designs http://www.ew.usna.edu/~bruninga/cubesat.html
APRS LIVE pages http://www.ew.usna.edu/~bruninga/aprs.html
APRS SATELLITES http://www.ew.usna.edu/~bruninga/astars.html
MIM/Mic-E/Mic-Lite http://ssdl.stanford.edu/mims/
----------------------------------------------------------------------
Subject: HT for APRS on sailboats
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Wed, 27 Aug 2003 08:25:27 -0400
X-Message-Number: 3
Though I haven't seen comments of late... I'm looking for feedback from the
group on a "cheap" HT to use for "APRS"... I'm going to try to track a
group of small sailboats that are racing over a 1 mile course. So the event
can be monitored on shore as well as on the committee boat...
In particular I'm looking for one's that are EASY to interface to a cheap
TNC (TinyTrac III or TigerTrac)....
Thanks in Advance
ALOHA
AH6LS
----------------------------------------------------------------------
Subject: List of speeders
From: "The Germinos" <mgermino@inreach.com>
Date: Wed, 27 Aug 2003 06:11:30 -0700
X-Message-Number: 4
A little while back, someone mention making up a list of people going fast.
I have a friend that would always make the list. His speed is not accurate
all of the time. This morning I looked him up and it showed him doing 144
MPH. Once APRS had him at over 900 MPH.
Mike
73, AD6AA
----------------------------------------------------------------------
Subject: Re: List of speeders
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Wed, 27 Aug 2003 08:31:55 -0500
X-Message-Number: 5
Must have been downhill :)
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 27 Aug 2003 09:45:46 -0400
X-Message-Number: 6
On 8/26/03 at 5:47 PM AE5PL Lists <HamLists@ametx.com> sent:
>These are not "buffered" packets. There are simply varying delays. All
Buffered is the term I have used since the start of APRS IS for the port
that includes a "buffer" of old position packets when you first
connect...initially it was roughly 8 hours of data, though now it is
usually just 30 minutes. What port on your server provides all live data
without any old data? From the port list on your server:
http://arizona.aprs2.net:14501/
it appears that port would be 10152 (which is the usual one for this), but
there is a notation "special IP's only". Indeed, when I connect to this
port I immediately get dumped.
>packets in APRS-IS are "buffered" and many factors affect where the
>start/stop of data feed for comparison is. Server load, bandwidth at
>the server, etc. all affect this.
Yes, it is true that between when a packet is sent and when it arrives, it
passes through many buffers, but that is not the meaning of the term, you
just seem to be anxious to pick apart every statement I make.
Yes, there are propagation delays of a few seconds between when packets
appear on different servers, which I account for in the method I use in
analysis, which is when looking at the data from server A to see if it
appears on server B, I throw out the first and last 15 seconds of server
A's data. I've explained this previously on the sig.
>As to whether connecting to the core is "the most reliable", this is a
>statement of your opinion with no proof. In fact, the reliability of
>data received from non-core servers is as reliable as that received from
>the core (and yes, there is proof of that). I recommend that users
>desiring the various capabilities provided by the non-core servers
>continue to connect to the non-core servers.
I do have proof...I place a live analysis on the web. It may well be that
the tier 2 servers are now just as reliable, I do not have data on that,
which is why I am trying to look at your server. However, tier 2 is most
definitely not more reliable, and I'm glad to see you have dropped that
claim. Using a tier 2 server means your packets may have to travel through
more servers to reach other users, and any time that happens there is a
greater potential for problems to occur.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 27 Aug 2003 09:16:05 -0500
X-Message-Number: 7
See below...
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Wednesday, August 27, 2003 8:50 AM
>Subject: [aprssig] RE: New fourth.aprs.net
>
>30 minutes. What
>port on your server provides all live data without any old
>data? From the port
>list on your server:
>
>http://arizona.aprs2.net:14501/
>
>it appears that port would be 10152 (which is the usual one
>for this), but there
>is a notation "special IP's only". Indeed, when I connect to
>this port I
>immediately get dumped.
First, this server is not "my" server. Other than having written the
software that it runs (as do 3 of the 4 core servers), I do not have
anything to do with any of the core or tier 2 servers.
Second, my guess as to why port 10152 is restricted by a sysop is to
reduce bandwidth and IP packet processing demands on their ISP while
still providing quality service to users of filtered ports.
I would guess that if you contacted the sysop of arizona.aprs2.net, you
could get your findu script server put on the list of "special IP's"
thereby alleviating this issue.
>Yes, it is true that between when a packet is sent and when
>it arrives, it
>passes through many buffers, but that is not the meaning of
>the term, you just
>seem to be anxious to pick apart every statement I make.
Not at all. Your implication was that somehow the tier 2 server was
doing buffering that the core servers do not. aprsD and javAPRSSrvr
have always referred to ports with a history dump as just that: history
dump. The term "buffered" has not been used because it is inaccurate.
All ports are buffered; some ports can be configured with a history
cache that is dumped to the client at connection time but it has nothing
to do with buffering.
>>As to whether connecting to the core is "the most reliable",
>this is a
>>statement of your opinion with no proof. In fact, the reliability of
>>
>Ido have proof...I place a live analysis on the web. It may
>well be that the
>tier 2 servers are now just as reliable, I do not have data
>on that, which is
>why I am trying to look at your server. However, tier 2 is
>most definitely not
>more reliable, and I'm glad to see you have dropped that
>claim. Using a tier 2
>server means your packets may have to travel through more
>servers to reach other
>users, and any time that happens there is a greater potential
>for problems to
>occur.
I have NEVER made the claim that tier 2 is "more reliable" than the
core. But, at the same time, your "proof" does not substantiate that
the core is "the most reliable" either. In fact, your "proof" is
showing arizona.aprs2.net as reliable as the core servers. My statement
is that the tier 2 servers are as reliable as the core and therefore
just as capable of providing high quality feeds to both IGates and
clients.
As to the number of servers that a packet goes through to get to the
"other side", there is a greater potential for problems due to the
increased number of computers that the packet goes through. Of course,
this is true for the Internet as a whole. A simple trace of an IP
packet route will show that most routes go through a minimum of 10
routers (usually 15 or more). In fact, with the non-core and core
servers keeping their software up-to-date, placing multiple servers in
the path does not increase the likelihood of lost packets.
Once again, I stand by my statement that your continual baseless
discouraging of the use of non-core servers is counterproductive to
APRS-IS and is alienating to those people (the majority of connections
to APRS-IS are via non-core servers) that run and use those servers.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
