[aprssig] Ambiguity due to GPS

Bill Diaz william.diaz at comcast.net
Thu Jan 5 18:11:44 EST 2006

  See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Scott Miller
>Sent: Thursday, January 05, 2006 15:48
>To: 'Curt Mills, WE7U'; 'TAPR APRS Mailing List'
>Subject: RE: [aprssig] Ambiguity due to GPS

>> A very good point.  What would be even nicer would be to use the
>> HDOP number to decide how much ambiguity to give the station on the
>> map.  That would work fine for your local station on your own map,
>> but we don't send HDOP in any of the APRS sentences except for NMEA,
>> and those sentences are way too long.

>Well, the OpenTracker does, but it wasn't intended to be a consistent,
>machine-readable format, though it wouldn't be hard to parse.  And it's
>several bytes, when one byte would be plenty for an 
>exponential ambiguity
>scale.  I *really* don't like the APRS convention of dropping the
>least-significant digits.

>The OpenTracker will also output HDOP in telemetry mode, but 
>again that's
>not going to help for this.  Also, I don't think there's a simple
>relationship between HDOP and circular error probability.  
>Maybe Gerry could
>answer that...

We have had a station in my area who sends APOT02 position packets with HDOP
and SATS data every 10 seconds.  In addition he sends telemetry at the same
interval, and >MAK-P2 packets at a longer interval.  

His transmissions amount to about 16 packets per minute, not counting
digipeats.  If we had multiple stations sending this kind of data at this
rate, the local network will quickly become unusable. 

We really need to encourage developers to prohibit these types of abuses on
144.39.  IMO, permitting a user to send such a volume of traffic at 10
second intervals should be reconsidered.

Bill KC9XG

>aprssig mailing list
>aprssig at lists.tapr.org

More information about the aprssig mailing list