[GPS] Mod Driver - GeoCaching, Lag, Compass, Cell Tower, Altitude, GPS support.

Search This thread

maesus

Senior Member
Dec 27, 2008
931
31
uninstall problem

I am also suffering from uninstallation problem. Even though I tried with manual removing the registry, using SKTool to uninstall etc, then upgrade to any other version, I will get the same warning that "The previous version of Mach2003 GpsModDriver will be removed before the new one is installed." No matter how thorough I cleaned the registry, the record is still there!:confused:
 

tcchuin

Senior Member
Dec 25, 2008
1,034
69
any automated cab for the garmin patch?and i can't understand the registry part..what's the name for the registry?
 

LongZheng

Senior Member
The only problem I'm experiencing now is that it seems only one application can connect to the COM port at the time. TomTom and Google Maps can't use the GPSModDriver COM port at the same time.

I don't know if this is a limitation or problem you can work around?
 

axl30

Senior Member
Dec 13, 2008
208
17
Breganze
problem

my impressions on the rc3 are fully negative...
then I don't know that rom uses you and whoever says that works well to me it happens with the igo to stop me to a semaphore and to see that on the screen my speed not and' lowered and to go on for at least 100 meters before realizes where I am really..
then I don't understand xche' the version 0.7 (according to me the only valid) with a correction of the lag of 0.7 seconds it acts very well and instead with the rc3 least it take at least 1.5 seconds of correction...(what and!'?!? does it create me him an additional delay?!?!) the updating of the speed effettevi seems too much me variable + /- 10 km / h besides I have noticed a graphic deceleration on almost all the navigators that I have tried as if the gps had a superior refresh to a second and a half
 

peacock93

Senior Member
Jun 3, 2007
90
3
With RC2 I was still getting the speed fluctuations with EnableSpeed set to 2. I set it to 0 and the speed stay very consistent. I still get some weird graphics sometimes when stopping, turning and starting. Mostly when turning. iGO8 will sometimes try to recalculate when all I did was turn the corner in the direction I was being told to.

Just want to give you some feed back. I will try RC3 and see if it helps.

peacock93
 

axl30

Senior Member
Dec 13, 2008
208
17
Breganze
I have made a will everything on a clean rom I have a po of competence and before speaking I make all the controls of the case
 
Last edited:

GermanGuy

Senior Member
Mar 19, 2005
1,327
158
Minneapolis
Question,

Which cab am I supposed to install - GPSModdriverRC_3 orGPSModdriver0_9? Also, does this include the UI or do I need to install that as a seperate cab? Thanks.
 
Jul 9, 2008
49
1
Hey mach!

I've just had some time to install you driver and driving a round a while. I have to say im pretty impressed. Verry nice solution. It worked much better than expected. With a LagAdvance set to 1500 i've almost no lag. Perhaps i even could adjust that value a little more, but had no more time.
I've tested your driver with the newest iGo software. For me it was important that the top of the arrow shows the position of the front of my car. And with your driver i was able to adjust this with the default values (except the LagAdvance).

Some questions (i've red the whole thread, but not at once so sorry, if i'm asking sth. beeing already answered):
1. Which is the prefered Baudrate (i know i've read this here but culdn't find it any longer)
2. I guess you're calculating the average acceleration and with this you're calculationg the future position. I've observed that in cases i'm accelerating verry fast and breaking directly after acceleration process (for example in front of an intersection) the calculationg position is a little to far from my real position (in the example: i stopped in front of the intersection... IGO shows the arrow behind the intersection). But that's normal because of that algorithm and after some short time IGO resets the arrow to the correct position. Driving with a constant speed (so acceleration is verry poor) the position is, like i've already said, almost perfekt.
Have you already thought (or perhaps even already tested) not to use the acceleration but the calculated position + some constant value (perhaps in meter) in the direction you are driving. Perhaps that would be even more accuret (don't really know if this would be better... it's only a proposal)
3. Did you use Visual Studio to write this driver?
4. I'm verry interesting in how you developed this, because some time ago i investigated a little time by myself to develope the same idea as you have/had. I faild by opening the com-port. I used the Devicemanager to emulate a WM6.1 device and installed a extension to simulate GPS. But i was not able to open the COM-Port. Perhaps i've had checked this on my Diamond ;). However..!

