Altitude is frozen to zero

I am running iGo Primo 9.6.5.211211 on a Wayteq x960bt with WIN CE 6.0.

Even though everything else is functional, the altitude appearing on the screen is frozen to 0. If I also use the gjak 1.08 skin, the number of available satellites also shows up as zero.

Searching the internet I found out a workaround, which is to put iGo on sleep and then wake it up. Then the two things above work normally.

However I would like to find a more convenient solution. Like something in the sys.txt file? Is there anybody encountering the same problem? Any solution?

Thanks in advance.

mpourdas wrote:Is there anybody encountering the same problem?

Yes, there have been others reporting similar issues..check out these threads:
http://www.navitotal.com/showthread.php?9651-How-is-altitude-computed-displayed&highlight=altitude

http://www.navitotal.com/showthread.php?6627-Trying-to-get-altitude-to-be-displayed-and-get-directions-earlier&highlight=altitude

http://www.navitotal.com/showthread.php?6717-Altitute-only-shows-after-reboot-Primo-1.2&highlight=altitude

The common denominator seems to be WinCE6 as opposed to WinCE5.

Thanks for the quick answer. I had searched the forum, but for some reason I found only the one of the above three threads. Sorry for starting a new one...

So, if it is really between two versions of WinCE, it would be difficult to find the solution myself by experimenting.

Ciao.

mpourdas wrote:Sorry for starting a new one.

Not a problem. Others have done the same.:D

mpourdas wrote:it would be difficult to find the solution myself by experimenting

If it is indeed a WinCE version thing (which happens sometimes with other software too), that would probably be correct...nothing you could add to sys.txt or messing around with other files or settings may help...and may turn out to make other things worse.
Regarding the (custom) OS versions on particular devices, sometimes, unfortunately, you just have to live with the quirks.
OEMs have been known to deliver devices with the OS customized or cut back in order to only be concerned with running the software that came on it, and not concerned about running anything else.

WinCE6, another masterful piece of software out of Redmond... where is Open VMS...

siberian

An "Open Source" OS on a device really does not guarantee anything. You could get an Android device or a TomTom (both Open-Source Linux based) and eventually run into similar quirks and limitations. Android GPS Software A runs great on Gingerbread or Froyo, but crashes or does not run at all on Ice Cream Sandwich (the latest in common distribution). The TomTom OS is so pruned back and modified it only runs TomTom GPS software and nothing else, and sometimes only the TomTom version that came on it...no upgrading allowed.
Both WinCE 5 and WinCE6 are, in terms of Operating Systems, ancient. Both were intended for PDAs....and when is the last time you saw a PDA for sale? But Win-Based GPS software is not that demanding on an underlying OS, and does not require much of the OS to be 'up to date'. Did Microsoft change some DLLs and modules when it went from CE-5 to CE-6 years and years ago? Yes, they did. Mostly in an attempt to be able to address more memory. And at the time, a stand-alone GPS device was yet to be broadly available or affordable and does not NEED to address much memory. 32 GB of RAM? Yeah, I'd like to have that, but 128MB seems good enough. Since it's release, there has always been a debate whether 6 was truly a worthy successor to 5. 5 seems more compatible with some software. But it is still up to the manufacturer of the device to decide which OS to use based on their own needs at the time, and what to include or not within the OS. So you can blame Microsoft, or you can blame the developers of the GPS software for not being 'up to date' with a SIX YEAR OLD OS. Or you can blame the device manufacturer for not providing an EIGHT YEAR OLD OS on their device. It still does not change the fact that it is beyond your control and you still have to dance with the one that brung ya.

Given all this interplay between Microsoft, the GPS software and the device manufacturer, I guess I should happy that I do not have more serious problems.

It is just a little quirk, for which I know the "workaround" as said, but it requires manual intervention.

A funny thing to add to the story is that it was working normally for some period. I do not remember for how long, say 2-3 weeks. And a few days ago the problem appeared. But reading the first post in Siberian's thread, I see that he encountered the same situation.

At the end I could not refrain from experimenting. I found a solution to the problem by adding to sys.txt the following:

[gps]
set_messages=0

I have no clue why this resolves the issue, and if it will work for Siberian or somebody else.

