| |
ZL3AI > APRDIG 28.12.03 01:42l 248 Lines 9708 Bytes #999 (0) @ WW
BID : 2558-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 25, 1/2
Path: DB0FHN<DB0FOR<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0BEL<ON0AR<WB0TAX<VK7AX<
ZL2BAU<ZL3VML
Sent: 031227/2250Z @:ZL3VML.#80.NZL.OC #:15441 [Chch-NZ] FBB7.00i $:2558-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Thursday, December 25, 2003.
1. RE: (re)building my tracker
2. Re: SmartBeaconing and corner pegging
3. RE: Santa's Sleigh
4. Re: SmartBeaconing and corner pegging From: "Spider"
5. Re: SmartBeaconing and corner pegging From: "Spider"
6. Re: SmartBeaconing and corner pegging From: "Spider"
7. UIView , Firewall
----------------------------------------------------------------------
Subject: RE: (re)building my tracker
From: WA8LMF2@aol.com
Date: Wed, 24 Dec 2003 23:58:36 EST
X-Message-Number: 1
In a message dated 12/24/2003 7:43:11 PM Pacific Standard Time,
kcechura@umr.edu writes:
>Anyway, thanks for the suggestions, now to just figgure out the cabling from
>my standard to the Mini-DIN...
Once again, my mini-essay on the MiniDIN6 packet/data connector... Full
details on the MiniDIN 6-pin "DATA" connector follow. This is a reprint of
a post I have made many times on various groups and mailing lists about
this issue.....
====== PASTE ========
The 6-Pin MiniDIN "DATA" or "PACKET" connector is an industry standard
adopted by all the Japanese ham mfrs. It is now superseding the various
proprietary 7, 8 and 13-pin full-sized DIN connectors used by various
manufacturers. The contacts on this connector provide access to:
1) TWO kinds of receive audio:
Raw non-deemphasized discriminator output sometimes labeled "9600 Baud
Receive".
De-emphasized squelched audio similar to what come out the speaker, but
at a fixed level unaffected by the volume control. It is sometimes labled
"1200 Baud Receive" or "RXD". On multi-mode radios (Yaesu FT-817, Yaesu
FT-100, Icom 706, etc), only the "1200 baud" output will be live on AM, SSB
or CW since the 9600 baud output is associated only with the discriminator
of FM receivers.
2) TX audio input (sometimes misleadingly labeled "TX Data Input" or
"TXD") In some radios, a menu setting for "1200" vs "9600" baud will
determine if this input goes either into the same channel as the mic input
(but at a higher audio level) for 1200 baud packet, SSTV, EchoLink, AFSK
RTTY, etc, or is DC-coupled directly into the TX modulator (for 9600 baud
packet).
3) TX PTT (confusingly labeled "Standby" by Kenwood) -- normal
ground-to-transmit line just like most mic inputs.
4) Receiver Squelch status line (normally no sig-squelch-closed = 0V,
signal active-squelch open = 5V). Sometimes labled "COR" (Carrier Operated
Relay - an archaic term from the early days of FM repeaters), "COS"
(Carrier Operated Switch), "RX", "CD" (Carrier Detect), "Activity" or
"Busy".
5) Common/Ground.
Note that despite the misleading labels referring to data input and output,
the jack only carries AUDIO, AUDIO, AUDIO! THERE IS NO ACTUAL RXD or TXD
DATA in the sense of RS-232 or TTL-level streams of 1s and 0s anywhere on
this connector!!!
This connector is the perfect point to connect packet TNCs, soundcard
interfaces, phone patches, IRLP/EchoLink controllers, APRS trackers, paging
encoders, or any other device that needs access to the transmit and receive
audio of a radio.
These audio inputs and outputs are high-level (100-300mV), similar to home
stereo "LINE" input level seen at RCA jacks on tuners, amps, tape decks, etc,
rather the the 5-10mV level seen at most mic input jacks.
NOTE that this means that you have to set the audio output ("TRANSMIT")
level of sound card interfaces, TNCs, data controllers, APRS trackers, etc to
a MUCH higher level than you would for a normal connection into the mic jack.
With some devices you will have to shift internal jumpers, or exercise
software menu commands to increase output level (recent Kantronics TNCs for
example).
On most radios with this port, grounding the DIN-6 PTT line mutes the front
panel mic input to prevent extraneous shack noises from getting mixed with
whatever you feed into the transmit audio input.
You can connect a TinyTrak here very effectively if you:
1) Change R5 (220K resistor) on the TT to about 27-33K to boost the TX audio
level from mic level to line level.
2) Connect the direct DC-coupled "CARRIER DET" line of the TT to the
MiniDIN "SQUELCH" or "COR" line.
An annotated pinout diagram of this connector, useful as a worksheet for
making up cables, is on my website at:
http://members.aol.com/wa8lmf/miscinfo
Click through the link on this page which will take you to a directory of
assorted downloadable files, not a web page. Look for the file
MiniDIN6-Packet.pdf
Note that this connector is exactly the same one used on PS/2 keyboard and
mouse cables. A PS/2 keyboard extension cable is an excellent source of a
plug and cable assembly to mate with the jack on the radio. [at a fraction
of the cost of the optional Kenwood or Yaesu cable assemblies! ] Cut the
female end off, strip the bare end and connect the bare leads to the
appropriate pins of whatever mates with your tracker, TNC, or soundcard
interface.
Stephen H. Smith wa8lmf (at) 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: SmartBeaconing and corner pegging
From: "Spider" <spider@rivcom.net>
Date: Thu, 25 Dec 2003 05:20:13 -0700
X-Message-Number: 2
----- Original Message -----
From: "Steve Jones" <s.jones@rogers.com>
>on 12/24/03 9:53 PM, Spider at spider@rivcom.net wrote:
>
>>There is nothing in the smart beaconing that would determine if a tracker
>>has stopped and it would not send
>>a posit indicating such.
>
>I'm not sure I understand you.
>
>Smartbeaconing can determine when you are stopped (by gps input) and adjust
>your beacon rate accordingly.
Steve,
It has nothing to do with adjusting any rate. When a vehicle is moving, at
any speed, and then suddenly stops, a packet should be sent indicating such.
Think about movement and time.
Jim, WA6OFt
----------------------------------------------------------------------
Subject: RE: Santa's Sleigh
From: Jeffrey Nast <jpnast@lca.duluth.mn.us>
Date: Thu, 25 Dec 2003 11:06:14 -0600
X-Message-Number: 3
He's been there a while... stuck in a chimney? ;-)
-Jeff
KC0MKS
Ken Patterson wrote:
>Ah, Santa's back on findu a/o 0902 CST.
>
>http://www.findu.com/cgi-bin/find.cgi?call=SANTA
>
>SANTA>APU25H,WX4GSO-9*,WIDE3-2,qAO,KD4BNQ-1:;Santa
>*250258z4430.00N/05838.00WX000/121Ho Ho Ho! Merry Christmas!
>
>It must be the work of the elves.
>
>de Ken,
>N5EQT
----------------------------------------------------------------------
Subject: Re: SmartBeaconing and corner pegging From: "Spider"
From: Dale Seaburg <kg5lt@earthlink.net>
Date: Thu, 25 Dec 2003 11:41:45 -0600
X-Message-Number: 4
"Spider" wrote:
"Steve Jones" wrote:
>>on 12/24/03 2:33 PM, hasan schiers at schiers@netins.net wrote:
>
>>>>I'm not sure what vehicle stopping has to do with corner pegging, but
>>>>perhaps it is part of the algorithim.
>>
>>Smartbeaconing can determine when your vehicle is stopped and reduce the
>>beacon rate accordingly.
>There is nothing in the smart beaconing that would determine if a tracker
>has stopped and it would not send a posit indicating such.
That is true Jim. We discussed adding this option to the SmartBeaconing
code on the HamHUD list. It hasn't been done yet, but has been
investigated.
73 - Dale. KG5LT
----------------------------------------------------------------------
Subject: Re: SmartBeaconing and corner pegging From: "Spider"
From: "Spider" <spider@rivcom.net>
Date: Thu, 25 Dec 2003 14:01:17 -0700
X-Message-Number: 5
----- Original Message -----
From: "Dale Seaburg" <kg5lt@earthlink.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Thursday, December 25, 2003 10:41 AM
Subject: [aprssig] Re: SmartBeaconing and corner pegging From: "Spider"
Hi Dale!
I've asked Byon to consider this feature for future TT's. One of the
concerns I know of is the delay in the GPS units reporting zero speed. I
do not know if this could be a real issue. I think it would also clean up
another issue with these tracker units.....that issue being: When a
vehicle stops, the code reduces the transmission rate. Some folks have
this way out there. The problem with NOT sending a 'stop' posit is that
everyone continues to see a vehicle moving as some slow speed.....slowing
to turn into a parking spot, for example. You now see this until the units
decides to send its next posit....or if the tracker is turned off, you see
it until your decay period is reached. Another feature would be for the
balloon folks. When their balloon snags in a tree and stops, it would send
a posit saying it stopped and hopefully exactly where it stopped. Without
this, all you really know is a last known location at a given speed and
direction. So, I think it would be a handy feature. Of course, all people
might not want it or have a need for it, so it should be a user settable
feature. I have no problem be all these features defaulting to off!
Hansen spoke of user education! One way that a software author could help
this user education process is force a user to read about the feature before
allowing a change in state. If, in the software, one decides to change the
state of a feature, a pop-up could appear with information on the feature.
Maybe some would then read it! I don't know!
Happy Holidays!
Jim, WA6OFT
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
