* GPS: 2.00—8.76 m
* GLONASS: 4.46—7.38 m
* GPS+GLONASS: 2.37—4.65 m [citation needed]
To improve development of the user segment, on August 11, 2010, Sergei Ivanov
announced a plan to introduce a 25% import duty on all GPS-capable devices,
including mobile phones, unless they are compatible with GLONASS.
Whether the ASIC implementation works and whether the iPhone API actually uses it - is another matter
Tim Cook mentioned sales growth in Russia as something to keep an eye on in Apple's latest conference call: http://www.apple.com/quicktime/qtv/earningsq411
Performance in urban canyons or heavily wooded areas is greatly improved, as there's a much better chance of the receiver seeing enough satellites. Likewise, startup times can be much quicker.
An intelligent receiver using GLONASS only when needed could have dramatically better real-world performance with only a minor increase in battery consumption.
We're inevitably going to see GLONASS everywhere due to the Russian import duty, but it's a real boon to most ordinary GNSS users, for whom the main limit on practical precision is being able to see enough satellites. This is likely to become increasingly important as the existing GPS satellites reach end-of-life.
In fact I just found a wikipedia article all about it - http://en.wikipedia.org/wiki/GPS_augmentation :)
There's an opensource rtklib which supports a handful of inexpensive receivers: http://gpspp.sakura.ne.jp/rtklib/rtklib.htm
You also need either a lot of storage locally or a fast data link between the base station and the rover - phones actually have both of these but they cost money
So, $0.50 instead of $0.01? :)
I used to have an updating map on the web of all the GLONASS satellites the Russian government had put into orbit, but it was taken down.
Right now, Kinze are heavily touting their autonomous system for grain carts: http://www.youtube.com/watch?v=MhA5aIw7xNk
John Deere and CNH have similar systems in actual production, but still require an operator to be present for safety reasons. And safety seems to be the big limiting factor. While the technology is basically there, nobody wants to remove the operator just yet. Though in this video, someone disabled the safety sensors to go fully autonomous: http://www.youtube.com/watch?v=zU4liQvrcm4
Most farmers are pulling their RTK data over wireless/mobile internet connections, rather than having their own base station. I don't know of anyone who maintains their own station. A few companies have placed base stations around various places in the countryside and will happily sell you their data.
In Europe (and of course in Germany) the federal governments offer realtime gps correction data via IP or 3G (radio was shut down a few years ago).
They offer a precision of 1cm-2cm used together with GPS/GLONASS
PDF: http://www.sapos.de/pdf/Flyer/2004Flyer_e.pdf
(Sorry, German language only:)
We successfully navigated a car down a twisting road, about 10' wide, without looking out the window, so it was a useful mechanism. It became less important, of course, once the US Government removed the S/A error from the GPS signal and the commercial use of GPS took off.
In actual receiver implementation you really get worse accuracy for simpler reason: most of the hardware resources (ie. receiver channels) are same between GPS and GLONASS, so using GLONASS ties up resources for GPS and vice versa.
Some modern receivers are able to use both GLONASS and GPS
satellites together, providing greatly improved coverage in
urban canyons and giving a very fast time to fix due to over
50 satellites being available. In indoor, urban canyon or
mountainous areas, accuracy can be greatly improved over
using GPS alone.
The most accurate GPS fix is had when the satellites you're seeing are widely separated in the sky. In the urban canyon, the problem isn't a lack of satellites, but the fact that you can only see those that happen to be in a narrow slice. And narrow slices are bad for constraining the solution to the equations.
The way I think about it is each satellite being used in the solution is like a rope tied to the satellite (where stretchiness of the rope is analogous to measurement error). Your GPS receiver can calculate your location to within the accuracy of how far you can move while keeping all ropes taut.
So if you had a fix from two satellites that are smack next to each other, you really don't have a fix any better than a single sat. If you've got two ropes at 180-degrees opposite each other (i.e., at either end of the street in the urban canyon), you've still got ambiguity due to your potential for lateral movement. For a good fix, you've got to bring in another rope at a wide angle from those -- but the tall buildings interfere with getting that rope, even if there are lots of satellites up there that could be offering it.
To use a reductio ad absurdum argument, imagine a satellite positioning network with a thousand nodes. Wouldn't it have a greater chance of providing a useful fix in this environment: http://g.co/maps/sa8zk ?
Also for OpenStreetMap this would be great. This would get the accuracy down to "error less wide than a street" levels on customer devices.
Sailors find that their charts are some times off by kilometers. I've personally seen a large, erroneous discontinuity in the western coast of St. Lucia while using a GPS chart plotter for navigation. Chart data is copied forward from older charts, many of which were made in the 1800s, those guys were good with a sextant, chronometer, and a pen, but when near land you need your eyeballs.
[1] http://abcnews.go.com/blogs/politics/2010/11/google-nearly-s...
For what it's worth, GPS seems to work fine for a lot of people around Lompoc, CA: http://www.strava.com/rides-by-country/united-states/califor...
Searching for combinations of terms like "GPS, blackout, airforce base, lompoc" only brings up this thread. I find it hard to believe that if it were a real occurrence no one else would notice and write/complain about it.