GREAT work! Keep going. If you need some help, just tell me :)
Chris
 

L_o_k_i

Senior Member
Jun 4, 2007
266
17
Brussels
Hi,

I tried some days ago your driver and I'm very impressed. It's a very good idea to compensate the lag of gps (why someone didn't thought about it before! :D ). I didn't have the time to test RC3, but I will tomorrow.

Have you already thought (or perhaps even already tested) not to use the acceleration but the calculated position + some constant value (perhaps in meter) in the direction you are driving. Perhaps that would be even more accurate (don't really know if this would be better... it's only a proposal)

I don't think it's a good idea to just add a constant value on the actual position because, as you said, when you stop at an intersection you will have this constant that will put your position ahead from your real one.

What I saw by testing (the real gps port):
- when we are not moving there is no lag in position
- when we are moving the lag's value depends on our speed. the more you speed the more there's lag

So the correction should depends on the the speed. What do you think?
 
Last edited:

oruam57

Senior Member
Aug 27, 2005
306
4
I drive tested RC3 on Topaz/Diamond2 with TomTom.

As with 0.9 lag compensation is very good.

As with 0.9 having both Course AND Speed enabled (EnableCourse = 1 or 2 AND EnableSpeed = 1 or 2) causes course instabilities at stop and low speed. Instabilities are small with very good GPS signal (open country) but intolerable with bad GPS signal (urban area, tall buildings).

Disabling Course OR Speed removes the problem. At the moment EnableCourse = 0 and EnableSpeed = 1 seems the best combination but I am not sure because difference from other combinations are small and so longer tests are in order.
 

Mach2003

Senior Member
Sep 3, 2008
1,020
88
Kelowna
any automated cab for the garmin patch?and i can't understand the registry part..what's the name for the registry?

Setup.dll could be used to rename the Garmin file, but then something could go very wrong. I'll think more about adding a cab for QueStub.

The only problem I'm experiencing now is that it seems only one application can connect to the COM port at the time. TomTom and Google Maps can't use the GPSModDriver COM port at the same time.

I don't know if this is a limitation or problem you can work around?

I have it on the 'list' to allow more than one app to use teh driver at teh same time. For now choose one app for ModDriver, and set the other to the original port.

With RC2 I was still getting the speed fluctuations with EnableSpeed set to 2. I set it to 0 and the speed stay very consistent. I still get some weird graphics sometimes when stopping, turning and starting. Mostly when turning. iGO8 will sometimes try to recalculate when all I did was turn the corner in the direction I was being told to.

Just want to give you some feed back. I will try RC3 and see if it helps.

peacock93

Great, I love ALL feedback. Try EnableSpeed at 1 (no averaging, but still allow the driver to calculate speed), when Enable speed is 0, you get the speed as calculated by the GPS, unaltered.

my impressions on the rc3 are fully negative...
then I don't know that rom uses you and whoever says that works well to me it happens with the igo to stop me to a semaphore and to see that on the screen my speed not and' lowered and to go on for at least 100 meters before realizes where I am really..
then I don't understand xche' the version 0.7 (according to me the only valid) with a correction of the lag of 0.7 seconds it acts very well and instead with the rc3 least it take at least 1.5 seconds of correction...(what and!'?!? does it create me him an additional delay?!?!) the updating of the speed effettevi seems too much me variable + /- 10 km / h besides I have noticed a graphic deceleration on almost all the navigators that I have tried as if the gps had a superior refresh to a second and a half

If RC3 has increased lag compared to 0.7, then try reducing SleepTime to 500 as a test. I'll have to go look at the changes from 0.7 to RC3 to see what you could be seeing.

Question,

Which cab am I supposed to install - GPSModdriverRC_3 orGPSModdriver0_9? Also, does this include the UI or do I need to install that as a seperate cab? Thanks.

Versions 0.x are Beta test, Versions RCx are release candidates, (and soon) versions x.x are ready for general use (released). RC3 is the newest!

Hey mach!

...snip

Some questions (i've red the whole thread, but not at once so sorry, if i'm asking sth. beeing already answered):
1. Which is the prefered Baudrate (i know i've read this here but culdn't find it any longer)
2. I guess you're calculating the average acceleration and with this you're calculationg the future position. I've observed that in cases i'm accelerating verry fast and breaking directly after acceleration process (for example in front of an intersection) the calculationg position is a little to far from my real position (in the example: i stopped in front of the intersection... IGO shows the arrow behind the intersection). But that's normal because of that algorithm and after some short time IGO resets the arrow to the correct position. Driving with a constant speed (so acceleration is verry poor) the position is, like i've already said, almost perfekt.
Have you already thought (or perhaps even already tested) not to use the acceleration but the calculated position + some constant value (perhaps in meter) in the direction you are driving. Perhaps that would be even more accuret (don't really know if this would be better... it's only a proposal)
3. Did you use Visual Studio to write this driver?
4. I'm verry interesting in how you developed this, because some time ago i investigated a little time by myself to develope the same idea as you have/had. I faild by opening the com-port. I used the Devicemanager to emulate a WM6.1 device and installed a extension to simulate GPS. But i was not able to open the COM-Port. Perhaps i've had checked this on my Diamond ;). However..!

GREAT work! Keep going. If you need some help, just tell me :)
Chris

