| |
ZL3AI > APRDIG 15.05.04 21:52l 318 Lines 12549 Bytes #999 (0) @ WW
BID : 3261-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 01, 2/5
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<F5GI<F6KMO<7M3TJZ<ZL2BAU<ZL2BAU<
ZL3VML
Sent: 040515/1922Z @:ZL3VML.#80.NZL.OC #:24106 [Chch-NZ] FBB7.00i $:3261-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ui-view] Re: UIview object transmission vs APRSdos
From: "Spider" <spider@rivcom.net>
Date: Sat, 1 May 2004 08:40:05 -0700
X-Message-Number: 7
From: "Robert Bruninga" <wb4apr@amsat.org>
To: <K3for@aol.com>; <aprssig@lists.tapr.org>
Cc: <ui-view@yahoogroups.com>
Sent: Saturday, May 01, 2004 7:14 AM
Subject: [ui-view] Re: [aprssig] UIview object transmission vs APRSdos
><<<K3for@aol.com> 4/30/04 11:10:33 AM >>>
><We were planning on using UIview for our next scout
><event to keep track of about 50 troops...[as objects]...
><We abandoned UIview and went back to APRSdos, which
><uses... the original APRS "new-info-quickly/old-info-
><decays" algorithm.
I would like to comment and ask questions in regards to this. I moved the
UI-View related comments over to the UI-View sig, but I have others that fit
better here.
1. a. Why did you need to re-transmit the object production that was taking
place from the command center?
b. Why was out going data from command on the same frequency as
incoming sensor data?
c. Who, other than command, needed to see this data?
The reason I ask this is based on some past experience setting up commands
under the heading of Logistics/Communications.
We have learned that data coming into a command center, were there is a
large amount of possible data, as in tracking 50 troops, is as far as the
data needs to go. We learned the primary purpose of all sensor data,
including troop movement, terminates at the command center. Large scale map
displays, such as a wall projector or any kind of large
screen device would be used to display non-classified data within the
command post. Of course, there is not any classified data the hams would be
sending....but if they did, this data would be only on certain 'view
protected' terminals.
Terminals receiving this data, are tied to a local network within the
command. Data that needed for be shared between these terminals would only
gate this data to these other terminal....kind of exactly like the APRS-IS.
This data would not go back out on the incoming sensor channels (including
troop movement, environmental sensors, etc), ever.
IMHO, people who intend to use APRS in a command structure really need to
think hard about what I just said.
APRS at 1200 baud is a very limited resource...we all know that. APRS,
within a command, becomes a Rx only resource. Clogging up a single
frequency with retransmissions from a CP is just bad design.
50 troops becomes a giant number for one channel....if each human had a
tracker....plus the troop resources plus the
resources that support the troop. Trying to use one channel for all this is
a little nuts to begin with.
For what it's worth, if this is properly set up, you can easily track the
maximum about of units that can possible occupy a 1200 baud APRS system.
I know we are all limited in funding to build a multiple channel APRS system
to support a CP, but that should be considered. Get the different data on
different incoming channels. Then bring it all together on the CP intranet.
Looking forward to responses!
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: On digipeater naming conventions
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 2 May 2004 01:44:30 +1000
X-Message-Number: 8
Here in Australia we give the repeaters a reserved letter.
eg VK4RBT VK4RZA VK4RZB
And then again you can have SSID on top of that
VK4RZD-3 is a different freq to VK4RZD-1 but still on the same site.
Example
VK4RZD-3 might be UHF
VK4RZD-1 might be VHF
You know straight away, Country, State, Repeater, Freq
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----------------------------------------------------------------------
Subject: Re: GPS Watch -- does anyone know anything about it??
From: Leonard Revelle <lenrev@ameritech.net>
Date: Sat, 01 May 2004 10:55:02 -0500
X-Message-Number: 9
I did a search for NMEA in both the Forerunner and Foretrex 201
manuals and only got a hit in the Foretrex 201 manual.
It would appear that it WILL be suitable for use with the D7 if the
correct cable can be made/found.
On Sat, 01 May 2004 00:00:07 -0500, you wrote:
>Re: GPS Watch -- does anyone know anything about it??
Len Revelle N9IJ
"My career goal is to retire!"
----------------------------------------------------------------------
Subject: Re: On digipeater naming conventions
From: "Spider" <spider@rivcom.net>
Date: Sat, 1 May 2004 09:05:22 -0700
X-Message-Number: 10
From: "Earl Needham" <needhame1@yucca.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Saturday, May 01, 2004 9:06 AM
Subject: [aprssig] Re: On digipeater naming conventions
> I haven't followed this discussion too closely, but didn't the old
>packet system have MANY nodes that used the telephone area code along with
>an abbreviation for the name of the city?
>
> Like 305MLB for Melbourne, Florida...
The CLLI for Melbourne, Florida is: MLBRFL
Akron, OH would be: AKRNOH
Lake Havasu City, AZ would be: LHCYAZ
Very simple protocol and most people can figure them out just by looking at
them. No rocket science needed.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: GPS Watch -- does anyone know anything about it??
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 2 May 2004 02:20:07 +1000
X-Message-Number: 11
You would have to make sure that the GPS outputs the correct NMEA sentence
that is compatible with the D7.
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----- Original Message -----
From: "Leonard Revelle" <lenrev@ameritech.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Sunday, May 02, 2004 1:55 AM
Subject: [aprssig] Re: GPS Watch -- does anyone know anything about it??
I did a search for NMEA in both the Forerunner and Foretrex 201
manuals and only got a hit in the Foretrex 201 manual.
It would appear that it WILL be suitable for use with the D7 if the
correct cable can be made/found.
On Sat, 01 May 2004 00:00:07 -0500, you wrote:
>Re: GPS Watch -- does anyone know anything about it??
Len Revelle N9IJ
"My career goal is to retire!"
----------------------------------------------------------------------
Subject: Re: [ui-view] Re: UIview object transmission vs APRSdos
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 01 May 2004 12:34:52 -0400
X-Message-Number: 12
>>>"Spider" <spider@rivcom.net> 5/1/04 11:40:05 AM >>>
>1. a. Why did you need to re-transmit the object production
> that was taking place from the command center?
Becasue FRS and MIL radios were also used, and so only at HQ could we
gather the best info where everything was at.
> b. Why was out going data from command on the same
>frequency as incoming sensor data?
KISS. If you use dual freqs, then *everything* must be digipeated so that
everyone gets updated. This is not needed on a simplex freq. There only
distant stations needed the digi.
c. Who, other than command, needed to see this data?
Everyone. The purpose of tracking all these objects was so that everyone
at all key locations including the plattons themselves knew where
everything was...
We learned the primary purpose of all sensor data, including troop
movement, terminates at the command center.
Yes. In some situations yes. But such situations are then entirely
dependent on HQ for all info and it requries two way-coms to and from HQ
then for everything. Greatly increasing the comm load on other channels.
In many cases, APRS is supposed to lighten the load by letting everyone see
what is where so that there is a lot less bother on the backs of HQ then to
try to use voice then to tell everyone else what to do and where to go and
where their ride is...
>Large scale map displays, such as a wall projector or
>any kind of large screen device would be used...
>within the command post.
We did that once and found that th emap view was so large to cover
everything that then the radio operators and people that needed to be able
to click, zoom, select, and get detail info and messages and status had no
access to what they needed.
The big screen display is very impressive and WOW's the VIP's, but we found
it almosst useless for the individuals in HQ that needed ready access...
That's why I came up with the APRS ZIP-LAN conecpt where two clip leads and
a DB-9 connector can connect up a dozen laptops located at each operator's
position all to one TNC over just ordinary 2 conductor wire (zip cord). We
even use PUSH-PINS to connect each person to the zip cord for speed and
simplicity.. See APRSdos docs ZIPLAN.txt.
>Terminals receiving this data, are tied to a local network
>within the command. Data that needed for be shared
>between these terminals would only gate this data to
>these other terminal....kind of exactly like the APRS-IS.
Yes, exactly what the APRSdos ZIP-LAN does, but it required no LAN cards,
no sys-admin, no network, no prior knowledge, no set-up and absollutely
anyone with a DB-9 serial port could join. And any flavor of APRS clients
can also plug in, DOS, WinAPRS, MacAPRS, UIview, anything All clients can
receive off the ZIPLAN.
The only thing unique about APRS ZIP-LAN is that to "send" on the lan,
(throught the one common TNC) is that you have to send in the internet 3rd
party format. And only APRSdos implemented that as an option on the serial
port...
>Trivial to do. This data would not go back out on the
>incoming sensor channels (including troop movement,
>environmental sensors, etc), ever.
Yes, we agree. Every operator in the HQ needs his own access to the data
so that he can click, zoom and manage his comms needs. Back in 1995 LAN
cards and instant LAN's were not as readily available. That is why we
defined the ZIPLAN so that ANY one at any time, anywhere could play.
>IMHO, people who intend to use APRS in a command
>structure really need to think hard about what I just said.
>APRS at 1200 baud is a very limited resource...we all
>know that. APRS, within a command, becomes a Rx only
>resource.
We absolutely agree here.
>Clogging up a single frequency with retransmissions
>from a CP is just bad design. 50 troops becomes a giant
>number for one channel....
Yes, unless they are tracked with the original decaying algorithm so that
non-moving objects quickly decay down to a low rate. Think of it as
SMART-BEACONING for objectgs. It was fundamental to APRS, but none of the
followon clients implemented it. Thus most present clients cannot do much
with objects because it kills the channel. Or the rate is so low that the
latency of info is too high...
>Trying to use one channel for all this is a little nuts to begin
>with. For what it's worth, if this is properly set up, you can
>easily track the maximum about of units that can possible
>occupy a 1200 baud APRS system.
I thnk we agree in principle. But you are talking about a completely
centrally managed venue where only HQ needs to see the data. But APRS also
is an excellent tool and was designed to be a distributed system so that
everyone can see and everyone can input data. That is what I am talking
about here.
In the centrally managed case, if you have separate inbound and outbound
channels, then you also have these limitations:
1) Only HQ knows where anything is, thus burdening voice comms for all the
others that want to know
2) All info is critically depenedent on HQ. If the HQ APRS station goes
down, all is lost
3) Users in the field do not have access to any data unless sent back out
by HQ. Thus they have to either monitor both channels or be lacking in
data...
>I know we are all limited in funding to build a multiple
>channel APRS system to support a CP, but that should be
>considered. Get the different data on different incoming
>channels. Then bring it all together on the CP intranet.
>
>Looking forward to responses!
And I am not arguing with you at all. I am in full agreement to your
sugestions for a completely centrally located and managed comm event. But
that model doesnt fit all cases and in fact, fits very few of the amateur
events that I am familiar with... just some thoughts... Bob, WB4APR
Jim, WA6OFT
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
