Order Tray | Contact Us | Home | SIG Lists

[aprssig] Ambiguity background

Robert Bruninga bruninga at usna.edu
Tue Jan 8 19:11:40 UTC 2008


> I see that the standard uses "significant digits" 
> for ambiguity. Does this stem back to the early 
> GPS capability whereby only position was 
> transmitted and error was not sent? 

No, it stems back before GPS to early APRS where the first
application was transmitting the position from a boat crew
underway.  Their position throughout the day varried by the
quality of their fix. If they were just estimating their
position, their log showd a position of only 38 deg and 58m
west.

If they used a celestial fix, they might have better precision.
If they were dead recckoning they would be less precise.  APRS
was designed to only TRANSMIT to the end user, ONLY what the
sender entered.  It was a CHARACTER STRING, not a number of
fixed precision.  The receiver got what the sender entered.

LORAN was available but manually plotted so precision was the
subjective call of the sender.  No way was I going to invent a
system that forced him to enter a precision he did not have.
That fails middle school science 101.

Bob, WB4APR


Bob> 	-------------- Original message -------------- 
> 	From: "Robert Bruninga" <bruninga at usna.edu> 
> 	
> 	> > I have a D700. What does *it* do to 
> 	> > the GPS Lat/Lon data when Pos-ambig is 
> 	> > turned on? 
> 	> 
> 	> In the normal APRS format. Unavailable digits of 
> precision are 
> 	> replaced with a SPACE. 
> 	> 
> 	> In the D700 (Mic-E format), unavailable digits of 
> precision in 
> 	> the latitude are replaced with the letter "Z" (not 
> zeros). The 
> 	> Longitude then is assumed to have the same level of 
> precision. 
> 	> 
> 	> When a person enters his estimated position into a D7
or D700 
> 	> manually, he only enters those digits he knows. Then
he uses 
> 	> the position ambiguity menu to INDICATE how many 
> extra digits of 
> 	> precision he is not using. The result is exactly the
same. 
> 	> 
> 	> On decoding of the Mic! -E fo rmat, the position used 
> by the client 
> 	> program should not insert "0's" into those unused 
> positions, but 
> 	> SPACES just like the full APRS format does. Again, 
> this is not 
> 	> truncation, but reproducing at the receipent exactly
what the 
> 	> sender intended. 
> 	> 
> 	> Bob, WB4APR 
> 
> 





More information about the aprssig mailing list