1) Baud rate has little effect, higher is, well, faster! I use 115200 if I have a choice.

2) Distance alone would be worse: to 100kph 1 second of lag is way farther than at 10kph. Earlier drivers ignored speed changes, and the result was worse. No matter what I do, with data comming once a second, there will be no way to accuratly predict where your position will be. Look at an example: At the time of GPS data, you are at 100 kph. By chance you slow quickly just after the instant that the gps data was calculated, my driver will use 100kph for that pass, but your actual speed may have been only 50...

3) Embedded VS 4.0, actually, all the system calls used are compatible with 2003 and up.

4) Too bad you did not get it to work, could have saved me a lot of time :) I have never tried it on the sims, easier to use the real device for driver testing. I flash often anyway, do Hard Resets don't upset me.

Hi,

../snip


So the correction should depends on the the speed. What do you think?

Speed is essential in the calculation. Averaged speed is even better for me.

Are you saying that the current driver does not do well at higher speeds?
 

Mach2003

Senior Member
Sep 3, 2008
1,020
88
Kelowna
I drive tested RC3 on Topaz/Diamond2 with TomTom.

As with 0.9 lag compensation is very good.

As with 0.9 having both Course AND Speed enabled (EnableCourse = 1 or 2 AND EnableSpeed = 1 or 2) causes course instabilities at stop and low speed. Instabilities are small with very good GPS signal (open country) but intolerable with bad GPS signal (urban area, tall buildings).

Disabling Course OR Speed removes the problem. At the moment EnableCourse = 0 and EnableSpeed = 1 seems the best combination but I am not sure because difference from other combinations are small and so longer tests are in order.

Try increasing DeltaDistance and DeltaSpeed instead of disabling Course and/or speed. Watch your speed indication under bad coverage, set DeltaSpeed to a number higher than the biggest number you see. Tweek DeltaDistance up until the effect goes away. These values work on the 'stopped' values, but allow the 'moving' values to be changed.
 

oruam57

Senior Member
Aug 27, 2005
306
4
Try increasing DeltaDistance and DeltaSpeed instead of disabling Course and/or speed. Watch your speed indication under bad coverage, set DeltaSpeed to a number higher than the biggest number you see. Tweek DeltaDistance up until the effect goes away. These values work on the 'stopped' values, but allow the 'moving' values to be changed.

At the moment I have DeltaDistance = 300 and DeltaSpeed = 30. Is it worth to increase them more?
 
Jul 9, 2008
49
1
...
I don't think it's a good idea to just add a constant value on the actual position because, as you said, when you stop at an intersection you will have this constant that will put your position ahead from your real one.

What I saw by testing (the real gps port):
- when we are not moving there is no lag in position
- when we are moving the lag's value depends on our speed. the more you speed the more there's lag

So the correction should depends on the the speed. What do you think?

In my case the lag with the original GPS port was always constant. Independent how fast i drove, the GPS position was aprox. 10m behind me. So i thought if i would eliminate this constant i would get perfekt results. And yes, youre right. If im standing (not moving) the original GPS port sends the correct information, but only after some time. Further more you could catch this up with a simple if block. Something like if youre standing return x, else return x+10m where x is the gps - pos of the original GPS port.
But youre right the real world is mostly more complex than that ;)

