| |
ZL3AI > APRDIG 23.12.03 19:30l 229 Lines 9267 Bytes #999 (0) @ WW
BID : 2535-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 19, 3/5
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<LZ3NP<KD7HAH<WA7V<VK7AX<
ZL2BAU<ZL3VML
Sent: 031223/0915Z @:ZL3VML.#80.NZL.OC #:15162 [Chch-NZ] FBB7.00i $:2535-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Building (rebuilding) tracker
From: Dale Mosby <dale@archcape.com>
Date: Fri, 19 Dec 2003 08:14:27 -0800
X-Message-Number: 15
When the APRS bug bit me I visited the local HRO looking for a small and
inexpensive 2 meter radio. Other requirement was that I had option of
controlling radio power externally - meaning that radio would power up when
12V was applied.
The Icom 2100-H had a $xx off coupon making the price $xxx. It would be
nice if I could have used a single connector, but I need to use an RJ45
style jack for microphone and PTT on the front of the radio and small plug
for audio on the back of the radio. I have one working with a TT3 in car,
and one working with KPC3 and Xastir running on Linux in the house.
The radio feels like it has a "soft" power switch, but it does indeed
spring back to life if you plug it into 12V. Are there examples of current
2 meter mobiles that are always powered off 12 is first applied (do not
retain the "on" setting)?
Dale, K7FW
>At 08:30 AM 12/19/2003 -0600, Ken Cechura wrote:
>Well, the APRS bug hit me again. I want to put a tracker back
>in my truck.
>thus I need something that can either auto-power-on or just be
>left on... So a hard power switch, not a softkey
----------------------------------------------------------------------
Subject: Re: SmartBeaconing and corner pegging
From: wes@johnston.net
Date: Fri, 19 Dec 2003 11:14:47 -0500 (EST)
X-Message-Number: 16
I wrote a version of smart beacon for the kenwood radio... it's in the
aprssig archives someplace.... for a basic stamp.
Smart beacon code for the ham hud only uses the heading as indicated by the
GPRMC. There is no angle measurement to/from the last beacon point. In a
nutshell...
1)beacon your position/spd/hding, remember heading and time of beacon.
2)calculate a permissible heading deviation based on speed (faster is smaller
angle)
3)if abs(current_heading-last_heading_beaconed)>heading_deviation then goto
step 1.
4)if calculated distance>speed x time from last beacon, then goto step 1.
5)if you are going below low speed threshold, set beacon rate to
enormous_long_time; wait for speed to increase again.
I added a hysteresis to slow speed.... I made it beacon as soon as you
dropped below the low speed, and again when you got 5mph over slow speed
theshold.
I would also consider adding a delta speed function (just like delta
heading)... because the clients can use dead reconing, but they depend on
speed AND heading for that .... so any significant change in either
warrants a postion TX.
The use of SB will reduce transmissions (in theory) and randomize the times
a tracker TXs... so two trackers won't get synched on the same second of
each minute and continually QRM each other. In practice where we have long
slow curves, I had to modify the routine to wait to beacon until I had two
sucessive GPRMC's with the same heading (ie you are not turning any more).
Also, here in the east, we have jogs in the roads... a slight turn the
left, a slight turn to the right which would cause two TX's... I'm sure
tuning would have taken care of that though....
I do like your idea of "off course" though.... Not sure we have the
processing abilities to do centerline deviation measurements in a pic
though....
So if I had my druthers....
1- check delta speed
2- check delta heading (subject to speed threshold)
3- distance
4- xx meters offcourse from straight line from last beaconed heading
5- stopped beacon rate with hysteresis (for stop and go traffic)
WEs
On Thu, 18 Dec 2003 15:42:44 -0800, "Scott Miller" wrote:
>
>An adaptive beacon rate algorithm is next on my list for the OpenTracker, so
>I went and looked up the SmartBeaconing algorithm used by the HamHUD and
>TinyTrak3. The algorithm looks pretty straightforward, but as I read it a
>proper implementation would require calculating the angle between a line
>from your current position to your last beaconed position and a line from
>your last beaconed position along the heading you were following at that
>point.
>
>My question is, do existing trackers really do this? Are they calculating
>the angle, or just going by the indicated heading? I think that'd be fine
>for most purposes, but if you were to take a dogleg in your course and
>return to your original heading before the next beacon, the tracker wouldn't
>notice.
>
>Thanks...
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: SmartBeaconing and corner pegging
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 19 Dec 2003 08:55:59 -0800
X-Message-Number: 17
Right... I've been giving it some more thought and basically what I'm
thinking of is a dead reckoning calculation that runs from the last beaconed
fix. Once the error between the dead reckoned fix and actual fix exceeds a
certain threshold (dependent on speed, I suppose) another beacon is
transmitted. It's just going to be a little tricky to do this without trig.
I think I might try treating the coordinates as rectangular and just
watching the slope. Might not work well at higher latitudes though.
Do other smartbeaconing trackers enforce a minimum time between beacons?
From a quick glance at the HamHUD code I can't see that it does.
Something else I've been considering on the opentrac side is the possibility
of saving one fix between beacons, either the midpoint or the point furthest
from a line drawn between the two beacons, and then transmitting that fix
with the next beacon. That'd double your track resolution, and with the
current element definitions, it works out to I think 10 extra bytes. A
differential fix element type might cut that down to 6 or less. That
doesn't help with real-time positioning, but for applications like SAR
search coverage it's important to know where you've been, not just where you
are now.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Holiday Traveling = 144.39 CTCSS 100
From: Bill Vodall - WA7NWP <wa7nwp@jnos.org>
Date: Fri, 19 Dec 2003 09:03:27 -0800 (PST)
X-Message-Number: 18
On Fri, 19 Dec 2003, Bob Bruninga wrote:
>You can only use Voice Alert on a rig that has the TNC connected to the
>discriminator or audio prior to the CTCSS Squelch circuit... otherwise
>your TNC wont hear anything except another local voice alert station.
Key here is when talking about a rig that "has the TNC." There's no
special hookup requirement for regular radios or scanners.
I have a memory programmed in the main rig for 144.39 with 100HZ enabled
for receiving and transmitting. Theory is, that as I'm scanning through
the memories, it'll break the squelch if I hear a packet or transmission on
144.39 with the tone. It ignores all the other packets with no tone.
That memory also allows me to call stations using Voice Alert. I have a
neighbor running Voice Alert on his mobile D700 but have yet to catch him
on the road when I'm by my radio.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: UNPROTO, etc.
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Fri, 19 Dec 2003 12:31:35 -0500
X-Message-Number: 19
Okay, let me ask it in a different way... My tracker shows up on Findu and
APRSworld when I use "APRSxx VIA WIDE, WIDE" and also when I use "GPS VIA
WIDE,WIDE".
So what's the difference? Why should I use one construct instead of the
other? And why do I seem to see even stranger things (e.g., "APD215") when
I look at raw packets on Findu? What do those mean??
----------------------------------------------------------------------
Subject: GPGGA with no GPRMC?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 19 Dec 2003 09:48:45 -0800
X-Message-Number: 20
Are there any GPS units out there that send GPGGA but not GPRMC, or vice
versa? I was looking over my code, and the way it's set up now it has to
get both or it won't ever beacon at all. It obviously can't get full data
without both, but do I need to provide an option to transmit with only one
or the other?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: UNPROTO, etc.
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 19 Dec 2003 11:49:38 -0600
X-Message-Number: 21
>Okay, let me ask it in a different way... My tracker shows up on Findu and
>APRSworld when I use "APRSxx VIA WIDE, WIDE" and also when I use "GPS VIA
>WIDE,WIDE".
The APRSXX or APD215 are encoding software version numbers in the TOCALL
field. Pretty much worthless, especially in the case of WinAPRS which encodes
its version 3 times in some packets. Look on Bob B's site for a listing of
the tocalls. You can also do stuff like ALTNET's or MIC-E encode latitude (or
longitude, I forget which).
APRS is a fine TOCALL to use.
>So what's the difference? Why should I use one construct instead of the
>other? And why do I seem to see even stranger things (e.g., "APD215") when
>Ilook at raw packets on Findu? What do those mean??
You can look in the APRS spec for further details, but it's not really that
important for a "dumb" tracker.
-Jim
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
