Haicom 303MMF altitude problems

[AlunS]

Using my brand new 303MMF the other day with OziCE I noted that the altitude displayed was incorrect. I was on the beach, and therefore would have expected an altitude somewhere near 0, but it was displaying 60m. I expect an error of a few metres, which I'm used to with my other GPS, a Garmin etrex Venture, but this was excessive.

Returning home, where the altitude is approx 50m above MSL, I examined the NMEA output ($GPGGA) and found something odd. Field 9, the altitude above MSL was giving me 102m, and field 11 which is supposed to contain the difference between MSL and the WGS84 reference ellipsoid contained 54.7m. Now, if I subtract that from 102, I get 47.3 which is much closer to reality, and if I do the same for the reading on the beach, I get 5.3, again a bit closer to what I expected.

Therefore it seems to me as if the 303MMF is putting the height above the WGS84 ellipsoid into the field that is supposed to contain the height above MSL instead. It can't complain that it doesn't know how to calculate height above MSL, since it clearly has a (fairly rough) geiod model to be able to calculate a value for field 11, so no excuses.

Is there any way I can get some kind of message either to Haicom or SiRF concerning this? I've searched the websites of both companies to no avail.

[DavidW]

It indeed looks as if it is doing as you say (I've got a Haicom HI-303MMF with firmware 231.000.000ES here).

Unfortunately direct communication with Haicom is reportedly difficult at the best of times, and SiRF basically won't talk to end users.


SiRFdemo 3.40 hints that my HI-303MMF may not have the navigation library stuff set up entirely correctly (for example, geodetic navigation status is always shown as NoGps, and the time doesn't display in the geodetic navigation window). It could be that some misconfiguration with the Navigation Library stuff could explain the problem - though this could be SiRFdemo 3.40 being buggy. Even so, SiRFdemo 3.40 shows the height above MSL and the height above ellipsoid correctly - of course, this using the GPS in SiRF binary mode, with raw track data enabled as is required for Navigation Library operation.

It's only in recent SiRF firmware versions that geoid correction is carried out - I believe it requires post 2.30 firmware with the Navigation Library functions. One big unknown is what geoid the corrections are being given against - and it could be that that is the problem. Whilst it's arguably non-standard to give WGS84 altitudes in field 9 and a correction in field 11, at least field 9 appears to be a WGS84 altitude, rather than an altitude on an unknown geoid. Note the comments at http://www.gpsinformation.org/dale/nmea.htm#GGA on this apparently non-standard behaviour. It could be that SiRF are actually doing the right thing according to the official NMEA 0183 documentation - though I have my doubts.


As you say, if you subtract field 11 from field 9 in the GGA sentence, you get a pretty good approximation to an Ordnance Survey height (within a metre or so according to a conversion using the WGS84 altitude and other information on the co-ordinate convertor at http://www.gps.gov.uk). However, it's not exactly the same as you get by subtracting field 11 from field 9. Moreover, using the figure given by using field 9 as a WGS84 altitude in the co-ordinate convertor, the resulting altitude matches up with the Ordnance Survey map for my home location.

I fear this is a case where you just have to live with the behaviour of the GPS unless you have access to the official NMEA 0183 documentation (which is not free) to get the definitive view on the contents of the GGA sentence and are prepared to write to SiRF, quoting that documentation in a bug report. Even so, the chances are that you won't get a firmware upgrade for your GPS - most SiRF vendors do not allow user firmware upgrades.


Meanwhile, maybe the best way out of this is to suggest to the author of OziExplorer that an option is introduced to interpret field 9 of the GGA sentence as WGS84 altitude even if a correction is present in field 11.

Oddly I've never seen any discussion on the altitude figures in the GGA sentence of post 2.30 SiRF firmware.



David

[AlunS]

Dave,

Thanks for taking the time to reply. I have, in the meantime, found some references on the net to some SiRF designs putting only the height above WGS84 in field 9, and leaving field 11 blank, which would make slightly more sense than what the 303MMF is doing. No mention of firmware versions though, although it wouldn't exactly surprise me if, if what you say is correct about them only putting geoid correction into the latest version, they just simply forgot to change what they were previously putting in field 9! Incidentally, I have the same firmware as you.

In any case, they're obviously using a different geoid / geoid model than Garmin, since it's putting 54.0m instead of 54.7m into field 11 at (to all intents and purposes) exactly the same location. Nowhere can I find either what geoid Garmin are using, although there are hints that it might be EGM-96.

My wife works for a company here in Ireland that has done some system design work using Trimble modules, so maybe she can find a copy of the "official" NMEA specs for me. Who publishes them, do you know?

I might also try your suggestion and write to the developer of OziCE. I know they've had a manual version of this in GPSDash for a while, where you can input a static geoid separation, and the latest version appears to be able to cope in addition with the aberrant behaviour of devices such as the 303MMF.

Alun

[DavidW]

Field 11 blank is, I believe, pre-2.30 SiRF behaviour.

NMEA publishes the NMEA 0183 specification! Details are at http://www.nmea.org/pub/0183/index.html.

If this is a SiRF firmware 'issue' (or bug - choose whichever seems appropriate), it's going to affect a lot of GPS hardware used with Pocket PCs, as a fair proportion is SiRF based.



David

[AlunS]

David,

I'd forgotten about the NMEA being the originator of the NMEA spec.! Silly me Anyway, at $250 I think I'll give it a miss, if you don't mind.

My wife says they don't have the document either, since in their product all the generation of NMEA sentences is done in the Trimble libraries they use.

This raises the issue of exactly where this is done in the SiRF solution. In the case of the Trimble module my wife's company uses, they apparently are quite dumb, merely squirting out raw pseudorange data every second over a serial interface using a Trimble proprietary protocol. Her company's product then basically provide all the processing power on an ARM chip using the pre-compiled libraries Trimble supply. All they do is then pass the raw data on to the Trimble code which gives them a WGS84 fix, do any coordinate transformations necessary, and generate the appropriate NMEA sentences.

So, depending on the level at which the SiRF chipset works, it could be a SiRF problem or a Haicom problem. In my wife's case, the product they have developed is marketed as a complete solution by yet another company, who then sell it on to companies who produce various GPS based solutions. The word Trimble isn't even used in their product literature! So, the actual GPS part of the SiRF solution may not even be made by SiRF themselves, and all they are doing is just what my wife's company are doing, i.e. integrating the GPS module and processor/flash ROM/processor and providing the firmware.

To complicate matters even further, some vendors such as Sony are already bringing out hybrid analog/digital single chip solutions blurring the distinction even further.

I'll have a good look at the SiRF website and see if I can get any more info.

[DavidW]

I quite understand you passing on the NMEA documentation - at US$250 it is a bit steep.


I'm pretty sure that you'll find that Haicom are using pretty much vanilla SiRF firmware. The SiRFstar IIe/LP chipset in your Haicom HI-303MMF contains an ARM core, and that's where the processing is done. The interface to the outside world is via a UART, to which is simply added serial glue logic (level shifting hardware such as a MAX3232, and, for CompactFlash mode, a CompactFlash UART, which is actually an Oxford Semiconductors part on the HI-303 series) - and, of course, on the other end, a GPS patch antenna and external antenna socket. In other words, the NMEA data stream comes straight out of the SiRF chipset - the external circuitry is just to interface that to the outside world.

SiRF do make it possible for their customers to customise the firmware, and some customers do - u-Blox in particular add quite a few features to their firmware.

My impression is that Haicom simply load the firmware that SiRF produce with at most minimal customisation. The HI-303MMF responds fully to the SiRFdemo tool that is used with SiRF evaluation boards.


I'd think something as basic as generation of the NMEA GGA sentence is likely to be code supplied directly from SiRF; I'm not sure whether vendors even get a chance to customise this code, or whether it's supplied in object code form only.

The only likely customisations to NMEA mode operation are adding support for up to three "user" sentences that are well documented as options for SiRF firmware devices (the mode switch command has the ability to configure how often these sentences are generated). Vanilla SiRF firmware simply doesn't have any "user" sentences. u-Blox have added support for a time and date sentence, for example.



Quite apart from asking more generally on these forums (as many common GPSes are SiRF based, and many vendors are now shipping 2.30 or later firmware), you could try the forums at http://www.gpspassion.com, which sometimes seem to get a bit more technical than here on Pocket GPS World. I much prefer the forums here, though!



David

[AlunS]

You seem pretty knowledgeable on these matters, David. Do you work with GPS systems at all? I'm just a user really, but with a background in computing and electronics which makes me interested in how these things work internally.

In case your interested, the company my wife works for (Silicon and Software Systems or S3, based in Dublin) did all the development work for the following product. http://www.xemics.com/internet/products/series.jsp?productID=13

Alun

[DavidW]

I'm really an amateur in these matters - though there's plenty of information on the Internet if you get reading! Where SiRF is concerned, it's largely a case of Googling for what you can pick up on the net; the most up-to-date stuff is on the U-blox site (you have to register, but that's free of charge), and they do have the decency to identify what is custom in their firmware. Make sure you're reading the PDFs relating to a SiRF chipset product, though!

More generally there's some excellent information around on how GPS and SBAS works.


My background is in R&D for a computer network firm (primarily software engineering); it was there that I picked up much of my ARM experience as I was programming some of the time in ARM assembler. My RF training comes from amateur radio - though through that I've had some exposure through a local amateur radio club to a fellow radio amateur who uses Leica survey-grade GPS gear and gave some excellent technical talks.



David

[DavidW]

This issue has been taken further in this thread.



David

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!