| |
ZL3AI > APRDIG 13.06.03 10:07l 333 Lines 11667 Bytes #999 (0) @ WW
BID : 1477-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 10, 2/3
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<RZ6HXA<SP7MGD<VK7AX<ZL2BAU<ZL3VML
Sent: 030612/1331Z @:ZL3VML.#80.NZL.OC #:2297 [Chch-NZ] FBB7.00i $:1477-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Stand Alone Digi
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 10 Jun 2003 13:08:51 -0500
X-Message-Number: 18
At 12:48 PM 6/10/2003 -0500, Dave Thege wrote:
>One way to get out of your hole would be to set the my alias parameter to
>relay on the home stations. Then they would act as mini-digis getting your
>mobiles to the high Digi. As for a standalone Digi I use the current
>Kantronics KPC-3+. Once programmed put into operation and you won't need a
>computer hooked up full time.
Beware, a "relay" digi is one-way only. If you want to hear anything,
you'll need at least a "wide". In this case, it would probably be best to
implement a widen-n to avoid collisions.
I do this occasionally when traveling, as it seems I'm always on the fringe
of digi coverage. I turn my car into a widen-n temporarily. This allows
me to roam around with the D7 HT on 20mW, since the car isn't too far away
usually. If I can hit a digi with the HT, then I just use that.
----------------------------------------------------------------------
Subject: Re: Stand Alone Digi
From: Doug Bade <dbade@clecom.com>
Date: Tue, 10 Jun 2003 14:17:21 -0400
X-Message-Number: 19
UIDIGI firmware in the 1270 will turn it into a fine digi... there
is a special interest group on yahoogroups.com where the author and other
support hang out...
Under UIDIGI
You will need someone with a rom burner to help out, and there may
be some mods to the 1270 needed depending on version...
Lots of info on the net if you do a google search on uidigi...
Doug KB8GVQ
----------------------------------------------------------------------
Subject: Re: Stand Alone Digi
From: WA8LMF2@aol.com
Date: Tue, 10 Jun 2003 14:41:11 EDT
X-Message-Number: 20
In a message dated 6/10/2003 9:16:19 AM Pacific Daylight Time,
bcdpe@innova.net writes:
>I guess
>what he meant was with no computer and able to reboot after power
>failure. He has an MFJ 1270.
Exactly the application the UI-Digi firmware replacement is intended for!
UI-Digi is replacement code for the 27256 eprom in the TNC2 or 1270-series
TNCs, developed by IW3FQG , that converts the unit to a dedicated APRS-only
digipeater.
You customize the base binary code with a txt overlay file that contains
your callsign, lat/log, beacon txt/intervals for up to three different
beacons/paths, etc. The result is that your personal settings are
literally "frozen in stone" in the 27256 eprom and can't be lost from power
failures, accidental resets, etc. Just plug the TNC2 into a radio, turn
it on and walk away.
Full information at:
http://gw.ir3ip.ampr.org/~iw3fqg/uidigi.htm
As I have mentioned before on this list, if you don't have access to an
eprom programmer neccessary to program the 27256, I will do it for you if
you email me the edited overlay file with your settings , and snail mail a
blank (or erasable) 27256.
DON'T reuse the original eprom in the unit. You will need to re-install it
if you ever want to run the CAL routine used to set tone freqs, deviation,
etc. [ The UI-DIGI firmware lacks the CAL command. ]
As I have also suggested several times on this list, an alternative is to
use a twice-as-large 27512 eprom. Place the UIDIGI code in the bottom half
of the eprom and the original firmware code (or TAPR 1.1.9) in the upper
half. Bend pin 1 of the chip so it misses the socket when you plug the
eprom in. Wire a single-pole double-throw switch to pin 1 so that you can
either ground it or connect it to +5 VDC. You can now select UI-Digi mode
for operation, or original mode for testing/setup at the flip of a switch.
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
----------------------------------------------------------------------
Subject: Re: How do I get a Kenwood D7A(G) a GPS *and* PC {to talk to each
othe}r
From: WA8LMF2@aol.com
Date: Tue, 10 Jun 2003 14:59:13 EDT
X-Message-Number: 21
In a message dated 6/10/2003 9:52:59 AM Pacific Daylight Time,
agonzales@arc.nasa.gov writes:
>The manual does seem to imply that passing GPS data can be passed through.
>
>WA8LMF2 tells me that what we want to do is possible and Mark Sproul
>advises
>
>"Yes, in WinAPRS you have to go to SETTINGS / SERIAL PORT and check ALLOW
>GPS"
>
>Two other conditions to consider.
>
>1) I am not yet licensed so I am just LISTENING NOT TRANSMITTING.
>
>2) I have not yet paid the activation fee for WinAPRS but will
>probably do so by the end of the week,
This has nothing to do with transmitting, or the application being used on
the computer. It is an inherent feature of the D700/ THD7. Here is some
background from a previous post I made on this very issue:
==================== PASTE ======================
Standard GPS devices automatically output a variety of GPS "sentences" ,
typically once every second. Each sentence contains several fields of
data. The strings are pure printable ASCII (no binary or control
characters) and look something like this:
$GPVTG,092.2,T,078.3,M,000.2,N,0000.3,K,A*17
$GPDTM,W84,,00.0000,N,00.0000,W,,W84*53
$GPRMC,091635,A,3409.8692,N,11807.0045,W,000.2,092.2,140503,013.9,E,A*07
$GPZDA,091637,14,05,2003,+08,00*60
$GPDTM,W84,,00.0000,N,00.0000,W,,W84*53
$GPGLL,3409.8688,N,11807.0045,W,091636,A,A*50
$GPGSA,A,2,27,28,,,,,,,,,,,00.00,07.83,00.00*30
$GPGSV,3,1,12,07,41,198,29,08,68,060,39,10,05,254,27,11,18,088,39*7A
$GPGSV,3,2,12,13,09,163,29,19,11,117,31,22,07,067,31,26,21,316,29*7E
[ These strings were captured, using HyperTerminal, from a GPS sitting on a
table in my living room in Pasadena, California. ]
These strings will be identical for any NMEA Ver 2.x GPS device. The data
fields are separated by commas making it easy to write programs to pick off the
desired pieces of data.
The most commonly used GPS Data Sentences (and the data they contain) are [
Full details on the structure of these strings is at the bottom of this
post ] :
=== GPRMC (Time, Lat, Long, Speed, MagVar)
=== GPGLL ( Lat, Long, Time)
=== GPGGA (Time, Lat, Long, GPS Valid, Number of Sats Used, HDOP, Altitude)
=== GPGSV (Satellite Status)
=== GPZDA (Time, Date)
==== GPVTG (Compass, Ground Course Velocity)
Assuming your GPS device actually outputs GPRMC, GPGLL and GPGGA (in some
units each sentence has to be turned on or off in a setup menu) the results
will be:
1) When the US version D7A(G) or any D700 is used in standalone 'APRS"
mode, the compressed Mic-E transmission format will contain altitude IF the
GPS outputs the GPGGA string. The Euro versions of the THD7 don't encode
altitude, even if altitude IS present in the GPS data stream. Note that
you can shorten the Mic-E burst (useful for posit-after-voice operation) by
turning off the GGA string in the GPS device so the comment field doesn't
get filled with altitude data.
2) When the D7/D700 are used in "PACKET" mode with an external program,
the internal firmware can echo ONE selected string of your choice received
at the GPS input out the main serial port connected to the PC. The
command GPSTEXT sent to the D7/D700 internal TNC determines which one (and
only one) GPS string is captured and forwarded to the PC each second. (
Use a basic terminal program like Hyperterminal set to 9600baud 8-N-1
connected to the radio's main serial port to send this command, and to view
the results.)
If you initialize with "GPSTEXT $GPGGA" the APRS program on the PC will be
able to "see" (and therefore transmit) LAT, LONG, TIME and ALTITUDE but not
speed and heading.
If you initialize with "GPSTEXT $GPRMC" the APRS program on the PC will be
able to see LAT, LONG, TIME and SPEED. but not altitude.
If you initialize with "GPSTEXT $GPGLL" the APRS program on the PC will be
able to see LAT, LONG, and TIME but nothing else.
======================================================
Details on the GPS Data Sentences:
Note 1: Lat and long are always expressed as Degrees, Minutes and decimal
fractions of minutes, --NOT-- as Degrees, Minutes and Seconds. There is no
delimiter between the degrees and minutes but there IS a decimal between
the whole and fractional part of minutes. Resulting data is formatted as
DDMM.mmm -- not DDMMSS
Note 2: Lat and long are not signed; a separate field indicates N/S or E/W.
Note 3: NMEA 3.0 format has added additional decimal places to the
lat/long values for higher resolution. Software that parses by counting
character positions from the beginning of the string (i.e. BASIC MID$
functions) instead of correctly using the comma delimiters) may not work
correctly with NMEA 3.0 format.
GPGLL ( Lat - Long - Time)
$GPGLL, LLLL.lll, N, LLLLL.lll, W, HHMMSS.ss, *CS
Fields:
1 - Latitude
2 - North/South
3 - Longitude
4 - East/West
5 - UTC (HoursMinsSecs.secs)
6 - Checksum
------------------------------------------------------------------------------
-
GPRMC (Time Lat Long, Speed, MagVar) Always one per second
$GPRMC, HHMMSS.ss, A, LLLL.lll, N,LLLLL.lll, W, KK.k, HHH.h, DDMMYY
------------------------------------------------------------------------------
-
GPGGA (Time - Lat -Long - GPS Valid - Number of Sats Used, HDOP, Altitude)
Always one per second
$GPGGA, HHMMSS, ss, llll.lll, N, LLLLL.LLL, W, 1, NN, 1.7, AA.a, M, -A.a, , ,
*CS
Fields
1 - UTC (HoursMinsSecs.secs)
2 - Latitude in DD MM.mm format
3 - North/South
4 - Longitude in DDD MM.mm format
5 - East/West
6 - GPS Fix Valid=1, Invalid=0
7 - Number of Sats in Use
8 - HDOP (One is Best, 10 is Worst)
9 - Altitude
10 - Units M=Meters, F=Feet
11 - Geoidal Sep
12 - Geoidal Units M=Meters, F=Feet
13 - Time Since Last DGPS Update Data (Not Used)
14 - Diff Corr Station ID# (Not Used)
15 - Checksum
------------------------------------------------------------------------------
-
GPGSV (Satellite Status)
$GPGSV, N, N, NN, 01, Ele1, Azi1, SN1, 02, Ele2, Azi2, SN2, 03, Ele3, Azi3,
SN3, 04, Ele4, Azi4, SN4, *CS
Fields:
1 - Number of GPGSV Messages
2 - GPGSV Message Number
3 - Number of Sats in View (i.e. determines number of GPGSV messages)
4 - 1st Sat Num
5 - 1st Sat Elevation In Degs (Rounded to integer)
6 - 1st Sat Azimuth in Degs (Rounded to integer)
7 - 1st Sat SNR 00-99 dB, blank when not tracking sat
8 - 2nd Sat Number
9 - 2nd Sat Elevation In Degs (Rounded to integer)
10 - 2nd Sat Azimuth in Degs (Rounded to integer)
11 - 2nd Sat SNR 00-99 dB, blank when not tracking sat
12 - 3rd Sat Number
13 - 3rd Sat Elevation In Degs (Rounded to integer)
14 - 3rd Sat Azimuth in Degs (Rounded to integer)
15 - 3rd Sat SNR 00-99 dB, blank when not tracking sat
16 - 4th Sat Number
17 - 4th Sat Elevation In Degs (Rounded to integer)
18 - 4th Sat Azimuth in Degs (Rounded to integer)
19 - 4th Sat SNR 00-99 dB, blank when not tracking sat
20 - Checksum
------------------------------------------------------------------------------
GPZDA (Time Date)
$GPZDA, HHMMSS, DD, MM, YY, *CS
1 - UTC Hours, Mins, Secs
2 - Day
3 - Month
4 - Year
5 - Checksum
------------------------------------------------------------------------------
GPVTG (Compass, Ground Course Velocity)
$GPVTG, DDD.dd, T, DDD.dd, M, NNN.n, M, NNN.n, K, *CS
1 - Heading (True)
2 - TRUE "T"
3 - Heading (Magnetic)
4 - Magnetic "M"
5 - Speed Knots or Mph
6 - Units ("N" or "M")
7 - Speed KM/h
8 - Units ("K")
9 - Checksum
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
