| |
ZL3AI > APRDIG 28.09.03 12:26l 196 Lines 9352 Bytes #999 (0) @ WW
BID : 2001-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 25, 1/11
Path: DB0FHN<DB0RGB<DB0IGL<DB0FSG<OE7XLR<OE9XPI<DB0CZ<DB0GV<DB0SIF<DB0EA<
DB0RES<DB0EEO<DB0GOS<ON0AR<ON0AR<VK6HGR<VK3AVE<ZL2BAU<ZL3VML
Sent: 030927/1127Z @:ZL3VML.#80.NZL.OC #:9134 [Chch-NZ] FBB7.00i $:2001-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Thursday, September 25, 2003.
1. Re: APRServe IPs and Ports
2. aprsworld.net DCC presentation / paper now available
3. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
4. Re: APRS PERL SPLIT Help needed
5. Re: APRServe IPs and Ports
6. APRS PERL SerialPort
7. Re: WAS: TRACKING THIEF IS: 911 and GPS Phones
8. RE: APRServe IPs and Ports
9. Re: APRS PERL SerialPort
10. Re: APRServe IPs and Ports
11. NDGPS
12. RE: APRServe IPs and Ports
13. RE: APRServe IPs and Ports
14. Re: NDGPS
15. what am I missing in this?
16. (no subject)
17. RE: what am I missing in this?
18. Packet Stats
19. RE: what am I missing in this?
20. Re: what am I missing in this?
21. RE: JFindu Has Moved
22. Re: Part 2/2 -Re: Take Control - oh let's just go backwards on things,
that's the solution NOT
23. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
24. Re: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
25. RE: JFindu Has Moved
26. Re: Part 2/2 -Re: Take Control - oh let's just go backwards on things,
that's the solution NOT
27. Re: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
28. I guess we're going to agree to disagree Bob. Part 1 of ?
29. I guess we're going to agree to disagree Bob. Part 2 of ?
30. I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
31. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
32. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
33. Re: APRServe IPs and Ports
34. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
35. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
36. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
37. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
38. Re: I guess we're going to agree to disagree Bob. Part 2 of ?
39. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
40. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
41. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
42. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
43. Re: I guess we're going to agree to disagree Bob. Part 2 of ?
44. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
45. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
46. APRS fundamentals
47. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
48. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
----------------------------------------------------------------------
Subject: Re: APRServe IPs and Ports
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Thu, 25 Sep 2003 14:22:05 +1000
X-Message-Number: 1
While we are on the subject ...
Can someone make a web page that picks up from the web stream which web
servers are alive or dead and the addresses ?
What is the qao type codes ? who miantains them ?
Maybe the servers can send a "hi i am here " packet to a central site ????
----------------------------------------------------------------------
Subject: aprsworld.net DCC presentation / paper now available
From: James Jefferson <jj@aprsworld.net>
Date: Wed, 24 Sep 2003 23:41:15 -0500
X-Message-Number: 2
Hi group,
I've put my (intended) slide presentation and a brief paper on "Integrating
the Aprsworld.net Database Into Your Application" online. See the news page
announcement at:
http://aprsworld.net/info/news.php
It's a work in progress, so I'm open to any suggestions.
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Thu, 25 Sep 2003 01:04:43 -0400
X-Message-Number: 3
I think some reading up on the differences between RELAY,WIDE and WIDEN
protocols is in order. Maybe we can all learn something new here,
definitely seems to be a lot of myths and confusion out there. My Digi TNCs
are set to a regionally approved standard setup and WIDEN standards when
those captures were taken, nothing functionally wrong with my digi's. Yeah
I'm about to "modify" their standard settings a bit here shortly, grin.
They work well and work even better when WIDE is killed on them.
Considering the number and nature of the feedback I got, I feel pretty safe
I'm not alone in my feelings on this topic. Not everyone is using UIDIGI in
their area on all digi's, maybe you're lucky in your area, grin. Who's to
say what is best, Kantronics, UIDIGI, DIGI_NED, and so on, from what I
gather they all have their pros and cons and if your user base doesn't work
and play well together then you've still got the choice to filter or not
filter problem makers that will not change. That could be another topic all
together ;-)
I think you may be right, you may have a bigger problem than you think
depending on the terrain and digipeater layout/type your area uses. Shorter
packets are just one of the advantages, more controled (read dupe
prevention) is the major advantage to WIDEN. UIDIGI may of improved on
RELAY and WIDE dupe prevention some, but like most suggestions I've seen it
only works best if everyone is running the same parms/code and under
controlled circumstances or it can also create issues. Of course WIDEN also
requires some user cooperation, bad paths will break the WIDEN functionality
and you're right back to the dupe/loop heavy WIDE stuff. Either way, we're
still in need of a better way (protocol) to meet the inevitable challenges
we are facing as we go into the future. In short, there's no perfect
solution for us yet, WIDEN is just a step in the right direction. I don't
think HOPlimit was ever implimented in WIDEN and that is the problem you've
got with the clueless blasting out WIDE5-5 or worse up there.
73 de Jeff, KD4EVB
From a section in the somewhat out of date (WIDEN protocol has changed A
LOT, keen in mind that this was written awhile back before WIDEN caught on):
http://www.aprs.net/vm/DOS/DIGIS.HTM
********** WIDEn-n ALL DIRECTION GENERIC DIGIPEATING! ****************
THE ULTIMATE SOLUTION FOR MOBILE POSITION REPORTING
For four years, we have been asking for someone to develop the WIDEn-n
digipeater code. The WIDEn-n digi simply repeats ANY packet with the VIA
address of WIDEn-n; but ONLY ONCE. It keeps a copy (or checksum) of the last
30 seconds of packets, and compares each new packet that it hears with these
last ones to avoid dupes. This completely eliminates the multiple looping of
packets caused by multiple generic paths such as WIDE,WIDE,WIDE. Without
WIDEn-n, such a 3 hop path launched in the middle of 3 WIDE digipeaters that
all hear each other can generate as many as 3x3x3 or 27 dupes! In a WIDEn-n
network, there would only be three packets outward bound 3 hops.
NUMBER OF HOPS: The "n" in the WIDEn-n path indicates the number of hops.
Each DIGI that repeats the packet decrements the WIDE-SSID by one. So the -n
decrmenets to zero but the WIDEn portion indicates the original number of
hops so that recepients know how far it traveled. A long distance traveler
or special event of wide interest may use up to WIDE7-7 but a local commuter
may only want to use WIDE2-2 to limit QRM.
SHORT PACKETS! THe biggest advantage of the WIDEn-n routing is that every
packet still only has one DIGIpeater call. THis means only 7 bytes of
overhead no matter how far the packet goes...
TRACEn-n. Notice, however, that WIDEn-n packets arrive as WIDEn-0, and the
receiver has no idea how it got to him. If the WIDEn-n digis also support
TRACEn-n, however, then at each hop, not only does the digi decrement the n,
but it also INSERTS ITS MYCALL. This way a TRACEn-n packet arrives a
DIGIa,DIGIb,DIGIc,DIGId etc. Although this is very powerful, it also makes
the packets grow significanly in length as they propogate and should only be
used when messaging...
NEW TNC COMMANDS REQUIRED: To make this work, there are three new TNC
commands needed:
MYFlood1/2: Similar to MYAlias, sets up the callsigns to be used for WIDEn-n
routing. Usually WIDE and TRACE...
HOPLimit: This is a SYSOP parameter that can be used to limit the maximum
number of HOPS permitted in a network. Already the maximum number of hops is
limited to 7, since the upper bit of the SSID is reserved for future use.
However, some SYSOPS may feel empowered to limit the maximum number of hops
to some smaller number.
AGELimit: The WIDEn-n digi has to keep a copy of all digipeated packets (or
a unique checksum) for a brief period for comparison with new packets heard
to assure that it does not repeat a packet more than once. This age limit
determines how long packets must be kept for comaprison. If the time is too
long, then the list is big, If it is too short, then packets may propogate
in a circle and get repeated again. 30 seconds seems like a good starting
value for 1200 baud channels.
----------------------------------------------------------------------
Subject: Re: APRS PERL SPLIT Help needed
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Thu, 25 Sep 2003 15:17:14 +1000
X-Message-Number: 4
Thanks for all your great help !
I have several great ways to do this now !
Thanks Guys and GAls !
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
