| |
ZL3AI > APRDIG 26.09.03 12:23l 227 Lines 9376 Bytes #999 (0) @ WW
BID : 1985-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 23, 5/7
Path: DB0FHN<DB0RGB<OE5XBL<OE2XOM<DB0PV<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<
ZL3VML
Sent: 030925/1606Z @:ZL3VML.#80.NZL.OC #:9013 [Chch-NZ] FBB7.00i $:1985-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: WIDEn-N to-UHF path splitters
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 12:49:45 -0400 (EDT)
X-Message-Number: 21
On Tue, 23 Sep 2003, Spider wrote:
>The same holds true by just using another vhf freq for local traffic
>too! A VHF freq for fixed data stations would not be a bad idea or for
>SAR where a single SAR could and would destroy the current "magic
>number" idea! Can you imagine 20 extra trackers coming into your local
>144.39 freq and transmitting every second or so? Odds are it would shut
>your local network down to the point of being useless! Yeah, it makes
>sense to have 144.39 as a 'national' freq for trackers, but LOCAL areas
>should consider using other VHF freqs...
I would be strongly opposed to this idea. This is just more and more
disintegration of APRS and fractionalization. Keeping it simple by
removing the DX WIDEn-N from the local area (could be your entire state)
will more than solve the problem of saturation. No need to go to a
Again, the concept is simple. Turn off WIDEn-N in digis that are flooding
your area with outside N-N traffic. Leave that digi intact as a
RELAY/WIDE digi with call substitution for all local or regional activity.
Install a second TNC and UHF transmitter that will still HEAR the WIDEn-N
traffic at that point, and send it out onto the UHF backbone where it can
still be heard in yoru area if someone wants to hear it.
Thus, nothing is lost. Yet one gains local control of what FLOODS your
area. In fact, by doing the crossband to UHF digipeat of WIDEn-N traffic
as it nears cities, then it can still GO THROUGH the city and out the
other side if all the surrounding WIDEn-N digis were using the same UHF
frequency.
In otherwords we have easily and effectively split all APRS traffic into
local and long-haul using what we already have. THus KISS...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Tue, 23 Sep 2003 12:40:54 -0500
X-Message-Number: 22
>But the idea is to stop digipeating WIDEn-N at the border digi before
>it gets to town and digipeat it out on UHF at that point. This way, the
>WIDEn-N is still available to anyone that wants to listen, but it does not
>QRM the central WIDE you are trying to protect.
Defining the borders could be interesting, given that many areas will
overlap.
>>If you make a special MAN (metro network) on some other frequency then
>>the digipeaters for the local area aren't subject to hearing the distant
>>posit reports on 144.39. Further, I am NOT specifying a local 70cm
>>frequency... because the local area frequencies could be coordinated so
>>that city A and city B do not have their LOCAL users on the same freq's.
>>Of course 144.39 will still be available for travellers.
for years, i've been proposing a high speed net on 440, announced on 2m.
>Yes, but I think it should be upside down from what you are proposing.
>THat way 144.39 still works EVERYWHERE and only those people that want to
>go read the WIDEn-N mail need to go find the UHF channel...
exactly.
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: "Daron J. Wilson" <daron@wilson.org>
Date: Tue, 23 Sep 2003 10:43:59 -0700
X-Message-Number: 23
<snip>
>In other words we have easily and effectively split all APRS traffic into
>local and long-haul using what we already have. THus KISS...
Let us just remember though that we don't already have:
2nd TNC at each location
UHF transmitter/cavity/antenna at each location
Dual band radios for each user in the area
Doing this presents a relatively large upgrade of the system, and we
need to be sure that is the most effective way of doing it.
I had wondered before if more of a streaming bit of data could be made
available on one UHF channel per area. Perhaps the incoming data on the
VHF side as well as some IP based information for the area/region could
be streamed in and buffered, then sent out on the UHF side in almost a
continuous stream of UHF data that could be decoded by stations having
that ability. In short, for local data you transmit and receive on VHF,
if you wish to see regional data you transmit on VHF and listen on UHF.
Again I echo the fact that we need to ultimately steer away from the TNC
on the hill top for routing, and consider an PC based (i.e. cheap)
solution. It seems like a moderate PC should be able to support two
data channels (UHF/VHF) as well as IP data and handle the necessary
routing.
It seems like we are honestly going the right direction, hopefully round
tabling the solutions like this will lead to the best answer.
73 Daron N7HQR
----------------------------------------------------------------------
Subject: RE: [aprsspec] OpenTrac
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 13:47:20 -0400 (EDT)
X-Message-Number: 24
On Tue, 23 Sep 2003, Scott Miller wrote:
>So I use 20 bytes for a simple value... fine, it's readable, but am I going
>to be able to view a plot of the value over time?
Sure, just query FINDU for all packets matching that format.
>Or do a query against an online database to compare readings from
>multiple locations?
Sure, every packet with such radiation data in it should be identical in
format. Trivial to parse.
> Where in the message does my river flow gauge go now?
Same place. Just parse for the words "river flow" or whatever format you
decide to use.. It is easy to write parsing code to look for Flood gages,
Radiation counters, absolutely anything you want to put in the comment
field, that is what it is there for. It is trivial to parse it out.
And it does not require constant revisions to the SPEC to do that. ANyone
can invent any format they want for any data they want in the comment
field. No need for a new protocol... APRS was written with that
extensibility in mind. THat is why there are 37 free bytes of Position
comment field that anyone can use for any thing they want...
>In OpenTrac, seven bytes gets me a
>single-precision floating point value unambiguously tagged with the correct
>units. And I can still add anything else I want to the message without
>having to worry about special delimiters or backwards compatibility.
>Yes, if I was going to do it today I'd put it in a comment field. But
>there's a LOT of stuff that people put in comment fields. Like you've said,
>it's about flexibility and enhancing communications.
>It's not a competition, Bob. I'm not here to argue how it could be done in
>APRS, I want to find out the RIGHT way to do it and make sure that's
>reflected in the new protocol.
I think we agree here. If you have a better protocol for future PC and
embedded processors data comunication that obsoletes all existing Kenwoods
and trackers and TNC trackers, then that is all fine and good, but it
would be best not to imply that it is APRS Version 2 and it probably
shouldn't target an already saturated 144.39 until or unless there is
unanymous local concurrence...
Bob
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 13:53:59 -0400 (EDT)
X-Message-Number: 25
On Tue, 23 Sep 2003, Daron J. Wilson wrote:
>>In other words we have easily and effectively split all APRS traffic
>>into local and long-haul using what we already have. THus KISS...
>
>Let us just remember though that we don't already have:
> 2nd TNC at each location
> UHF transmitter/cavity/antenna at each location
> Dual band radios for each user in the area
Ah, but those are only needed if one insists on continuing to see WIDE7-7
traffic from everyone in their surrounding states. THe fundamental
principle is to simply turn off WIDEn-N in those LAN's that are flooded
by external traffic. It requires NOTHING to do that.
I only offer the added TNC and UHF radio for those that then want to go
back in and still hear all that junk. I cannot imagine MOBILES would
ever be interested in flooding their screens with traffic from 500 miles
away. The only people that would need a UHF receiver (about $80) would
be an IGate that might need to still hear the DX traffic.
>Doing this presents a relatively large upgrade of the system, and we
>need to be sure that is the most effective way of doing it.
I dont think so. It is a trivial chnage. Just turn UIFLOOD in the
offending digi's TNC to OFF.
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Subject: Tactical RF Networking !!!
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Tue, 23 Sep 2003 14:06:44 -0400
X-Message-Number: 26
http://www.faqs.org/rfcs/rfc1677.html
Having heard repeatedly about the "tactical" nature of APRS... the one
thing that APRS really fails to deliver is ASSURED DELIVERY of position
info. In REAL tactical situations... you really need to get the message
through in time to be useful - or at least know that it failed to get
through...
I won't go at length - but it's interesting that there is an internet
RFC on the topic...
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
