Home PageFacebookRSS News Feed
PocketGPS
Web
SatNav,GPS,Navigation
Pocket GPS World - SatNavs | GPS | Speed Cameras: Forums

Pocket GPS World :: View topic - Height problem with TomTom GPS
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in for private messagesLog in for private messages   Log inLog in 

Height problem with TomTom GPS
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Pocket GPS World Forum Index -> Advanced GPS Lounge
View previous topic :: View next topic  
Author Message
lbendlin
Pocket GPS Staff
Pocket GPS Staff


Joined: 02/11/2002 22:41:59
Posts: 11878
Location: Massachusetts, USA

PostPosted: Thu Jan 22, 2004 2:26 pm    Post subject: Reply with quote

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

Report Map Errors here:
TomTom/TeleAtlas NAVTEQ
Back to top
View user's profile Send private message Send e-mail
lbendlin
Pocket GPS Staff
Pocket GPS Staff


Joined: 02/11/2002 22:41:59
Posts: 11878
Location: Massachusetts, USA

PostPosted: Thu Jan 22, 2004 3:24 pm    Post subject: Reply with quote

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

Report Map Errors here:
TomTom/TeleAtlas NAVTEQ
Back to top
View user's profile Send private message Send e-mail
Dave
Frequent Visitor


Joined: Sep 10, 2003
Posts: 6460
Location: UK

PostPosted: Thu Jan 22, 2004 7:45 pm    Post subject: Reply with quote

You mean this ?



It's the Leadtek 9533 and we have some more pics at http://www.pocketgpsworld.com/insidetomtomgps.php
Back to top
View user's profile Send private message Visit poster's website
DavidW
Pocket GPS Moderator
Pocket GPS Moderator


Joined: 17/05/2003 02:26:21
Posts: 3747
Location: Bedfordshire, UK

PostPosted: Thu Jan 22, 2004 9:15 pm    Post subject: Reply with quote

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.



David
Back to top
View user's profile Send private message Send e-mail
DavidW
Pocket GPS Moderator
Pocket GPS Moderator


Joined: 17/05/2003 02:26:21
Posts: 3747
Location: Bedfordshire, UK

PostPosted: Fri Jan 23, 2004 4:02 pm    Post subject: Reply with quote

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.



David
Back to top
View user's profile Send private message Send e-mail
AlunS
Occasional Visitor


Joined: Dec 22, 2003
Posts: 43
Location: near Dublin, Republic of Ireland

PostPosted: Mon Jan 26, 2004 8:02 pm    Post subject: Reply with quote

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.

--
Alun
Back to top
View user's profile Send private message
DavidW
Pocket GPS Moderator
Pocket GPS Moderator


Joined: 17/05/2003 02:26:21
Posts: 3747
Location: Bedfordshire, UK

PostPosted: Tue Jan 27, 2004 2:55 am    Post subject: Reply with quote

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!



David
Back to top
View user's profile Send private message Send e-mail
AlunS
Occasional Visitor


Joined: Dec 22, 2003
Posts: 43
Location: near Dublin, Republic of Ireland

PostPosted: Tue Jan 27, 2004 10:00 am    Post subject: Reply with quote

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.

--
Alun
Back to top
View user's profile Send private message
AlunS
Occasional Visitor


Joined: Dec 22, 2003
Posts: 43
Location: near Dublin, Republic of Ireland

PostPosted: Wed Jan 28, 2004 1:39 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AlunS
Occasional Visitor


Joined: Dec 22, 2003
Posts: 43
Location: near Dublin, Republic of Ireland

PostPosted: Wed Jan 28, 2004 2:02 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
AlunS
Occasional Visitor


Joined: Dec 22, 2003
Posts: 43
Location: near Dublin, Republic of Ireland

PostPosted: Wed Jan 28, 2004 2:06 pm    Post subject: Reply with quote

Mark,

Don't bother ... I just found it on Leadtek's Taiwanese FTP site at ftp.leadtek.com.tw/gps/Tools/GMSetup1095.zip.

Thanks for the pointer!

--
Alun
Back to top
View user's profile Send private message
DavidW
Pocket GPS Moderator
Pocket GPS Moderator


Joined: 17/05/2003 02:26:21
Posts: 3747
Location: Bedfordshire, UK

PostPosted: Thu Jan 29, 2004 2:34 pm    Post subject: Reply with quote

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.



David
Back to top
View user's profile Send private message Send e-mail
Dave
Frequent Visitor


Joined: Sep 10, 2003
Posts: 6460
Location: UK

PostPosted: Sat Jan 31, 2004 8:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DavidW
Pocket GPS Moderator
Pocket GPS Moderator


Joined: 17/05/2003 02:26:21
Posts: 3747
Location: Bedfordshire, UK

PostPosted: Sun Feb 08, 2004 7:14 am    Post subject: Reply with quote

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. Crying or Very sad


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.



David
Back to top
View user's profile Send private message Send e-mail
epideme
Occasional Visitor


Joined: Mar 30, 2004
Posts: 2

PostPosted: Tue Mar 30, 2004 2:20 pm    Post subject: Reply with quote

Regarding the GGA field 9 and 11 issues with SIRF firmware 320.000.000 and above:

I have been in contact with Holux on this matter. My Holux GM-210 experience this problem as it is using firmware 231.

After some semi-stubborn and rigorously written bug descriptions of mine they requested some time I got this reply:

"...please allow us a short while to look into this a little more
deeply so that we can come back with a satisfactory solution..."

Let's hope they sort this out with Sirf.

Cheers.
//Tony
Back to top
View user's profile Send private message







Posted: Today    Post subject: Pocket GPS Advertising

Back to top
Display posts from previous:   
Post new topic   Reply to topic    Pocket GPS World Forum Index -> Advanced GPS Lounge All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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

Powered by phpBB 2.0.11 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Make a Donation



CamerAlert Database

Click here for the PocketGPSWorld.com Speed Camera Database

Download Speed Camera Database
20.114 (23 Nov 22)



WORLDWIDE SPEED CAMERA SPOTTERS WANTED!

Click here to submit camera positions to the PocketGPSWorld.com Speed Camera Database


12mth Subscriber memberships awarded every week for verified new camera reports!

Submit Speed Camera Locations Now


CamerAlert Apps



iOS QR Code






Android QR Code







Terms & Privacy


GPS Shopping