| |
ZL3AI > APRDIG 19.09.03 10:14l 238 Lines 9215 Bytes #999 (0) @ WW
BID : 1942-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 16, 7/9
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PCC<OK0PAD<OK0PPL<DB0RES<ON0AR<VK6HGR<
ZL2BAU<ZL3VML
Sent: 030918/1412Z @:ZL3VML.#80.NZL.OC #:8616 [Chch-NZ] FBB7.00i $:1942-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Travel Report on use of "WIDE" - IGATE access
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 16 Sep 2003 12:16:17 -0700
X-Message-Number: 42
I think the main digis of interest on that strech are N6CP-1 and KD6DSI-5.
As far as I know they don't ignore WIDE. I agree that that's not the way to
do it... WIDE should work the same as WIDE1-1.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Tue, 16 Sep 2003 15:36:56 -0400
X-Message-Number: 43
I, too, am using UI-View 32 in the EOC and wherever my laptop is (home,
jeep, etc). I am using PMaps 6 right now with great success. There was a
talk a while back with the Firenet Guys about topo maps... I forget where
we got with that. I'm still looking for maritime maps...
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "Ramon F. Kolb" <ramon@ieee.org>
Date: Tue, 16 Sep 2003 15:57:53 -0400
X-Message-Number: 44
.... and there is full integration for both PMAP5 and PMAP6 in UI-View.
Also, the UI-View API would make it easy for any half-baked programmer
(which would thereby disqualify myself) to program an interface between
a mapping engine and UI-View, while maintaining all UI-View
functionality. For Europe (where SAR is not part of HAM Radio due to
licensing restrictions), there is Auto-Route integration. Also, there is
some integration for Vicinity maps coming up (I saw some discussion on
that, but I haven't followed it too closely) where you can pull life
maps off the internet. Recently, a life web server was added a-la
APRS+SA. Use the internet to see what your station is hearing and doing.
I'm not sure if that's usable for SAR, but it's rather useful in
public-relations situations. (example: http://66.43.237.146/ , which is
Hasan N0AN's webserver which I am quoting here without permission...
thanks/sorry Hasan!)
So no... it doesn't only work with geo-referenced bitmaps... v1.97 is
the latest and is available at TAPR or http://www.ui-view.com. It's
supported via ui-view@yahoogroups.com, but naturally all of you already
knew that and I'm stating the obvious.
73s, Ramon
KX1T / PA3EUG
http:
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "KA0WFI Chuck" <KA0WFI@arrl.net>
Date: Tue, 16 Sep 2003 13:44:32 -0700
X-Message-Number: 45
Scott, Curt et al,
Here in Whatcom County, WA, along the Canadian border, RACES personnel have
be experimenting with the beta of a new program called DMapper:
( http://www.roadfacts.com/software/dmapper/dmapperInfo.htm )
Looking at their site, you will see the explanation of their capabilities.
During Field Day, we were simultaneously tracking several targets over
MapTech Terrain Navigator PRO's topographic base maps. And yes, contours
and shading are available, although we have not tested the program with that
in mind.
I have not worked with the author since Field Day. This new thread prompts
me to renew that effort and to see where development stands at this time. I
will see if he will update his web site.
Although the last version I used was just a little bit rough around the
edges, it will not take much to make this the Software of Choice from our
point of view.
Cheers,
Chuck KA0WFI
Lummi Island WA
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "Spider" <spider@rivcom.net>
Date: Tue, 16 Sep 2003 13:56:45 -0700
X-Message-Number: 46
----- Original Message -----
From: "Scott Miller" <scott@opentrac.org>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 16, 2003 9:30 AM
Subject: [aprssig] APRS software for SAR
>Ok, I'm getting tired of the path debates, so here's some fuel for a brand
>new flame war. =]
>
>What do you think is the best APRS software package for Search and Rescue
>use? And I mean in the command post, not PDAs in the field.
>Please share your SAR software experiences... Xastir's my top choice for
>now, but I'm always willing to listen to alternatives.
>
>Thanks...
I would say UI-VIEW and Xastir at this time. They are well supported. By
experience, you might find yourself leaning towards paper maps during a
search at a command post. I know how to read and plot on a map....but so
far the large majority of people I deal with on searches do not know how to
use a map! As you can see by my posts, I use APRS to collect data that
helps me paint a better common picture of the battlefield...so-to-speak.
Tracking team members, airships, etc, greatly reduces the need for voice
communications and allows the comm unit to communicate via voice channels
for messaging and traffic much better. I do not try to bundle all comm
into one mode. APRS is only a part of the tactical communications picture!
Jim
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 16 Sep 2003 13:56:39 -0700
X-Message-Number: 47
Now if it could give me a real-time interface with ArcView, I might be
interested...
----------------------------------------------------------------------
Subject: Re: APRS software for SAR
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 16 Sep 2003 14:14:38 -0700
X-Message-Number: 48
Yeah, as I imagine the initial installation, the scope would be fairly
limited. I still expect to have users copying down information on paper
topo maps and notepads for now. More intuitive and more reliable.
BTW, did anyone else see the first episode of 'Tactical to Practical' on...
umm.. History Channel, I think. Or maybe TLC. They had a segment on GPS,
and showed a SAR team using Garmin Rinos. Of course, for the demo the
search area was limited to 5x5 miles. =] And the CP was having to copy
data off the tiny little Rino screen...
Speaking of Rinos, how's the decoding project coming?
And on the paper maps subject, would 7.5' topos be usable printed at
11"x17"? I think that's the largest size I've seen in a reasonably
affordable inkjet printer. And having fresh quads printed in the field
would beat the heck out of the stupid photocopied unreadable gray blobs they
always like to hand out.
Mandatory reading for all ARES and SAR members: EDSAR's 12 codes at
http://comspark.com/esarc/funcodes.htm.
Scott
N1VG
----------------------------------------------------------------------
Subject: Proper DIGI ID interleaving
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 16 Sep 2003 18:11:35 -0400 (EDT)
X-Message-Number: 49
Part of the problem might be that some digis are not correctly
implementing the every-10-minute-Direct concept. If incorrectly done, it
could be adding a LOT of duplication... Here is how I would do it:
DIRECT every 20 starting at 00
WIDE every 40 starting at 10
WIDE2-2 every 80 starting at 30
WIDE3-3 every 160 starting at 70
The result is a local packet every 10 minutes (with only one missing once
every 2.5 hours):
0 1 0 2 0 1 0 3 0 1 0 2 0 1 0 . 0 1 0 2 0 1 0 3 0 1 0 2 0 1 0 . 0 1
1 2 1 1 2 1
1 1
Time increment above is every 10 minutes, where 0 means a DIRECT 0 hop
packet, 1 means a WIDE packet, 2 means a WIDE2-2 packet etc... And you
see how this results in no duplication, yet the local area gets no more
than the desired 10 minute rate.
CONVERSLY, if sdigis are uwing the brute force method of 10, 30 and 60
minutes, then we end up with a lot of bunching and almost DOUBLE the
number of local ID's as follows:
0 0 0 01 0 0 012 0 0 01 0 0 0123 0 0 01 0 0 012 0 0 01 0 0 0123 0 0 01 0
1 12 1 12
1 1
And you can see that there are duplicate ID's every 30, triplicate's every
60 and Quads every 2 hours, etc, for almost DOUBLE the number of total
packets than what was intended. This averages at the LOCAL level to be a
packet every 6 minutes. That is too much...
Maybe if we implement it this way, this will help get the number of
packets down to the only 0.0016 channel load intended...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: PCsat holding.
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 16 Sep 2003 18:19:10 -0400 (EDT)
X-Message-Number: 50
Since PCsat recovered this weekend, I have just kept my mobile on 145.825
and have snagged 24 users in my radio's station list. This last pass I
saw 18 on the base station PC.
The PCsat A side has been resetting, but fortunately the B side is still
holding the spare UHF receivers OFF and conserving power. I restored the
A side (PCSAT-1 call) and cleared the 72 hour fail safe timer at about
2205z
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
