| |
ZL3AI > APRDIG 25.09.03 09:54l 271 Lines 10232 Bytes #999 (0) @ WW
BID : 1975-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 22, 4/7
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<WB0TAX<7M3TJZ<ZL3VML
Sent: 030924/1404Z @:ZL3VML.#80.NZL.OC #:8955 [Chch-NZ] FBB7.00i $:1975-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Fw: Excessive Paths - WIDE5
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 22 Sep 2003 15:21:47 -0400 (EDT)
X-Message-Number: 19
On Mon, 22 Sep 2003, Bill Vodall WA7NWP wrote:
>You cannot make a general "nation wide" statement about paths. When
>something like WIDE3-3 is excessive in one area, a path like WIDE5-5 might
>be not only acceptable but actually desireable in other areas. It's up
>to each community and the number of active stations there to decide what
>the recommended path needs to be.
>
>The distance to the IS has nothing to do with the community "RF network"
>conventions.
Yes, this is entirely true. That is why this new idea of letting people
use WIDEn-N as needed without judgment and simply letting network
managers LOCALLy manage whether they will accept WIDEn-N DX traffic is so
beautiful.
It puts the control where it needs to be (LOCAL) and it lets local
operation return to fundamental APRS which is to support RELAY and WIDE
local communications.
In complex areas it is a fun challenge to figure out what digis need to
have WIDEn-N to get the long haul stuff into the city perimeter, but then
to keep it out of damaging the local networks where the population centers
are... But challenges is what HAMS do best. This returns network
management to local control. Lets all put on our thinking caps and
figure out how to use this new capability..
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: APRS telemetry application
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Tue, 23 Sep 2003 06:15:52 +1000
X-Message-Number: 20
Scott,
I do a similiar thing. Meters are a bit trickier. Maybe there are some JAVA
guruss.
What I do is telnet to aprs.net.au and use perl to extract data into mysql.
Once the data is there I use PHP jpgraph to make line graphs of weather
stations.
Actully now I think about it, I did do something like you are talking about
in VB6.
VB6 has a gauges pack with it.
I can see a need for things like :-
Baloon altitude plots
Temeparture plots
Speedo style displays
----------------------------------------------------------------------
Subject: Re: Fw: Excessive Paths - WIDE5
From: "Spider" <spider@rivcom.net>
Date: Mon, 22 Sep 2003 13:16:25 -0700
X-Message-Number: 21
From: "Georgette Sampson" <georgette.sampson@cox.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, September 22, 2003 6:23 AM
Subject: [aprssig] Re: Fw: Excessive Paths - WIDE5
>Consider that there was no IS path:
>
>Is WIDE5-5 ever a valid choice?
Have not heard a valid reason in the USA to run WIDE5-5 yet. APRS is a
LOCAL TACTICAL means of communication.
For those areas that 'think' they are doing their states a favor by
covering their entire state, they are just fooling themselves on APRS.
>Is APRS dependant on the Internet for proper operation?
Nope.
Jim, WA6OFt
----------------------------------------------------------------------
Subject: Re: Fw: Excessive Paths - WIDE5
From: "Spider" <spider@rivcom.net>
Date: Mon, 22 Sep 2003 13:25:20 -0700
X-Message-Number: 22
From: "Bill Vodall WA7NWP" <wa7nwp@jnos.org>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, September 22, 2003 9:17 AM
Subject: [aprssig] Fw: Excessive Paths - WIDE5
>You cannot make a general "nation wide" statement about paths. When
>something like WIDE3-3 is excessive in one area, a path like WIDE5-5 might
>be not only acceptable but actually desireable in other areas.
Bill, show me a case where WIDE5-5 is needed that does not cause excessive
propagation of the traffic that affects others!
>The distance to the IS has nothing to do with the community "RF network"
>conventions.
Yes and no. If a guy is trying to get seen on the IS and he can do it 4
hops less than WIDE5-5, yes is does matter to your 'RF NETWORK".
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Fw: Excessive Paths - WIDE5
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Mon, 22 Sep 2003 15:45:40 -0500
X-Message-Number: 23
>I'm a SkyWarn spotter and a storm chaser. When I go mobile with a laptop I
>use paths just long enough to reach my own Igate. In turn, our regional NWS
>office (150 miles away) uses APRS, but is only on the internet.
There's two of us? :)
I've been working with APRS and SSTV now for four years, through our county
EOC.
Haven't had too many get active yet, but I could put at least five trained
ops in the field with aprs and sstv if needed.
SSTV is great for local radar updates as well as observations inbound.
----------------------------------------------------------------------
Subject: Re: APRS telemetry application
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 22 Sep 2003 13:51:01 -0700
X-Message-Number: 24
Right, it just needs to be flexible so you can put together a custom
telemetry screen without any programming. The X10 ActiveHome software had
controls like that, though more for input than display. There's a
screenshot at http://www.x10.com/products/ck11a_more_sw_screen.htm.
I don't have my APRS spec handy... is there a combination object/telemetry
format? Things might get a bit hairy if you're trying to send lots of
values from a single station. OpenTrac handles it with multiple
entities... it parses something like this:
N1VG-7 (implied entity 0)
Comment: High altitude balloon experiment
Position: xxx.xxxxx, yyy.yyyyy, zzzzzz.z
<next entity>
Comment: External sensors
Temperature reading
Pressure reading
Humidity reading
<next entity>
Comment: Internal sensors
Temperature reading
Voltage reading
Current reading
So you wind up with three entities, N1VG-7:0, N1VG-7:1, and N1VG-7:2.
Since :1 and :2 don't provide a position, they're assumed to be at the same
place as :0, the base entity. If they had a position, they'd be treated
more like APRS objects, and could show up on the map on their own.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Excessive Paths - WIDE5 (NEW IDEA)
From: Mark Cheavens <mcheavens@usa.net>
Date: Mon, 22 Sep 2003 16:02:15 -0500
X-Message-Number: 25
I have stayed quiet long enough!
Here are some ideas that would be helpful and my .02 worth on path lengths.
1. in order for the ideas below to work WE (a group of hams) need to sit
down and either talk Kantronics into releasing the code for the KPC-3 and
the KPC-3+ OR do a clean room reverse engineer of the code and write our
own ROM for it.
2. All of the path problems revolve around what is best for each area! We
(as the sysops of a KNOWN area) KNOW what the path SHOULD be for our area!
3. Many users want MUCH more than "Just making to FindU".
My proposal would be to use the very much under used ssid routing feature.
Forget the directional routing and turn the N/S/E/W routing into "what I
would LIKE the network to do for me" path.
-8 as an example might be "get me to an i-gate" and the digi would put in
the path needed to get the user directly to an i-gate. This would eliminate
all the packets not needed if that is all the user wants.
-9 "get me to an igate and as far as the local system can stand" (low digis
would put in paths to get the farthest reach with a DIRECT path and end the
packet with a WIDE)
Since this works with Kenwoods as well it should please Bob!
ALL digipeaters would then change the path to the BEST path (or most
direct) for the area involved.
This would not require ANY hardware changes to the mobile base. Just
programming changes.
The NEXT part of this needs to be that ALL the APRS I-Gate clients need to
have a query function for remote stations.
I need to be able to query with a simple message (again path not needed!)
to LOCATION>I-GATE-8,USER-X,USER-Y,etc (ability to string is critical!)
This would send a message to a "location" server, via the locale I-gate
(direct path known by the Digi that hears me, note the -8) for a user by
his/her callsign and ssid.
It would be NICE if the local I-gate would then continue to spit out that
persons location (reverse gate) for a period of time, again this would be
best known by the LOCAL sysops!
This way I could get in my car NOW, turn on my computer, send a message and
query the location of XXXXX and find out where they are and continue to
track them (based upon local conditions) no matter WHERE in the world they
are.
These ideas would solve the "what is good for you is not good for us"
problem that we have now. It would also REDUCE all network traffic since
the digis would be changing ALL paths to directed paths!
The original packet length would be smaller.
Since this could be implemented easily in all of the UI-Digi and Digi-Ned
digipeaters immediately the only hold back is fixing the I-gate software
and the KPC-3's.
As the sysop of 4 digis and 2 I-gate's I would embrace the idea and
reprogram tomorrow all of my sites to help fix the problem.
(Three of the sites use UI-Digi and One is a KPC-3) Both I-gates use OLD
non-UI compliant TNC's in KISS mode with UI-View.
As an example of all of the above. When I drive from Houston (Metro area)
to Colorado I am NOT going to change the path as I drive, but I DO want all
of my packets to make it to an I-gate, I also want to be able to find out
where user X, Y, and Z while mobile in an easy method. AND if possible
continue to receive those location reports as I travel. For you weather
spotters out there, wouldn't it be nice to be able to query a weather
station up the road and get the weather information from it, even when out
of range?
It is MY belief that the ONLY thing holding us back from DOING something
about the problem is writing the software! NO hardware has to be replaced.
That is CRITICAL for a bunch of CHEAP hams. Let's face it we can't get
everyone to run trackers that have smart beaconing, BUT if we could get
everyone's packets to where THEY want them to go (if possible) then we
would be a LONG way down the road!
Let the war begin,
Mark Cheavens
KC5EVE
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
