Ahhh, that's the 64 nanosecond question. I did a lot of self surveys with a geodetic grade antenna over a spot known to within less than a millimeter. Most results were with 6 feet lat/lon 6 meters altitude (hey, can I get a job at JPL landing spacecraft? I can mix english and metric in the same measurement). But, the key word is most. Some were off over 50 feet lat/lon and 100 meters altitude. Unless you have a known position to compare against you may never know for sure. And, if you have a precisely known location, you can't enter it into the Tbolt with sufficient accuracy since that message uses single precision numbers. I am doing a couple more tests with a 50 foot error and another with all the error in the altitude (those first two graphs were with lat and lon offset by around 141.4 feet and the altitude exact) ---------------------------------------- Or. to put it another way, what could we reasonably expect to see as a position error if the T'bolt is allowed to self survey? _________________________________________________________________ NEW mobile Hotmail. Optimized for YOUR phone. Click here. http://windowslive.com/Mobile?ocid=TXT_TAGLM_WL_CS_MB_new_hotmail_072009

In message <BLU125-W29155884599C7E38CB3A21CE170@phx.gbl>, Mark Sims writes: >But, the key word is most. Some were off over 50 feet lat/lon >and 100 meters altitude. Unless you have a known position to compare >against you may never know for sure. [...] Actually, you will, if you monitor the per-sat time residuals from the GPS. A couple of years ago, I got to play around with 10 M12M's during a burn-in test, and managed to get some hacked up code to improve the pos-hold coords, while staying in pos-hold mode. The basic trick is to project the per-sat time residuals onto their hemispherical coords (alt+azi) and determine if there is a net E/W or N/S imbalance. The E/W direction worked great simply by comparing the eastern to the western hemisphere and moving the pos-hold longitude accordingly. It is easy to see that if your pos-hold longitude is too far east, sats west of you will have a slightly longer signal path making their signals arrive a little too late, and vice versa. To test my hacked up code, I would intentionally give it a bogus pos-hold to start with, and over a month it would edge onto the right longitude. It can probably be tuned to be much faster. I never got the N/S direction working to my satisfaction, because at 55°N, I have no usable sats north of my antenna, and I never found a good way to do the N/S imbalance with only data for southern half the plane. And then I had to deliver the NTP servers and never got around to play with it again... It should be possible however, because the residuals vary strongly with altitude: almost no effect on a sat right overhead, big effect on sats near horizon (think: basic triangle geometry). Some details at: http://phk.freebsd.dk/raga/sneak/ The above observation gave me another idea which I didn't get to play with, so I don't know if it will work: If your pos-hold is not correct, your time solution will jump whenever a sat is added/deleted from the solution. It may be possible to detect the sign of these jumps, by monitoring the per-sat residuals, and use it to twist the pos-hold coords without the tedious detour over mapping and balancing hemispheres. It is important to not be fooled by near-horizon artifacts, so a high mask-angle is probably required for this to work. Somebody[tm] should really pick up this idea... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.