If your GPS2000 had no EGNOS reception at the moment, then a 50’ error would be pretty normal, although this depends on the chipset – I recently got another $40 Chinese device that gives much more stable and accurate altitude readings than any other consumer-grade GPS receivers I had; unfortunately, it has a different poroblem, occasionally dropping GPS reception altogether for 5-10 seconds.
Are there any GPS apps which can reveal if EGNOS is being received?
This is android v6; I also have v5 and v4.4.2.
The GNS2000 is running in the “generic” (NMEA over bluetooth serial) mode, not the IOS mode.
Peter wrote:
Are there any GPS apps which can reveal if EGNOS is being received?
Yes, all you need to do is check the satellites in view. All SBAS satellites have NMEA identifiers between 33 and 54. Currently active EGNOS ones are 33 and 49.
In many places Google Earth is based on the Shuttle Radar Topography Mission (SRTM) data.
Depending on the topography of your home, this can be off by up to 20m. See here
Unfortunately this is a deep rabbit hole… if you’re really curious, you’ll get into Geodesy really quickly, which isn’t a bad thing.
Although the application of a Geoid is straightforward for WGS84 (see this ), Great Britain has a really complex system that involves high order calculations for simple datum conversions, (see here ) because GB isn’t based on the ITRS and shifting heights from one datum to another involves executing a grid-shift (see previous link) to be accurate.
What this means is that SRTM (Google Earth) may provide 3-20m of difference, GNSS can provide 30m of difference, applying a Geoid should bring you within 10m (or so, depending) but then you still have a difference between what the Geoid model refers to as “sea level” and what the local survey datum defines it as, which is what your altimeter was probably calibrated to…
The British Vertical Datum references the “Ordinance Datum Newlyn” which is an averaged value from a tide gauge at Newlyn from 1915-1921 that was referenced to a different ellipsoid than WGS84 (obviously ;) ).
As gravity is not homogeneous, (the ocean doesn’t actually follow an oblate spheroid), it undulates (is a geoid) and therefore the measurements taken by field crews can differ dramatically from those taken from space. (The US has a real problem in Louisiana, where the earth is sinking and gravity is actually changing over time)
In the end, it is possible to correlate them all, but for most people, the differences are academic. Now that everyone uses GNSS to navigate, these differences are becoming more apparent…
If you’re into this kind of stuff, check this out, as it will explain the datums in the UK and how they relate to WGS84 in some pretty good depth.
Oh, and sorry for the book, I really do try to write shorter posts, but fail miserably.
all you need to do is check the satellites in view
Right now I can’t find an app which can use the external GPS and which displays satellite numbers.
But Oziexplorer is now reading the fairly correct 230ft! This was after leaving the GNS2000 outside for an hour.
Your post is very interesting, AF – many thanks. I will have a read tomorrow. I am sort of aware of this stuff (e.g. I know there is a polynomial which gives you the mag variation given the lat/long, over most of the surface) but I thought that with EGNOS the AMSL is corrected.
OTOH I do know that the old IFR GPSs (e.g. KLN94, GNS430) had a lookup table for the geoid variation over the whole earth’s surface which is why these boxes really are very accurate – within 20ft on the KLN94.
Peter wrote:
Surely an EGNOS GPS should not need the geoid correction?
Indeed it does.
As EGNOS is merely an augmentation system for GNSS, it is computed in the same type of coordinate system as those positioning systems: (GPS=WGS84, Galileo=ITRF, Glonass=PZ-90, EGNOS=ETRF). These coordinate systems are all similar, but aren’t perfectly aligned. They all have a defined origin at the volumetric center of the earth (each calculated slightly differently), with an ellipsoid defined according to that origin. Their coordinates can be calculated in X,Y,Z from the center of the earth or in polar coordinates, (lat/long) with altitude/height being referenced to the ellipsoid. This makes the computation of a position very straightforward, and transformation between each of these systems is typically only a helmert transformation (i.e. simple).
So now that a coordinate is computed which references the ellipsoid model (lat, long, altitude). The difference between the perfect ellipsoid, and the undulating ocean is needed.
Gravity varies over the surface of the earth, so the oceans are not actually smooth like we would think! There are points in the Atlantic Ocean which are 100m lower than other parts of it… This is because gravity is not homogeneous around the earth (parts of the earth are denser than others). See a visual of these differences here
These differences between the real sea level and the ellipsoid is what makes up a geoid model. As the values from the GNSS receiver are calculated in lat/long/alt, these offsets needs to be applied to convert from ellipsoid height to “sea level”. Without these offsets you’ll be looking at your altitude above a perfect ellipsoid… which is sometimes above, and sometimes below the real ocean surface. For the ETRF coordinates of EGNOS, these differences shouldn’t be too large. (but I haven’t checked, so I’m not sure)
I bought this app and for my location it tells me the geoid variation is 144ft.
I don’t know which direction this is to be applied, however.
Unfortunately, like most apps, it uses only the phone’s internal GPS, so it is good only for telling me things like the geoid variation, the mag variation, declination, etc.
The funny thing is that when I start up Oziexplorer, it shows 144ft. This is with it showing the current location (from when it was last used) and with geoid correction set to OFF.
If I set geoid correction ON, it reads -10ft.
The funny thing is that the phone GPS itself (Samsung S7) with geoid correction ON in Ozi, I see 200ft as the altitude. So the GNS2000 is no improvement… EGNOS or no EGNOS.
I am going to give up on the GNS2000. This is about the 3rd time I have messed about with it. The reception is very unreliable and today it is not working at all.
FWIW this is what I see for the satellite data from the phone’s GPS
The stuff in red shows EGNOS/WAAS satellites but I am fairly sure the S7 GPS does not receive any of that. Yet, Oziexplorer clearly gets supplied with those satellite numbers.
Note that that picture of the world is just a fake; I am obviously not in Florida. I think it just represents the sky around where you are.
@Peter, satellites 65 and 66 (and anything else from 65 to 88) are not EGNOS/WAAS, these are regular (low-orbit) GLONASS satellites. From my own observations, having GLONASS capability does somewhat improve accuracy compared to GPS only, albeit not as much as EGNOS does. On the other hand, you can easily get GLONASS when on the ground, while EGNOS is often obscured by terrestrial objects because of satellite’s low elevation.
The S7 GPS spec says: GPS, A-GPS, Glonass, BeiDou. So you are right about Glonass.
You also explain why the GNS2000 (etc) almost never seems to show EGNOS.
Sorry for the incredibly late reply to this thread…
I had it in the back of my mind and didn’t find it until just now.
The reason that GLONASS satellites don’t really help the accuracy of a fix is that it has its own set of errors, which are different to GPS, and therefore the constellation only adds to the availability of the overall solution, not really the accuracy (except in situations where the observed GPS satellite geometry is poor, and a Glonass bird helps that geometry issue).
The fundamental difference between the satellite systems (GPS, GLO, GALILEO, BEIDOU, etc) and the augmentation systems (WAAS, EGNOS, etc.) is that the augmentation system is transmitting atmospheric corrections which are applied to the signal received from the satellites to minimize/correct signal attenuation errors induced by e.g. the Ionosphere.
So, in other words, the satellites are generating code-based pseudo-ranges, which is used by your receiver to calculate a position (multiple pseudo-ranges provides triangulation), but these pseudo-ranges are “stretched” or “compressed” by the atmosphere as they pass through to it to your position. The result is that your position looks like it is being pushed/pulled around, as these “strings” to space are stretched and pulled…
The augmentation systems record this “stretching” (attenuation) of the “strings” (signal) and as their position is fixed well known, they can easily determine the quantity of “stretch” from each satellite. From this information, a model of the atmosphere is calculated and this is transmitted to an augmentation satellite, which is then transmitted to your receiver from space. Thus, the signal from the augmentation satellites is only a model of the atmosphere, used to correct the distortion observed.
This correction reduces the errors induced by the atmosphere by a significant margin (often to less than 1m for most receivers).
Finally, you can think of GNSS systems in 3 classes:
1) Autonomous (no corrections) = +/- 3m typical
2) Augmented or DGPS (atmospheric corrections) = +/- 0.5m typical
3) Kinematic (RTK or PPK) (phase corrections) = +/- 0.03m typical
In case anyone is still following (and curious), RTK is Real-time Kinematic, and PPK is Post-Processed Kinematic and they both refer to the same process. Namely, using the phase of the radio signal, which has a length of roughly 20cm to determine the position down to cm (and in some cases, mm). This method is used in Geodesy (Land Surveying) and requires a reference antenna very close (within 40km) of the GNSS receiver used for measurements. This method is very similar to the Augmentation method, except that it directly transmits the phase offsets observed by the reference antenna, so that the roving system (what you are using) can directly apply them to the exact same satellites being observed. The baselines to the satellites are so similar that this method works quite well.