1) Baud rate has little effect, higher is, well, faster! I use 115200 if I have a choice.

2) Distance alone would be worse: to 100kph 1 second of lag is way farther than at 10kph. Earlier drivers ignored speed changes, and the result was worse. No matter what I do, with data comming once a second, there will be no way to accuratly predict where your position will be. Look at an example: At the time of GPS data, you are at 100 kph. By chance you slow quickly just after the instant that the gps data was calculated, my driver will use 100kph for that pass, but your actual speed may have been only 50...

1) OK, but doesn't drain a higher buad-rate the battery?
2) I understand what youre telling but i'd like to have more informations. Assuming xi is the measured gps position from original GPS port at time t where i=0. We have to predict the position within 60 seconds. Are you averaging the speed or the acceleration? And how many previous xi whre i<0 are you using for calculation the average data?
 

peacock93

Senior Member
Jun 3, 2007
90
3
Great, I love ALL feedback. Try EnableSpeed at 1 (no averaging, but still allow the driver to calculate speed), when Enable speed is 0, you get the speed as calculated by the GPS, unaltered.

Mach2003,

With EnableSpeed set to 1 my speed read out very badly. Some times +/-10 or 20 mph. With it set to 2 my speed varies by +/- 5mph and with it set to 0 it varies +/-1 or 2mphs.

peacock93
 

Mach2003

Senior Member
Sep 3, 2008
1,020
88
Kelowna
In my case the lag with the original GPS port was always constant. Independent how fast i drove, the GPS position was aprox. 10m behind me.

I don't realy care if the indicated position is 10 meters out, does not effect anything for me. Accuracy of the signal is, at best, 3 meters anyhow. Even when geocaching, 10 meters id close enough most of the time.
1) OK, but doesn't drain a higher buad-rate the battery?
2) I understand what youre telling but i'd like to have more informations. Assuming xi is the measured gps position from original GPS port at time t where i=0. We have to predict the position within 60 seconds. Are you averaging the speed or the acceleration? And how many previous xi whre i<0 are you using for calculation the average data?
1) faster baud causes more battery drain? I fail to see how this is possible, but whatever baud you want to use, the driver will work with any setting. It opens the original port at the same baud rate as you open mine at.
2) It is complicated... Both is the short answer. Long answer:
Save previous original GPS position, heading and speed.
On each valid reading, calculate distance moved, and heading from change in original GPS position (CurrentCourse), record time lapse from the GPS time stamp. Calculate speed.
Average Speed = Distance Traveled/Time taken.
NewSpeed = 2*AverageSpeed - LastSpeed.

For this text, Delta filters are removed.

If( EnableCourse == 2 )
NewHeading = AverageOf( CurrentCourse, LastCourse)
Else
NewHeading = CurrentCourse

If( EnableSpeed == 2)
CurrentSpeed = AverageSpeed
Else
CurrentSpeed = NewSpeed

