| |
ZL3AI > APRDIG 21.06.03 19:28l 296 Lines 13507 Bytes #999 (0) @ WW
BID : 1491-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 14, 1/3
Path: DB0FHN<DB0RGB<DB0SL<DB0FSG<DB0GAP<DB0GPP<DB0LX<DB0LEL<DB0TTM<DB0FP<
DB0CWS<DB0ROF<DB0ACH<DB0OVN<DB0GOS<DB0EEO<DB0RES<ON0AR<ZL2BAU<ZL3VML
Sent: 030616/1328Z @:ZL3VML.#80.NZL.OC #:2591 [Chch-NZ] FBB7.00i $:1491-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, June 14, 2003.
1. GPS AND KENWOOD
2. Re: Digis and UI-digis Part 1 of 2
3. Re: Digis and UI-digis Part 2 of 2
4. TN-204 GPS Rcvr to D700?
5. APRS Voice Rptr Advisories
6. Re: VOICE ALERT for Europe
7. Re: Better than 52 simplex
8. Re: PIC accessory for Mobile APRS
9. Re: Digis and UI-digis
10. Re: VOICE ALERT for Europe
11. Re: Better than 52 simplex
----------------------------------------------------------------------
Subject: GPS AND KENWOOD
From: Andy Gonzales <rocketeer21@attbi.com>
Date: Fri, 13 Jun 2003 21:09:02 -0700
X-Message-Number: 1
I HAVE BEEN TRYING WITHOUT SUCCESS TO GET MAGELLAN 310 GPS DATA INTO THE
GPS PORT OF A KENWOOD TH-D7A(G) AND THEN BACK OUT THE SERIAL PORT TO
WINAPRS 2.7.2 . I HAVE READ MANY WEBSITE POSTINGS AND THE HELP MANULA FOR
WINAPRS. THE DATA GETS TO THE KENWOOD, BUT NO FURTHER. THE CABLES ARE
CORRECT BECAUSE THEY WORK FOR EVERYTHING ELSE.
I KNOW THAT THE CORRECT GPS POSITION IS IN THE GPSTEXT BUFFER BECAUSE I CAN
SEE IT USING HE LTEXT COMMAND.
I HAVE FOLLOWED EVERY INSTRUCTION AND SETTING SEVERAL TIMES. WHEN I CHECK
THE ALLOE GPS BOX AND CHECK THE INTERNAL STATE, THIS ITEM SOWS UP IN RED AS
A PROBLEM.
DOES ANYONE HAVE ANY IDEAS ABOUT WHAT I AM MISSING ?
ONE ODD THING THAT I JUST NOTICED IS THAT WHEN I GIVE AN HB 1200 COMMAND I
GET STATIONS POPPING UP. WHEN I GIVE HB 9600 COMMANDS, NOTHING. THIS IS
WITH THE SERIAL PORT SET TO 9600 BAUD. COULD THE TWO THINGS BE LINKED ?
THANKS IN ADVANCE
----------------------------------------------------------------------
Subject: Re: Digis and UI-digis Part 1 of 2
From: WA8LMF2@aol.com
Date: Sat, 14 Jun 2003 05:54:28 EDT
X-Message-Number: 2
In a message dated 6/13/2003 7:36:58 PM Pacific Daylight Time,
yn1ncv@arrl.net writes:
>I am quite new to APRS and I am trying to share some packet nodes with APRS
>use. There won't be any problem about crowded frequency, as there are not
>that much users. My question is simple where I can read about how the digis
>and UIdigis work?
APRS doesn't use nodes as used in traditional connected packet -- It only
uses simple "classic" digipeaters and only uses unconnected "UI" packet
frames.
It is a one-to-many broadcast-like mode rather than the one-on-one nature of
traditional connected packet.
====== Reprint of post I have made on several APRS mailing lists ======
Some background and information on APRS digipeating and path selection.
Digpeating is much more critical to APRS than to conventional packet because
APRS heavily involves packet data transmission to and from moving vehicles.
[Traditional packet was overwhemingly used between fixed locations,
typically with better antennas and more power.]
*** WHY DIGIPEATING IS MORE ESSENTIAL ***
Signal levels that you may consider adequate on voice WON'T BE on packet,
because data transmission is an all-or-nothing proposition. --ALL-- of a
packet has to be received PERFECTLY to recover --ANY-- data from it. The
kind of noisy, scratchy, not-completely-hard-quieted, operation so many
people inflict on voice repeaters, especially with underpowered handhelds,
JUST WONT WORK on data transmissions. A pop, a momentary burst of white
noise, flutter, or multipath-induced phase distortion that you don't even
notice on voice WILL be fatal to a packet transmission.
With APRS, the problem is even worse than with conventional [connected]
packet because it operates in a non-connected mode. With traditional
packet, a station receiving a defective packet will automatically send a
request for retransmission to the sending station (or the sending station
will automatically retry if the receiving station doesn't acknowledge in a
reasonable time). With APRS there is no ACK/NAK (Negative AcKnowledgement)
handshaking process. The sending station just blasts out packets at
intervals and "hopes" the receiving station(s) get them. The receiving
station just ignores the packet if it is defective in anyway. [ This is
the price you pay for the one-to-many broadcast nature of APRS, compared to
the one-on-one nature of traditional connected packet. ]
Signals to/from mobile units can and do fluctuate in strength by 15-20 dB
as the mobile moves over even a short distance. For reliable data
transmission, you must have massively excess signal strength over the
intended path. Enough excess signal that even with a 20dB drop, the signal
will remain noiseless and hard quieted. [ Note that the instruction manual
for the Kenwood D700 acknowleges this fact by stating that you can't expect
reliable packet operation until the S-meter reads full scale. ]
{{ FUNDAMENTAL UNAVOIDABLE FACT OF PACKET LIFE: Roughly speaking, a given
antenna installation and transmitter power will produce about 1/2 to 1/3 the
RELIABLE range on APRS packet that it produces on FM voice. }}
*** APRS DIGIPEATER USAGE ***
To increase the reliability of transmission from mobile units (i.e.
likelyhood that a packet will "get through"), APRS uses two categories of
digipeaters:
1) "Public" digipeaters in high locations (typically hilltops, the tallest
building in town, water towers, etc); i.e. similar to the placement one would
choose for a voice repeater. This type reponds to the alias callsign of
"WIDE"
2) Personal home stations typically running digipeater duty alongside other
activities (such as being an APRS client and/or Internet gateway). This type
responds to the alias callsign "RELAY".
The assumption is that there are far more home stations then wide-area digis.
Therefore a mobile is far more likely to be heard by a nearby home station
than by a much more distant WIDE.
On the other hand, even a minimal home station is likely to have a better
and higher antenna system than anything on a mobile. Thus the home
station's liklyhood of successfully transmitting to even a fairly distant
WIDE is much greater than a mobile's. This is especially true for an area
situated in a geographic low spot, or "urban canyons" where mobiles have
trouble "getting out".
*** How APRS PATHS ARE USED ***
PATH settings determine what kind and how many digipeaters will be used to
deliver your packets to their destination. Typically the "destination" be
either other stations listening on RF, or a fixed station that will receive
your packet and transfer it into the Internet and then onward to findu.com.
A transmission path of "RELAY, WIDE" is requesting the helping hand of
nearby cooperating home stations as the first step into the APRS network. [
Normally, WIDE digipeaters will also respond to the alias "RELAY" so if a
WIDE hears you directly, it can also serve as the first hop. ]
If you want multiple digipeat hops, you specify something like "RELAY,
WIDE, WIDE". As in conventional packet, each digipeater in the chain
"crosses off" the callsign it responded to. This example shows results as a
user tries to use three wide area digipeaters in sucession. The path
string will change like this as the packet propagates from digi to digi:
RELAY,WIDE,WIDE,WIDE {as sent by the user }
*RELAY,WIDE,WIDE,WIDE {after home station first digipeat}
*RELAY,*WIDE,WIDE,WIDE {after first WIDE digipeat}
*RELAY,*WIDE,*WIDE,WIDE {after second WIDE digipeat)
*RELAY,*WIDE,*WIDE,*WIDE {after third WIDE digipeat)
The path is now "used up" and no further digis will repeat this packet.
This kind of path will work with any kind of TNC pressed into duty as
digipeaters.
Because all APRS digipeaters use the same generic callsigns, the
re-transmission process can happen in several geographic directions
simultaneously if several digis are within range of the one transmitting. A
widening circle of digipeats involving more and more digis on each hop will
spread outward from the user in all directions. This phenomenon, known as
"UI-FLOOD", is sharply different from the directed linear sequence of
digis, each identified by a unique callsign, used in traditional connected
packet.
If you know them, you CAN use explict callsigns in APRS paths instead of
the generic WIDE. This is one approach to reducing unneccessary
retransmissions, especially in your home territory where you likely will
know the actual callsigns of local digis.
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: Digis and UI-digis Part 2 of 2
From: WA8LMF2@aol.com
Date: Sat, 14 Jun 2003 05:54:30 EDT
X-Message-Number: 3
In order to shorten the path strings to allow more packets per minute ,
APRS introduced a new convention. You add a fake "SSID" to the WIDE
"callsign" in the path, indicating the number of hops desired. Each
digipeater that processes the packet decrements the value of the "SSID" but
doesn't cross it off as "used up". When the SSID decrements to zero,
further digipeating stops. This type of "WIDEn-N" digipeating path looks
like this for the example above:
RELAY,WIDE3-3 {as the user transmitted it]
*RELAY,WIDE3-3 {after home station RELAY digipeat}
*RELAY,WIDE3-2 {after first WIDE digpeat - note WIDE IS NOT crossed off,
just changed}
*RELAY,WIDE3-1 {after second WIDE digipeat}
*RELAY,WIDE3 {after third WIDE digipeat -- all used up, no more
digipeats}
Note that the path string is half the length of the one before
Sometimes you may want to know what actual digis a signal passed through.
The generic callsigns conceal the identity of individual digipeaters. To
see the actual callsigns, you substitute the callsign "TRACE" for "WIDE"
Now, each digi will insert it's own (real) callsign in the path before
forwarding it. The example now looks like this:
RELAY,TRACE3-3 {as the user transmitted it]
*RELAY,TRACE3-3 {after first RELAY digipeat}
*RELAY,*digicall1,TRACE3-2 {after first WIDE digpeat}
*RELAY,*digicall1,*digicall2,TRACE3-1 {after second WIDE digipeat}
*RELAY,*digicall1,*digicall2,*digicall3,TRACE3
{after third WIDE digipeat -- all used up, no more digipeats}
Note that the path string gets longer after each digipeat. Normally, TRACE
is only used for testing and discovering the APRS environment in a given
location; not for routine use.
[ Acually I have simplified the path examples for purposes of discussion.
In reality, the very first WIDEn-N digi (but no subsequent ones) is
supposed to insert it's own real callsign (marked as used) into the path in
front of the WIDEn-N phrase, before forwarding it. This allows users many
WIDEn-N digi hops away to determine the general location the packet
originated from. ]
Note that these advanced paths require that the "callsign" actually be
changed by each digi that processes it. This process of "callsign
substitution" is unique to APRS and requires special APRS awareness in
TNCs. Currently only the Kantronics KPC3+/KPC9612+, and TNC2 clones with
UI-DIGI firmware, can do this "standalone" without a computer attached).
Increasingly, as APRS grows, WIDEn-N digipeating is becoming the standard
everywhere. However, some areas are still covered by older "dumb" digis
using pre-APRS-aware TNCs. [ The sole advantage of traditional WIDE-only
mode is that any 20-year-old junker-clunker hand-me-down TNC can do it. ]
In these areas, you will be forced to use the longer, less-efficient
WIDE,WIDE,WIDE type of path.
As a traveler outside of your home area, you may not know whether WIDE or
WIDEn-N digipeating is in use in a given area. This is especially true of
simple trackers that transmit but don't receive -- you have no way of
monitoring what the locals are using. Even if you do know, you may not
have the means (computer and configuration program) with you, to reprogram
your tracker to the correct path.
A good compromise path for travelers into "terra incognita" is RELAY, WIDE,
WIDE2-2. In areas with dumb digis you will get two hops - dumb digis will
ignore the "callsign" WIDE2-2. In areas with smart WIDEn-N digis, you get
up to 4 hops - smart digis WILL normally respond to the non-SSID'ed "WIDE"
as well as to WIDEn-N.
Some other considerations:
1) Normally, you would never put more than one "RELAY" in a path.
2) --NEVER-- put RELAY in a path after WIDE. If you do this, dozens (or
hundreds) of home stations within earshot of one or more WIDEs will
needlessly clog the channel retransmitting the WIDEs packets for no reason.
3) Paths longer than about WIDE4-4 are almost useless. The probability of
success goes down exponentially as the path lengthens. On the other hand,
you can create literally thousands of useless packets for every
transmission, as the UI-FLOOD spreads outward over hundreds of miles.
Indeed, in some areas, intelligent digipeaters are automatically
reformatting excessivly long paths to something more reasonable such as
WIDE2-2 or WIDE3-3.
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
| |
