| |
ZL3AI > APRDIG 09.02.04 13:54l 257 Lines 9926 Bytes #999 (0) @ WW
BID : 2800-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 06, 2/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2TZE<ZL3VML
Sent: 040209/1128Z @:ZL3VML.#80.NZL.OC #:18733 [Chch-NZ] FBB7.00i $:2800-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: HF APRS
From: Adam Pirkle <adam@pirkle.org>
Date: Fri, 6 Feb 2004 09:22:00 -0600
X-Message-Number: 8
Hi,
I'm a new member of the list and a new ham. I'm trying to figure out a good
setup that will allow me to run an APRS GPS beacon as I ride a bicycle from
Austin, TX to Anchorage, AK next summer (http://www.texas4000.org/).
After talking with a few people, it seems that the best approach will be to
have a small HT on my bike and a more powerful mobile unit in one of our
gear/support vans. The mobile will act as a relay for my weak HT signals.
However, I'm afraid that even with a fairly powerful 2m radio in the van, I
won't get enough range to hit the nearest digi when we get into the Rockies
and Canada.
My original plan was to relay with a Kenwood TM-D700 in the van, but I was
talking to my dad (K8CYJ) last night and he suggested the idea of using a
quad-band mobile that could retransmit my packets on HF APRS. Another
advantage is that if we're in the middle of nowhere and need emergency
communication, HF might be a better bet than 2m. Neither of us knows a lot
about HF (yet), and there doesn't seem to be a ton of HF APRS info on the
web.
So, I have a couple of questions, which might not have really
straightforward answers, but I'd love to get some input.
1. Is HF APRS alive?
2. What sort of range could I expect out of a mobile HF APRS rig?
3. Would I be able to expect coverage in the Rockies/Canada area?
4. Is it worth the hassle to use HF APRS instead of just 2m for this
purpose?
Regards,
Adam Pirkle
KE5AGK
----------------------------------------------------------------------
Subject: Re: maps
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 6 Feb 2004 10:30:36 -0500
X-Message-Number: 9
On 2/5/04 at 4:44 PM Jeff King <jeff@aerodata.net> sent:
>
>On Thu, 5 Feb 2004 13:35:33 -0600 (CST), Sean \\The RIMBoy\\ wrote:
>>On Thu, 5 Feb 2004, Jeff King wrote:
>>What/which APRS-IS servers? Are you talking about central servers,
>>Tier 2, or igates in general?
>
>In general. Do a traceroute, I'm not going to spoonfeed you. Distributed
>computing has a solid foundation and is well suited for APRS. I'm not
>interest in debating this. Yes, it is easier to have a big fat pipe..I'm just
>suggesting that it is a sole source of failure.
Of course it is. That is why I'm not advocating a single server anywhere,
and never have. There is a backup machine for findU, there are multiple
servers for the APRS IS, and as I said all along, whatever happens with an
APRS mapping server needs to be redundant.
However, redundant servers on fat pipes will beat redundant servers on DSL
any day. As hams we do have access to fat fat pipes, and that is what we
ought to be using!
Steve K4HG
----------------------------------------------------------------------
Subject: RE: HF APRS
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Fri, 6 Feb 2004 10:32:34 -0500
X-Message-Number: 10
Hi Adam,
Just a thought, but you could use a Kantronics KAM+ (Dual Port TNC) with VHF
APRS at 1200 baud on one side and HF APRS at 300 baud on the other and run a
custom path that would allow your bike station to gate over to HF in the
van. I wouldn't setup the TNC to cross over a station that was RELAY or
WIDE but maybe something like XCROSS or HF or something like that. (i.e.
APRS VIA HF,GATE,WIDE) This would allow your station to go from VHF APRS,
cross over to HF, gate back to VHF and go one hop.
Hmmm... But thinking about this you wouldn't get out on VHF locally... I
don't know how the TNC would respond if you had the digipeat and the Port
Gateway set to the same parameter. I could check into it if you like.
Maybe your setup will allow you to have a alternating path (i.e. APRS via
RELAY,WIDE2-2 and then go to APRS via HF,GATE,WIDE). Just a thought though.
73s,
Eric KF4OTN
AMSAT Member: 35360
TAPR Member: 8869
All contact logs are uploaded to the ARRL LoTW and eQSL.
----------------------------------------------------------------------
Subject: Re: HF APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 06 Feb 2004 10:56:25 -0500
X-Message-Number: 11
>>>Adam Pirkle <adam@pirkle.org> 2/6/04 10:22:00 AM >>>
I'm trying to figure out a good setup that will allow me to run an APRS GPS
beacon as I ride a bicycle from Austin, TX to Anchorage, AK next summer
(http://www.texas4000.org/).
REPLY: Dont overlook the use of Satellites. Each day you will get:
6 passes of ISS
6 passes of Sapphire (NO45)
6 passes of UO22 (which may not have been renabled for digi yet)
3 passes of PCsat (if its still alive)
But you will have to know approximately when they come over to know
when to QSY your transmitter...
Just a thought when you are out of range of the terrestrial system.
Bob
----------------------------------------------------------------------
Subject: Re: converting other formats to shapefiles
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 6 Feb 2004 08:13:57 -0800 (PST)
X-Message-Number: 12
On Fri, 6 Feb 2004, James Jefferson wrote:
>Anybody up for this? I wrote a aprsDOS to shapefile converter a few years ago,
>but it got lost in a disk crash.
>
>By using shapelib (or there is a shapefile writing library for Java, Gregg :-)
>do these converters isn't hard. Perhaps the input files could be parsed using
>some of the code from xastir. I see nice files in the source tree called
>map_dos.c and map_pdb.c that might work with some adapting.
I was thinking about this a month or two ago. What would be even better
would be to write an aprsDOS module for OGR. Then we could use ogr2ogr to
convert to/from aprsDOS maps at will.
It'd be much more useful than a standalone shape<->aprsDOS converter. You'd
be able to convert between a wider range of vector map types. You could
convert directly from Tiger/Line format to dos, to/from shapefiles, etc.
The aprsDOS code from Xastir might be a good place to start with respect to
writing an OGR module. Working code is always a good reference.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: RE: HF APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 06 Feb 2004 11:08:59 -0500
X-Message-Number: 13
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 2/6/04 10:32:34 AM
....you could use a Kantronics KAM+ (Dual Port TNC) with VHF APRS at 1200
baud on one side and HF APRS at 300 baud on the other and run a custom path
that would allow your bike station to gate over to HF in the van.
COMMENT: Yes, intereesting problem. Normally, I'd suggest RELAY,WIDE and
let your chase van XGATE call be RELAY. But the KAM cannot both RELAY on
VHF and also have its MYGATE call be RELAY also (one or the other takes
priority)...
AH, but since the chase van knows if it is in VHF area or not, it can be
responsible for changing the MYALIAS and MYGATE call back and forth as
needed so the bike doesnt care...
Just a thought.
de WB4APR,Bob
----------------------------------------------------------------------
Subject: Mapping plans
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 6 Feb 2004 11:33:32 -0500
X-Message-Number: 14
Without anyone coming forward with plans to provide a comprehensive mapping
server, let me lay out my plans for accomplishing this. First, all code is
to be released under the GPL. I'l like to do a sourceforge project, but do
not have the time to mess with setting one up, perhaps someone else is
willing to do this. Code will be in Perl with MySQL as the database.
The maps may be GIF/PNG/JPG maps as findU currently does, the APRSworld
maps, and any of the APRS format maps. The architecture allows any sort of
program to be plugged in.
The system consists of three modules, the librarian interface, database
backend, and mapping interface. It will designed for Linux, but since MySQL
and Perl have wide
Applications like findU and APRS clients generate a request via a web
interface, the primary parameters would be lat/lon/range). The mapping
interface processes the request, and returns either an error message or a
geo file (which in turn includes a url to the map image, saved at a
temporary URL on the file server).
I think this interface will provide the most utility to all APRS clients
with the least amount of work...many clients already have the ability to
deal with geo files, those that do not should be able to add the capability
without much difficulty. By sending back the geo file, it opens the
possibility for returning a cached map, that map be close enough for use.
There would be a slop parameter, perhaps defaulting to 5%, which could be
used to get exactly the map you want.
Note that this will not do any drawing on the map, the idea is for this to
be a backend for any sort of APRS client, allowing it to be used by any
client.
The librarian interface will provide a fairly painless way for someone to
manage the lists of maps, inlcuding boundaries, scales, and levels of
detail.
There will be a way to mirror the data and maps between servers.
While the server code itself will be open source, there is no requirement
that mapping modules be open source.
I'll be providing more details for the interfaces as I develop them, if
anyone want to help with development, please do, I'd love some help on this
one.
Also, when done there will be a need for one or more librarians that will
abccept
map submissions and check them into the system.
Documention maintainers and a SourceForger manager will also be most
helpful.
More to follow...
Comments welome!
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
