| |
ZL3AI > APRDIG 01.12.06 06:20l 242 Lines 9363 Bytes #999 (0) @ WW
BID : 9163-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 29 #27, 1/2
Path: DB0FHN<DB0RGB<DB0SL<DB0FSG<DB0PV<OE7XLR<OE2XUM<OE5XBL<OE6XPE<OE3XZR<
OE1XAB<HG8LXL<7M3TJZ<HS1LMV<TU5EX<IW2OAZ<ZL2BAU
Sent: 061201/0511Z @:ZL2BAU.#79.NZL.OC #:18021 [Waimate] $:9163-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Re: Proportional Pathing and Aprstracker v0.11? (Chris Kantarjiev)
2. RE: Proportional Pathing...(SmarBeaconing) (Steve Bragg)
3. RE: RE: Proportional Pathing...(SmarBeaconing) (Robert Bruninga)
4. Garmin GPS35PC not getting fix (Ralph Milnes)
5. RE: Garmin GPS35PC not getting fix (Amir's email)
6. RE: Proportional Pathing NOW in KPC3+ trackers (Robert Bruninga)
7. RE: Garmin GPS35PC not getting fix (Curt Mills)
8. RE: Garmin GPS35PC not getting fix (Amir's email)
9. RE: Garmin GPS35PC not getting fix (Curt Mills)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Nov 2006 10:03:57 -0800 (PST)
From: Chris Kantarjiev <cak_at_dimebank.com>
Subject: [aprssig] Re: Proportional Pathing and Aprstracker v0.11?
Is there a way to set up the D7 or D700 to do this? Sure would be better
than what they do now.
73,
chris
------------------------------
Message: 2
Date: Wed, 29 Nov 2006 13:30:16 -0600
From: Steve Bragg <steve_at_hamhud.net>
Subject: [aprssig] RE: Proportional Pathing...(SmarBeaconing)
format="flowed"
Since Tony Arnerich and I developed SmartBeaconing(tm) (originally for the
HamHUD II), I just can't resisting putting an oar in here.
Bob WB4APR wrote:
>My concern (maybe unfounded) is the un-deterministic
>timing of smart-beaconing settings so that I may pass within
>yards of a smart beaconing system and never know it.
If you're talking about receiving an update coincidental to your relative
positions, yes, but you have the same problem with a timed beacon system.
Since your desire to see a position update may not coincide with the
tracker's beacon schedule, you may not get a beacon when you're within
"yards" of it, regardless of the path.
But APRSDOS and other APRS clients do dead-reckoning. SmartBeaconing's
primary goal is to enable dead-reckoning to be as meaningful as possible.
If corner-pegging is implemented properly, nearby stations should be able
to see when the path of a tracker comes within "yards" of their station,
even if the tracker doesn't beacon when nearby. And speed-dependent
beaconing means more updates if the tracking is changing position more
rapidly.
>Or may
>drive though a small town where someone is just loitering along
>at 10 MPH and never see his smart beacon until 10 minutes later
>after I am long gone.
Unlikely, because corner pegging will trigger beacons on turns, even at 10
MPH. Also, there is minimum beacon setting (at least in HamHUD) so that
the "10 minutes later when I am long gone" situation doesn't occur.
I think this is another situation where the same problems will be
encountered with a timed-beacon system that is improperly configured. It
may actually be worse because the timed beacon is uncorrelated with vehicle
motion.
>Smart beaconing had the same goal of proportional pathing, to
>minimize QRM on the network, and does an excellent job of that.
That is only one of the goals of SmartBeaconing. As I said, the primary
goal is to create what KD7TA and I call "1-dimensional position
uncertainty", where a moving station's position is constrained to a line
(or great circle). In other words, to make dead reckoning into a useful
tool.
>But it does so, by sacrificing local updates as well. And
>treating local and distant areas with the same reduced-reporting load.
This has to be put into historical context. When Tony and I came up with
SmartBeaconing back in 1998, there were no nationwide path recommendations,
as in the "New N" protocol. Even if most SmartBeaconing implementations
ignore local/DX path considerations, reducing QRM everywhere is still a
worthwhile goal.
And I take issue with the charge that SmartBeaconing "sacrifices local
updates". SmartBeaconing tries to optimize position updates, whether they
be local or DX. SmartBeaconing does not "sacrifice" updates; it ensures
that the position updates carry spatial information about the general state
of motion of the vehicle. A timed beacon can't do that, pathing or no
pathing, because it is uncorrelated with vehicle motion.
>I personally like Proportional Pathing because it keeps
>the local rate consistent and high enough for good tracking,
>while at the same time reducing QRM further out.
The 'smart' move (pardon the pun) is to bring Proportional "Pathing" under
the umbrella of SmartBeaconing, as Arno has done, and as I have promised to
Bob in private email that I would do on the next release of HamHUD. (I add
the quotes because 'Path' isn't a verb, so is 'ing' really appropriate?)
Making SmartBeaconing aware of local and DX paths, in my opinion, just
makes a good thing better.
73,
Steve Bragg KA9MVA
--
HamHUD - Heads-Up Mobile Ham Radio
HamHUD Nichetronix, LLC
http://www.hamhud.net
------------------------------
Message: 3
Date: Wed, 29 Nov 2006 16:01:52 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] RE: Proportional Pathing...(SmarBeaconing)
Steve,
Thanks!
Good info on Smart Beaconning. Looks like you covered all the bases and I
agree completely with all you said. Bob, WB4APR
------------------------------
Message: 4
Date: Wed, 29 Nov 2006 16:32:04 -0500
From: "Ralph Milnes" <ralphmilnes_at_patmedia.net>
Subject: [aprssig] Garmin GPS35PC not getting fix
I have an old Garmin GPS 35PC (I think I bought it from TAPR many years
ago).
It's been sitting in a box for those many years, and I'm now trying to get
it going. I've hooked it up to my D700 and via the P.MON option I can see
that it is sending GPRMC and GPGGA sentences OK.
The problem is that it's not getting a fix after 2 days out in the open
(tried several locations). The RMC sentence includes a "V" in the second
field indicating "no fix", but has the correct UTC time and date in the
sentence.
I've had the unit powered at 12V direct from the car battery for 2 days.
Could the backup battery -- which is no doubt depleted -- be the problem?
Anyone know if there's an easy solution to this? The cost for Garmin to look
at it exceeds its value.
Ralph KC2RLM
------------------------------
Message: 5
Date: Wed, 29 Nov 2006 16:52:27 -0500
From: "Amir's email" <sarlabs_at_twcny.rr.com>
Subject: RE: [aprssig] Garmin GPS35PC not getting fix
Hi Ralph:
Go to this page: http://www.garmin.com/products/gps35/download.html
Download the latest software update (from 2000) and install it in your
dinoGPS. I bet it will work then. Simply, in August 1999 the GPS calendar
hit a Y2K-like bump and mot units were not ready for it (other than the
Garmin III or III+ I believe). I was on a search in the Great Sandy Desert
in Western Australia then and one day my Garmin II was working fine, the
next nothing. Nothing worked till I got back home and did the procedure I
described above (with the appropriate file).
OTOH, this unit is so old, the technology so ancient that it may not be
able to perform. I don't remember how many channels the 35 has, but they
definitely are not parallel, so it will take a long while to lock on the
satellite and retaining acquisition in a car, where at least half the sky
is covered by the roof, well it is going to be iffy at best.
73 de K9CHP, Amir Findling, member ARRL, AMSAT #36083
1st Special Response Group (1SRG) http://www.1srg.org/
Apprentice Tracker, Joel Hardin Professional Tracking Services
http://www.jhardin-inc.com/index.htm
------------------------------
Message: 6
Date: Wed, 29 Nov 2006 20:10:17 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Proportional Pathing NOW in KPC3+ trackers
>But those BLT settings you show would send a 3-hop packet every 6 minutes!
OOPS. Yes, the BLT-4 was supposed to be every 12 minutes.
>Three-hop path routines are not desirable at all in the Western USA.
That depends on what you mean by "west". I think in the central plains
states out to the Rockies, that 3 hops is usually OK.
>Also, you need a ToCall something like GPSMV
>(in the LTP settings) to produce a "car" map symbol.
Ah thanks again!
------------------------------
Message: 7
Date: Wed, 29 Nov 2006 18:40:38 -0800 (PST)
From: Curt Mills <archer_at_eskimo.com>
Subject: RE: [aprssig] Garmin GPS35PC not getting fix
On Wed, 29 Nov 2006, Amir's email wrote:
>OTOH, this unit is so old, the technology so ancient that it may not be able
>to perform. I don't remember how many channels the 35 has, but they
>definitely are not parallel, so it will take a long while to lock on the
>satellite and retaining acquisition in a car, where at least half the sky is
>covered by the roof, well it is going to be iffy at best.
Huh? It most certainly has parallel receivers, 12 of them. It was going
for $440 retail at the time I bought mine, but I bought it for a bit less
used from someone that only needed one for testing a short time. So I
bought mine when they were quite new. It was the first 12-channel parallel
unit from Garmin that I could actually get my hands on.
It doesn't have WAAS, but it is 12-channel parallel and locks up nice and
fast.
--
Curt, WE7U. archer at eskimo dot com
http://www.eskimo.com/~archer
Lotto: A tax on people who are bad at math. - unknown
Windows: Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me: I picked the coordinate system!"
------------------------------
Read previous mail | Read next mail
| |
