On 2013.04.28 23:27 , Me wrote:
> On 29/04/2013 10:51 a.m., Alan Browne wrote:
>
>>
>> The thing there is that it's based on "satellites in view" rather
>> than satellites actually being received and tracked. "in view"
>> means "from where you are, if there were no obsacles..."
>>
> No. There's even a free android app "GPS essentials" which gives a
> graphic positional chart, showing satellites that are in view, and of
> those, which are in view which ones are used for tracking, and a
> graphical representation of s/n ratio for each.
Which goes to the estimated position but not to the estimate of
accuracy. This is an old issue with GPS receivers. The DOP's and URE
are based on "in view" and not on "tracked". But show me an app that
proves to do it differently and I'll be happy to look into it.
I just DL'd the "GPS Essentials" manual. It makes no mention of
fundamental GPS errors at all. No mention of the various DOP's. No
mention of FOM. No mention of URE. It does mention the 'used' / 'not
used' sats but it does not state _how_ it estimates accuracy.
(Note: the receiver device provides URE/FOM/DOP info so most apps won't
bother doing an independent estimate)
(No mention of WAAS, EGNOS or SBAS either)
S/N doesn't contribute much to accuracy unless the receiver is trying to
track well below recommended tracking thresholds. It would be nice if
there was a user setting for "conservative" v. "aggressive" acquisition
and tracking thresholds.
>>
>>> So I walk outside with my GPS phone on to my deck, zoom in with a
>>> google satellite overlay, and it shows that I'm on the deck of my
>>> house, reported accuracy 4m - but I presume that's maximum
>>> deviation, as it's pinpointed my position within a metre.
>>
>> I can show you Google satellite views that are off by over 10
>> metres - without even referencing a GPS. Take it with a grain of
>> salt. That said, Google sat views are very good - but not always,
>> dependably so.
> I'd like to know how systems like Google Earth allow for tectonic
> plate movement.
Google earth uses photos indexed to WGS-84, the same as GPS reference
system. But if the company providing a given photo didn't reference
it to WGS-84 correctly then there will be errors (as I've seen locally).
Plate movement is very slow. So slow that Google's continuous
replacement of aerial photos would more than account for it except where
there was a recent large shift.
Over time of course, the various constants in mapping systems that
relate _places_ to _geo-references_ will have to be updated. Esp. in
active regions such as Japan and California.
>>
>>> But the phone outperforms each dedicated device in other ways.
>>> Battery use is much lower, map loading is much faster, screen
>>> resolution is higher with much faster refresh/scrolling, route
>>> calculation (using a dedicated "off-line" car GPS app) is much
>>> faster.
>>
>> I plot WAAS GPS' v. the iPhone and the iPhone error is usually
>> 5-20 metres v. true all-in-view/WAAS errors of 3 - 5 metres.
>>
>> The iPhone GPS saves power by driving the correlators less often.
>> (Typical is 1 Hz, some GPS' go 10 or 20 or more. The iPhone is 0.5
>> Hz or worse).
>>
> I'm not using an iPhone. GPS update interval is user-adjustable.
There are plenty of GPS' with user settable _recording_ (or reporting)
rates, but that is not the GPS correlator _tracking_ loop rate. These
are different things.
Tracking loop rate is an internal thing to the device in the smartphone.
Some advanced GPS allow a user setting of 1 Hz, 2 Hz, 5Hz, 10 Hz, 20
Hz and so on tracking loop rates - but these are
configuration settings and typically not changeable without a re-start.
These are not very useful for hiking, but find their
place in inertial aiding and so on.
In the iPhone, to save power, they reduce the tracking rate. It's not
published, but looking at track recordings it's clear enough that the
rate is not better than 2 Hz. (And why it uses WiFi and cell towers for
"aiding").
>> Shipboard GPS systems are integrated with plotters and the radar
>> system, position reporting, autopilot and so on. It's very
>> sophisticated and in someways laughably badly done - esp. the
>> communications bus (bogged down by legacy crap).
>>
> Yes - I was on a suction dredger a few weeks ago, made my way out on
> the harbour pilot boat, accompanied by a tech from a marine
> instrument company who was going to service some of their systems.
> The systems were complex, I believe integrating sonar depth plotting
> - the dredge head must be positioned accurately, taking into account
> tide and the hopper load as they fill it. If they get it wrong,
> something very expensive gets broken.
I neglected to mention sonar - quite an important part of the plotter
integration to be sure - and not just for dredging. That also predates
GPS integration.