yashsingh1/xdaforums huggingface dataset:
[Windows Mobile Apps and Games] Batistuta88:
GPS Mod Driver together with Toms GCz

Hi

After I read your first post I thougt this was it :) "I have found that I now have a GeoCaching enabled phone"

I posted a comment about your software in the thread about GCz and it was tested by Master Darko

You can read his test here.

Toms geocaching software thread

http://xdaforums.com/showthread.php?t=482249&page=216

I tested to and come to the same conclusion?:confused:

Why doesnt it work:confused:

Cheers

Batistuta
[Windows Mobile Apps and Games] Mach2003:
I had a quick look at the thread you listed, and it looks like the test was invalid, as he did not get data on the GpsModPort, but on the original port, so none of my modified data was seen by the application. In order to see the results, you need to read data from the GpsModPort (COM1).

I use CacheMate's CacheNav and the Driver certanly gets rid of the 30 meter problem. It also works fine with WhereIGo player.
[Windows Mobile Apps and Games] xyphan:
I'm testing this out on the Imagio, and it seems to work (even without the Que fix for Garmin). The only problem is that the GPS takes an incredibly long time to update the position. It's confirmed to be using com3. Also, when I make a turn, it doesn't register for a very long time.
[Windows Mobile Apps and Games] Batistuta88:
Ok, will you test it with GCz its a awesome geocahing software and ones you tried it you newer use something else. And toghether with your software it should be outstanding tool in the geocach world :):)

Cheers