If( LagAdvance )
dist = (NewSpeed * 3.0 - LastSpeed) * LagAdvance / 7200.0; // meters to move over LagAdvance
CourseChange(LastCourse, CurrentCourse) * Time/LagAdvance // degrees change over LagAdvance
Project NewPosition, and insert into data.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    GPS Mod Driver (From original post in Diamond thread Ending Here)
    This Driver installs between your gps application and the GPS driver that reads the hardware gps.

    - Lag is compensated, by guessing your position 'some number' of milliseconds in the future, current course and speed changes are included in the guess.
    - Driver corrects for invalid data in the gps strings, Out of range DOP values, and Heading values of 'NaN' (Not A Number). Position, Speed, and course are reported, even though the distance traveled is less than 30 meters.
    - Cell Tower location is used when GPS is unavailable
    - Altitude is corrected from/to WGS84/ASL
    - Hardware Compass Support
    - Allows selction of many input sources, including MSApi (GetPosition api)
    - Suports GPS applications on any COM port, as well as GPSApi (GetPosition api)

    Hardware Compass Support information is in Post Number two
    QueStub support is in post Number Six, Garmin can now use GPS Intermediate Driver, so no longer needs QueStub

    Newest Version:

    3.4.4
    Add back in the detection of dead input port

    3.4.5
    Fix GpsApi when calling app is stupid
    - Caller asks for V1 data with V2 dwSize (I return V1 as version with V2 size, and V2 data in the return
    FixGpsApi GPSGetDeviceStatus
    Change ReadNewData to detect, and call GPSGetDeviceStatus, and set the waiting handles (if there are any)

    3.4.6
    Remove trap on stuck GPS from msapi, only COM ports are detected (TP2)
    Rename gpx and csv files to: "ModDriver_{date}_{time}{In or Out}.{gpx or csv}"

    3.5.0
    Add GPX tracklog 'ending' to each log write, fseek back to overwrite.
    Change time sync to CellInit, since clock is functioning when service loads.
    - Detect when Cell service not loaded, and sync on GPS open port

    3.5.1
    Created a new device MsClock, provides current device time with millisecond resolution
    Created and linked MachClock.dll (uses MsClock)
    - Provides SystemTime and FileTime with 1 m/s resolution
    - Uses device clock for base time
    - Re-Sync time on device wake-up from sleep
    Used MachClock to keep time in sync (all apps and drivers)

    Fixed a bug in appending GPX tracks to existing logs

    3.5.2
    Move DeviceStatus maintenece to ModDriver
    - Modify COM_Read, COM-Write to support transfer of data to caller (GPSApi.dll)
    Remove Power up/down redundentcies from ModDriver and MachCell
    Add Thread open count to MsClock
    Fix Power up notify in MsClock
    Fix Extra calls to UpdateDeviceStatus in ModDriver, when no-one is listening
    Create Named event in GPSapi.dll to track mutiple instances of dll

    3.5.3
    Include AutoLog, RegUtil, and CardPath into MachClock.dll
    - Should save some ram since the code will only load once (shared for all apps and drivers)
    - On my device running GpsModSetup saves 20kb of ram
    MachCell should have saved another 20kb too, but since it is a service I can't prove it
    - Fix a COM port read issue when GSV is not sent regularaly (some BT recievers)


    3.5.4 - 3.5.6
    Fix EnableLogs Registry read error issue
    Remove close COM port on PurgeCom (bug)
    Fix time error
    Fix GPX logging
    - Could stop/delay output data

    3.5.7
    ModDriver could be sending data to the application way too often
    MsClock driver was not being used by ModDriver
    MsClock bit of tweeking, and was made faster too
    could have stayed running 'awake' when nothing was using it.

    GPX log files was still broken sometimes, another tweek there too.
    reset the device clock to the GPS time (+500m/s)
    added some logging to MsClock, but only for testing

    3.5.8
    Logging Owner Process Name in ModDriver and MsClock
    Extra Delay removed reading some COM input devices
    When input port times out, reader thread could stay active (or even duplicate)
    MsClock, only reset device clock if it needs resetting (read current clock, and compare first)
    Changed timing on EnableSmooth
    - Used to return data at 600, 400+, 600...
    - Now 500, 500+, 500, 500+,
    Better handling when reader app crashes without closing the ports
    - System sends me Ioctl_Psl_Notify
    - I force close reader port, SetLastError( 6 )
    - In GPSApi I react to GetLastError() == 6, by exiting the reader thread.


    3.6.0
    - Fixed a minor issue with sudden loss of BT com port

    Version 3.10 and newer: Added Direct support for reading cell tower location.
    See the change log and Cell Tower features starting on post 1346 here

    External Card Storage
    - If the card is removable, installing a device driver to it is just a BAD idea, don't do it!
    - My attached shortcuts don't work, make your own or edit mine.
    - Your card may not be avalable during early boot, so driver may not autoload.
    - Driver will take londer to load, so phone will take longer to boot.
    - ModSettings will take longer to load
    - Uninstall is not as perfect, but still works fine, except it is possible that the dll on the card may not be removed if it is in use at the time.
    - Did I say don't install to a card unless you have to?

    - Install the driver cab, change your GPS application to the indicated port or to use Gps Intermediate Driver, instead of the original internal com port.

    - Run GpsModSetup (found in start), you will see live gps data from the ModDriver on the main page. Tapping the screen will toggle to a sattelite view screen.

    Menu/[Profile] (driving or Walking): to use a preset setup, Save will update driver to use new profile. If auto profile is enabled you will not be able to make this selection, but can still edit the profile's values.

    Menu/System: to change the values used by ModDriver.
    - Log File: Creates a debug log in \Mach2003 of the device.
    - Extended: Adds more information to the logs.
    - Track Log: Creates a GPX and CSV file to card\Mach2003 that can be viewed in Google Earth, or many other applications.
    - Raw Data: Includes an extra GPX and CSV file for the raw input readings from the GPS source.
    - Smooth: Allows Mod Driver to insert an extra GPS output at half the sleep time, so that some map displays are less jumpy.

    GpsModDriver section
    - Sleep Time: Amount of time that Mod Driver will wait for a new GPS reading. Default devices are 1000 ms.
    - ComTimeOut: Passed on to the windows com driver when using a COM input port, amount of time readfile will wait for ANY data to arrive on the port.
    - Keep Alive: Driver will keep reading raw data for this many milliseconds after the last reader port is closed. Allows for switching GPS applications without loosing fix.
    Be very careful changing the following port, you may need a factory (HARD) reset if you change a port to one that is already in use!
    - Com Port: The output port Mod Driver will use to send data to your GPS Application.
    - Enable: Enable (or disable) All Mod Driver functions.

    Internal GPS Device section
    These settings are written to the internal GPS device registry, and MAY be used by the original driver
    - Sleep Time: Time to Wait for data when no data is available ro read.
    - Poll Rate: How often to check for new data from the internal driver.
    - Input Buffer: Amount of phycical RAM to reserve for READING the internal GPS device.
    - Output Buffer: Amount of RAM to reserve for communication to MS GPSID driver.
    Be very careful changing the following port, you may need a factory (HARD) reset if you change a port to one that is already in use!
    - Com Port: Com Port for GPSID data, same as using the 'External GPS' control panel 'software port' item.
    - Enable: Enable (or disable) the internal GPS, same as "allow windows to manage device" under external GPS settings.

    Menu/Extras: To configure additional settings.
    Altitude Table section
    - Altitude Fix, To enable driver to correct altitude to true (ASL)
    - Prefer GPS, To use GPS altitude when avaiable instead of the table values
    - Kill Feature Remove Table, Use to remove the altitude correction feature, and the table file from your card.
    Auto Profile Selection
    - Gsensor Angle, angle from vertical when to switch to/from walking profile.
    - Enable portrait, To autoswitch profile when in portrait mode
    - Enable landscape, To autoswitch profile when in landscape mode
    Cell Tower Location
    - Service is Running Now, Reports current service status, tap to update
    - Enable Cell Service, ...
    - Enable Service, Only with GPS, starts and stops cell service when Mod Driver is used/closed
    - Enable Internet Cell Data, Allows Servicer to use data connection to resolve location of unknown cell towers
    - Entries To Save, restricts the size of the cell tower database
    - Default MCC, Can be set to YOUR Mobile Country Code for when your RIL does not have this vital information
    - ReStart, Stop/Start Buttons.
    - Export, To export known cell tower locations to a GPX file
    - Update, Used to resolve all unknown cell tower locations, ignores Enable data Flag (use while connected through A/S)
    - Kill Feature Remove Service, Use if you don't want cell tower location features.
    Menu/Ports: To enable Mod Driver to use other input ports.
    Port Scan Mode
    - Scan On Power Only, default, allows scanning for a better input port only when the device is plugged in.
    - Scan on Battery Too, allows port scan at all times, regardless if device is plugged in or not.
    - Never Scan, disables the port scan feature.
    - Scan Only Once, does an imediate scan, then sets itself to "never scan".

    Input Port section
    - Port (MSAPI, or Com Ports from 1 to 9)
    - Enable, allows Mod Driver to read this port
    - Fix, applies Mod Driver Lag, speed, and heading fixes to this port (some devices might not need these fixes)
    - Order, Mod Driver tries to find GPS data on the Enabled ports in this order, 0 first, then 1, 2... (99) is auto entered for the "output" port, as it can not be used for input as well.

    All screens have an 'Undo' and 'Save' button. Undo will revert all changes made to the screen, save will update the driver to use the new settings.

    Profile Screens
    - Name: Used for profile selection and display (alters the names on menu and selection screens)
    - Set To Defaults button: Sets all profile fields to factory default values, as installed from the latest CAB.

    To Insert Speed and Course section
    - Distance Moved: Meters times 10 to update course and speed (30 = 3.0 meters)
    - Zero Speed Time: Milliseconds to speed when distance above is not exceeded, your speed will "stick" until this time passes when not moving.
    - Minimum Speed: Any speed below this value will be considered as "zero" to filter out erratic slow readings.

    To Calcualte Lag Position section
    - Speed Threshold: kph times 10 to update LagAdvance position (50 = 5.0 kph), readings with speeds below this value will not have lag applied.
    - Lag Advance (ms): Number of milliseconds to project your position into the future to compensate for delay in GPS readings

    Toggle Enable section
    - Speed Fix: Allow the driver to correct speed
    - Prefer GPS: If GPS raw data has a valid speed, use it instead of calcualting speed from position.
    - Course Fix: Allow the driver to correct Course
    - Prefer GPS: If GPS raw data had a valid course, use it instead of calculating course from position.
    - Dop Fix: Allow the driver to correct bad dop values
    - Compass: Allow hardware compass with this profile

    Auto Input Selection
    Mod Driver allows you to select more that one source port for reading GPS data. No matter what input port is used, your GPS application can read Mod Driver to get GPS data.
    - You can enable Bluetooth GPS devices as well as MSAPI, and the internal COM port devices.
    - 'Order' assigns the preferred port to use, 0 is the most prefered, 1 is next...
    - When first started (any GPS application opens Mod Driver port), driver scans ports starting from 0, to find input data.
    - If the scan mode is enabled, it tries lower order ports every 30 seconds or so, and switches 'up' to a better port if fixed data is there.
    - If the current port looses connection, Driver will try any enabled port to get good data (regardless of scan mode).
    - To install a BT device, pair it with your phone, and add an external com port to it.

    Altitude Fix
    The NMEA standard requires GPS altitude to contain Altitude above sea level (standard was made by boat people), and seperation from the WGS84 ellipsoid used in calculating the ASL. Sea level varies on the planet by up to +- 100 meters from the ellipsoid due to gravitational force changes. Using data from NGA (2008), a table was created (stored on CARD under \Mach2003, 64kb), and is used to determine the seperation value for the current GPS position. In testing, we found that the table value was more current (a more accurate value) then even the devices' driver was using. Prefer GPS will override the table value, and use what the device thinks is correct only if the GPS data actually has the seperation value. You CAN disable this feature and save a bit of card memory by deleting the Altitude*.RAW file. (if card memory can not be found, the file is retained in the devices \Windows folder).

    There are also a couple of shortcuts attached here to auto-select a profile. You can copy them to start menu, or to app keys to assign to a hardware button. There is also a shortcut for running the "scan once" selection without "starting up" mod settings.

    KillDriver.exe
    Used to remove a stuck un-install of the driver instead of using SKTools.
    Copy the un-zipped file to the device and run it. It will remove all the files, registry entries, plus the Mod Driver entry in the uninstall database.

    It may leave behind some registry entries, and does leave behind the files under \Windows\App Install. You may delete these files manually after running the kill driver application.
    3
    GPS Mod Driver - Hardware Compass Support

    Mod Driver supports the hardware compass on the HTC, and Samsung devices that have a hardware compass.

    - Mod Driver uses Compass Heading below Delta Speed for the current profile in place of GPS heading.
    - Compass speed is configurable, default is 2.5 kph (works with Garmin Mobile XT)
    - Not all GPS applications will use the heading without a speed, your results will vary.

    Samsung Devices need to have the SDK 2.0 cab installed (attached here).

    When a hardware Comapass is detected an additional menu item is available for presetting the difference between the hardware compass and actual heading. This is required because your phone may be mounted slightly off angle, and it also reports a 'magnetic' heading instead of the GPS 'True' heading.

    Compass hardware does NOT detect landscape rotation properly, but Mod Driver adjusts for this automatically.
    Calibration factors are retained for each profile, so mounting (or holding) position is accounted for.

    Hardware compass is quite useless in an automobile because of the huge amount of metal around you, and teh EMI that the car generates. You can disable the compass under "Driving" profile, and when using auto profile selection, the compass will only be used when you have the phone out of it's car cradle. Or if you don't use auto-profile, when you select walking profile.

    The best way to calibrate the driver's compass value to to just edit the value directly, note that you can not enter a negitive value, but just add 360, and enter that (ie: -21 degrees = 339 degrees).

    To calibrate the compass
    Choose compass from the menu button.
    Be prepared to exceed your current 'Delta Speed' Value for at least 10 seconds, and travel in a relatively straght path.

    Compass Screen:
    - Num Averages: The number of compass/g_sensor readings to average together
    - Landscape Angle: For HTC only, the amount of rotation to determine that landscape is triggered.
    - Poll Time: How often to read the sensors.

    - The portrait and Landscape buttons are not selectable, but will show the current orientation of the device.
    - Values for the current calibration from GPS to COmpass heading can be enetered manually, or viewed here.
    - Reset to Zero, allows a simple reset function for each orientaion.
    - Calibrate button enters self calibarate mode (see below)
    - Help?, condensed version of this post :)

    Calibration
    There are three 'status' messages displayed. One for speed, averages, and overall status.
    Each message has a check box that will tell you if that item has been satisfied.

    Press Calibrate button,
    Notice that count (at the bottom) will count down the number of seconds until you get to Delta Speed.
    Once at speed, the count will change to teh number of readings included in the calibration average.
    Compass and GPS heading are updated as messages arrive from the driver (about once a second).

    Once 10 readings are taken for the average value, the updated value will be shown.
    3
    Thank you Mach i thought that you left from this threat

    I will test it and i will tell you as soon as possible

    Thank you again

    :eek: Left the thread :confused: no way! I've been making test builds and letting RoryB do all the work of testing them (via email). He deserves a thanks for his hard work.
    3
    New Public beta build

    I am now using a new build number version system for this project.

    Currently Major version 3, will change with whole program update
    Minor Version 3, will change if new features are added
    Release Version 4, will change anytime I email or post an update
    Build Version (various), each module has it's own counter.

    Build numbers may not be the same on all apps/drivers in a cab (they don't all get built the same number of times).


    Changes from 3.29 to 3.3.4
    -Exiting COM input by testing good messages recieved
    -Fixing altitude, whole new line of thought
    My old routines were not updated when I changed from saving seperation value to saving AEL
    No longer need to compare last reading to this reading to detect changing items
    I am introducing a small error for some devices, when your actual seperation value is exactly 0.0
    I will assume you have AEL in the data, when you actually have ASL and AEL, but they are equal
    Driver will use its table, and alter ASL incorrectly, but table will be very close to zero, so the error will be very small

    -Added version checking/logging for ALL related apps and drivers, including your GPS application itself
    -Simplified ModSettings main page text (and font used)
    Using off screen composting now
    - Allowed restore backup settings on fresh install
    - Detect loss of GPS data string, and switch ports (sudden BT power off)
    - First "KeepFix time" of connection will use CellTower location, even when KeepFix is not enabled
    - ReDo all the insert speed/heading, and keep fix logic
    - Using KeepFix time for ALL cell tower insertion timeouts.

    - rework portscan
    - Changed scan allowance to get fix from 30 to 60 seconds
    - Repair time difference calculation, messed up everything
    - Reset GPS string time on first fixed position only
    - Re-Work switch over to Cell/Unknown rules
    - Clear GPS valid speed flag, and reset speed to zero as required
    - Add short name to version screen/logging
    - Menu, About, displays version info for all related aps and drivers, tap screen to close

    For those that need the PPC2003 version of the driver, I have attached a beta version for you to try now as well.
    3
    Update

    3.6.2
    - Fixed a bug where when loss of fix happens, the time to "keep fix" may have been incorrect.
    - If device clock was in the past, it would never be reset to GPS time.
    - Better detection of lost GPS input
    - If allowing MSAPI, and COMx (both internal GPS, default config), and the current port looses GPS, ModDriver will switch to the other port. This recovers a stuck internal GPS on some devices.