| |
ZL3AI > APRDIG 19.04.03 08:56l 236 Lines 9216 Bytes #999 (0) @ WW
BID : 1174-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 16, 1/2
Path: DB0FHN<DB0ZWI<DB0HDF<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<ZL2BAU<ZL3VML
Sent: 030418/1040Z @:ZL3VML.#80.NZL.OC #:64146 [Chch-NZ] FBB7.00i $:1174-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, April 16, 2003.
1. Uploading GPS way points via GPRS
2. Re: HF APRS Suggestion
3. APRS using PSK31
4. Re: HF APRS Suggestion
5. Re: HF APRS Suggestion
6. Beware of New Brain-Dead GPS Devices
7. New Delorme GPS with USB
8. Pizza Bash-Dayton
9. MapBlast Assimilated !
10. Re: Opening up the proverbial can o' worms - baaack to it and opening it
wider
11. Re: MapBlast Assimilated !
12. Pizza Bash
----------------------------------------------------------------------
Subject: Uploading GPS way points via GPRS
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Wed, 16 Apr 2003 20:08:21 +1000
X-Message-Number: 1
People
I thought I would let you know about a demo that I just got working. I
connected my GPS receiever up to a STAND ALONE GPRS modem which provided
a TCP/IP connection to some server software that I have written.
Basically I wrote some software that connects to the IGATE system, and
waits for a GPRS device to connect. When it connects, it sends the
device $GPWPL commands, with the GPRS device set up to send this
information out it's serial port. The same software also takes the data
from my GPS and sends it to the IGATE system after adding my callsign.
This work was done so that you can track as if you had a D7 handheld,
but where no ham network exists.
More information is available on
http://www.radio-active.net.au/web/tracking/teamtrak.html
Darryl
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
Darryl@radio-active.net.au | www.radio-active.net.au
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 16 Apr 2003 06:33:16 -0400
X-Message-Number: 2
>PSK31 uses Varicode, and is not byte orientated. See:
>
>http://www.kender.es/~edu/psk31theory.html#Information Coding
>
>Hence, W2EV>HK is actually 72 bits long (9 bytes).
>
>Interestingly enough, if you interested in saving some transmission time,
>you can re-code what you where sending as:
>
>w2ev>hk (lower case) it would be 59 bits long , a transmission savings of
>18%. This is because Varicode is designed to save space based on the most
>used characters, which are lower case and not upper case.
Oh Duh! :) Of course. I was more keyed in to answering the "bit stuffing"
aspect of AX.25 and the fact that it is only one mode used by APRS that I
ignored entirely the varicode thing (there's even a short snippett on it in
this month's QST).
In fact, folks on APRS on 28.131 PSK31 use lower case wherever possible for
exactly that reason. Because most APRS software forces upper case it's
usually a combination of both (W2EV>HY:[fn03xd] -or- W2EV>CQHY:[fn03xd]).
Other software is being developed that does not force uppercase, but that's
a future thing.
Thanks for the reminder, Jeff.
Ev, W2EV
----------------------------------------------------------------------
Subject: APRS using PSK31
From: "Germino" <mgermino@inreach.com>
Date: Wed, 16 Apr 2003 04:50:31 -0700
X-Message-Number: 3
Where can I find more information on APRS using PSK31. What software do you
use and how do you set it up?
Mike
73,AD6AA
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: <BobDonnell@arkalmus.com>
Date: Wed, 16 Apr 2003 09:36:28 -0700
X-Message-Number: 4
Hi Ev, and all,
Ok - you're right, and I missed that. If it requires special software
to support it, as would seem to be logical in an environment where
gateways exist, what's wrong with having it be the responsibility of
that gateway software to add/remove the 2-byte APRS compatibility header
when the data stream makes the transition between the non-AX.25 APRS
environment and the AX.25 APRS (or APRS-like) environment? I think
that's a much more reasonable approach than requiring all of the various
and sundry existing APRS software packages to make their programs
non-compliant with the intended design of ALTNET to implement your
proposed view of how ALTNET should be used. If it's a matter of client
display software that can accept data from both AX.25 networks and
non-AX.25 networks, it would then also be the responsibility of that
client program to deal with the disparities in data between each air
interface.
73, Bob, KD7NM
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 16 Apr 2003 15:38:50 -0400
X-Message-Number: 5
>Ok - you're right, and I missed that. If it requires special software
>to support it, as would seem to be logical in an environment where
>gateways exist, what's wrong with having it be the responsibility of
>that gateway software to add/remove the 2-byte APRS compatibility header
>when the data stream makes the transition between the non-AX.25 APRS
>environment and the AX.25 APRS (or APRS-like) environment? I think
>that's a much more reasonable approach than requiring all of the various
>and sundry existing APRS software packages to make their programs
>non-compliant with the intended design of ALTNET to implement your
>proposed view of how ALTNET should be used. If it's a matter of client
>display software that can accept data from both AX.25 networks and
>non-AX.25 networks, it would then also be the responsibility of that
>client program to deal with the disparities in data between each air
>interface.
Hi Bob,
There is no gateway system that will automatically add needed information
to the header, therefore, the responsibility rests on the user to place it
there.
You may have missed a followup showing that one can use IDxx and CQxx and
nothing is broken. The idea is 100% APRS compatible. There's no downside,
and lots of advantages.
Regards,
Ev, W2EV
Recap:
KD7NM>HK,... 20m operation
KD7NM>IDHK,... 20m operation from a station that is NOT interrogative
KD7NM>CQHK,... 20m operation from a station that IS interrogative
All three are valid APRS protocol-compliant systems. It is up to the
originator as to which one they choose to use. The first is an ALTNET, the
other two are not. All three are parsable should that function be of use
to propagation study, etc.
HG = 30m
HK = 20m
HR = 15m
HY = 10m
VB = 6m
VK = 2m
----------------------------------------------------------------------
Subject: Beware of New Brain-Dead GPS Devices
From: WA8LMF2@aol.com
Date: Wed, 16 Apr 2003 17:27:10 EDT
X-Message-Number: 6
[ This is a response I made to a post on another mailing list, but it is of
sufficient general interest to the APRS community that I am reprinting here.
de WA8LMF ]
In a message dated 4/16/2003 10:27:44 AM Pacific Daylight Time,
ksykes2742@aol.com writes:
>There is a new Earthmate available soon. Looks like a vast
> improvement over the old one. Smaller, faster etc. Worth a look.
>
> Kinsley
>
It's been out for a month or so now. The unit by itself only works on USB
ports of a PC. Supposedly an optional serial cable adapter will be available
in a month or two.
When the serial cable becomes available, this may be the ultimate GPS
for APRS applications. -- Use it with the serial interface for stand-alone
trackers, or in the USB mode on a PC to save the real serial port for a TNC.
One thing remains to be seen though. A traditional GPS is a radio receiver,
AND a dedicated computer that uses data recovered from the radio part to do
the heavy-duty trig calculations neccessary to determine the position. The
output of this computer is the familiar NMEA ASCII data stream that you feed
into an APRS device.
In a manner similar to brain-dead "Winmodems", soft-MIDI sound cards and
cheap Windows-only printers that use huge software drivers to simulate
hardware left out of the device, there is now a new breed of brain-dead GPS
devices being released.
These very-low-power-consumption (typically 25mA instead of 100-150 mA)
devices contain the antenna and radio receiver part, but not the data
processing part. These devices are totally dependent on being connected to
PCs running huge Windows-only drivers to supply the missing computation. The
driver's output is typically a simulated serial port that talks to the
GPS-using map or APRS program. The simulated COM port is similar to the kind
USB-to-serial converter dongles create. These devices are small and cheap
because they are literally only half of a GPS and take advantage of the vast
surplus of computing power in the typical current Windows PC. BUT THEY
ARE ABSOLUTELY USELESS for standalone hardware-only trackers or non-Windows
operating systems on PCs (i.e. DOS or Linux).
BEWARE ! ! !
Stephen H. Smith wa8lmf @ aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
