Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Joined: 02/11/2002 22:41:59 Posts: 11878 Location: Massachusetts, USA
Posted: Thu Jan 22, 2004 2:26 pm Post subject:
Some GPS receivers are known to wrongly add the height correction coming from the sats (instead of subtracting it). Your receiver may be one of them. Either ask for a firmware update or get another receiver... _________________ Lutz
Joined: 02/11/2002 22:41:59 Posts: 11878 Location: Massachusetts, USA
Posted: Thu Jan 22, 2004 3:24 pm Post subject:
Yes, it should be a Leadtek. I think if enough people ask for a firmware upgrade then eventually they will listen. Doesn't hurt, right? _________________ Lutz
Joined: 17/05/2003 02:26:21 Posts: 3747 Location: Bedfordshire, UK
Posted: Thu Jan 22, 2004 9:15 pm Post subject:
This phenomenon is seen seemingly in all devices using SiRF firmware 2.30 and later.
This thread contains a detailed commentary on the problem - it's written about the Haicom HI-303MMF, which is a SiRF based GPS, as is the TomTom wired GPS.
Joined: 17/05/2003 02:26:21 Posts: 3747 Location: Bedfordshire, UK
Posted: Fri Jan 23, 2004 4:02 pm Post subject:
If you've got 2.20 firmware, then the problem isn't with arguably incorrectly signed ellipsoid to geoid corrections as Lutz and I thought. As you've spotted 2.20 SiRF firmware simply doesn't support corrections at all!
I don't think your issue isn't one of firmware or bugs. It seems you're expecting an Ordnance Datum Height figure, when what you actually have is a WGS84 ellipsoid altitude. You need to do some mathematics to convert that to an OS height; unlike Garmins and similar, you can't (with some exceptions - particularly uBlox receivers) configure a SiRF based receiver to return anything other than WGS84 figures. There's various comments on these transformations in the thread I already mentioned.
Switching GPS won't help - the standard for GPSes is to return WGS84 figures and support for other datums is optional. The best way is to code the transformations from WGS84 into your program.
Joined: Dec 22, 2003 Posts: 43 Location: near Dublin, Republic of Ireland
Posted: Mon Jan 26, 2004 8:02 pm Post subject:
croz,
NMEA 0183 specifies that field 9 must contain the height above MSL, and field 11 the (signed) difference between MSL and the WGS-84 reference ellipsoid. To get the height above WGS84, you need to add the two.
Whilst many GPS devices primarily aimed at the car navigation market seemingly bend the rules somewhat, and put height above WGS84 in field 9, and leave field 11 blank, my Garmin etrex Venture, and other Garmin handhelds I have tested do it properly. Since these units are used in a different application area, altitude is arguably more important than in a typical car navigation scenario, and since the calculations require some processing power, and storage for the geiod model, I'm guessing they just can't be bothered.
Note that this is independent of whatever datum you have chosen in the setup, since the Garmin units use a simplified worldwide geiod model called EGM-96 to derive the corrections to WGS84 height and subtract this before putting that value in field 9. Since they're using a vastly oversimplified worldwide geoid model, and not a separate one for each datum, the altitude corrections aren't going to be that accurate, but then the altitude information from GPS units isn't that accurate anyway. In any case, you can't (I think?) set a datum in any of the CF GPs's I've seen.
I have a Haicom 303-MMF, and that does something very perverse, namely it puts the height above WGS84 in field 9 *and* puts a correction value in field 11 too, which is even worse than leaving it blank in my opinion.
You're not alone BTW, the makers of GPSDash have a similar "fudge factor" feature in their software.
Joined: 17/05/2003 02:26:21 Posts: 3747 Location: Bedfordshire, UK
Posted: Tue Jan 27, 2004 2:55 am Post subject:
This looks like a perfect opportunity to bring this older thread up to date.
AlunS wrote:
NMEA 0183 specifies that field 9 must contain the height above MSL, and field 11 the (signed) difference between MSL and the WGS-84 reference ellipsoid. To get the height above WGS84, you need to add the two.
Whilst I too believe that to be true, have we established that this is what NMEA 0183 really says - or are we still going off the sum total of what is on the Internet because the official NMEA document is so expensive?
AlunS wrote:
Whilst many GPS devices primarily aimed at the car navigation market seemingly bend the rules somewhat, and put height above WGS84 in field 9, and leave field 11 blank, my Garmin etrex Venture, and other Garmin handhelds I have tested do it properly. Since these units are used in a different application area, altitude is arguably more important than in a typical car navigation scenario, and since the calculations require some processing power, and storage for the geiod model, I'm guessing they just can't be bothered.
I don't believe that a blank field 11 is "bending the rules" - my understanding is that it is likely permitted by the NMEA 0183 standard and it simply means that the device doesn't carry out any WGS84 ellipsoid to geoid corrections.
I'm curious as to the "GPS devices primarily aimed at the car navigation market" comment. In that category appears to be anything running SiRF firmware prior to 2.30 - but SiRF chipsets turn up in numerous applications, included many embedded devices and at least one handheld GPS. A bit of Googling indicates that some (probably older) Magellan GPSes don't output anything in field 11 either. The consensus seems to be in those cases that the figure in field 9 is a WGS84 ellipsoid altitude. Again, without sight of the definitive NMEA 0183 documentation, we cannot be sure.
AlunS wrote:
Note that this is independent of whatever datum you have chosen in the setup, since the Garmin units use a simplified worldwide geiod model called EGM-96 to derive the corrections to WGS84 height and subtract this before putting that value in field 9. Since they're using a vastly oversimplified worldwide geoid model, and not a separate one for each datum, the altitude corrections aren't going to be that accurate, but then the altitude information from GPS units isn't that accurate anyway. In any case, you can't (I think?) set a datum in any of the CF GPs's I've seen.
I can only take your Garmin comments on face value. However, it is possible for GPS altitude to be pretty accurate, particularly if SBAS is in use. The ESA specification for EGNOS, once operational, is 2m horizontal position error and 5m vertical position error - both with 95% confidence.
One thing is clear - there are differences in how different devices fill in field 9 and field 11 of the GGA sentence, and not all can be right. Without sight of the official NMEA 0183 documentation, it's hard to know which are right and which aren't.
It seems that there's three alternatives.
Field 9 contains a figure, field 10 is M, field 11 is blank - in that case, field 9 is almost certainly an altitude in metres from the WGS84 ellipsoid.
Field 9 contains a figure, fields 10 and 12 are M, field 11 contains a figure. In this case, it seems that this should mean that field 9 is an altitude above mean sea level on some or other datum (in metres) and field 11 should be the height of the mean sea level above the WGS84 ellipsoid.
However, SiRF firmware from 2.30 onwards (at least to version 231.000.000ES, which is in the HI-303MMF GPSes that Alun and I have) appears to put altitude in metres from the WGS84 ellipsoid in field 9, and the height of mean sea level (the geoid) above the WGS84 ellipsoid in field 11.
One of these latter two interpretations seems wrong - but sources on the Internet note that both are observed, and differ on the significance of a blank field 11 (at least one source says that it means the entire altitude reading should be regarded as suspect and not used in this case).
There's also the problem of exactly what datum has been used for the geoid - that is, precisely which mean sea level has been used. This question of which datum also afflicts other navigation data, such as longitude and latitude. At least one web site argues that Garmin GPSes are broken as NMEA data should always be WGS84 irrespective of the datum configured on the GPS!
Another problem is one Alun identifies - how good is the quality of the correction applied to turn the WGS84 altitude into one relative to mean sea level.
The only definitive source of information on these details is the NMEA 0183 specification. I would love to be able to tell you which is right and which is wrong, but I haven't access to a copy, and I'm not paying over a hundred US dollars for a copy.
One possible conclusion from this situation is that for any application where altitude figures are important, maybe the best altitude figure to derive is a WGS84 one - then do any geoid correction in your own code.
It would be interesting to question SiRF as to why some of their recent firmware seems to use field 9 differently to everyone else, but the chances of a response to an enquiry from the public is slim.
Datums can be set on at least some CompactFlash GPSes. Anything using an Evermore chipset (such as a HI-303E) has configurable datums. Anything that runs uBlox's variant of SiRF firmware has configurable datums. I'm not sure anyone produces a CompactFlash GPS using a uBlox module, but it's possible.
Indeed, I believe there may be configurable datums in SiRF firmware from version 2.30 onwards, but documentation on the Navigation Library is scarce. It may be that it's possible to get post-2.30 SiRF firmware GPSes to behave like other brands in the way they treat field 9 using some Navigation Library initialisation functions; I just don't know.
AlunS wrote:
I have a Haicom 303-MMF, and that does something very perverse, namely it puts the height above WGS84 in field 9 *and* puts a correction value in field 11 too, which is even worse than leaving it blank in my opinion.
Whatever the rights and wrongs, the mere fact that different GPSes behave in clearly different ways is unhelpful!
AlunS wrote:
You're not alone BTW, the makers of GPSDash have a similar "fudge factor" feature in their software.
Is that to allow a static offset to field 9? If used, what happens to the treatment of field 11?
I'm simply trying to draw out the issues more clearly; without access to an official NMEA 0183 specification it is near impossible to say with certainty which manufacturers are correct and which are not even though we may have strong suspicions!
Joined: Dec 22, 2003 Posts: 43 Location: near Dublin, Republic of Ireland
Posted: Tue Jan 27, 2004 10:00 am Post subject:
David,
You are, of course, right. Without the official NMEA0183 specs, it's impossible to say exactly what is intended in the relevant fields of the GPGGA sentence. The majority of web sources, including various GPSR manufacturers' websites, seem to favour the interpretation that says that field 9 should be height above MSL and field 11 the signed difference between the WGS84 ellipsoid and the geiod. Regardless of how accurate the geoid model in the GPSR is, you can then always just add the two values together and use offline processing s/w to generate more accurate height measurements using a locally optimised geoid model.
Maybe an email to the NMEA could clarify this without shelling out $250 for the full spec? It's worth a try.
The GPSDash people have a switch that allows you to enter an optional static offset (+ or -) to the contents of field 9. If it finds anything in field 11 it uses it automatically, otherwise it uses the fudge factor. Clearly in the case of my (our) Haicom receivers this wll screw up big time.
Joined: Dec 22, 2003 Posts: 43 Location: near Dublin, Republic of Ireland
Posted: Wed Jan 28, 2004 1:39 pm Post subject:
croz,
which program od you use exactly for this, and where did you get it from? Was this soemthing taht ran on the PocketPC or an a Windows PC?
I've tried nearly every variation of {Win({Fast|CE) | GPS Monitor } program I can find, both on this site, GpsPassion and the Leadtek site, bu can't find one that matches your description, or at least one that has the menu items you describe.
Joined: Dec 22, 2003 Posts: 43 Location: near Dublin, Republic of Ireland
Posted: Wed Jan 28, 2004 2:02 pm Post subject:
Hi,
The only Leadtek GPS Monitor I could find was an old version 1.0.2.1. I installed it and it looks remarkably like a customised version of SirfDemo. The latest version of SirfDemo I have is 3.40, and I can't find an Action | Get/Set Default Setting menu item anywhere in either.
Where did you get it BTW? Did it come with the GPS? Any chance of posting it somewher, or mailing it to me?
Joined: 17/05/2003 02:26:21 Posts: 3747 Location: Bedfordshire, UK
Posted: Thu Jan 29, 2004 2:34 pm Post subject:
I've installed that program quickly on a laptop to take a look.
The Haicom was in a PC Card slot in an adapter, and set to 38400bps SiRF - there's no serial input to the GPS in mouse mode.
The program looks like a somewhat modified version of SiRFdemo. Unfortunately attempting to retrieve the current configuration from my HI-303MMF appears not to work (neither do other possibly Leadtek specific functions, such as polling for serial number and test date).
With that in mind, there's no way I want to risk changing the datum setting on my GPS - if the functions rely on Leadtek's own variant of the SiRF firmware, I might land up irretrievably trashing my GPS.
I'm very interested in your results, though, Mark - particularly if you can give examples of the GGA sentence on datums 0, 150 and 214.
It would also be interesting to post the firmware version of your GPS - and the altitude readings in SiRF mode with each datum option.
There's no way of switching the LED off, so you probably have changed some settings and reconfigured the GPS to not receive signals, by changing the baud rate to an invalid one, or the protocol to SiRF. Switch it back to NMEA 4800 if you can still connect.
Joined: 17/05/2003 02:26:21 Posts: 3747 Location: Bedfordshire, UK
Posted: Sun Feb 08, 2004 7:14 am Post subject:
The results are certainly interesting, Mark.
One important distinction to draw between your results and those of Alun and myself is that your GPS is running pre-2.30 SiRF firmware and our HI-303MMFs are running post-2.30 SiRF firmware, which has the Navigation Library and seemingly some built-in geoid correction functions.
What fascinates me about your results is that you've got a Garmin style response from the unit - that is, you can switch datums at will, and all the NMEA data (latitude, longitude and altitude) is then on that datum. I wasn't aware that switchable datums were a feature of standard SiRF firmware. uBlox have added some multi datum facilities to the firmware builds used on their products, and have documented them. I'm unsure at this point whether the datum features in your Leadtek GPS mouse have been added by Leadtek, or are in standard SiRF firmware and not normally publicly exposed.
SiRF don't provide technical information directly to the public; so far as I can tell, you have to enter into various agreements with them to get decent technical level dialogue with them (apparently if you have a company sufficiently well recognised with SiRF, you can get new firmware builds directly from them, for example, as well as tools to customise the firmware to your needs). One consequence of this is that there's still not that much information about post-2.30 SiRF firmware available to the public. For example, SiRFdemo 3.40 can control which SBAS satellites are used on 231.000.000ES firmware in the HI-303MMF (this may be a 2.31 and upwards only feature) - but details of what SiRF messages are used to do this, and whether it's possible to make these settings persist after the GPS is powered down, are not available anywhere to my knowledge.
It would, of course, be nice to have some hard information on:
1. Precisely what the NMEA 0183 specification says should be in fields 9 and 11 of the GGA sentence.
2. Why SiRF 2.30 and upwards firmware seems to handle fields 9 and 11 in the GGA sentence different to other manufacturer's products.
3. Precisely what support for changeable datums is in standard SiRF firmware, and what is custom Leadtek.
4. Precisely what the SiRF Navigation library in 2.30 and upwards firmware is capable of.
5. Precisely what configurability of GPS defaults is standard in SiRF firmware, and what is custom Leadtek.
I doubt, sadly, that we'll get any hard answers.
One conclusion from all this is that it's maybe best to drive SiRF GPSes in SiRF mode if you need reliable altitude figures. Irrespective of firmware version and, on the Leadtek Mark is experimenting with, the configured datum, that always seems to give a WGS84 altitude.
Posted: Today Post subject: Pocket GPS Advertising
We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!