Now, I have an irrelevant question, but I do not want to start a new thread, since it will be trivial for some people here. What is the purpose of nnghal.dll?

mpourdas wrote:What is the purpose of nnghal.dll?

Has to do with detecting/using an FM Transmitter, and in some cases TMC.
If you have neither, it does nothing but does no harm either. If you have one or both, leave it alone.

mpourdas wrote:At the end I could not refrain from experimenting. I found a solution to the problem by adding to sys.txt the following:

[gps]
set_messages=0

I have no clue why this resolves the issue, and if it will work for Siberian or somebody else.

Now, I have an irrelevant question, but I do not want to start a new thread, since it will be trivial for some people here. What is the purpose of nnghal.dll?

Why did you try that particular sys.txt line and no other? It does not make sense, gpsmessages and altitude.

nabi wrote:set_messages=0

According to NNG, that setting prevents iGo/Primo from altering the baud rate of the GPS receiver.

I don't get the connection either.

Yurbuh Tuggly wrote:
I don't get the connection either.

Unless it's coincidental or technical (poor connection somewhere), it worked before, then not, then again.

Just an idea.
How many satellites are needed for positioning/routing ? At least 3 I believe. No I am sure of this. There are 24 satellites in orbit and minimum 4 should always be visible

And for altitude? Also 3 or more? I think (don't know :( ) more than 3. But here the angle of the satellite above the horizon is important for altitude measuring. Too low or too high on the horizon and you can't get an accurate altitude. This is me just guessing. Not scientific explaining.

There could very well be your answer. Temporarily not enough satellites in sight. Or in a good position.

I think I explained my problem very precisely in my first post. It is not a problem related to the number of available satellites. Even if there are many, my altitude is frozen to 0 and everything else is fine. With gjak 1.08 skin, the number of available satellites also shows up as zero (even though this is not true) in the bar in the bottom. So the altitude and the APPEARED number of satellites are correlated for sure at least in my gps.

Assume that by standing in the same place I put it to sleep and then wake it up. Then both fields, that is the appeared number of satellites and altitude, start to show values. For example, if I am in my home city, 7-8 satellites and a reasonable altitude of around 250m show up. The rest of the GPS is working normally, before or after the sleep/wake procedure.

So, I tried to play with various settings in my GPS but with no success. So I started to search the internet for sys.txt files to see what are the "lines" that people use. Btw my sys.txt is rather minimal, almost like the one given by Yurbuh here a few days ago in his repair kit). Given all the above, I looked for lines containing the word satellite, but nothing was found, or gps; anything that would "trigger it". So I tried under [gps] things like source=..., port=... and the one with set_messages=0 worked. If I remove it, back to the problem. I say again I do not know why, I do not even know what this line is supposed to do. Neither the baud that was mentioned in a previous post.

I have done the "experiments" driving from home to work and also one day in a parking, nothing to argue on that aspect. So I have solved my problem, but I do not understand "why".

mpourdas wrote:but I do not understand "why".

Here is what I may understand (which may not be much) of the "set messages" situation.
Primo (and iGo), by default, may automatically adjust the communication rate of the GPS port based on calculated delays and other data received from satellites (the "messages")--comparing one satellite 'hookup' with another and so on--to try to establish a pattern of synchronization so that navigation can be more reliable.
Basically, with the set_messages=0 entry in sys.txt, this automatic adjustment is turned off, and the communication rate (baud) remains static as it is first detected by Primo/iGo or at the specific rate set in sys.txt (which is typically not necessary any more since Primo does a pretty good job of detecting just about everything by itself on most[color="#FF0000"]**[/color] devices).
[color="#FF0000"]**[/color] There are always exceptions to this.

It is POSSIBLE (and this is only a guess!) that your particular WayTeq is more 'sensitive' to any such adjustments to the com port, and it loses track of some things...something like "Altitude" may be a lower priority feature since it does not necessarily have any bearing on accurate navigation, so that is dropped in favor of location accuracy.
That it works for you is fantastic..and an excellent FIND by you, but it may or may not solve similar issues on other devices.
But at least it is now something people who have altitude issues can TRY since it really should do no harm UNLESS it also starts to affect navigation accuracy...it may, on some devices.