| |
ZL3AI > APRDIG 08.08.06 14:35l 258 Lines 9934 Bytes #999 (0) @ WW
BID : 88GHS1LMV012
Read: GUEST
Subj: [APRSSIG] Vol 26 #5, 1/2
Path: DB0FHN<DB0FOR<DB0MRW<DK0WUE<DB0RES<ON0AR<HS1LMV
Sent: 060808/1334z @:HS1LMV.#NGK.BKK.THA.AS [OpenBCM] obcm1.06
From: ZL3AI @ HS1LMV.#NGK.BKK.THA.AS (Sunan)
To: APRDIG @ WW
X-Info: Sent with login password
R:060807/2327Z @:HS1LMV.#NGK.BKK.THA.AS #:56847 [57015] FBB7.01.35 alpha $:8526-ZL3AI
R:060807/2326Z @:7M3TJZ.13.JNET1.JPN.AS #:59139 [Tokyo] $:8526-ZL3AI
R:060807/2326z @:ON0AR.#AN.BEL.EU $:8526-ZL3AI
R:060807/2326z @:IW2OAZ.ILOM.ITA.EU $:8526-ZL3AI
R:060807/2224Z @:ZL2BAU.#87.NZL.OC #:62650 [Waimate] $:8526-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Re: Replacing Lithium Battery in PK-900 (KC2MMI (Jared))
2. Re: Re: Replacing Lithium Battery in PK-900 (Ben Jackson)
3. Re: "Packet Radio USB micro TNC" (wa7nwp_at_jnos.org)
4. Mic-E encoding on HF -- does generic SSID path GATE? (Ben Jackson)
5. APRS Callsign Extensions (Robert Bruninga)
6. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Robert Bruninga)
7. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Stephen H. Smith)
8. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Robert Bruninga)
9. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Ben Jackson)
10. F5VAG map server (Tyson S.)
11. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Stephen H. Smith)
12. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Ben Jackson)
13. Re: Mic-E encoding on HF -- does generic SSID path GATE? (Robert Bruninga)
14. Seven balloon flights aloft over central Kansas (Mark Conner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 Aug 2006 13:22:58 -0400
From: "KC2MMI \(Jared\)" <kc2mmi_at_verizon.net>
Subject: [aprssig] Re: Replacing Lithium Battery in PK-900
Never met that TNC but the extensive manual is online (patience, apparently
on someone's dial-up home computer). It doesn't reference a battery but the
appendix makes it look like a welded coin cell--with enough room to that a
little careful work with a soldering iron and a coin cell HOLDER could let
you upgrade the TNC and use standard coin cells in the future. Holder &
coin cell, each anywhere from 50 cents to five dollars depending on the
source.
To steal a line form MasterCard, "The cost of being able to use
off-the-shelf batteries forever after?...Priceless"
http://www.w5sdc.net/w3mrc/packet/AEA_PK-900_manual.pdf is anyone needs it.
------------------------------
Message: 2
Date: Fri, 4 Aug 2006 10:28:00 -0700
From: Ben Jackson <ben_at_ben.com>
Subject: Re: [aprssig] Re: Replacing Lithium Battery in PK-900
On Fri, Aug 04, 2006 at 01:22:58PM -0400, KC2MMI (Jared) wrote:
>appendix makes it look like a welded coin cell
I had to replace a welded battery in a laptop once. I wasn't set up for
welding, and I also never wanted to do it again, so I got a much larger
CMOS battery and attached it with a pigtail that let me move the battery
somewhere that it would fit.
--
Ben Jackson AD7GD
http://www.ben.com/
------------------------------
Message: 3
Date: Fri, 4 Aug 2006 12:50:11 -0500 (CDT)
From: wa7nwp_at_jnos.org
Subject: Re: [aprssig] "Packet Radio USB micro TNC"
>Yea. KISS support _while_ doing tracking _while_ doing pre-emptive
>WIDEn-N digipeating _while_ doing anti-tracking (waypoints on the
>GPS screen)...
But no SSHD... Progress is being made on the slug...
Bill
------------------------------
Message: 4
Date: Fri, 4 Aug 2006 10:52:03 -0700
From: Ben Jackson <ben_at_ben.com>
Subject: [aprssig] Mic-E encoding on HF -- does generic SSID path GATE?
[this is a duplicate of a message I posted to nwaprssig a month or so ago,
but I got no reply]
The "Generic APRS digipeater path" encoded in the Destination SSID includes
all the paths typically used on VHF (WIDE1-1 and up) but it doesn't include
a SSID for "GATE".
Is GATE implied on HF as a matter of configuration at the receiving station?
Or does HF APRS need to use dest SSID-0 and encode the GATE,WIDE* path
longhand?
--
Ben Jackson AD7GD
http://www.ben.com/
------------------------------
Message: 5
Date: Fri, 04 Aug 2006 14:09:36 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: [aprssig] APRS Callsign Extensions
APRS developers.
This topic comes up every few years, but I just got a new data point, and
so thought I would bring it up again. That is the use of mixed case
letters for extening the Callsigns and other address fields of APRS.
The new data point is that the KPC-3+ which seems to be a large part of the
APRS infrastructure (digipeaters) in the USA, can apparently receive
callsigns that are not only mixed case, but can actually include other
characters as well. This gives the possibility of using callsigns like
Wb4aPr-1 which actually can carry 6 additional bits of information in the
"case" of the existing 6 bytes for example. This could be used to uniquely
encode 7 character callsigns, etc..
This has always been a loophole in the AX.25 spec, in that the spec says
that only UPPERCASE letters and digits will be *transmitted* in the AX.25
hearder, but it does not say anything about *receiving*. In the past it
has often been observed that many TNC's will actually decode these extended
range callsigns just fine.
But before we could make any use of this extended address range, we would
need to know what can and cannot decode these packets. Problem, is, no one
can TX these callsigns because all TNC's enforce the UPPERCASE only for
transmitting. But someone could easily hack out a few packets using KISS
and see what OTHER TNC's do with it.
Since we now konw that the KPC-3 family can decode them, I'd like to see
what other TNC's decode them. There are 3 possiblities:
1) TNC Ignores the packet
2) Decodes it just fine, but forces the display to uppercase
3) Decodes and displays the mixed case call.
If the majority of TNC's do either 2 or 3, then special applications might
find a way to use these bits. For many years I have always been
interested in adding a few additional bits of informatioon to APRS packets
(and still be backwards compatible).... For example:
1) Two Priority bits to give 4 levels of priority
2) Human Presence bit
3) others?
Bob, Wb4APR
------------------------------
Message: 6
Date: Fri, 04 Aug 2006 14:33:39 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: Re: [aprssig] Mic-E encoding on HF -- does generic SSID path GATE?
If you are referring to SSID routing, the only TNC that implemented this
idea were the Kenwoods, and so for the last several years we have abandoned
that proposal. It only made sense back when we were using long paths or
private networks. Now that most areas of the country are using only 2
hops, the advantage of SSID routing is obsolete... and no longer
receommended. de WB4APR
------------------------------
Message: 7
Date: Fri, 04 Aug 2006 14:49:24 -0400
From: "Stephen H. Smith" <wa8lmf2_at_aol.com>
Subject: Re: [aprssig] Mic-E encoding on HF -- does generic SSID path GATE?
ben_at_ben.com wrote:
>[this is a duplicate of a message I posted to nwaprssig a month or so ago,
>but I got no reply]
>
>The "Generic APRS digipeater path" encoded in the Destination SSID includes
>all the paths typically used on VHF (WIDE1-1 and up) but it doesn't include
>a SSID for "GATE".
>
>Is GATE implied on HF as a matter of configuration at the receiving station?
>Or does HF APRS need to use dest SSID-0 and encode the GATE,WIDE* path
>longhand?
You will have to use the explicitly-stated long-form path if you really
want to be gated, but it really isn't necessary anyway.
Nearly all APRS HF receive stations igate received packets directly into
the Internet system, along with any other functions such as cross-band
digipeating.
Gating onto VHF first so that numerous areas hundreds of miles apart will
have their local nets cluttered with out-of-area transmissions on two
meters, that then generate multiple duplicate entries into the Internet
system from 2M is really unnecessary.
Bear in mind that ALL of a packet has to be received PERFECTLY before
ANYTHING is recovered from it. The shorter the packet, the less air time it
takes, and the more likely it is is to be successfully received. (Less
chance to be hit with a pop of noise, a fade or QRM from other dumb
trackers. )
Using Mic-E format on HF with NO PATH at all (i.e. "direct") and no comment
field (just lengthens the packet) is most likely of all to succeed, since
it creates the absolutely shortest possible packet.
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com
NEW! JavAPRS Filter Port 14580 Guide
http://webs.lanset.com/wa8lmf/aprs/JAVaprsFilters.htm
UI-View Misc Notes and FAQ
http://webs.lanset.com/wa8lmf/aprs/UIview_Notes.htm
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://webs.lanset.com/wa8lmf/DigiPaths
Updated "Rev G" APRS http://webs.lanset.com/wa8lmf/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:
------------------------------
Message: 8
Date: Fri, 04 Aug 2006 16:35:19 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: Re: [aprssig] Mic-E encoding on HF -- does generic SSID path GATE?
>>>wa8lmf2_at_aol.com 08/04/06 2:49 PM >>>
>Using Mic-E format on HF with NO PATH at all (i.e. "direct") and no
>comment field (just lengthens the packet) is most likely of all to
>succeed, since it creates the absolutely shortest possible packet.
Very good advice!
And DIRECT with NO PATH is also a very good advice, since the GATE,WIDE
idea was back in 1994 before the APRS-IS and internet IGate systems. One
had to be gated to VHF before anyone but other HF'ers would see you. Your
point about it not being necessary if the objective is to get into an IGate
is excellent. The added length of GATE,WIDE2-1 is just not needed. (which
is actually an additional 14 bytes) is very high on a Mic-E packet that is
only 23 bytes long in the first place.
Thanks
Bob, WB4APR
------------------------------
Read previous mail | Read next mail
| |
