| |
ZL3AI > APRDIG 12.05.04 10:27l 269 Lines 11153 Bytes #999 (0) @ WW
BID : 3220-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 3/10
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23799 [Chch-NZ] FBB7.00i $:3220-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Help with a Trace
From: "Michael J. Pawlowsky" <mikep@mikeathome.net>
Date: Fri, 23 Apr 2004 13:15:27 -0400
X-Message-Number: 12
I'm about to put a remote APRS weather station out in field far from
everything. Today I drove down there just to make sure that I would be able
to reach a digipeater. I set my path to RELAY,WIDE,WIDE,TRACE.
When I got back home I took a look at the Raw Packet from findu and found
this:
VE2MUD>TU3P3P,VE2RTS-3*,WIDE,WIDE,TRACE,qAS,VE2ETS:'f1ql#/j/]"4N}Mike
VE2MUD is me naturally.
I have no idea what TU3P3P is, can someone clarify this for me....
I'm guessing VE2RTS-3 was used as a RELAY?
qAS???????
And VE2ETS is probably the wide.
The reason why I'm trying to figure this out is to determine which
direction to point the antenna. For this test I was using my D700 with a
whip.
Thanks for any help in decoding the path.
Cheers,
Mike
----------------------------------------------------------------------
Subject: Re: Help with a Trace
From: wes@johnston.net
Date: Fri, 23 Apr 2004 13:53:50 -0400 (EDT)
X-Message-Number: 13
The mic-encoder position format uses the TO call as part of the lat/lon.
TU3P3P is you latitude (I think).... the rest of the postion (longitude,
icon and status) is contained in the part of the packet after VE2ETS: .
ve2rts-3 is indeed the relay station. The first station to hear you on RF.
qAS is a construct for tracing where a packet entered and how it entered
the APRS internet stream. The packet was received from another IGATE or
generated by this IGATE. The callSSID following the qAS is the login or IP
address of the first identifiable server.
Which means is plain english, that the ve2ets IGATE heard your station and
passed it on to the net.
Wes
----------------------------------------------------------------------
Subject: RE: Everlasting discussions, Smart Move/Transition?
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 23 Apr 2004 10:56:17 -0700 (PDT)
X-Message-Number: 14
On Fri, 23 Apr 2004, Scott Miller wrote:
>>My vision is a smooth move or transition to a new REAL STANDARD.
>>As I proposed two days ago:
>
>I'm not pushing for this myself. My philosophy is to concentrate on
>building the best system possible. If and when the system shows itself to
>be significantly superior to APRS, people will adopt it. Or maybe this
>effort itself won't be integrated into mainstream use, but the lessons
>learned could be applied toward a future APRS incarnation.
That's as I see it also. OpenTrac learned from the mistakes of APRS. APRS
can now learn from OpenTrac, as APRS evolves into what it will become next.
The important thing is to evolve.
>Where I DO intend to actively pursue OpenTRAC use is in closed settings,
>especially SAR team use and special purpose telemetry applications, balloons
>included. By the time the protocol matures, the whole Kenwood issue might
>be moot.
In a SAR situation, with a Base setup that can receive both OpenTrac and
APRS, we can use both. That will allow us to deploy the ones that make
sense at the time, which may vary with the mission or with the types of
roving devices avwett <sean@rimboy.com>
Date: Fri, 23 Apr 2004 12:42:38 -0500 (CDT)
X-Message-Number: 16
On Fri, 23 Apr 2004, Michael J. Pawlowsky wrote:
>I'm about to put a remote APRS weather station out in field far from
>everything. Today I drove down there just to make sure that I would be
>able to reach a digipeater. I set my path to RELAY,WIDE,WIDE,TRACE.
>
>When I got back home I took a look at the Raw Packet from findu and found this:
>
>VE2MUD>TU3P3P,VE2RTS-3*,WIDE,WIDE,TRACE,qAS,VE2ETS:'f1ql#/j/]"4N}Mike
>
>VE2MUD is me naturally.
>
>Ihave no idea what TU3P3P is, can someone clarify this for me....
I'm not sure either, someone might have a better clue than I... I just
pulled you up on FindU and it showed this:
VE2MUD>TU2U7P,VE2RTS-3*,WIDE,WIDE,TRACE,qAS,VE2ETS:'eOLl!lj/]"4C}Mike
However, keep in mind that the raw packet you show above reflects your
last posit which I assume is not where the WX station will be. I don't
think Montreal is that remote :)
Where you're at now you're approx 9-10 miles from the digi and the digi is
approx 15-16 miles from the iGate.
>I'm guessing VE2RTS-3 was used as a RELAY?
Yes it was. It looks like it's fairly close and it is within earshot of
an iGate. FYI here is the BTEXT... R-W-T APRS Mercier Qc. DIGI. Inst par
VA2SPP & VE2KCW Resp. VE2TEE & VE2SYQ
>qAS???????
>
>And VE2ETS is probably the wide.
http://www.aprs-is.net/q.htm
VE2ETS is the server or iGate that provided the feed to the APRS-IS. At a
minimum it is an iGate that does not support the q construct. If it's
part of a tier network then it could mean a couple of other things. It
looks like it is an iGate though:
VE2ETS Montreal APRS Server
>The reason why I'm trying to figure this out is to determine which
>direction to point the antenna. For this test I was using my D700 with a
>whip.
Well, without knowing where you're planning to put the WX station it's a
little hard to determine which way it should be pointing nevermind the
appropriate path. I would try and contact some of your local APRS users
and better yet contact those APRS users in the area you plan to put the WX
station. Most areas frown upon having a stationary station with RELAY in
its unproto path unless the situation dictates such a path. If your
running your station mobile most areas are moving to RELAY,WIDE or
RELAY,WIDE,WIDE however the situation may dictate otherwise. It's best
to contact other APRS users in your area to find out what they would
prefer. Likewise they may be able to help provide insight into the best
path for your WX station.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: Re: Everlasting discussions, Smart Move/Transition?
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 23 Apr 2004 13:24:59 -0500
X-Message-Number: 17
On Friday 23 April 2004 12:19, Robert Bruninga wrote:
>Why not just have the PIC check the list every 30 seconds.
>There is not much in APRS that should be that time
>critical that a few sesetting (frequency for instance) the radio will jump
back to the home display (ie band a and band b) and leave whatever menu or
list it was in.
I made a little PIC device that would take the VFO b frequency on the TH-D7
and put it into the APRS status text. It worked fine except for the problem
outlined above.
-Jim KB0THN
----------------------------------------------------------------------
Subject: LAN and LINKn-n (long)
From: wes@johnston.net
Date: Fri, 23 Apr 2004 14:24:56 -0400 (EDT)
X-Message-Number: 18
Just to make something clear which may not be....
in the old days, we frowned upon using three or more of any callsign alias
in a row for paths. For example, APRS via WIDE, WIDE, WIDE would cause a
ping pong effect. So to get around that, WIDEn-n was developed. Now you
could do the equivalent of 7 wides in a row with no ping pong effect and no
duplicate packets like this: APRS via WIDE7-7. Since that time, we have
actively discouraged the use of three of any alias in a row. People have
forgotten about the use of WIDE,WIDE in their packets.
About the same time as WIDEn-n came along, kantronics also introduced the
UIDIGI command which contains a list of up to four callsigns that the
digipeater will perform a callsign substitution on as the packets are
digipeated. The neat thing about this, is that if a packet is elligible
for digipeating, and the TNC sees that it's callsign is already in the
path, it will not digipeat the packet again. Since UIDIGI does indeed do
callsign substitution, a given TNC can only digipeat a packet once using
UIDIGI's list of four aliases.
*note to kantronics owners... MYALIAS command is able to digipeat packets
containing RELAY, but it's use should be discouraged... use UIDIGI RELAY
instead for your home station... it helps trace the entry point of packets
into the network and will not allow duplicates like MYALIAS does.
Because of the duplicate checked method used in UIDIGI (callsign
substitution), you can now run more than three of the same alias in your
outbound path without causing a ping pong effect. So, running a path of
APRS via WIDE,WIDE,WIDE,WIDE would be acceptable in areas served by
kantronics digipeaters.
Now, back to the UIDIGI command. Normally we only put RELAY and WIDE in
there. But that leaves two open slots. Lately, we've been suggesting that
you use the two letter state abbreviation (SC for south carolina). That
still leaves one open slot. My suggestion for uses for this slot would be
to name it after the NWS office in your area.
Consider that the Charleston SC weather office covers two states, SC and
part of GA. Digipeaters in SC will use UIDIGI RELAY,WIDE,SC,NWSCHS in
their setup. Digipeaters in parts of GA supported by the charleston NWS
office will use UIDIGI RELAY,WIDE,GA,NWSCHS. Other digipeaters in SC and
GA not in the charleston NWS area would not include NWSCHS in their UIDIGI.
By mixing and matching the areas like this, we do not limit ourselves to
only covering one state when we switch to LAN and LINKn-n.
Let's say I set my outbound path to APRS via SC,SC,SC,SC. Every digipeater
in south carolina will digipeat my packet, but the digipeaters in NC and GA
won't. So the people in NC and GA are not QRMe able to reach as far as Savannah GA. So the solution is to
make his outbound path APRS via NWSCHS,NWSCHS,NWSCHS,NWSCHS . Now any
digipeaters in southern south carolina and southern georgia will pass this
packet.
Overlapping 'logical' or 'tactical' areas like this allows us to
communicate over a clearly defined area without causing QRM to other
stations which are beyond the range of our intended audience.
Parts of this have been hashed out on the CarolinaAPRS@yahoo group, I'm
just relaying the summary to here to help spread the idea of these
overlapping areas.
Please note that WIDEn-n and TRACEn-n are completely different digipeating
mechanisms than what I'm addressing here.... they are UIFLOOD and UITRACE
commands. If you choose to omit the word WIDE from your UIDIGI callsign
list, and UIFLOOD is still set to UIFLOOD WIDE,28,NOID , then your station
will in fact still digipeat packets such as APRS V WIDE2-2, but will not
digipeat packets such as APRS V WIDE. I guess the point to bringing this
subtlety to your attention is that UIDIGI does not have to have the word
WIDE in it... if you run out of aliases in the UIDIGI command because you
want to support another group or logical area, then its probabbly OK to
forfeit the use of WIDE in your UIDIGI command.
Just some food for though.... and a breath of fresh air for the sig.
Have a good weekend everyone.
Wes
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
