| |
ZL3AI > APRDIG 19.03.03 10:32l 222 Lines 9903 Bytes #999 (0) @ WW
BID : 1034-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 16, 1/2
Path: DB0FHN<DB0RGB<DB0FSG<DB0GAP<DB0KFB<DB0CZ<DB0GE<LX0PAC<LX0HST<HA3PG<
HB9OK<IK6PYS<ON0AR<ZL2BAU<ZL3VML
Sent: 030318/1008Z @:ZL3VML.#80.NZL.OC #:61968 [Chch-NZ] FBB7.00i $:1034-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, March 16, 2003.
1. Re: KPC3 (Not+)
2. Some comments on Mic-E / APRN up and running in Los Angeles
3. RE: Some comments on Mic-E / APRN up and running in Los Angeles
4. Re: How find digipeater in a specific region hundreds of miles away?
5. Re: KPC3 (Not+)
6. APRS wx protocol help needed
7. Re: KPC3 (Not+)]
8. RE: Some comments on Mic-E / APRN up and running in Los Angeles
9. Test Please ignore
10. Re: APRS wx protocol help needed
11. Re: How find digipeater in a specific region hundreds of miles away?
12. KPC3, the KPC3+, and other TNCs
----------------------------------------------------------------------
Subject: Re: KPC3 (Not+)
From: KC7ZRU - Tate <kc7zru@arrl.net>
Date: Sat, 15 Mar 2003 23:26:41 -0700
X-Message-Number: 1
Tim,
Can you elaborate on this modification? Like - how to do it, exactly -
or where to find the 'how-to' if it's online sompleace already?
Thanks
Tim Cunningham wrote:
>There is a simple modification for TNC2 clones that will allow them to
>operate open squelch.
>
--
"The Dungeon" online at http://go.to/kc7zru
Casper, WY | CARC Repeater
DN62tt | 146.940-
http://www.trib.com/~carc
----------------------------------------------------------------------
Subject: Some comments on Mic-E / APRN up and running in Los Angeles
From: WA8LMF2@aol.com
Date: Sun, 16 Mar 2003 03:09:38 EST
X-Message-Number: 2
[ I originally posted this in response to some questions on the Yahoo UI-View
mailing list, but felt it was of sufficiently general interest to repeat
here... ]
In a message dated 3/15/2003 7:20:38 PM Pacific Standard Time,
k1uc@adelphia.net writes:
>I had a couple of quick questions I hope you can answer for me:
>1. When using Findu, my packets often contain some garbage
>characters. Is this the Mic-E compression you spoke about? Can I turn
>off MIc-E?
>
>2. I expect my packets to begin with APK when viewed on Findu, but
>instead I see things like "TS2S6P." Any idea what that is?
Here is an actual capture of the transmissions from my TH-D7 as monitored on
a KPC3+ connected to HyperTerm 6.3. If you are seeing something like this,
Yes it is Mic-E format.
WA8LMF>DEAYXS,WIDE2-2:'._ l [/>Mobile SSTV LiveCAM
(Position report with status string appended)
WA8LMF>DEAYXS,WIDE2-2:'._ l [/>
(Position report only)
Here is the same packet after passing through an Igate and displayed on Findu:
Raw packet:
WA8LMF>APK001,WIDE2-1,qAO,K6TVI:@160641z3409.81N/11807.01W[000/000/Mic-E/M0/Off
1) Note that Findu has decoded and expanded the Mic-E compression back to
normal text format.
2) Note how incredibly shorter the Mic-E format is!
3) Note also that while most igates pass the Mic-E format into the Internet
system as-is, leaving it up to Findu to decode, a few try to decode Mic-E
packets themselves and may mangle them in the process. [ WinAPRS 2.4.6 was
notorious for this and should ---NEVER--- be used for igate applications! ]
Mic-E is the format the Kenwood D700 and TH-D7 use to transmit when operating
in the native stand-alone "APRS" mode with no computer attached. The only
way to get around this is to place the Kenwoods' built-in TNC into "PACKET"
mode and use an external computer and APRS program that formats normal APRS
plain text strings (i.e. non-Mic-E ).
Of course, the transmissions will take more air time and be less reliable
(the longer the packet, the greater the chance they will hit by a mobile
fade, noise pop, or be clobbered by another station) --BUT-- the position
reports will be human-readable with just a terminal attached to a TNC.
The Mic-E ( Mic-Encoder) format was originally created to allow a VERY short
and unobtrusive APRS position burst ( less than .3 sec ) to follow a voice
transmission on unkey. The idea was to have a TNC attached to a voice
repeater's input that would detect the packet burst, mute the repeater's
audio for a moment so the burst doesn't get retransmitted on the repeater
output (similar to muting autopatch touch tones), and then retransmit the
packet on 144.39 (using an additional transmitter at the repeater site) so it
would enter the normal APRS network.
The Kenwoods are capable of this type of operation (you select DATA TX -
PTT instead of DATA TX - AUTO in their APRS setup menus), as is the Byonics
TinyTrak. Only a handful of repeaters have implemented this feature but it
can be very helpful for public service events, search-and-rescue, etc.
Note that even if the repeater doesn't strip, mute and re-transmit Mic-E
bursts on another frequency, you can let Mic-E bursts pass through any voice
repeater. Then anyone monitoring the repeater's OUTPUT with a TNC attached
to their transceiver (or even a BearCat scanner) and an APRS program on their
PC can see your position each time you unkey from a voice transmission. [
Or for the ultimate in minimum hardware setups, feed the receiver monitor
audio into the PC's soundcard and use a software TNC such as the AGW Packet
Engine or MixW combined with UI-View or other APRS app. ]
The TinyTrak encoder can be inserted in the line between the mic and mic
jack of just about any radio to add this capability ( as well as normal APRS
autobeaconing ) instantly. Of course, you also need a GPS connected to the
TinyTrak's serial port. See
http://www.byonics.com
for info on this transmit-only TNC-like device that sells for $xx US in kit
form.
I am using this approach to Mic-E after voice on the 146.700 Sunset Ridge
repeater about 40 miles east of Los Angeles. Here I am following up live
mobile SSTV transmissions ( my "Mobile SSTV LiveCAM" ) with the Mic-E
transmissions. At my house (about 28 miles west of the repeater), a receiver
monitoring 146.70 is connected to both a computer soundcard (to decode the
SSTV pics and save them as JPG files) and a Kantronics TNC (to decode the
Mic-E bursts and hand them to an APRS mapping display). The picture, and a
map showing where it was sent from, are then assembled into an HTML page and
automatically uploaded to my website.
To minize the irritation to voice listeners on the frequency, I have the
TX deviation of the Mic-E bursts turned down to only 2 KHz (as against 5KHz
peak on voice). The brief packet squawk is barely noticable against the much
louder repeater squelch crash that immediately follows it.
The results ( APRN - Automatic Picture Reporting Network ) can be seen at:
http://members.aol.com/_ht_a/wa8lmf2/aprn/
[ Note: There is an SSTV net every Sunday night starting at 7:30PM Pacific
time on this repeater. If you monitor my website then you will see a new
picture appearing every few minutes for several hours as well as randomly
during the week. ]
[ Note 2 I have extended the APRN concept even farther. I use the Kenwood
VC-H1 "KenCam" handheld SSTV device connected to my TH-D7 handheld on UHF to
transmit SSTV pics, complete with Mic-E bursts, short distances to my car. In
the car, a Kenwood TM-742 tribander in cross-band-repeat mode retransmits at
full power on 2M to the Sunset repeater. I plan to use this setup to send
"LiveCAM" pics of the upcoming monthly TRW ham swapmeet on Sat March 29 --
It's always the last Saturday of each month. ]
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: Some comments on Mic-E / APRN up and running in Los Angeles
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sun, 16 Mar 2003 08:15:13 -0600
X-Message-Number: 3
>-----Original Message-----
>From: WA8LMF2@aol.com [mailto:WA8LMF2@aol.com]
>Posted At: Sunday, March 16, 2003 2:13 AM
>Subject: [aprssig] Some comments on Mic-E / APRN up and
>running in Los Angeles
>
>Here is the same packet after passing through an Igate and
>displayed on Findu:
>
>Raw packet:
>WA8LMF>APK001,WIDE2-1,qAO,K6TVI:@160641z3409.81N/11807.01W[000
>/000/Mic-E/M0/Off
>
>1) Note that Findu has decoded and expanded the Mic-E
>compression back to
>normal text format.
Actually, K6TVI's IGate has decoded the Mic-E sequence. Most current
IGate software (I believe WinAPRS is the exception, though I may be
mistaken) no longer default to decoding Mic-E packets before inserting
them on APRS-IS. The decoding of Mic-E packets before insertion on
APRS-IS can cause duplicate packets to be passed because different
software translate into different formats. As you also mentioned, the
translated packet itself is substantially longer than the original Mic-E
packet. Both of these issues increase the bandwidth requirements on
APRS-IS.
Another problem with Mic-E translation at the IGate is accuracy. There
has been IGate software that has had bugs causing the Mic-E packet to be
improperly translated. Another problem is that the implementation of
the conversion from the Mic-E format to display decimal is different
between software causing minor variances. These minor variances can
cause the station to appear to move randomly on a client, especially if
multiple packets are inserted on APRS-IS for the same Mic-E packet.
For IGate operators: If your software allows you to turn off Mic-E
translation, please do so. It will have no affect on your client
presentation, but it will greatly improve the accuracy and bandwidth
utilization of what is presented on APRS-IS.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