Batistuta
[Windows Mobile Apps and Games] Mach2003:
Nope :( I'm quite happy with what I have now (GSAK,CacheMate). I don't need to get live data from the cell network to cache. I can always use the geocachiong wap site to get updated data when I need it.

You should get the author of GCz to test my driver further, and see why his software did not open MY comm port. Read the port (linked from the first page) to the solution for MobileXT, you may have to use QueStub for GCz as well, if he is reading the GPSID reg to get the comm port.
[Windows Mobile Apps and Games] LongZheng:
So does this work on (and have any effect) on non-HTC devices? Samsung i780?
[Windows Mobile Apps and Games] hidriver:
Is it works on kaiser?
[Windows Mobile Apps and Games] Mach2003:
It should work on any device that has a gps, and uses GPSID. Try it and see.
[Windows Mobile Apps and Games] Mach2003:
Driver RC1

First Post updated, read the whole post....

Reg have changed, the posted UI will needs to be updated to edit the new keys, sorry, but the serial5 path was protected, so this way will be better in the long run...

Second post, edited to contain the 0.9 driver and information.
[Windows Mobile Apps and Games] axl30:
rc1 is not good

I warmly dissuade you to tryit....:(

the rc1 from a series of many problems...

1 filter so much the signal gps that puts also us some minutes before seeing him/it

2 the creator you/he/she has added the time of the buffer and and' the most wrong thing considering that the first tweak for accellerare the gps and' to reduce the buffer planned by wm

3 why to annul the effect "I swing" that you/he/she could be introduced there sometimes now and' the risk that if the tomtom sees you turned in the wrong direction of march...he risks to make the whole road in reverse, which can be amusing but I doesn't practise

4 the time of refresh of the tomtom and become unbearable they also pass 3-4 seconds before the position is adjourned on the screen...

I mind saying him but after the version 0.7 bushels losing away the straight line....

p.s. I don't want to do criticisms but I try to bring you a little of the experience done for aiutorti to best the everything

excuse me for my English:p
[Windows Mobile Apps and Games] omek07:
Mach2003 Thanks for everything

Could you please tell as the right steps that we can Unistall the Previous version ???? I have the 0.9 and i want to install the RC1 .....

Thanks again
[Windows Mobile Apps and Games] Mach2003:
Give me an hour or so, I might have found a bug in RC1 when calculating average course (this is used in LagAdvance even if EnableCourse=0 or 1).

Use system/uninstall, if that works fine, just soft reset, then install the new cab. If uninstall does not work, then use SKTools to uninstall 0.9. SR, install new cab. Edit reg as required. Uninstall UI if you have it installed, it needs to be updated first.

If you are using QueStub, download and install the new version before you run Garmin.
[Windows Mobile Apps and Games] omek07:
what is the UI ?????
[Windows Mobile Apps and Games] axl30:
.....i use tomtom and igo with version 0.7 and already se sktool to uninstall it.........

...ok wait the new release....
[Windows Mobile Apps and Games] Mach2003:
If you read the thread, at all, but since you did not read it, and you might install a newer version of the driver, then don't install that UI now.
[Windows Mobile Apps and Games] axl30:
the rc1 have blocked my HD

after HR i have installed already th rc1 but the gps don't is exact the position is very wrong (100-200 meter out):mad:
[Windows Mobile Apps and Games] furikaburi:
In my topaz I had a similar experience to axl30
[Windows Mobile Apps and Games] Mach2003:
RC2, fixed averaging, and better LagAdvance (I hope) on first post.

The RC versions should not take longer to update the application, but without using TT, I'll have to get more reports from you out there.

The buffer increase from 512 bytes to 1024. is a slight waste of ram, but this way the buffer will sure be big enough, and I don't have to dynamically allocate it from the Kernal stack, better, faster, safer!

If your indicated position was 'way out', then your GPS position was "way out" in the first place. My driver will not modify your position that far unless you are traveling at, um, 1000kph! Try RC2, to see if the averaging corrections fix this issue. (re)set the DeltaSpeed and DeltaDistance to a number >= 50 each.
[Windows Mobile Apps and Games] omek07:
Ok look

:)
[Windows Mobile Apps and Games] RoryB:
For now I'll leave them be unless you would like me to remove them to help test another version's install. I hope not to hard reset anytime soon and I do not know what certs are already in the NRG ROM I have. I would hate to remove a cert it is using.
[Windows Mobile Apps and Games] Mach2003:
3.29

- Correct error deleting missing key "UnInstall"

- Add trap to COM read when partial string is read, but the rest of the string takes a long time to arrive

This might fix omek07's install issue.
[Windows Mobile Apps and Games] omek07:
Thanks Mach2003

I install it and i havent any problem on installation(the only problem is that have to go and put the com manually but this is not a problem).

I noticed that when is on NO FIX it cant stable the satelites one time is on 10 sat and on 10 seconts is on 2 and then to 10 and then to 4 ..............

What i can do for this ?????
[Windows Mobile Apps and Games] Mach2003:
What port are you using for input (msapi)?

Generally the sats in view come from the GPS source. I do retain previous information in case the latest data has no sats info in it, but that is used for only a reading or two.

I suspect that you are actually getting various sats in view at the time. Where are you testing it (outside)?
[Windows Mobile Apps and Games] omek07:
I am using

Gps program Port com 4

Gps hardware port com 9

GpsModDriver Port com 2

I am testing it outside of course
[Windows Mobile Apps and Games] Mach2003:
In ModSettings, what does it say on the first line of text?

Menu, ports, What ports have a check mark, and for these ports what is the order value?

Are the erratic sats in view messages shown in ModSettings text? And on the graphic view too?

I ask these questions since my primary unit is also O2, and I have a backup O2 too, and neither have this issue.
[Windows Mobile Apps and Games] jakiej:
it seems that the time reported by gpsmod is off by about 30 mins on my device. is this just me?
[Windows Mobile Apps and Games] omek07:
oooo

First where is the modsettings s some txt or in the program ????

on the menu ports is check the scan on Power Only and the MsApi (Enable and Fix)
[Windows Mobile Apps and Games] Mach2003:
Where are you reading the "time reported by GpsMod" from? In the output data, ModDriver reads the current clock on the device, adds some milleseconds related to how long the device has run since last soft reset. In input data, the clock from the GPS system is compared to current device time, and adjusted to match.

ModSettings IS the configuration application. It has a text screen ,and a graphic screen (tap to toggle).

I see from your pics that you are using msapi as input port.

On msapi input, sats in view come directly from the original GPS data. There is no way to read a partial buffer using this port. I'd have to see a ModDriver.txt log while this is happening to you to see why you get eratic results.
[Windows Mobile Apps and Games] jakiej:
thanks for the detailed explanation and in short it's expected behavior.

i use this phone as a sole gps device (it has no SIM card) or a card reader when connected to pc (so no-sync). That's why usually I rely on gps to correct my device time :)

thanks again for this great mod driver. it does make my navigation much smoother.. btw, i tried both 3.20 and the lastest beta.
[Windows Mobile Apps and Games] RoryB:
I notice something similar.

If under ports I use the MsAPI Enabled and Fixed as 1 in order and COM4 Enabled and Fixed as 2 I see a flicker in my satellite. One time I was able to catch that it was changing from 3d to no fix.

I unchecked MsAPI Enabled and Fixed and the flicker goes away.

This also seems to have stopped the flicker in GMM.

I have only recently updated this and XDAFacebook and it seems one of these is causing a battery drain. I am posting this in both threads to see if anyone else has noticed battery drain to help me figure which.
[Windows Mobile Apps and Games] omek07:
hmmm

Where i can find the ModDriver.txt ,

And what i do you thing , what i have to check on the port ????
[Windows Mobile Apps and Games] Mach2003:
On some devices, including my Omnia, msapi sends an unfixed data set that has only updated sats view, then very soon after sends an updated fix position (that includes the same sats in view). I handle this anomally correctly (or you would see loss of fix). I have never seen a message from msapi that has the "sats in veiw valid" flag set, and no sats in view. This would be required to lose sats. Something else must be wrong here. If msapi reports a loss of fix, it could also "lose" sats in view for a bit. but ModDriver will fake a fix, regardless of your keep fix time, for at least 2.5 seconds.

To get the ModDriver.txt file: Use ModSettings, menu, system page. Enable loggging and also expanded. Save. Run until you see loss of sats, then exit ModSettings. You will find files in device \Mach2003 folder.

Point your mouse to the "donate" link in my sigy below, you will see my email address, send me the file.

If no application is using GPS, ModDriver will consume NO POWER. MachCell will run a bit of extra program code whenever you change towers or it's signal changes, or you change data connections... MachCell will also start a data connection (if allowed) when you see a new to you tower. In my experience, MachCell power consumption is very small, especially after running it in your area for a while (preferably with GPS active).

If any application is using GPS, watch your battery go bye-bye, regardless if ModDriver is in the loop or not. However ModDriver will consume a small amount of power reading your sensors, if those features are enabled, causing a slight increase in power used when GPS is on. Driver also runs additional code, and writes data to the registry on each pass, again very little power lost.

Be sure to use the "exit" button in ModSettings, and not the close button. Close is standard windows, and it keeps running the GPS in the background.
[Windows Mobile Apps and Games] RoryB:
I always use the exit menu item in any program that has one since I figured it was a controlled shut down versus it just being stopped by the system.

Must not be GPSMod then because I have not been running GPS apps other than a couple minutes to double check the fix flicker.

Thank you
[Windows Mobile Apps and Games] bartvdv:
apperently i unsubscribed to this topic ...

Anyhow I've been in bed most of the time ... perhaps is testing GPS settings fixes etc a more convenient hobby during summer ... have a severe cold now, in fact pneumonia ... probably from stepping into the freezing cold for a few minutes 2x every hour to get a quicker fix ...

I see 3.29 is out now going to download and install...
[Windows Mobile Apps and Games] Matze2:
First...a very good application, runs without problems...

only

...the altitude corrections is no longer working.

With version 3.20, my GPS applications displays the corrected altitude when "Altitude Fix" is checked.

Now, with version 3.29 (also with the versions 3.27 and 3.28) , displays my GPS applications always the same (incorrect) altitude, regardless of whether "Altitude Fix" is checked or not.

What could be the problem or is this really a bug?

my device: Omnia2

GPS applications: iGO8, AutoMapa, VisualGPSce
[Windows Mobile Apps and Games] Mach2003:
Tell me what you see for ASL and AEL on ModSettings main page (and if you think either of those is correct)
[Windows Mobile Apps and Games] Matze2:
Altitude fix checked ---> Asl: 170.0 Ael: 126.7

Altitude fix unchecked ---> Asl: 170.0 Ael: 126.7

It's the same, there is no difference.

The correct height for my current location is approximately 126m (says Google Earth, my external GPS mouse and my old PDA with internal GPS)
[Windows Mobile Apps and Games] Mach2003:
Ok so 126.7 is the number you are looking for.

Do you also have Prefer GPS selected beside Altitude? If so, then when your GPS unit contains seperation value, ModDriver will use that value, and Altitude fix will only take effect when the GPS data contains no seperation value.

Is the seperation from elippsoid to sea level of 43.3 meters correct for your region?

Most GPS programs will report the "ael" value as altitude, however some may report "asl".
[Windows Mobile Apps and Games] Matze2:
I have a little bit played with the GPS (i have changed my position, so different altitude values than before) and some logfiles created.

internal GPS (Omnia2) without ModDriver

NMEA-Log: $GPGGA,223310.0,xxxx.447459,N,xxxxx.363403,E,1,07,2.3,323.0,M,,,,*07

GPS app: 323.0m

external (Bluetooth) GPS without ModDriver

NMEA-Log: $GPGGA,224407.000,xxxx.4441,N,xxxxx.3647,E,1,7,1.23,280.1,M,45.8,M,,*5E

GPS app: 280.1m

internal GPS with ModDriver

"Altitude Fix" unchecked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,223402.513,xxxx.447449,N,xxxxx.363398,E,1,07,1.8,323.0,M,,,,*5A

ModDriver: Asl 323.0 Ael 0.0

GPS app: 323.0m

"Altitude Fix" checked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,223605.816,xxxx.445887,N,xxxxx.363353,E,1,07,1.7,323.0,M,43.6,M,,*53

ModDriver: Asl 323.0 Ael 279.4

GPS app: 323.0m

"Altitude Fix" checked, "Prefer GPS" checked

NMEA-Log: $GPGGA,223709.752,xxxx.446928,N,xxxxx.363499,E,1,07,1.6,323.0,M,43.6,M,,*54

ModDriver: Asl 323.0 Ael 279.4

GPS app: 323.0m

external GPS with ModDriver

NMEA-Log: $GPGGA,224017.373,xxxx.447900,N,xxxxx.364900,E,1,06,1.3,281.3,M,45.8,M,,*58

ModDriver: Asl 281.3 Ael 235.5

GPS app: 281.3m

"Altitude Fix" checked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,224219.357,xxxx.446600,N,xxxxx.362800,E,1,06,1.3,281.8,M,43.6,M,,*52

ModDriver: Asl 281.8 Ael 238.2

GPS app: 281.8m

"Altitude Fix" checked, "Prefer GPS" checked

NMEA-Log: $GPGGA,224353.549,xxxx.447600,N,xxxxx.362500,E,1,07,1.2,281.8,M,45.8,M,,*5B

ModDriver: Asl 281.8 Ael 236.0

GPS app: 281.8m

The correct altitude for my current location is approximately 279m (Google Earth and topographic map...is altitude above sea-level).

What is the result...

- The data from the internal GPS receiver does not meet the NMEA-standard (altitude over ellipsoid instead altitude over geoid, seperation from ellipsoid is not contain)

- All my GPS applications showing "ASL" .

- The "Altitude Fix" works, but not quite as expected. It is insert only the seperation in the NMEA-data, the incorrect altitude information (Ael) is not corrected to Asl. For the record, with version 3.20 it has worked.

Now I'm confused, should it really be so?:o
[Windows Mobile Apps and Games] Mach2003:
Thanks for all the work...

I must know if you had ModSettings, ports, set to use msapi or COMx as input during the internal GPS tests. And what happens to the numbers when the other one is used?

I had a note somewhere that Omnia COM had the wrong altitude inserted, but dismissed that note as an error, but now you prove that Omnia COM is: ael and 0. But there is almost no way to tell from the raw the data if it is Omnia, or standard NMEA, so I don't see an easy way to correct it. I always use msapi as input on Omnia, and it does not seem to have this problem. {to tell the truth, my Omnia no longer works with COM as input, I must have broke it in my last kitchen build}.

It looks like my seperation value is applied backwards. It should be 281.8 + 48.8 = 330.6, I must be using 281.8 - 48.8 = 236.0. I'll correct that in the next version.
[Windows Mobile Apps and Games] Matze2:
I have it tested with MSAPI and com as input. The result is the same.

I once researched a bit....

GPS receivers measure the Altitude relative to an Ellipsoid (Ael). They also contain a table of geoid heights (the difference between ellipsoid and geoid) and calculate the height relative to sea level (ASL) with this values. This calculated height (ASL) and the used geoid height is (according to the NMEA standard) included in the output NMEA data (GGA-String). Most consumer GPS applications then show this altitude (ASL). Professional GPS Applications (eg GIS) calculated with this two values, the original ellipsoidal height.

The GPS receiver in the Omnia works not correct or not contains a table of geoid heights. Therefore, the data contain no separation value and the given altitude is the ellipsoidal height. I think this is a principle (regardless of the GPS receiver)...if no separation value are included then is the specified height the ellipsoidal height.

I think the "Altitude Fix" should therefore work as follows :

original GGA-String:

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,07, 2.3,323.0,M,,,,*07

ModDriver output:

"Altitude Fix" unchecked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,0 7,1.8,323.0,M,,,,*5A

ModDriver: Asl 323.0 Ael 0.0

"Altitude Fix" checked, "Prefer GPS" checked or unchecked (does not matter)

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,0 7,1.8,279.4,M,43.6,M,,,*5A

ModDriver: Asl 279.4 Ael 323.0

or

original GGA-String:

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,7,1.2 3,279.0,M,45.8,M,,*5E

ModDriver output:

"Altitude Fix" unchecked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,0 6,1.3,279.0,M,45.8,M,,*58

ModDriver: Asl 279.0 Ael 324.8 or 0.0

"Altitude Fix" checked, "Prefer GPS" unchecked

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,0 6,1.3,282.3,M,43.6,M,,*58

ModDriver: Asl 281.2 Ael 324.8

"Altitude Fix" checked, "Prefer GPS" checked

NMEA-Log: $GPGGA,xxxxxx.xxx,xxxx.xxxxxx,N,xxxxx.xxxxxx,E,1,0 6,1.3,279.0,M,45.8,M,,*58

ModDriver: Asl 279.0 Ael 324.8

The setting "Prefer GPS" would not be really necessary.

What do you think?
[Windows Mobile Apps and Games] Mach2003:
I re-quoted this string because every other device I know, besides the Omnia, that uses the same format (asl present, blank seperation value), includes ASL not AEL. So there is virtually no way to tell if it is a Omnia bad string, or a normal string from any other device. I'll have to take another user's sugestion and put in a user setting for it.

Prefer GPS exists for those devices that have both numbers, but user wants to select GpsMod's table instead of the GPS's one (unchecked).
[Windows Mobile Apps and Games] Matze2:
Yes, that must be corrected.

For information: ASL + (+ / - separation) = AEL...or...AEL - (+ / - separation) = ASL

If the separation value is a positive value, then the geoid above the ellipsoid and the altitude with respect to the geoid (ASL) is less than the altitude with respect to the ellipsoid (AEL).

Really ... a GGA string without separation value I know (so far) only on the Omnia and Omnia2. This of course makes it difficult to find a reasonable adjustment...:(

By the way, I found an interesting note on this issue ...

"If the height of geoid is missing then the altitude should be suspect. Some non-standard implementations report altitude with respect to the ellipsoid rather than geoid altitude. Some units do not report negative altitudes at all."

I understand what this setting is for. I think, this setting is useful when several receivers are used on the same device (alternately).

But because it interests me, what exactly does this setting? Is only the separation value changed or is also re-calculated ASL (restore original [measured by gps-receiver] AEL with the separation value from original GGA-string and then recalculated ASL with separation value from GpsMod's table)?
[Windows Mobile Apps and Games] Mach2003:
Done in the next release (soon)

I have been testing this on my Diamond, and Omnia with msapi, and sure enough the Diamond includes a "0" as the seperation value, so I can detect that (vs the Omnia's "blank"). I have notes from when this was all added to ModDriver showing devices that had ASL and blank, but that makes no sense since GPS knows AEL, if they had the table, why would they insert ASL, and not the seperation value? Well Omnia's output also makes no sense...

Regardless I have coded the next release to detect the difference betwwen the Omnia and The Diamond, I'll wait until someone *****es here.

// this introduces a possible error

// if we have ASL, and a valid seperation value of 0.0 (asl == ael)

// We are going to incorectly assume value is ael (Omnia style), and inject our seperation value to calculate asl.

// but then out table value should be very close to zero, and the error will be very small

The altitude's "Prefer GPS" setting only applies when the GPS has both ASL and AEL (or ASL and a valid Seperation value on COM input), otherwise this setting is ignored.

When setting is disabled, and both values exist in the GPS stream, the seperation value is overwritten with the value found in My Table, changing the ASL value accordingly (at least with the latest (unreleased) build it works this way).

Unless I am even more confused, Garmin Mobile XT also has a bug here.

When I submit (via gpapi) AltitudeWRTSealevel as 414.7, and AltitudeWRTEllipsoid as 398.3 (using the table value at my house of -16.4), Garmin displays altitude as 431. When I submit GGA values 414.7, and -16.4 (via COM), Garmin correctly displays 398.3.

I could patch the gpsapi to detect Garmin, and correct the values to make it happy, but I'm not so sure what other applications do with the gpsid values I am sending (or if I am sending the wrong values).
[Windows Mobile Apps and Games] takeuchie:
hello der mate,

would u mind point me to which post on how to exactly use this on my omnia 2 with garmin xt or u can just tell me..

thanks..
[Windows Mobile Apps and Games] Mach2003:
1) Install the driver cab from the first post, restart device if prompted.

2) Run MobileXT, tap the signal bars in the upper left corner. Tap disable. Select GPS Intermediate Driver. Tap Enable.

3) Use Garmin normally from now on.

You may tweek ModDriver using the installed ModSettings application, but the defaults work just fine on my OmniaII.
[Windows Mobile Apps and Games] takeuchie:
which one to use 320 or 2003 320...? im using win 6.5..

how bout the ports..?