View Full Version : [PROB] TouchPro GPS lag problems
ahh
20th November 2008, 11:18 AM
changing these settings didnt seem to make a difference for me :(
I'm using a Touch Diamond and have applied all the GPS tweaks, but no joy. There is still a lag of 5-6 seconds.
Upquark
21st November 2008, 07:54 AM
Hi Guys,
i have still lag problems.
my tp gets 7-8 fixes in 10-20 secs. but they disappear in a second then they appear again.everytime like this.Now i give up to use my internal gps, i use my globalsat bt gps receiver.
i ve tried all settings, tweaks, programs and some radios except roms but i couldnt have a solution yet.
what did you or people have my problem do?
you give up like me or you solve the problem?
Sounds like you've got A-GPS enabled. Turn it off, that should at least solve the dropping signal problem. I'm not sure why you state you've still got lag problems though, because that's quite another issue.
xeryus1907
21st November 2008, 11:40 AM
Sounds like you've got A-GPS enabled. Turn it off, that should at least solve the dropping signal problem. I'm not sure why you state you've still got lag problems though, because that's quite another issue.
A-GPS is disabled, not enabled.
wmm
21st November 2008, 12:55 PM
A-GPS is disabled, not enabled.
Yeah, me, too, and I still wasn't able to get a lock for ten minutes last night using GPS Test. It showed two satellites and never added any more. Clear night, and me standing outdoors in the same place where I often get a lock in a few seconds to a minute. (I did get a lock in a minute or so a couple of hours later.)
I don't know what the problem with GPS on the Fuze is, but it's NOT aGPS (or at least not the whole problem -- aGPS might make it worse or be a different problem, but turning off aGPS is clearly not the complete solution).
Jouke74
21st November 2008, 01:22 PM
For all of you who did the following tweak and are not able to get a GPS signal / fix :
Drivers\SleepOnNoData -> 100 (default is 1000)
Please restore the value to 1000 or even 1500!
This tweak means that you're basically giving the GPS reciever 0.1 second to find a signal. If it's not there it's going to sleep again. Of course, your GPS program does not like that and is turning it on again... etc. It also means that if you have put the Polling at 250, that the GPS receiver will be turning on and off twice during one Poll. I cannot imagine this being good for the receiver.
With the values at 1000 or 1500 it will have 1 or 1.5 second to get a signal. Enough to receive data from any satellite. In speed it won't matter much. The tweaks that do most are the buffers and the Pollinginterval tweak.
Raymond77
21st November 2008, 01:50 PM
None of the tweaks made enough of a difference for Tom Tom7 to be of any use to me, so I switcehd to IGO 8 and the lag is now gone completely.
For the first time since I've owned it the Touch Pro is actually doing something well!:)
pcborg
23rd November 2008, 02:22 PM
I will soon be trying the fixes from this forum on the touch pro, however I noticed the gps issue with the Copilot 7, which is allgegedly compatible with the touch pro. Its crap. Ages to get gps signal, then the signal is lost periodically every several seconds.
I'll update if any of the fixes does the job for me. This touch pro was bought < 2 months ago.
abc73
25th November 2008, 01:06 AM
I am getting the Att version of HTC TP and i was wondering if any of these programs are mentioned here work on this phone or do i have to change the Rom..If so which Rom best fits to the purpose?
Thanks to all.
markmensch
26th November 2008, 03:54 PM
But I don't get it, it used to work the first days...
When you's worked 'for teh first few days', was that before the tweak listed above, or after?
mine goes in and out, but is useable (off and on) at highway speeds. rarely get a fix when walking, but it happens.
trying to decide whether to do teh tweak at the top of this thread.
brent1f
27th November 2008, 12:33 AM
I'm not sure this is related but I have a buddy who was having GPS lag and locking issues with his phone (Sprint Mogle - HTC PDA). He updated the Radio Rom today and his phone instantly locks on Sats, less than 3 seconds and there is no lag in any program (Live, Google Maps, Inav, etc.) we tested them all. I'm begining to believe that there is something to the radio rom and gps performance.
I applied the FUZE GPS fixes to my new FUZE and have effectively solved my issues.
willybilly
27th November 2008, 02:24 AM
I'm not sure this is related but I have a buddy who was having GPS lag and locking issues with his phone (Sprint Mogle - HTC PDA). He updated the Radio Rom today and his phone instantly locks on Sats, less than 3 seconds and there is no lag in any program (Live, Google Maps, Inav, etc.) we tested them all. I'm begining to believe that there is something to the radio rom and gps performance.
I applied the FUZE GPS fixes to my new FUZE and have effectively solved my issues.
Can you share with us which version of Radio Rom your buddy is using?
P525Lover
1st December 2008, 11:47 PM
Can i disable A-GPS using registry?
i know it can be disable with advance config 3.2, But i wanna found out the exact key in registry.
Matthes42
2nd December 2008, 06:52 AM
yes, you can disable it by changing the right registry key. Advanced config does nothing else.
Can i disable A-GPS using registry?
i know it can be disable with advance config 3.2, But i wanna found out the exact key in registry.
P525Lover
2nd December 2008, 11:59 PM
yes, you can disable it by changing the right registry key. Advanced config does nothing else.
so do you know the right address in registry to dosable A-GPS? i searched by resco registry tool and found some keys but i'm not sure.!
thanks
brent1f
3rd December 2008, 12:10 AM
Can you share with us which version of Radio Rom your buddy is using?
I've asked, will let you know asap. If it helps he said it just came out a few days ago.
brent1f
3rd December 2008, 12:23 AM
Mogel Radio Rom Version 3.42.40
willybilly
3rd December 2008, 02:47 AM
I've asked, will let you know asap. If it helps he said it just came out a few days ago.
The observation I made about lagging are as follows:
a. Phone in 3G mode very little lag.
b. Phone in Edge/GPRS mode some lagging.
It's worth trying out the Radio ROM that your friend is using.
Thanks.
omaralt
3rd December 2008, 03:23 AM
hey, sorry i dont have time to read through all 27 pages, but here is what i found:
- turn on gps test 1.04 (the cab is floating around here somewhere, search for it)
- Let it lock on to the satellites
- once it does, then open garmin, tomtom, etc.. (i've only tested with garmin)
- YOU MUST KEEP GPS TEST RUNNING IN THE BACKGROUND!! if you turn it off, then turn on garmin, it'll keep losing signal...
as long as i have gps test running, i get no lag, and no issues.. i'm just wondering how this affects battery life; having two programs using the gps...
willybilly
3rd December 2008, 03:49 AM
hey, sorry i dont have time to read through all 27 pages, but here is what i found:
- turn on gps test 1.04 (the cab is floating around here somewhere, search for it)
- Let it lock on to the satellites
- once it does, then open garmin, tomtom, etc.. (i've only tested with garmin)
- YOU MUST KEEP GPS TEST RUNNING IN THE BACKGROUND!! if you turn it off, then turn on garmin, it'll keep losing signal...
as long as i have gps test running, i get no lag, and no issues.. i'm just wondering how this affects battery life; having two programs using the gps...
Never thought keeping gps test 1.04 running could solved the lag problem.
Will give it a try once i get hold of the gps test 1.04. Thanks.
drbf
3rd December 2008, 05:11 AM
hey, sorry i dont have time to read through all 27 pages, but here is what i found:
- turn on gps test 1.04 (the cab is floating around here somewhere, search for it)
- Let it lock on to the satellites
- once it does, then open garmin, tomtom, etc.. (i've only tested with garmin)
- YOU MUST KEEP GPS TEST RUNNING IN THE BACKGROUND!! if you turn it off, then turn on garmin, it'll keep losing signal...
as long as i have gps test running, i get no lag, and no issues.. i'm just wondering how this affects battery life; having two programs using the gps...
I did the same thing with GPSgate, reduced the lag but lost GPS sig every few min. I will try gps test 1.04 tomorrow
Thanks
omaralt
3rd December 2008, 05:28 AM
i havent tested it out extensively yet, so i dunno if this is a fix.. i'm actually going to pick up a friend from the airport, so i'll try using tomtom7 on the way there to see if its any good.. i'll update in half an hour or so.
omaralt
3rd December 2008, 06:18 AM
worked pretty good, actually got tomtom to work for once.. once it got a lock, it was solid :) so i guess i can use this as a temporary fix until somebody comes out with a permanent fix
willybilly
3rd December 2008, 07:21 AM
I don't seem to get gps test 1.04 working.
When I launch it what it does is it keep scanning from COM1 to COM9. Is that suppose to behave that way?
trackhouse1
4th December 2008, 09:49 PM
Is there any way to test the gps driver in a Sptint Touch Pro?
Matthes42
7th December 2008, 07:58 PM
No, I donīt know the value. I prefer doing it via advanced config. give it a try.
so do you know the right address in registry to dosable A-GPS? i searched by resco registry tool and found some keys but i'm not sure.!
thanks
miwu
7th December 2008, 08:37 PM
Tried it with GPS Test 1.04 - No Success :-(
wmm
7th December 2008, 10:08 PM
I don't seem to get gps test 1.04 working.
When I launch it what it does is it keep scanning from COM1 to COM9. Is that suppose to behave that way?
You should set the "program port" in the External GPS settings to some port (COM4 is a popular choice) and then in the GPS Settings page of GPS Test set the same port, at 4800 baud.
aaswouw
8th December 2008, 01:10 PM
Hi all,
Last night I had to use my TomTom for a long drive and this is what I discovered:
My TomTom has a lag (4/5 seconds) but after a while it seems that TT is noticing this lag 'cause the screen goes to grey (like there is no gps signal, but there is) and stays this way for a while (between 10 sec and 1 minute). After that, colours & navigation come back and all of a sudden TomTom is acurate. The lag is totally gone!
But after a while, lag is coming back and a while later TomTom notices it again.
Weird huh?
noellenchris
8th December 2008, 04:49 PM
For all of you who did the following tweak and are not able to get a GPS signal / fix :
Drivers\SleepOnNoData -> 100 (default is 1000)
Please restore the value to 1000 or even 1500!
This tweak means that you're basically giving the GPS reciever 0.1 second to find a signal. If it's not there it's going to sleep again. Of course, your GPS program does not like that and is turning it on again... etc. It also means that if you have put the Polling at 250, that the GPS receiver will be turning on and off twice during one Poll. I cannot imagine this being good for the receiver.
With the values at 1000 or 1500 it will have 1 or 1.5 second to get a signal. Enough to receive data from any satellite. In speed it won't matter much. The tweaks that do most are the buffers and the Pollinginterval tweak.
This worked for me...Thanks... I applied the GPS fixes and the .CAB file and then it seemed to get worse. After I changed these settings above, the GPS works everytime...
Upquark
8th December 2008, 05:18 PM
Hi all,
Last night I had to use my TomTom for a long drive and this is what I discovered:
My TomTom has a lag (4/5 seconds) but after a while it seems that TT is noticing this lag 'cause the screen goes to grey (like there is no gps signal, but there is) and stays this way for a while (between 10 sec and 1 minute). After that, colours & navigation come back and all of a sudden TomTom is acurate. The lag is totally gone!
But after a while, lag is coming back and a while later TomTom notices it again.
Weird huh?
Sounds like AGPS turned on.... turn it off and try again.
aaswouw
8th December 2008, 06:02 PM
Sounds like AGPS turned on.... turn it off and try again.
Nope, AGPS is disabled (at least, that's what Advanced Config says...)
Or is this program not the way to turn of AGPS?
livesoca
10th December 2008, 02:21 AM
Hello All,
Maybe this might be helpful for some. All testing was done on foot (pedestrian). No test was ever conducted in an automobile or other.
----------------------------------------------------------------------
Before the weekend I used to use TomTom Navigator v7.450.9028with the TomTom7 Western Europe 1GB 815.2024, and I've always encounterd the lag that everyone also encountered.
I've tried the settings that were posted on the first page, but still encountered the lag. However, after applying those settings, I usually got a solid fix between 45 seconds to 1 min 45 seconds. Hot start would be about +/- 45 seconds and cold start could last up to 1 min 45 seconds.
Yesterday I uninstalled TomTom v7.450.9028 and installed the TomTom Navigator 7.9.10 (9185). I also removed Western Europe 1GB 815.2024 and installed Western and Central Europe 2GB v725.1906 map.
After doing this still encountered the lag. I said to myself, let me just set part B of the fix posted on the first page to its defaults and also removed the entry instructed to create. I then restarted the phone.
On my way walking to work this morning I said let me test and see if I would still encounter the lag. To my surprise it was on point! I tested again walking home on my way from work and it was spot-on! It's a 2Km walk to work and back (each direction). I get a comple fix in 45 seconds - 1 min 45 seconds still, but it's on point.
When I'm at a corner, it shows me at a corner on the map. When I've crossed the street, it shows me crossing the street also.
This is information for my device.
TomTom was installed on my microSD card.
HTC Touch Pro
ROM: 1.90.401.1 WWE
ROM Date: 08/01/08
Radio Version: 1.02.25.19
Protocol Version: 52.33.25.17U
Matthes42
10th December 2008, 11:02 AM
Iīve got the same configuration but I still have the lag.
What happens when you stop walking or start walking. How long does it take to show your walking speed? Isnīt there a delay of 2 or more seconds?
Hello All,
Maybe this might be helpful for some. All testing was done on foot (pedestrian). No test was ever conducted in an automobile or other.
----------------------------------------------------------------------
Before the weekend I used to use TomTom Navigator v7.450.9028with the TomTom7 Western Europe 1GB 815.2024, and I've always encounterd the lag that everyone also encountered.
I've tried the settings that were posted on the first page, but still encountered the lag. However, after applying those settings, I usually got a solid fix between 45 seconds to 1 min 45 seconds. Hot start would be about +/- 45 seconds and cold start could last up to 1 min 45 seconds.
Yesterday I uninstalled TomTom v7.450.9028 and installed the TomTom Navigator 7.9.10 (9185). I also removed Western Europe 1GB 815.2024 and installed Western and Central Europe 2GB v725.1906 map.
After doing this still encountered the lag. I said to myself, let me just set part B of the fix posted on the first page to its defaults and also removed the entry instructed to create. I then restarted the phone.
On my way walking to work this morning I said let me test and see if I would still encounter the lag. To my surprise it was on point! I tested again walking home on my way from work and it was spot-on! It's a 2Km walk to work and back (each direction). I get a comple fix in 45 seconds - 1 min 45 seconds still, but it's on point.
When I'm at a corner, it shows me at a corner on the map. When I've crossed the street, it shows me crossing the street also.
This is information for my device.
TomTom was installed on my microSD card.
HTC Touch Pro
ROM: 1.90.401.1 WWE
ROM Date: 08/01/08
Radio Version: 1.02.25.19
Protocol Version: 52.33.25.17U
aaswouw
10th December 2008, 01:52 PM
Nope, AGPS is disabled (at least, that's what Advanced Config says...)
Or is this program not the way to turn of AGPS?
Found out that Advanced Config is indeed the correct program to disable AGPS.
So if AGPS is disabeld, the question remains: what's happening to my TomTom?
hopper13
10th December 2008, 02:02 PM
It appears to me that among other things, TomTom uses a smoothing algorithm.
Not only does it sometimes take a few seconds to reach zero mph when I stop, at times it actually continues straight for a second after I've turned! This means two things in my mind: 1) The program has predicted where I will be in one or two seconds since the gps never sent it data saying that I had passed the intersection, and 2) That there is a one to two second lag in getting the information from the gps to the program. I have tried most of the registry edits suggested, but they have not changed this behavior. (AGPS is off, running version 7.9.10)
Just my .02
sracercelica
10th December 2008, 04:26 PM
Is there any way that we could start a petition to send over to HTC so they can acknowledge the problem and hurry on working a fix??
mikempower
10th December 2008, 06:15 PM
somebody tried tomtom 6 on the rapahael? ihave lots of problem in fixing satellite with tt7,maybe the older version is better...can someone help me and show settings of a tomtom without a problem on this device?
Fallon
10th December 2008, 07:03 PM
TomTom Navigator 7.910... It's been working pretty good for me, however the other day when my wife was holding the phone in her lap in her Ford Escape it was getting the lag I keep hearing about. The phone/GPS works fine in the windshield mount on my Tacoma, and finally when we put the phone up on the dash, but was lagging horribly sitting in her lap a few feet back with much worse reception.
May or may not be applicable to anybody else, but couldn't hurt to make sure your phone is in a place where it can get good signal.
livesoca
11th December 2008, 12:16 AM
Hi Matthes42
After making a complete stop and proceed to continue walking it tool about 6 - 12 seconds before it displayed my walking speed.
'
Iīve got the same configuration but I still have the lag.
What happens when you stop walking or start walking. How long does it take to show your walking speed? Isnīt there a delay of 2 or more seconds?
Hi
pythonguy
15th December 2008, 02:44 AM
This worked for me...Thanks... I applied the GPS fixes and the .CAB file and then it seemed to get worse. After I changed these settings above, the GPS works everytime...
Same here, I followed a bunch of threads and tried different tweaks, even installing that stupid AT&T telenav garbage, and tried thethe .28 radio. The .28 radio worked a little better to lock but actually would hang my fuze after 15 minutes or so of using the GPS. I'm back to the stock .32 radio and this tweak (i set my SleepOnNoData to 1500) fixed the GPS up right, locks on every time now in less than 10 seconds from my indoor bedroom window.
quiescent
16th December 2008, 05:52 PM
Here's an ironic response from HTC Singapore. They should come here and take a look.
New Response From [ Cathy Zhang (Singapore Support (Tech)) ]
Dear quiescent, Thank you for contacting HTC International. With regards to your query, the lagging problem may be also due to the software itself. Since we don't provide technical support on third party sofrwares, from personal suggestion, you may try to use another GPS software have a try like MAPKING which we recommend. Thank you.
Country Singapore
Inquiry Information
Inquiry Type Technical Support
Inquiry Description GPS Lag problem. I'm using Garmin XT, I suppose I'm quite sure there's people complaining of this problem whereby your position lags about at least 5 - 10 meters away. Is this a hardware issue?
Issue Date & Time
2008/12/15 17:53
noellenchris
16th December 2008, 06:12 PM
Same here, I followed a bunch of threads and tried different tweaks, even installing that stupid AT&T telenav garbage, and tried thethe .28 radio. The .28 radio worked a little better to lock but actually would hang my fuze after 15 minutes or so of using the GPS. I'm back to the stock .32 radio and this tweak (i set my SleepOnNoData to 1500) fixed the GPS up right, locks on every time now in less than 10 seconds from my indoor bedroom window.
Mine still seems a little slow to 3d fix, only when I haven't used the GPS in a few days. I do get lag w/Garmin Mobile XT. I used to have a little less w/my Hermes(8525) and ext. antenna. Thought the lag was from my ext antenna, but after dealing with the fuze, I think that the software is mostly the cause. I will experiment with the ext antenna and see what happens.
daosis
16th December 2008, 11:35 PM
First of all, my touch pro almost never has a fix, even with all the tweaks and hacks and hard resets whatever. And quickgps feature has never worked for me until now. Then i noticed an interesting thing. At my home even google maps "my location" feature does not work - "Your coordinates are temporary not found". In fact in my town there are numerous places like that. But moving aside about 100 meters, google maps started to work and SO the quickgps. The fix was instant (less then in sec) in all my gps software - igo, ozi, gpstest etc. Now i understand why it didn't work before. There is no gps information in some parts of town, at my place for instance, from cellular towers or whatever quickgps uses (as agps). Now my gps works very accurately, with lag, but at least has a fix. Just use google maps "my location" until it starts to work. Then use quickgps.
pcborg
24th December 2008, 12:01 AM
Hi there, I have the HTC touch pro as well. It was not until I bought Copilot live 7 that I realised that the gps was crapola. Of course I believed the so called compatibility with the touch pro as advertised on the Copilot website. Of course no useful solution was offered from co-pilot support, just a why dont you try to install again solution. Thoroughly useless. Not to mention that email support is achingly slow.
After I read this and other sites, I realised that there is problem with the HTC touch pro (not all, but a significant amount it seems), so why the so called compatibility on the Copilot site?
Ok anyway I gave up on the HTC for gps, and try to install on my N95 8GB, no luck, so I talk to support (expensive as hell given the nice long wait before anyone can answer), no useful solutions for it.
So, sick of the cost of calls I go back to email support, slow and irritating as it is, and what do I learn? I need to use the Copilot Central desktop software to prepare it for the N95... I ask them to tell me how to get it (it comes free as part of the products they ship), he tells me, oh you need to pay Ģ15 for that!!! That the product they sell for download through Handango is CRIPPLED without this software that comes as standard with the shipped product.
Copilot can kiss my a**, and so can HTC.
crimo
24th December 2008, 03:22 AM
To all HTC TOUCH Pro Users with GPS lag problem,
after 2 months of tweaking, hacking, searching and endless tries, i found my solution.
A new Radio - see Thread below.
[RADIO]Raphael Radio Thread - Latest Raphael 1.08.25.20M1 [8 Dec 2008]
Original shipped Australian Rom - better Battery consumtion and 3G reception
Satelite fix within 20-30 seconds after coldstart and ca. 5 seconds after warmstart. Very accurate possition and indoor reception close to the windows, what never worked before on my device.
My recommendation to all of you !
quiescent
24th December 2008, 03:28 AM
To all HTC TOUCH Pro Users with GPS lag problem,
after 2 months of tweaking, hacking, searching and endless tries, i found my solution.
A new Radio - see Thread below.
[RADIO]Raphael Radio Thread - Latest Raphael 1.08.25.20M1 [8 Dec 2008]
Original shipped Australian Rom - better Battery consumtion and 3G reception
Satelite fix within 20-30 seconds after coldstart and ca. 5 seconds after warmstart. Very accurate possition and indoor reception close to the windows, what never worked before on my device.
My recommendation to all of you !
been there, done that. doesn't fix it.
crimo
24th December 2008, 05:12 AM
Give it a try,
hardreset your device or better flash an original shipped rom as me an then flash the radio. You´ll wonder i guarantee !!!
misfitwrx
24th December 2008, 05:21 AM
i just bought a fuze yesterday and tried to use the gps with google maps, i have not downloaded att nav, or anything else. the first couple of trys with gps and google maps it would not find a single satellite however after a few trys it got a lock and after that it was lightning quick getting a fix and really accurate... it seems like the gps unit actually needs to get warmed up or something now i have left it alone to charge for a few hours and its not getting a lock at all. this happened earlier and eventually it locked on and was fast again.. really strange at least its all software trouble i think. that means there is a fix for it
crimo
24th December 2008, 05:29 AM
I had the same impressions with my original o2 Diamond Pro warming up the gps unit, but since i have flashed an original HTC Rom and the new Radio mentioned above it works perfect without warming it up!
willybilly
24th December 2008, 06:06 AM
Give it a try,
hardreset your device or better flash an original shipped rom as me an then flash the radio. Youīll wonder i guarantee !!!
Just downloaded the radio rom an hour ago.
Took a drive and tested it using Garmin XT. Yes, it does work!!!
No more lagging and don't have to hard reset. Thanks a bunch for sharing .....8)))
m4rc3l1n0
25th December 2008, 05:50 AM
Just downloaded the radio rom an hour ago.
Took a drive and tested it using Garmin XT. Yes, it does work!!!
No more lagging and don't have to hard reset. Thanks a bunch for sharing .....8)))
which radio version is working for your fuze?
28? 32?
or do you have any recommendation which one to try first?
willybilly
25th December 2008, 04:25 PM
which radio version is working for your fuze?
28? 32?
or do you have any recommendation which one to try first?
[RADIO]Raphael Radio Thread - Latest Raphael 1.08.25.20M1 [8 Dec 2008]
cmloo
26th December 2008, 06:46 PM
I reverted back original ROM with this radio. Unfortunately lag still exist. In fact its worst than with ROMeOS 1.51 (must be due to the GPS One tweak)
Original Rom : 1.90.707.4 WWE
Radio : 1.08.25.20M1
Sounded too good to be true but sigh.......back to custom ROM and 25.19 radio
drjim
26th December 2008, 06:50 PM
As with many Fuze users, I'm having problems getting my phone's GPS to get a location fix. I found two separate threads on xda-developers that give very different advice (I'm posting this comment on both).
One recommends the following:
1. disable A-GPS
2. disable GPS logging
3. logfile name must be empty
4. old logfile name must be empty
5. maximum size of logfile must be 0
6 delete the files : \windows\GPSLogFile.txt and \windows\GPSLogFileBack.txt
One recommends:
* Assisted GPS: Enabled
* Log file: \windows\GPSLogFile.txt
* Old log file: \windows\GPSLogFileBack.txt
* Max. log file size: 32768
Any thoughts?
sndtubes
27th December 2008, 06:12 AM
To all HTC TOUCH Pro Users with GPS lag problem,
after 2 months of tweaking, hacking, searching and endless tries, i found my solution.
A new Radio - see Thread below.
[RADIO]Raphael Radio Thread - Latest Raphael 1.08.25.20M1 [8 Dec 2008]
Original shipped Australian Rom - better Battery consumtion and 3G reception
Satelite fix within 20-30 seconds after coldstart and ca. 5 seconds after warmstart. Very accurate possition and indoor reception close to the windows, what never worked before on my device.
My recommendation to all of you !
Forgive me for being stupid, but...... I'm unsure if the radio you refer to is the entire radio or just the GPS radio? Reason I ask is that I have a Sprint CDMA TP and I'm fully aware that you cannot flash a GSM radio into it. However, if this radio firmware is just for the GPS, shouldn't it work on any of them including the Sprint model? Please clarify. Thanks a bunch. I'd sure be lost completely without these forums!
crimo
27th December 2008, 03:39 PM
Forgive me for being stupid, but...... I'm unsure if the radio you refer to is the entire radio or just the GPS radio? Reason I ask is that I have a Sprint CDMA TP and I'm fully aware that you cannot flash a GSM radio into it. However, if this radio firmware is just for the GPS, shouldn't it work on any of them including the Sprint model? Please clarify. Thanks a bunch. I'd sure be lost completely without these forums!
Hey,
special GPS Radios doesnīt exist. Thats allways the entire radio. And you canīt flash a GSM Radio on a CDMA version !
mjj2332
28th December 2008, 02:20 AM
My Raphael is running on PROVEN rom.
It get a fix very fast, very good gps signal reception, the gps lag is still there...
maw
28th December 2008, 03:55 PM
Dudes
I lost my GPS! Only Google Maps can find it, no other program! Can someone post me their complete registry file ASAP for the GPS ?? I think something corrupted my registry file. Thanks!!!
maw
28th December 2008, 07:08 PM
Never mind... I hard resetted my device and reinstalled everything
Sleuth255
28th December 2008, 07:46 PM
My Raphael is running on PROVEN rom.
It get a fix very fast, very good gps signal reception, the gps lag is still there...
I'm really interested to see what this looks like. Anyone want to post a vid?
COF23
28th December 2008, 09:31 PM
Just got the Fuze last night. Hardspl it and Running NATF rom 3.2. Decided to do a side by side comparison with my stand alone GPS ( tom tom one XL-s ). Fuze running Tom Tom Mobile Navigator. Set up both gps to go same place and running them at 200% speed. Started them in same time ( actually the stand alone had head start by sec.) GUESS WHO WON.... THE FUZE!!! It arrive at the location 4 MINS. faster than the stand alone. No lag or what so ever On the Fuze. Everything was buttery smooth.
Ronaldob
28th December 2008, 10:19 PM
A lot of people have problems with the TouchPro GPS especially for pedestrian use...
From stock the TP GPS is quite unsable in car especially with TomTom 7 and totally unusable for pedestrian use.
After 2 weeks of reading and testing tweaks, here are the results of my tests and the applied tweaks to enhance the GPS performance
A. With Advanced config 3.2 http://www.touchxperience.com/fr/outil-de-configuration-avancee/telechargements/40-advanced-configuration-tool-downloads/9-advanced-configuration-tool-32-cab.html
1. disable A-GPS
2. disable GPS logging
3. logfile name must be empty
4. old logfile name must be empty
5. maximum size of logfile must be 0
6 delete the files : \windows\GPSLogFile.txt and \windows\GPSLogFileBack.txt
7. it seems that if TomTom is installed on a fast microSD decrease the lag(have to test to be sure)
With those changes car usage will be quite perfect
B. Then edit registry with TotalCommander http://ghisler.fileburst.com/ce/tcmdpocketarm.cab
Under: HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\
- Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000)
- Drivers\InputBufferSize -> 512 (default is 4096)
- Drivers\OutputBufferSize -> 512 (default is 4096)
- Drivers\SleepOnNoData -> 100 (default is 1000)
- Multiplexer\MaxBufferSize -> 512 (by default not present, you have to create it)
Tests to be done with buffers at 256...seems to be a little better
Tests to be done with other PollInterval value...seems to "drain" battery
With those tweaks pedestrian usage will be much better but not perfect...I explain.
You have to walk for a least 250m in order to have a reposition with mouvement on the map (before that, speed is always 0km/h) and then if you continue to walk there is quite no lag...and the speed reflect reality
...BUT if you stops you have to walk again for a least 250m in order to have a reposition with mouvement on the map and then if you continue to walk there is quite no lag...
Very strange indeed...
I hope this will help people...please test and feedback.
PS : tests were done with
TomTom_Navigator_7.450.9028_R3_VGA_black_edition
GoogleMaps 2.2.0.16 -- http://www.google.be/gmm/GoogleMaps.CAB
GPSTuner 5.4 -- http://www.gpstuner.com/download/GPSTuner_v5.CAB
I've made almost all the steps above, but I don't know how to create the registry "MaxBufferSize". Could you help me?
whyfish2001
3rd January 2009, 12:01 AM
I tried to be systematic about the changes. I made the registry changes one at a time and checked between each change, to see which change really made the difference. (This is because I have the feeling that the changes are guesses whose side-effects aren't well understood. I don't think they are all necessary.) I systematically tried some of the other changes I found on reading the voluminous posts and listed my results below (it would be so nice if everyone listed their phone, their rom, their software, etc... so the group testing could be somewhat systematic (and doubly nice if peole wouldn't post fluff like "I'll try this soon").
-----------------------
Phone:
HTC Sprint Touch Pro
ROM 1.03.651.3 (stock rom)
Radio 1.03.15F
GPS Software:
TomTom 6.032
Googlemaps 2.2.0.19
Lag:
Lag is about 1 to 1.5 seconds second.
Things that didn't work:
1. Changing the log file per the instructions:
> 1. disable A-GPS
> 2. disable GPS logging
> 3. logfile name must be empty
> 4. old logfile name must be empty
> 5. maximum size of logfile must be 0
> 6 delete the files : \windows\GPSLogFile.txt and \windows\GPSLogFileBack.txt
2. The following changes didn't seem to make any difference, and I decided keep the original values.
> - HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\SleepOnNoData -> 100 (default is 1000) --- The discussion at (http://forum.xda-developers.com/showthread.php?p=3013753) suggests this is a bad setting, anyway.
> - HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Multiplexer\MaxBufferSize -> 512 (by default not present, you have to create it)
3. Changing the baud rate on COM 4 made no difference. I tried rates from 4800 to 384000.
Things that worked (more or less):
1. Using an external TomTom Bluetooth GPS fixes the problem.
2. HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000) -- this change made the most difference. It made things better, but didn't fix the lag completely.
3. - HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\InputBufferSize -> 512 (default is 4096)
- HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\OutputBufferSize -> 512 (default is 4096) --- these two changes made very little (if any) difference. But I decided to keep them.
Conclusions:
0. No one has done very careful tests. It's the blind leading the blind here. Caveat Emptor.
1. Not likely to be a CPU usage issue (per http://forum.xda-developers.com/showthread.php?t=420460). I don't expect (but I am not 100% certain) that fetching the data from an external GPS versus fetching it from the internal chip should make a difference to the CPU usage.
2. Some of the registry fixes are an improvement, but not a complete fix. There is still a significant lag of roughly .5 - .75 seconds.
3. Using an external bluetooth GPS is much better, so I think it's a hardware or communication buffer issue.
4. Tests with googlemaps are difficult, because I have registration (i.e. alignment) problems. Sometimes, it seems that the maps are offset and sometimes not. I wouldn't recommend using googlemaps for tesing.
Things I'd like to know:
1. Can this be reproduced on other stock Sprint TPs ?
2. Some people report that things are completely fixed.
Are you really getting no lag at all?
It is the tip of the arrow in Tomtom or the middle of the arrow that is aligned with where you are?
Does your real position and GPS-indicated position match at all speeds?
3. Does the \Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000) change change the batter drain?
gemballa2
4th January 2009, 07:54 AM
My GPS is still not working, and its starting to tick me off.
I followed all the steps listed, however, I could not delete the \windows\GPSLogFileBack.txt file. Not sure if thats why its not working
I installed VisualGPSce and it shows that there are 7 satelites in view, but it will not lock on to any of them. Any one have any ideas why?
It's a Touch Pro from Telus if that makes any difference.
Smaniac
4th January 2009, 05:25 PM
After the changes suggested my lock time went from 30-40 seconds to 10-15, that alone makes a huge difference.
About that lag I couldn't test it yet, because I always use the GPS with the phone under the dashboard, so the signal isn't very strong anyway. But it seems more stable.
I have to buy a windshield mount to be able to test it.
I suspect it's all because of the poll interval. I'm a little worried about battery life after that, but that's a minor issue since I have a car charger.
Thank you very much for your tips, they were great!
Sleuth255
4th January 2009, 08:01 PM
Maybe we need to standardize this as well. Might I suggest the following test:
Auto speed 50 KpH (about 35MPH). When car goes by street, start stopwatch. When map shows going by street, stop stopwatch. How many seconds is your lag?
Mine is essentially zero. My map position updates 3-4 times/second. Using TomTom v7.450.9028 VGA.
pajaa
4th January 2009, 09:05 PM
Maybe we need to standardize this as well. Might I suggest the following test:
Auto speed 50 KpH (about 35MPH). When car goes by street, start stopwatch. When map shows going by street, stop stopwatch. How many seconds is your lag?
Mine is essentially zero. My map position updates 3-4 times/second. Using TomTom v7.450.9028 VGA.
Hi
will you be so kind to start your stopwatch when you stop the car and stop
the stopwatch when display of speed on TomTom show "0"
Regards
maw
4th January 2009, 09:35 PM
I am starting to agree with your conclusions Whyfish.... Actually the GPS signals transmitted from the sattelites have a built-in inaccuracy designed by the US Defence Department who own the GPS sattelite network. GPS module producers compensate this descrepancy in the GPS chip to adjust the allignment to get a near accurate reading. I'm now wondering if they forgot to compensate this descrepancy in the GPS chip causing the it to give the raw GPS position directly from the satellite without correcting the data to be able to be used in GPS navigation software. Normally there is a descrepancy between 10 and 15 meters. If this is the case, then I think the manufacturer should make a hotfix for the GPS chip to adjust and fix this problem since everything we have tried to remedy this problem doesn't seem to fix the lag problem we are experiencing. It could be that Tomtom and iGO assume that the GPS chip is correcting the descrepancy and their software isn't made to correct it. I'm just guessing that this is the problem we are facing at the moment.
I too would like to know the answers to question 2 from the different users out there that are using Tomtom and/or iGO and have been able to get rid of the lag. What did you do to solve this? Unfortunately a lot of people that fix the problem never report back to others what they did. Lets hope they do now because 1000s of people are facing this problem and its really frustrating! If however my gut feeling is right that the problem is with the chip not correcting the GPS data being received from the sattelites, then HTC better come with a patch or update for the GPS chip a.s.a.p.!!
As far as question 3 goes, I haven't noticed any battery drain at all with this registry tweak, although I'm not getting the results that I had hoped for.....
That's my 2 cents on this matter... I will keep an eye on this thread to see what others reply....
Conclusions:
0. No one has done very careful tests. It's the blind leading the blind here. Caveat Emptor.
1. Not likely to be a CPU usage issue (per http://forum.xda-developers.com/showthread.php?t=420460). I don't expect (but I am not 100% certain) that fetching the data from an external GPS versus fetching it from the internal chip should make a difference to the CPU usage.
2. Some of the registry fixes are an improvement, but not a complete fix. There is still a significant lag of roughly .5 - .75 seconds.
3. Using an external bluetooth GPS is much better, so I think it's a hardware or communication buffer issue.
4. Tests with googlemaps are difficult, because I have registration (i.e. alignment) problems. Sometimes, it seems that the maps are offset and sometimes not. I wouldn't recommend using googlemaps for tesing.
Things I'd like to know:
1. Can this be reproduced on other stock Sprint TPs ?
2. Some people report that things are completely fixed.
Are you really getting no lag at all?
It is the tip of the arrow in Tomtom or the middle of the arrow that is aligned with where you are?
Does your real position and GPS-indicated position match at all speeds?
3. Does the \Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000) change change the batter drain?[/QUOTE]
Sleuth255
4th January 2009, 09:36 PM
Hi
will you be so kind to start your stopwatch when you stop the car and stop
the stopwatch when display of speed on TomTom show "0"
Regards
Yep. I have several seconds of "Speed lag". Is this what everyone is referring to when they say "lag"?
maw
4th January 2009, 09:43 PM
YES!
This is what everyone is referring to and is called GPS lag! For instance when I stop the car it takes 5 seconds for my speed to actually go to 0 km/h on iGO. When driving at 50 km/h, the moment I actually passed an intersection is shown 3-4 seconds after I have already passed it on iGO. In Tomtom it is even worse! When driving at higher speeds it makes no difference, lag is still there no matter what speed I'm driving. I must say that the little dot (actual position) is acurate and on the arrow under clear sky, when driving in a built up area or riding through a forest or road with big trees, the blue dot wanders off course....
Sleuth255
4th January 2009, 09:53 PM
Well, how is it that I have "speed lag" but not "positional lag" I wonder? You would think that both would occur if they were due to similar issues :confused: I don't see any delay when driving by cross streets. Maybe this is due to navigation software differences. Perhaps TomTom does a better job of extrapolating position based on speed than iGo does.
edit: I plan on doing an apples-to-apples comparison between my tilt and my fuze itnf. Same version of navigation software, same resolution. This means I'll be testing with TomTom v6.032.8351 with the USA and Canada maps.
maw
4th January 2009, 10:00 PM
Speed lag is the same as positional lag because it takes a couple seconds for it to catch up with actual position. The 2 are joined together! I'm also baffled that you have no lag problems when crossing an intersection if you say you have speed lag problems. It doesn't make sense!
Furthermore, Tomtom works worse by me than iGO hence I don't use Tomtom anymore. It's impossible to navigate with. It can also be that you have a more recent Touch Pro version than others here, one that they maybe have corrected the problem in the GPS chip. What I don't understand of HTC is, why only fix it on new devices and not make a patch or hotfix for the 1000's of Touch Pro's already sold?! I just can't believe they would do this, or could they ?!
Sleuth, the TT version you are going to be testing is not the TT version that everyone is using on the Touch Pro. Everyone is using version 7.910 build 9185 (VGA version). The version you are going to be testing is a QVGA version that is also much lighter than this version that was made for the Touch Pro. So you are making more of an apple and pear comparison than an apple and apple comparison....
Sleuth255
4th January 2009, 10:44 PM
No, I'm making apples to apples. We are testing the GPS chip and whether it is flawed in the TP or not. To do that, you need to use the exact same software. This eliminates software as the cause you see. If results are identical on both devices using the same software then lag=TomTom v7 and we need to bug them & get off HTC's case. I do this sort of stuff for a living btw ;)
That being said, here are the results:
Both devices running same software, same settings and same map. Both turned on in the exact same place inside my house and left to lock.
Both devices locked at exactly the same time. It was almost scary. Interestingly, my Tilt engaged the data connection showing that it was using AGPS to get the ephemeral data.
I immediately noticed that the Fuze had almost a bar better signal strength than my Tilt. This better reception condition persisted throughout the test. I walked the two devices to my car and set them side by side in portrait orientation on the console in front of the shifter of my 2003 BMW (where those useless BMW coffee cup holders retract from).
Testing conditions were as follows: continuous varied speed (to throw any speed averaging algorythims), two types of stops: normal and "jam the brakes on". Area was a subdivision with winding roads and lots of cross streets.
Both devices tracked to cross streets identically. there was no noticible differences in my position on the map while travelling between the two devices. Both devices exhibited "speed lag" on stops. On normal stops, the Tilt would have about 4 seconds of lag and the Fuze about 4-5 seconds. The tilt always hit zero first but the fuze was close behind. Panic stops were different: the Tilt's speed lag remained at about 4 seconds but the fuze shot up to around 8 seconds. Observationally it was interesting to see that the fuze seemed to hang on "1MPH" far longer than the Tilt did. Both tracked down quickly in close step during the rest of the deceleration.
Based on this, my initial working theory is that we are seeing a supported NMEA sentence difference between the two devices with regards to the various speed sentences the two send. Speed is an interesting thing and may be interpreted differently depending on what sentences the two devices may or may not epxress. I'm particularly interested in whether both devices send the $GPVTG sentence (ground speed) or whether $GPVBW (dual ground/water) or neither is being sent. If the fuze isn't sending speed data and the Tilt is then we have our problem: The navigation software needs to interpolate it from positional info on a fuze which would absolutely cause a "speed lag" that would be much more pronounced on panic stops. Positional data is used for map updates which is why both were virtually identical with regards to chart position.
Next up: nmea string logging to see what's really being sent on the two devices.
petard
4th January 2009, 10:59 PM
Finally someone thats knows what they are doing is comparing them!
I don't know what is wrong, but I know for sure the FUZE is worst than my old Tilt at navigation. It could be the TomTom software, but I don't think so because even GPSTest drops the fix a lot.
maw
4th January 2009, 11:26 PM
Great Test Sleuth! Now for the other tests... So far according to your test its not TT that is causing the lag but something with the GPS chip in the Fuse/Touch Pro not interpreting the information fast enough.
pajaa
4th January 2009, 11:27 PM
Well, how is it that I have "speed lag" but not "positional lag" I wonder? You would think that both would occur if they were due to similar issues :confused: I don't see any delay when driving by cross streets. Maybe this is due to navigation software differences. Perhaps TomTom does a better job of extrapolating position based on speed than iGo does.
edit: I plan on doing an apples-to-apples comparison between my tilt and my fuze itnf. Same version of navigation software, same resolution. This means I'll be testing with TomTom v6.032.8351 with the USA and Canada maps.
Hi,
I wrote this in Diamond forum about lag
"as I understand you well( sorry, English is not my native) and as I know, gps devices not using positions to measuring speed, they use "Doppler shift".
You can read about tech specifications of different gps devices that they have accuracy from 0.01m to 10m ( depended of the price) but almost all have accuracy of the speed 0.1mph"
Sleuth255
4th January 2009, 11:32 PM
Ok, both transmit the $GPVTG sentence but there is something veerry interesting about the fuze. Both tests were with the device not moving. Sentence is shown with both devices locked
Fuze:
$GPVTG,nan,T,,M,0.0,N,0.0,K,A*42
http://images46.fotki.com/v1416/photos/4/43626/167477/CapScr0015-vi.jpg
Tilt:
$GPVTG,,T,,M,0.0,N,0.0,K*4E
http://images45.fotki.com/v1426/photos/4/43626/167477/CapScr0002-vi.jpg
Here's a link to the sentence description:
http://aprs.gids.nl/nmea/#vtg
Gotta love that VGA screen btw :D
Here's what's interesting: WTF does the parameter "nan" mean? :confused: That appears to be an invalid argument for this sentence. I wonder if this is forcing navigation software to ignore the $GPVTG sentence altogether... I'll do some digging for this parameter but I've never seen anything like it before...
maw
4th January 2009, 11:35 PM
WOW cool detective work Sleuth! Finally you are nailing the problem on the head! Keep a log of all your work, then you can prove to HTC that there is indeed a f...ing problem with their GPS chip! Hopefully it will force them to fix it!
Sleuth255
4th January 2009, 11:48 PM
It may be even easier (since we can't depend on HTC to do anything)....
The $GPVTG sentence is one of 26 interpreted sentences. This means that the chip may be out of the picture (all it does is report position) leaving us with the raw driver or the intermediate driver. We should be able to nail down which by swapping these out with HTC devices that are working that have the same GPSOne chip. Blackstone leaps to mind here. Anybody with a blackstone want to capture a $GPVTG for us after your device has locked?
What I need to do next is find out if the GPSOne chip does the speed interpretation itself or not. I suspect not because there are devices with the same chip that don't have this issue. It really looks like a software bug in a driver somewhere to me...
maw
4th January 2009, 11:52 PM
Great work Sleuth, if that is indeed the case, then it would be as simple as you are suggesting to by updating the driver or replacing the driver with one that does work. I don't have a Blackstone, but I downloaded HTC GPS Tool and can make a logfile of the information on my Touch Pro if you want. I guess that it makes a .txt logfile??
Maybe its a good idea to post your findings on the blackstone thread and see if you get any reactions! ;)
maw
5th January 2009, 12:13 AM
This is my log:
PGSA,A,3,07,15,24,26,27,,,,,,,,8.7,8.2,2.9*38
$PSTIS,*61
$GPGSV,4,1,13,07,20,060,18,15,35,289,16,24,18,271, 20,26,57,293,17*73
$GPGSV,4,2,13,03,02,014,,06,,,,08,61,060,,10,56,20 5,*43
$GPGSV,4,3,13,19,06,045,,21,12,316,,25,03,063,,27, 67,063,*77
$GPGSV,4,4,13,28,45,135,*47
$GPGGA,230815.6,5111.332617,N,00524.347638,E,1,05, 8.2,109.9,M,0,M,,*7F
$GPVTG,nan,T,,M,0.0,N,0.0,K,A*42
$GPRMC,230815.6,A,5111.332617,N,00524.347638,E,0.0 ,,040109,,,A*4F
$GPGSA,A,3,07,15,24,26,27,,,,,,,,8.7,8.2,2.9*38
$PSTIS,*61
Like yours, I also have the nan reading. Say it is a faulty driver, are you able to rewrite the driver to correct this problem? Is the GPS chip in the Tilt the same as in the Touch Pro? Would the correct working driver from the Tilt work in the Touch Pro since they are working on the same OS? It's just an idea.....
Sleuth255
5th January 2009, 12:15 AM
You know, I'm guessing that the "nan" parameter (googling this in reference to NMEA coding seems to show "NaN" being used by programmers when initializing) only hits when speed is zero. As such its a bug because the first parameter would normally be course which is undetermined at speed=0. The valid parameter display for this condition would be NULL (,,).
This rationale would explain why I observed the "1mph" on TomTom last for so long as well as why it was much more pronounced during panic stops. TomTom was probably rejecting the invalid $GPVTG sentences containing "nan". Eventually it may have timed out and set the speed to zero based on position not changing. Of course this took a few seconds and at 1mph you can travel quite a ways. This would also explain why position on the road seems to track correctly as well as my other observations of my position "snapping back into place" when stopped at an intersection.
maw
5th January 2009, 12:21 AM
Great! You nailed the problem! So it is indeed a fault in the driver code, now how to fix it ? Is it possible to interchange the drivers from the Tilt to the Touch Pro?? It seems that the Tilt has the correct interpretation of the raw data compared to the Touch Pro. We both got the same reading in the Log file, so I would presume it is now indeed an issue with the TP GPS driver.
EDIT: Or maybe it is possible, once we find out for sure, that we can interchange the driver from the Blackstone to the Touch Pro if the nmea log comes up correct on the Blackstone? Just wondering if this is possible and if so, whats the easiest solution since I don't expect HTC to fix this problem anytime soon eventhough the truth is facing them now straight in the eye!
Sleuth255
5th January 2009, 12:25 AM
T...Say it is a faulty driver, are you able to rewrite the driver to correct this problem? Is the GPS chip in the Tilt the same as in the Touch Pro? Would the correct working driver from the Tilt work in the Touch Pro since they are working on the same OS? It's just an idea.....
If we can find the driver that generates $GPSVTG, it may be possible to patch: its signed though and won't load if not signed correctly. A patch would throw off the checksum requiring a re-signing. I could use a developer cert but we would have to load those everywhere (did this on hermes in fact)...
I'm not as aware of the GPS architecture as some others here might be. When we worked on Hermes we wrote a RIL shim to start the gps chip. This may mean that the raw driver is part of the radio and that we only have control over the GPSID. I suspect that there's a third component in SYS or XIP here though.
DA_G's been playing with this pretty extensively. Perhaps he can give us a clue...
maw
5th January 2009, 12:30 AM
hmmmmm sounds more complex then I thought! bummer, on the bright side we know now what the problem is and that's a whole lot since this problem was initially signaled since September! A BIG THANKS!
Maybe it is possible, if you have connections with someone at HTC, to show them your results from your testing and let them make a correct patch? It shouldn't be that difficult for them anymore, they have everything at hand, they just need to patch this sucker!
maw
5th January 2009, 12:41 AM
I PM-ed Da G to check this thread, I hope he will reply!
I'll be keeping my fingers crossed........
Sleuth255
5th January 2009, 12:45 AM
Maybe the radio is responsible. Comparing yours and mine show differences but not major revision changes. The software bug may well exist in both. Could somebody with the latest radio try this test:
Fire up HTC GPS tool, get a lock while your device is stationary then post your log containing $GPSVTG.
I'm also going to test while moving to see if my theory is supported ($GPSVTG will display valid heading info while moving).
Sleuth255
5th January 2009, 12:50 AM
One other thing that's been noted in other GPS threads is the $PSTIS,*61 shown in your log that I also saw. This appears to be proprietary and would (should) be ignored by navigation software but I did notice that there's always a pause afterward. This sentence appears to give no data, perhaps its a request? The *61 is simply the sentence checksum.
Also, I can't say that we know what the problem is. I can say that we have a supported theory at this point however. I need to search for a way to refute it now. Still an anomaly is the fact that many note "positional lag" whereby the crossroad on the map passes by out of sync with the car itself. This fact is not supported by this theory unless one considers software differences. Even then its speculation...
maw
5th January 2009, 12:51 AM
Maybe, but since we have the same results I think the fault may well be in your radio as well. Now that you say, I think this problem persists in the .28 en .32 radio but not in the 20M1 radio?? Could that be possible? None of these radios did it for me, I encountered massive battery drain! This was the original radio that came with my device so I reverted back to it and have excellent battery life now which I find very important as well....
Looking forward to see if your theory is indeed grounded!
Sleuth255
5th January 2009, 01:09 AM
I think I'll flash 20M1 just to see if it changes anything. It's a simple test.
edit1: 20M1 flashed. GPS Test tool is acquiring a signal...
edit2: still no lock... Interesting. I re-ran quickgps and placed my fuze outside. This radio may not be as good as 1.02.25.28 when it comes to warm starting the gps. I'll have to try it for a few days to be sure...
edit3: Lock acquired $GPSVTG still shows "nan". The radio change to the most current version doesn't correct this condition.
rcll
5th January 2009, 01:31 AM
How is 20M1 with regards to GPS? I was considering flashing from .32
ben1do1
5th January 2009, 02:04 AM
http://forum.xda-developers.com/showthread.php?t=467374
ENJOY
mod edit from Sleuth: sorry, but we're working on lag, not lock atm.
Sleuth255
5th January 2009, 02:24 AM
Ok, here's more. I just did two things.
First was refresh my memory from the Hermes GPS project. To get NMEA sentences from that device, we first flashed a Trinity radio. the Trinity was the first HTC device featuring a built-in GPS and it happened to have the same chipset as the hermes. Next, we put in a RIL shim to send the radio AT commands when we opened a port and voila! NMEA data was received. The Hermes was missing GPS antenna circuitry so we never got it to work but the interesting point is this: The radio is what generates NMEA data. Nothing else matters. GPSID is simply a more advanced architecture for the shim we originally wrote.
That being said, I jumped into the car with GPS Test running and went for a drive.
$GPSVTG showed valid heading data as soon as I started moving and when I stopped, "nan" didn't re-appear. The last heading was displayed when speed was zero. More important is this: The speed lag was easy to see in the $GPSVTG sentence. It took 4-6 seconds for the speed in the sentence to show 0 and it "stuck" on .9K for several seconds.
To be sure, I need to re-flash my original radio and repeat this step. I've introduced the 20M1 radio as a new variable to this troubleshooting session and that's a no-no.
Soooo... There's still good logic behind the concept that its either the radio or the chip that's causing this. And, it'll be easy to determine!
Blackstone owners say their GPS shows no lag and the Blackstone has the same radio/GPS hardware as our raphaels. If what the owners say is true, my speed lag will disappear when I flash a blackstone radio since all things will be equal from a $GPSVTG perspective. I can do this too b/c my Fuze is security unlocked.
More to come...
Sleuth255
5th January 2009, 02:26 AM
How is 20M1 with regards to GPS? I was considering flashing from .32
Took forever for the first lock but that may be due to it having to cold-start the GPS. Jury is out on this one. Unfortunately, I'm going to load a blackstone radio next so I won't be able to test much.
Sleuth255
5th January 2009, 02:44 AM
Ok, Blackstone radio v1.10.25.25 has been flashed. Good signal strength!
... The suspense is killing me...
Loading up GPS Test tool now. I expect it'll be a while to get a fix while it cold starts...
edit1: Yikes, locked already! Way different experience than the 20M1 radio! $GPSVTG shows "nan". Going for a drive....
edit2: Let's just say this: I'm sticking with this radio.
What I found: The nmea string sequence is completely different with this radio. It wasn't easy to see the $GPSVTG statement from the display because it wasn't always in the same place. So I fired up the Tilt vs. Fuze test again.
At first the results were disappointing. It looked like the speed lag was the worst it had ever been. My Fuze was a full 10 "stop lag" seconds behind my tilt when I started the test. However, as I continued the stop and go driving, my Fuze began to start tracking with my Tilt. At the end of the test, they were damn near lock-step. Looks like the radio can "learn" Doppler data and increase its speed accuracy.
At the end of the test, my Tilt and my Fuze were very close; this was especially noticeable when I was turning onto side streets. Both devices would start "rotating" the display at about the same time (the tilt was a hair faster, about as fast as you can mutter "ba-bing"). This may improve further as I use this more.
My initial conclusions: radio plays a big part in "speed lag" which is defined as the time it takes the navigation software to go to 0 after your speedometer says 0. Effects of this symptom are the gps location indicator going into the intersection when stopped and the indicator "overshooting" a turn onto a side street then "jumping" onto the street as you proceeded down it.
The Radio ROM may also play a big part in warm-start lock time. More as I use this radio over time.
fiuner
5th January 2009, 02:50 AM
Loading up GPS Test tool now. I expect it'll be a while to get a fix while it cold starts...
Have you used QuickGPS to download satellite data? Cold start should not take a long time after that.
rcll
5th January 2009, 03:15 AM
Ok, here's more. I just did two things.
First was refresh my memory from the Hermes GPS project. To get NMEA sentences from that device, we first flashed a Trinity radio. the Trinity was the first HTC device featuring a built-in GPS and it happened to have the same chipset as the hermes. Next, we put in a RIL shim to send the radio AT commands when we opened a port and voila! NMEA data was received. The Hermes was missing GPS antenna circuitry so we never got it to work but the interesting point is this: The radio is what generates NMEA data. Nothing else matters. GPSID is simply a more advanced architecture for the shim we originally wrote.
That being said, I jumped into the car with GPS Test running and went for a drive.
$GPSVTG showed valid heading data as soon as I started moving and when I stopped, "nan" didn't re-appear. The last heading was displayed when speed was zero. More important is this: The speed lag was easy to see in the $GPSVTG sentence. It took 4-6 seconds for the speed in the sentence to show 0 and it "stuck" on .9K for several seconds.
To be sure, I need to re-flash my original radio and repeat this step. I've introduced the 20M1 radio as a new variable to this troubleshooting session and that's a no-no.
Soooo... There's still good logic behind the concept that its either the radio or the chip that's causing this. And, it'll be easy to determine!
Blackstone owners say their GPS shows no lag and the Blackstone has the same radio/GPS hardware as our raphaels. If what the owners say is true, my speed lag will disappear when I flash a blackstone radio since all things will be equal from a $GPSVTG perspective. I can do this too b/c my Fuze is security unlocked.
More to come...
Sounds promising. Other than the underperforming graphics, the GPS problem is definitely a top priority issue for the Raphael. Glad you're on the case Sleuth255 ,) I'll security unlock for Blackstone radios if that's your finding for a solution. Can you see if battery drain becomes a problem with the Blackstone radio? I've read comments about running radios not designed for the device sometimes impacting battery life.
Sleuth255
5th January 2009, 03:28 AM
Have you used QuickGPS to download satellite data? Cold start should not take a long time after that.
Startup procedures between the blackstone 1.10.25.25 and Raphael 1.08.25.20M1 radios were identical: after flashing, I reset then ran QuickGPS.
Sleuth255
5th January 2009, 03:39 AM
@rcll: I'll for sure test battery life with this radio but it'll be a few days before I have enough empirical data to draw any conclusions.
Right now my impression is this for US based users (I'll explain this in a bit):
Load a ROM with the fastest graphics drivers you can find. TomTom should update the map 3-4 times/sec at all times.
Turn off AGPS, enable QuickGPS. This is a Geographical based recommendation and may vary greatly in different parts of the world. In the US, it seems that the AGPS URLs "lock up" my fuze after a fix occurs. The symptoms show as the fix being lost soon after acquisition then acquired again and so on... Conversely, QuickGPS is proven to load good ephemeris data for my location. The accuracy of QuickGPS will be geographical as well since ephemeris data itself varies by geographical location. You need to find a site that QuickGPS can connect to that gives valid ephemeris data for your location. Not sure what the best test for this is yet.
Run the best radio. Right now, it's my initial impression that the Blackstone 1.10.25.25 radio is best with GPS. I may modify this impression over time.
Navigation software may make a difference. Incorrect $GPSVTG sentences may alter the positional accuracy of some navigation software products depending on how they use speed and position data in their tracking algorithms. TomTom v6 is what I tested. I'm about to go back to v7 VGA. I'll post if this changes anything.
If you see a Flags=2 value in HKLM\Drivers\Builtin\GPSID, delete it. Flags=2 tells device.exe that the GPSID driver can be unloaded if inactive. This causes TomTom to need a "kick start" from some other gps software such as VisualGPSce or the HTC GPS tool to acquire a lock when warm starting. It's logical to assume that other navigational software may be similarly affected. Also, if TomTom doesn't see the GPS as a "Built-in GPS Device" then find a ROM with a compatible GPSID. Not sure how many are out there. The one I'm running has this (kudos to Da_G's hard work here btw).
That's all for now...
petard
5th January 2009, 05:19 AM
I have a suggestion.
What if someone wrote a GpsGate (http://www.franson.com/gpsgate/) like program that can translate the incorrect data that the GPS chip is outputting and correct it and output that to applications?
hopper13
5th January 2009, 04:30 PM
Have you used QuickGPS to download satellite data? Cold start should not take a long time after that.
Mine often takes from 1.5 to 9 minutes, even with fresh QuickGPS data.
maw
5th January 2009, 04:57 PM
Sleuth, you've been working hard last night! Sorry I haven't replied until now, the site was down all day! I read everything you posted since last night. I'll wait and see whatelse you post in the meantime about the blackstone radio. Have you managed to contact Da_G and ask him his opinion on this matter or maybe he can help with a solution? My device isn't security-unlocked (warranty issues) so I'm not going to try flashing a Blackstone radio. However now that you have narrowed the problem down to a faulty driver/radio and/or gps chip, I think HTC should come up with a remedy for this problem. We have been waiting for to long and getting no kind of response from HTC on this matter when you have now proven that HTC is at fault here.
I'll check u online later!
Edit: P.S. I checked out what you wrote:
If you see a Flags=2 value in HKLM\Drivers\Builtin\GPSID, delete it. Flags=2 tells device.exe that the GPSID driver can be unloaded if inactive. This causes TomTom to need a "kick start" from some other gps software such as VisualGPSce or the HTC GPS tool to acquire a lock when warm starting. It's logical to assume that other navigational software may be similarly affected. Also, if TomTom doesn't see the GPS as a "Built-in GPS Device" then find a ROM with a compatible GPSID. Not sure how many are out there. The one I'm running has this (kudos to Da_G's hard work here btw).
I don't have this Flag=2 value in my registry.
hopper13
5th January 2009, 05:06 PM
I don't have this Flag=2 value in my registry.
No Flag on my Fuze either.
mindfrost82
5th January 2009, 06:10 PM
Load a ROM with the fastest graphics drivers you can find. TomTom should update the map 3-4 times/sec at all times.
ROMeOS should be sufficient for this requirement right?
I've been using the 1.10.25.25 radio since it came out but I haven't tested GPS much with it. I turned it on this morning and the lag seemed horrible, but I didn't leave it on for very long...and like you mentioned in one of your posts, it seemed to get better the longer you had it on, so I'll have to test that theory as well.
Sleuth255
5th January 2009, 06:37 PM
My current opinion on the "nan" issue is that while it is a bug, it only happens when the GPS first locks. As soon as you start moving the issue goes away and "nan" is replaced by valid heading information. This means that it can't have an ongoing effect on navigational software and so isn't the cause of speed lag.
Another theory that needs to be investigated is raphael hardware revision and its effect on GPS issues. Posters have documented evidence of "recognized hardware problems" that were "being resolved". This throws another wrench into the solution equation. My fuze is brand new with a serial number in the HT846 range. Does it incorporate a "hardware fix" that's missing in earlier versions?
maw
5th January 2009, 06:38 PM
Are these the specs for the GPSOne chip?
- GPS Protocol: NMEA 0183
- Navigation Chip: Qualcomm MSM7201A gpsOne
- Assisted GPS
http://www.qctconnect.com/products/gpsone.html#Technical%20Specifications
Found this one specifically on the chip: http://www.qctconnect.com/products/msm_7201.html
Actually I have no idea who is at fault here, Qualcomm or HTC? I'm thinking both?? Who normally makes the radio's ? The producer of the device or not ?
I found this article on the web with reference to XDA: http://www.wmexperts.com/articles/do_you_have_gps_lag_on_the_tou.html#comment-25201
For those still wondering what lag is? Please look here:
http://forum.xda-developers.com/showpost.php?p=2444726&postcount=1
Edit: My serial number range is: HT834K don't know if this has something to do with it..... Yours seems to be a later model.
fiuner
5th January 2009, 09:30 PM
Sleuth255, Are you saying that you have only so called speed lag, but not position lag at all? I always thought that they are connected and the same thing, but if not, how does that speed lag interfere navigating?
I think the most important thing is to find the solution for position lag while driving, because it can make you miss turns and so on.
It may also be that I have understood something wrong here.
maw
5th January 2009, 09:36 PM
In my opinion, position lag and speed lag are the same, because it takes 4-5 seconds for the navigation to catch up with the actual position. So in that respect, you are correct, they are intwined.
Sleuth255
5th January 2009, 09:38 PM
....For those still wondering what lag is? Please look here:
http://forum.xda-developers.com/showpost.php?p=2444726&postcount=1
That's what's fascinating about this issue. I refer to that explanation as "positional lag". I can't re-create that with any of the tests I've done. I can, however, see "speed lag". Interestingly, both functions are handled by processing different nmea statements. I've verified speed lag as being produced by the $GPVTG sentence. Positional lag would be produced by another sentence $GPGGA (http://aprs.gids.nl/nmea/#gga). It's these two sentences, along with "sticky roads programming" that cause navigational software to move the map.
edit:
If you have "position lag" answer me this: how often is your map being updated? On mine, the map definitely updates (moves) about 3-4 times/second.
maw
5th January 2009, 09:44 PM
So somehow these 2 statements $GPVTG and $GPGGA are somehow not properly being interpreted by the driver to feed the navigation system with the correct data resulting in lag be it speed and/or positional, correct?
Weird.... it would seem that then it should be a simple fix to correlate the data. Looks like it needs a pair of glasses LOL well... if they can fix the the Hubble telescope with a software/driver update, then they sure can do the same with this GPSOne receiver!
fiuner
5th January 2009, 09:47 PM
That's what's fascinating about this issue. I refer to that explanation as "positional lag". I can't re-create that with any of the tests I've done.
So basically you can navigate with no problems? I think that the speed lag alone is a very minor issue, if position is correct while you drive.
It would be good if you could do some tests with a device that has real position lag.
Sleuth255
5th January 2009, 09:53 PM
Yes, I can navigate without issues.
Another question for those with positional lag: Are the voice prompts correctly timed? I've read that the answer is yes. Is this correct?
Sleuth255
5th January 2009, 10:00 PM
So somehow these 2 statements $GPVTG and $GPGGA are somehow not properly being interpreted by the driver to feed the navigation system with the correct data resulting in lag be it speed and/or positional, correct?
Weird.... it would seem that then it should be a simple fix to correlate the data. Looks like it needs a pair of glasses LOL well... if they can fix the the Hubble telescope with a software/driver update, then they sure can do the same with this GPSOne receiver!
Interestingly, if you look at your $GPGGA statement from the log you posted, it places you at 51 11.332617N by 5 24.347638E. I believe that's off the coast of Norway just north of Scotland. :eek:
Mine, otoh, shows 43N by 87W: off the coast of Lake Michigan where I should be.
Maybe there's a bug with that sentence in older raphaels?
edit: no, there's a bug in the software I used to check. Google shows you just south of Eindhoven on the corner of Voor and Kegel
fiuner
5th January 2009, 10:01 PM
Another question for those with positional lag: Are the voice prompts correctly timed? I've read that the answer is yes. Is this correct?
It's not an easy question to answer if you don't have two devices. One with lag and one without. I can't really tell when those voices are really supposed to come out.
In my opinion, it's not just the screen that has the lag.
Da_G
5th January 2009, 10:37 PM
Re: the NaN issue, that got me to thinking, one of the debug apps displays a compass.. so i took a closer look at it, it's for a compass made by a company called akemd... they integrate into devices like mobile phones.. the test program can't connect (not even sure if the device has the h/w, but the debug s/w is there..)
if the gpsdriver is trying to grab heading info from the non functional internal compass, that could explain that, at least. and a timeout initializing might explain the lag.
maw
5th January 2009, 10:58 PM
Yes, this is my exact location! Its in Belgium indeed, just south of Eindhoven.
edit: no, there's a bug in the software I used to check. Google shows you just south of Eindhoven on the corner of Voor and Kegel
On the other hand, I haven't really listened to the voice prompts, I switched off the sound! She was driving me bezerk! But what I remembered they are linked to the distance displayed in the navigation. So if I'm in the program lagging about 50 m, although I passed the intersection I supposed to have turned right in, she will not say my actual position. With other words, the position from the voice prompt is the position u see in the navigation.
So no, they are not correctly timed to actual position but to the position that is being fed to it retarded.
So the data that is coming into the navigation is affecting the correctiveness. This is in TT7 as well as iGO, I tested them both, but TT7 has such an outragous lag I don't use it anymore.
@Da_G: great that you are looking into the matter as well! Say it doesn't have the h/w but the debug s/w is affecting the functionality, wouldn't it be best to disable this debug s/w or will this really screw things up? Sorry, I'm just thinking rational here, I'm not a pro.....
Sleuth255
5th January 2009, 11:30 PM
Voice lag in sync with position lag eliminates graphic drivers as causal.
Since I've never experienced positional lag, I can't say if the blackstone radio fixes it.
However, I'm beginning to think that a quiet hardware fix is involved. I have no problems with voice prompts (other than John Cleese who's delivering them... I stick with him b/c the kids die laughing when he's talking).
I'm beginning to believe that "speed lag" is a red herring since I see it on my Tilt as well. Position lag would drive me crazy if I had it.
So what does that leave us with?
If somebody with position lag could perform the following test then we would have an answer:
Remember: I've never had position lag. I can post a YouTube if you don't believe me.
Sooo, the test is simple: Load up my exact ROM/Radio:
Da_G 2.04 with the 1.02.25.28 radio. Now load TomTom v7 VGA and drive.
Got Position lag?
yes=hardware: HTC made a quiet change to the later devices (my bet is here).
no=software: ROM/Radio is the culprit.
maw
5th January 2009, 11:50 PM
LOL I had John Cleese as well on TT but I changed to Joe Pesci hahahaha but since he was off I kinda ended up in arguments with him who could swear the most hahahaha Too bad you can't get those voices with iGO....
About loading up your ROM and radio, I think I will pass on that one. Maybe someone else that has no problems about warranty and so forth is willing to do the test and see if the issue is h/w or s/w related. Would be interesting to know if they did the test on a lower serial number series as I believe that they maybe have indeed made a quiet fix/change in later models. I just don't get it though, why do it like that and admit you had a problem with the other devices and issue a fix?? Just doesn't make sense.....
Now you know how annoying position combined with speed lag feels like... I think I will grow accustomed to it after a while, just make sure u look at the screen and then look at the road and judge from there, but thats not the way its suppose to work and especially not when you paid 600 euros for it!
petard
6th January 2009, 12:02 AM
I have the stock AT&T ROM and Radio (ROM 1.95.502.5 WWE Radio 1.02.25.32) with TomTom 7.910 (9185) and I have a ridiculous amount of lag. About 3-4 seconds of positional AND speed lag.
My S/N is HT844K915XXX and my P/N is 99HEYXXX
maw
6th January 2009, 12:14 AM
I remember someone asking here in the forum about which serial number series everyone had that had issues with GPS and those that didn't have issues. I can't seem to find the thread in this maze. But I think that there is some truth in the matter that the newest serial numbers don't have any problems anymore? Could be...
I have HT834K and I have both issues you have, positional AND speed.....
PeteNewt
6th January 2009, 12:45 AM
I've done a test with two devices, side by side: Raphael with stock ROM and .28 radio and a Polaris. Both with TomTom (Raphael with the VGA version). At higher speeds the voice instructions are more behind on the Raphael than at lower speeds. At one point (while slowing down from 120km/h to 50 or so) they were even sync while there was still a positional and speed lag on the Raphael.
Now I've adjusted the A-GPS settings as explained here: http://forum.xda-developers.com/showthread.php?t=444700&page=27:I get a fix within mins, inside my home. Tomorrow I'll do a driving test.
Sleuth255
6th January 2009, 02:14 AM
I'm going to create a youtube showing the tests I performed. It'll feature my fuze and my Tilt, side by side running the same version of TomTom with shots out the side windows when I pass side streets. Then I'll load your rom/radio configuration, maw and re-test. Heck, Da_G is churning out ROMs like a man possessed so I'm used to flashing a new ROM every other day... :)
I'm really starting to believe that its a hardware issue that was corrected by a later change. These tests will definitively determine wtf is going on IMHO.
AllTheWay
6th January 2009, 03:05 AM
I'm going to create a youtube showing the tests I performed. It'll feature my fuze and my Tilt, side by side running the same version of TomTom with shots out the side windows when I pass side streets. Then I'll load your rom/radio configuration, maw and re-test. Heck, Da_G is churning out ROMs like a man possessed so I'm used to flashing a new ROM every other day... :)
I'm really starting to believe that its a hardware issue that was corrected by a later change. These tests will definitively determine wtf is going on IMHO.
Looking forward to your findings ;)
Sleuth255
6th January 2009, 04:55 AM
Hopefully I'll live through the making of the test video: my car's a manual shift and I'll be using the webcam from my laptop (since the phones will be in use for other things).... Maybe I can rig something up with duct tape :rolleyes:
newsflash40
6th January 2009, 05:50 AM
Hopefully I'll live through the making of the test video: my car's a manual shift and I'll be using the webcam from my laptop (since the phones will be in use for other things).... Maybe I can rig something up with duct tape :rolleyes:
I'd be glad to give you some baling wire left over from my last electronics project, which was held together with that and duct tape. :)
Looking forward to your report.
maw
6th January 2009, 07:23 AM
Great! Can't wait to see the video! But please be careful will you?
Da_G
6th January 2009, 07:46 AM
I will donate one (1) slightly used roll of duct tape for your valient effort!
Superluminal
6th January 2009, 11:16 AM
I've got a Touch Pro using the latest rom (for '3' network in oz). My GPS works fine and I use it all the time with TT Navigator 6.
What I have noticed that after a hard reset or rom update the handset cannot get a fix with Navigator 6. What I do is; Set the GPS settings to 4800 baud and com 4 then soft reset (the GPS already has these settings and I'm not sure this does anything but it seems to) then use the Google Maps app to get a fix which can take twenty minutes or longer on this first occassion. Be patient.
After doing this Navigator 6 and Google Maps get a fix in about 2 minutes from then on. I've no idea why this works and discovered it by accident when Navigator 6 stopped working after a rom update.
Sleuth255
6th January 2009, 01:44 PM
You have a "fix issue" which is different from lag. If you don't have lag, would you mind telling us the first 4 digits of your TP's serial number (its under the battery)?
Some things to look for on fixing your problem:
remove flags=2 value if it exists in HKLM\Drivers\Builtin\GPSID
run the most popular radio in the sticky radio thread (1.02.25.28)
Load a ROM that supports the most current GPSID. Da_G is one, there may be others too.
Turn of AGPS
Enable QuickGPS and set for automatic updates.
You shouldn't need a "kick start" to get an initial fix with TomTom.
maw
6th January 2009, 02:22 PM
Hi Sleuth
I was reading in this other thread all the stuff that Da_G has been researching on the lag issue. I was wondering if you were also tracking this? U can find more information here:
http://forum.xda-developers.com/showthread.php?t=444700&page=26
It seems that changing the values in the driver registry have 0 effect on the responsiveness of the GPS. The only value that has effect is the polling.
HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000)
I changed my poll interval from 100 as suggested to 2500. I have to test it and see if this will resolve the lag. Default is 1000, the registry tweak changes this to 250 but this tweak was made for pedestrian mode. I notice that when driving at very low speeds, for instance 15 to 20 km/h like I had to do this morning because of ice and snow on the road, the lag just disappears! If you travel at 40 km/h or more the lag returns. I'm now wondering if changing the poll interval to a higher value will cause the lag to disappear. Maybe because of it polling so much that its not having enough time to process the data. By upping the polling from once every 0,25 sec to once every 2,5 sec maybe it will have an effect on the lagging giving it enough time to process the data correctly?
I'll test it out later on my back home from work and see what effect it has. Otherwise I will go back to default, namely once every 1 second. Can you maybe test this as well and see what effect it has on your device?
Flying Kiwi
6th January 2009, 02:30 PM
You have a "fix issue" which is different from lag.Sounds like the Kaiser WM 6.1 upgrade issue all over again.:mad: Unfortunately TP owners don't have the option of reverting to WM 6.0 but I hope you succeed in getting to the bottom of this Sleuth255. I'm just following this thread with interest having owned a TyTN II since they first came out I was considering upgrading - that is until I found out more about the TP. If HTCs record to date is anything to go on it looks as if there are still further low level driver and software issues preventing these devices from working as well as they should. Your earlier point about there possibly having been a quiet hardware change to address the lag issue is interesting. Maybe there'll be something like the Intel Pentium 90 CPU maths bug recall as a result if you succeed in proving a hardware fault and getting word out to the media:eek:
telegraph0000
6th January 2009, 02:33 PM
Seeing as how we can resize the arrow icon, even superimpose an image of a car on it...wouldn't it be feasible to somewhow change/move the cursor's location up via the sys.txt to compensate for the lag? But that would leave actual location behind, wouldn't it...
Superluminal
6th January 2009, 04:20 PM
@Sleuth
S/N first 4 digits (after HT) 838K. Hard reset the Pro tonight to test and tried the GPS first with Navigator and after more than 45 minutes on my window ledge it was still searching for a valid GPS signal. Ran Google Maps got a fix after 13 minutes and one retry then switched straight to Navigator and it got fix 30 seconds later. Seems more than coincidence.
As for lag I can't swear I don't get it. I use the GPS driving and really only look at the screen when I've slowed down and it may have "caught up". Voice directions appear to be timely. I will try and check more closely.
Sleuth255
6th January 2009, 06:03 PM
Hi Sleuth
I was reading in this other thread all the stuff that Da_G has been researching on the lag issue. I was wondering if you were also tracking this? U can find more information here:
http://forum.xda-developers.com/showthread.php?t=444700&page=26
It seems that changing the values in the driver registry have 0 effect on the responsiveness of the GPS. The only value that has effect is the polling.
HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000)
I changed my poll interval from 100 as suggested to 2500. I have to test it and see if this will resolve the lag. Default is 1000, the registry tweak changes this to 250 but this tweak was made for pedestrian mode. I notice that when driving at very low speeds, for instance 15 to 20 km/h like I had to do this morning because of ice and snow on the road, the lag just disappears! If you travel at 40 km/h or more the lag returns. I'm now wondering if changing the poll interval to a higher value will cause the lag to disappear. Maybe because of it polling so much that its not having enough time to process the data. By upping the polling from once every 0,25 sec to once every 2,5 sec maybe it will have an effect on the lagging giving it enough time to process the data correctly?
I'll test it out later on my back home from work and see what effect it has. Otherwise I will go back to default, namely once every 1 second. Can you maybe test this as well and see what effect it has on your device?
My poll interval is set at 250. That's 4 times/second.
maw
6th January 2009, 06:50 PM
Okay I tested it at poll interval 2500, I got good results on speeds higher than 50 km/h almost no lag, but at slower speeds the position lag doubled. So then I tested at 1500, lag improved quite a bit but not yet perfect, but almost no visible positional lag. So I reduced it now to 1250. I haven't yet tested it as yet. I hope that this interval will be perfect. I think the settings posted in the first post are really meant for the best results in pedestrian mode. At least that is what I think because at 250 it is perfect for low speeds, no positional lag, speed lag 4-5 seconds. But at high speeds high positional AND speed lag. So I'm guessing 1250 is better.... Will test it out tomorrow morning when I go to work. Not leaving the house tonight... too much ice on the road and its going to be -21 C tonight....
licht77
6th January 2009, 07:05 PM
Hi guys, hi Sleuth!
i am kinda stuck at this point with my GPS... (see http://forum.xda-developers.com/showthread.php?t=466908 and / or http://wiki.xda-developers.com/index.php?pagename=GPS%20Issues )
I use Romeos 1.51 GER (where several users attested that their GPS is working flawlessy) and the same Radio like u (BS 1.10.25.25). Although i tried several other RadioRoms too.
I played with this hint ( http://forum.xda-developers.com/showthread.php?t=427888 ) as well as this ( http://forum.xda-developers.com/showpost.php?p=2894542&postcount=1 ).
Within Romeos, there is no flag=2. I played with GPSGate too - but no constant fix possible.
With the latest config, i managed to get somekind of fix within 5-10min, but it stalls after approx. 1 or 2 seconds. Just like a flashlight, the Satellites jump to green and back to red (3d fix -> no fix -> 3d fix -> no fix etc.). Tried with HTC GPS Tools, GPStest and VisualGPS.
On a short trip with the car it worked "somehow" for 5mins or so (although laggy and jumpy positions) but when traveling faster than 100 km/h the connection is lost (so i dont need to talk about 160 or faster *g*).
I stopped and started GPSGate in order to stop that on/off behaviour... but up from that point there is no GPS fix anymore.
So - before i kick that device away i am graceful for each hint...
maw
6th January 2009, 07:13 PM
Install this program on your internal storage and it will go away. Although it says lag fix, it doesn't fix the lag, it will however fix the problem with the GPS switching on and off, the problem you are having now.
Installeer dit programmaatje op je interne geheugen en het zal jouw probleem oplossen met het aan en uit knipperen van jouw GPS ontvanger. Het repareert, ondanks de naam, niet de "lag"!
licht77
6th January 2009, 07:20 PM
Ill give it a try... what exactly does this tool do? Which registry settings are changed?
maw
6th January 2009, 07:21 PM
I don't really know what it changes. But I had this problem also with the GPS switching on and off the whole time and when I installed this the problem went away! So give it a try....
licht77
6th January 2009, 07:25 PM
Ah ok... the cab contains all the fixes here from omega01: http://forum.xda-developers.com/showthread.php?t=427888
Already applied this manually - but ill give it a shot!
Sleuth255
6th January 2009, 08:03 PM
It's usually having AGPS turned on that causes the problem you describe.
maw
6th January 2009, 08:07 PM
Well... AGPS is turned off, don't know who you posed the question to... Anyway, the cab file fixes the problem so I guess it works. Did you try changing the poll interval and check what effect it has?
Sleuth255
6th January 2009, 08:33 PM
I've not had any reason to change the poll value from 250 actually. I will play with this but I'm more focused on getting the video out to everybody atm. My first run over lunchtime was a bust b/c the camera just shows glare on the two screens during the day. I have a newer "Rightlight technology" logitech cam I want to try and I'll also do a night run which will eliminate the glare but will make it harder to show the car's actual position when crossing side streets. I'll want to do a freeway run as well since it seems that lag gets worse at higher speeds. It should really make any differences between the Tilt and the Fuze much more pronounced if lag does change in this manner. Too bad I have a day job and won't be able to try again for another 2-3 hours... Kinda tough in a recession to explain driving around shooting TomTom on various HTC devices during work hours.
Of course, if they fire me, all I have to do is go to AT&T's mobile devices division and tell them I'm a mod over at XDA. That'll either land me a job or put me in the slammer.... either way its food and a roof over my head :)
maw
6th January 2009, 08:41 PM
Well just be careful and indeed it ain't worth losing your job over it! Besides ATT mobile division you can try land a job with HTC or Qualcomm LOL :) I do think it also has something to do with the polling interval though, I will test it in the morning while driving to work, its 20:40 here at the moment. I just hope it doesn't snow again tonight, the weather here is terrible at the moment! We have an easterly wind blowing subzero temperatures out of Siberia across Europe.... so I'm not going outside if I don't really have to, -21 C is too damn cold!
AllTheWay
6th January 2009, 08:47 PM
Of course, if they fire me, all I have to do is go to AT&T's mobile devices division and tell them I'm a mod over at XDA. That'll either land me a job or put me in the slammer.... either way its food and a roof over my head :)
Really? That's all it takes? Why didn't I try that sooner? BTW I was looking at your signature and noticed the 1.20.25.25 blackstone radio. Do you have a link for that radio? All I have seen is the 1.10.25.25 radio.
Sleuth255
6th January 2009, 08:49 PM
fat fingered it.... DOH!
tr72
7th January 2009, 01:33 PM
hi everyone,
i had the same problem and test a lot of solution. For me the big problem was the fix wich was very long or which never come.
Now my tp works nice with this changement :
- first i change the radio with the 1.02.25.28 (hardspl needed first, no phone or connection problem with this radio)
- i set my gps on 38400 bauds (i did it with gpstest to be sure that the setting stays on 38400)
- agps enabled (i have unlimited data)
- with diamond tweak i put the logfile to 0 (that was tghe setting of a blackstone wich has a very quick fix)
With this setting i now always have a fix in a minute.
Some people use gpstoday, like that they can open the gps everytime to have a quick fix when they launch ggogle map or tomtom... Good for gps but bad for batterie. With the settings I huse I didn't need it.
hope can help someone
tr72
mindfrost82
7th January 2009, 02:03 PM
I'm experiencing the speed lag as mentioned earlier by sleuth and maw.
I'm using the 1.10.25.25 Blackstone radio with the tweaks on the first page and different PollIntervals.
I tried 1250 last night as maw suggested and still noticed it at 50mph. At 30mph it was right on, but once I got to 50+ it started to lag by about a second or so.
1250 is better than it was at 100 or 250, with the lower settings I was getting lag even at 30mph.
maw
7th January 2009, 02:12 PM
Hi Mindfrost
I tried 1250 as well and it improved the lag, but not yet perfect. So I lowered it now to 900. I will see what difference it makes after work, otherwise I will put it back to default 1000. I think the settings in post 1 work only with pedestrian mode but for motorized transport it is terrible. The higher (faster) the polling interval, like 250 (0.25 sec) or 100 (0.1 sec), will force the position to advance while walking, but since you are walking maybe 3 to 4 km/h it has time to adjust your position in the navigation. But if you are travelling in a car at 50 km/h and faster it just can't update it that fast! So by polling at a lower (slower) setting, default 1000 (1 sec) or maybe 900 (0.9 sec) it will adjust to the speed of the car. I will test on the way back home and see what poll interval 900 will do. If it is spot on then I can make some conclusions this evening....
The most perfect solution would be an automatic polling interval feature that will automatically adjust to the speed you are moving thereby assuring that your position is acurately being adjusted in the navigation. Is such a thing possible??
Sleuth255
7th January 2009, 02:20 PM
Ok, I have the comparison video completed. It features a 9 minute drive through the outskirts of Milwaukee WI. At the end of the video, I get the car up to about 100 Km/h (60-65MPH) to see if there's any speed related lag differences between the two devices. Here are some things to note/watch for as you view it:
In a nod to those of you who want to see the test run with current fuze navigation software, my Tilt is running TomTom v6.032.8351 and my Fuze is running TomTom v7.450.9028 VGA edition. My Registry polling interval value is at 250 (poll 4 times/second).
BMW speedometers are set at the factory to read faster than actual speed. Why they do this is a subject of intense debate outside of XDA...
There are several points in the video where I say "mark" or "now" when passing a cross-street. These provide the absolute best way to view and make your own conclusions about any differences between what both devices show and what's happening in real-time. In fact, when I last say this towards the end of the video, you will see a reflection of the intersection's street-light flash by at the same moment. Speaking of intersections, at one point I provide a verbal reference to passing through a large, controlled intersection. My reference is made when the car passes by all the side street ramps as well. You will see what I mean when you view the video.
TomTom 6 postion is the center of the indicator and TomTom 7 is the leading point of the indicator. Again, you will see this for yourself during the video. It's easier to measure lag based tracking differences by watching the side streets tracking from top to bottom on each device's respective map. The absolute best time to view any positional syncronizaton between the two devices by using this technique is near the end of the clip where I am jabbering about POIs being a POS in the US while lots of side streets are going by. :)
IMO, "Speed lag" is well documented by this video and occurs on both devices. The fuze is slightly more pronounced.
sorry about taking the camera off the devices to show the speedometer for a few seconds during the high speed run. I wasn't sure if you were going to be able to read the speed on the displays. As it turns out, you can.
IMO, "Position lag" is non-existant or within the boundries of GPS accuracy for each device. In fact, you'll see that the Tilt actually shows the car passing by intersections before I mark them verbally in a few instances. I feel that the fuze has more overall accuraty from a positional perspective. This may be due to its signal strength advantage.
Speaking of this, note how the fuze signal strength compares to the tilt signal strength throughout the entire video. :eek: This persists even when I swap the two device's positions to eliminate any reception hot-spot advantages.
As far as I can see, my own GSM Raphael is a capapable navagator when using its built in GPS. In fact, its every bit as good (IMHO better) than my Kaiser. After viewing the video, I think you will agree that there's no significant positional lag on either device. This is good news for RALPH1000 owners who do have position lag because it means that there's either an already accomplished software fix or an early revision based hardware issue at the root of the lag controversy. CDMA ralphael owners are a different story however since your hardware isn't identical.
Here's the 9 minute clip. Enjoy the ride!
Tilt/Fuze TomTom comparison (Sleuth's on the road investigating lag) (http://www.youtube.com/watch?v=BFaOFYzfqqQ)
Up next, I test with a ROM/Radio of a poster who reports un-navigatable position lag. If I reproduce the positional lag issue, then (at least one of) XDA developers' awsome ROM chefs have already provided a ROM based fix for GSM raphaels running TomTom v7.450.9028 VGA edition. If I don't get lag then HTC has some 'splaining to do to you older raphael owners... ;)
Sleuth255
7th January 2009, 04:12 PM
@mindfrost82: Could you be referring to "position lag" instead of "speed lag"? I say this because you mention it happening at 50mph. Speed lag is a variance of the displayed navigator speed to the displayed speedometer speed and is best noticed right after you stop your vehicle. Position lag is a variance of the displayed navigator position to your vehicle's actual position and is best noticed when driving at a constant rate by noting side streets or other landmarks.
mindfrost82
7th January 2009, 05:46 PM
@mindfrost82: Could you be referring to "position lag" instead of "speed lag"? I say this because you mention it happening at 50mph. Speed lag is a variance of the displayed navigator speed to the displayed speedometer speed and is best noticed right after you stop your vehicle. Position lag is a variance of the displayed navigator position to your vehicle's actual position and is best noticed when driving at a constant rate by noting side streets or other landmarks.
I guess I have both, but as you stated in your previous post, its not enough to make it unusable for me.
For speed lag, when I come to a stop it'll take 1-2 seconds for iGo to show me at 0mph, which is fine with me. I think my Tilt did the same thing.
For the position lag, it seems to get worse at faster speeds, which is why I referred to it as speed lag. If I'm going 20-30 mph it is almost dead on when I cross a street. I can be crossing a street and look at the screen and it'll show me crossing it too. When I get up past 40mph, then its about 1-2 seconds behind. I'll be completely past the street then look at the screen and it'll show me passing it a second later.
I don't really remember how my Tilt was with position lag, and I might do a test like your's just to see. I know when I used Garmin on my Tilt, it was just as accurate as a Garmin Nuvi. I took a 600+ mile trip with a Nuvi and Garmin running on my Tilt side-by-side and the voice prompts were almost identical in timing.
mindfrost82
7th January 2009, 05:48 PM
Up next, I test with a ROM/Radio of a poster who reports un-navigatable position lag. If I reproduce the positional lag issue, then (at least one of) XDA developers' awsome ROM chefs have already provided a ROM based fix for GSM raphaels running TomTom v7.450.9028 VGA edition. If I don't get lag then HTC has some 'splaining to do to you older raphael owners... ;)
How can you tell if we have a newer version or an older one? Would a serial number help? I'm curious to see if I have an older one or newer one.
Sleuth255
7th January 2009, 05:55 PM
Just look under your battery for the first 3 digits of the serial number. This is the revision number of your device. You can use it to tell how old it is. Mine's in my sig.
Black1982
7th January 2009, 06:02 PM
Hi Mindfrost
I tried 1250 as well and it improved the lag, but not yet perfect. So I lowered it now to 900. I will see what difference it makes after work, otherwise I will put it back to default 1000. I think the settings in post 1 work only with pedestrian mode but for motorized transport it is terrible. The higher (faster) the polling interval, like 250 (0.25 sec) or 100 (0.1 sec), will force the position to advance while walking, but since you are walking maybe 3 to 4 km/h it has time to adjust your position in the navigation. But if you are travelling in a car at 50 km/h and faster it just can't update it that fast! So by polling at a lower (slower) setting, default 1000 (1 sec) or maybe 900 (0.9 sec) it will adjust to the speed of the car. I will test on the way back home and see what poll interval 900 will do. If it is spot on then I can make some conclusions this evening....
The most perfect solution would be an automatic polling interval feature that will automatically adjust to the speed you are moving thereby assuring that your position is acurately being adjusted in the navigation. Is such a thing possible??
I think you are right about this! It would be great if such an app could be made to see if it improves the lag! I still dont think "the lag" has anything to do with faulty hardware!
Mazzel
btprice2001
7th January 2009, 06:10 PM
Just look under your battery for the first 3 digits of the serial number. This is the revision number of your device. You can use it to tell how old it is. Mine's in my sig.
For what it's worth, my Fuze is a HT843, and I am seeing the position lag.
mindfrost82
7th January 2009, 06:18 PM
Mine is HT844
Sleuth255
7th January 2009, 06:39 PM
I think you are right about this! It would be great if such an app could be made to see if it improves the lag! I still dont think "the lag" has anything to do with faulty hardware!
Mazzel
Easy test: load my ROM/Radio config and run TomTom. Got lag?
As you can see in the video, I have no positional lag so it is possible to configure a raphael to eliminate this. We haven't ruled out hardware yet though. To do this we must load ROM/software from a known good device on proven laggy device or ROM/software from a known laggy device on a proven good device.
Navigation software may play a role here as well. I have not tested iGO but other's have reported the same positional lag issues between tomtom and iGO.
Sleuth255
7th January 2009, 06:51 PM
For what it's worth, my Fuze is a HT843, and I am seeing the position lag.
:eek: the perfect case! You are running damn near the same config as me already. Do you use TomTom navigator?
btprice2001
7th January 2009, 06:55 PM
TomTom 6 postion is the center of the indicator and TomTom 7 is the leading point of the indicator. Again, you will see this for yourself during the video. It's easier to measure lag based tracking differences by watching the side streets tracking from top to bottom on each device's respective map. The absolute best time to view any positional syncronizaton between the two devices by using this technique is near the end of the clip where I am jabbering about POIs being a POS in the US while lots of side streets are going by. :)
Are you sure about this? Why would position indication have changed? Obviously if I assume that my position is indicated by the leading point of the arrow, the difference between the indicated position and my actual position would be less. If this is the case, maybe this is why some people are thinking they have more of a lag, ie they're thinking their position should be the center of the arrow. I feel like this isn't the case though; I haven't had a chance to watch your Youtube video yet, but when I turn corners it would seem that my position is indicated still by the center of the arrow but with the position lag. Turning corners is when my position lag is most noticeable/annoying. What do you find when you turn corners? Does your Youtube video show any corners?
Thanks for all of your efforts in looking into this matter. Hopefully there's a solution for all of us!
[Edit] Sorry I didn't see your post. Yes, I am running Tomtom 910.9185.
Sleuth255
7th January 2009, 06:56 PM
Watch it please. It shows everything.
maw
7th January 2009, 08:15 PM
Okay I tested at 900 poll interval, lag was almost gone, now I changed it back to default, almost perfect! So I can conclude the following by trying out all these different polling...
If you are going walking and need navigation, change the poll interval to 100 or 250.
If you are going biking and need navigation, change the poll interval to 500
If you are going with a car, leave the poll interval at default (1000) for best results!
Increasing the poll interval any higher will result in more speed lag but better positional lag.
I think if they came up with an automatic poll interval changer that would adjust to the speed you are going then you would have near perfect results in any scenario. Maybe something the developers can work on...
Going to look at Sleuth's video now!
btprice2001
7th January 2009, 08:22 PM
@Sleuth, watched it. Thanks for doing that btw. When going straight, your position appears to be dead nuts on with the Tilt with no lag in crossing intersections. I don't see any indication even of a difference in position indication between the leading point or center of the arrow. I definitely see more of a position lag then that on my Fuze. (I wish I had kept my Tytn II to make the same comparison you did:o)
As I mentioned before, my position lag is more problematic when making turns. I do see an example in your video that illustrates what I always see; it's the right turn at 2:40. While not as pronounced as what I see on my Fuze, I would consider this an example of position lag. What do you think?
@maw, sorry, what program are you running for these comparisons? Your findings seem interesting.
Sleuth255
7th January 2009, 08:35 PM
That would be the right turn onto davidson road. My thinking is that its speed lag that causes it. I think this way because the car overshoots the position because speed is too high and Tomtom is using both speed and position to plot. As the position changes, TomTom "snaps" the indicator back onto davidson road.
This might also be TomTom 7 related. I'll have to go back and check but I believe that when I originally ran the test with TomTom 6 loaded on both devices I didn't see that issue nearly as pronounced. It might have something to do with VGA refresh as well (4X as many pixels to update).
btprice2001
7th January 2009, 08:38 PM
So you're able to load Tomtom 6 on your Fuze? When I tried to install with the cab I had used on my Tytn II, I got a not intended for device type error.
Sleuth255
7th January 2009, 09:32 PM
Yeah, I had no problems. I believe I have the cab in my v3.0 sleuth kaiser rom (click my sig to link).
maw
7th January 2009, 10:02 PM
I'm using iGO8 version 8.3.2. TT7 is not as acurate as iGO8 and I find the lag within acceptable range as well. In TT7 the lag is too much!
Sleuth, thanks for the wonderful video you made! Consider yourself blessed that you don't have the problems some of are encountering! I did however seem some lagging on the Fuze but like you say, it could be caused by the VGA refreshing.
Flying Kiwi
7th January 2009, 10:34 PM
my Tilt is running TomTom v6.032.8351Thanks for taking the time to produce this video comparison. I do like the sound of that car but I'm surprised it's a manual transmission in America - that must be a rarity. You're running the same TTN version I'm using with my TyTN II but I found running it on the HTC WWE Windows Mobile 6.1 ROM (with the HTC official 1.65.17.56 Radio) resulted in weak (and fluctuating at low speeds) signal reception. The other GPS problem I had was it took ages to get a fix - a matter of several minutes when moving, sometimes still with no fix after 10 mins and at least one minute when still from cold). Since my TyTN II was reverted back to WM 6.0 the GPS is once again excellent. The only problem (and it's a biggie) is that there are no newer maps for TTN 6 and the 'latest' one that I have is very much outdated.
These days stationary fixes from cold out in the open are consistently around 20 ~ 25 seconds and from warm (ie having already run Tomtom at some stage since the PPC had booted) about 4 or 5 seconds (both timed from when the driver has fully loaded and Tomtom starts trying to get the satelite lock). If you want to get even better GPS performance from your Tilt and you haven't already done so, perhaps a WM 6.0 ROM/Radio may offer that - at least if HTCs efforts for devices over this side of the ditch are anything to go by. Turning off POIs on both devices for future video tests will also ensure a fairer comparison. I realise most people are going to want to use 'the latest and greatest' ROMs (many people will imagine the two go together) but I'm just suggesting these ideas as ways to maximise the differences between the Kaiser and Raphael for testing/video 'evidence' purposes.
Sleuth255
7th January 2009, 11:31 PM
Yeah the BMW dealer was all smiles when I ordered it with a manual transmission. Most Americans are more interested in good cup holders than a true driving experience it would seem :rolleyes:
Anyhoo.... one more test to go and we should be able to tell what's causing this.
Sleuth255
8th January 2009, 03:31 PM
@btprice2001:
Let me make sure that I've got your device correct:
AT&T Fuze SN HT843
Da_G 2.03-MSVC
Stock AT&T radio v1.02.25.32
TomTom v7.910.9185
You have position lag that's worse than whats shown in my clip
Try this: change PollInterval to 250 in HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOneDevice
Still have more Position lag than the Video?
I'm going to say that this is the test here. You have almost my exact config and the exceptions shouldn't affect results because of the following points:
I never experienced positional lag with any radio I tested and yours, (1.02.25.32) is almost a dead ringer for the one I was using the most (1.02.25.28). My testing seemed to show that radios affect lock time and overall signal strength but had no effect on lag. So your radio is a wash IMHO.
You are runining the same ROM as me. Da_G already incorporates most of the tweaks I use with the exception of PollInterval above.
I never experienced positional lag with either TomTom version I tested with. It's reasonable to assume that your newer version of TomTom 7 wouldn't introduce lag either.
Let me know what you uncover with the PollInterval change!
edit: I know this is asking a lot for the community, but if you do have more positional lag would it be possible to create a YouTube showing this? Simply set up a camera as I did then say "mark" as you pass side streets. This will show us all the amount of positional lag you are encountering and at what speed.
kk0813
8th January 2009, 03:58 PM
I have the following device,
ATT FUZE
ROM: NATF v4.0
Radio 1.02.25.32
S/N: HT843
I am using Iguidance v3.01 and Copilot Live 7 and I have the exact same lag issue. I am getting the gps fix in just few seconds but while driving I can see clear lag. After seeing your video and reading your post Last night I changed PollInterval to 250 and also to (512) in HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOneDevice and I still have lag.
Actually I tried all the changes that was mentioned in first post
Under: HKLM\SYSTEM\CurrentControlSet\GPS Intermediate Driver\
- Drivers\GpsOneDevice\PollInterval -> 100 (default is 1000)
- Drivers\InputBufferSize -> 512 (default is 4096)
- Drivers\OutputBufferSize -> 512 (default is 4096)
- Drivers\SleepOnNoData -> 100 (default is 1000)
- Multiplexer\MaxBufferSize -> 512 (by default not present, you have to create it)
After testing this PollInteval was changed to 250. but I left every thing else as mentioned above.
Sleuth255
8th January 2009, 04:13 PM
@Flying Kiwi:
I did want to respond to some of the other points you made in your excellent post. You are correct about the WM6.1 Kaiser GPS issues. I found that my Sleuth v3.0 ROM never really suffered from warm-start acquisition issues after the first week or so. I attributed that to the validity of AGPS ephemeris data improving at the site coded into my registry.
My Tilt also hot starts in about 5 seconds and warm starts in less than 2 minutes. Anything over 2 minutes is a "Cold Start" and minimum time will be 5-10 minutes depending on how "lucky" the GPS chip is while it is randomly searching for satellites. Your comment on signal strength differences is interesting though. I didn't know that! Maybe that is why my Tilt seems to under perform in that respect.
Your point about POI settings differences is valid too. I was going to re-run with POI off on both devices but my original side by side TomTom v6 tests ran with identical POI settings as well and there were still no differences. I think that POI affects map re-draw times when there's a lot of POI positions to mark. Its also an easy test for everyone to perform: Turn off POI. Got position lag?
Sleuth255
8th January 2009, 04:18 PM
@kk0813: Evidence is mounting that Positional lag is hardware related. However, perhaps you might want to try this to help us all out:
Follow the link in my signature to my Kaiser Sleuth v3.0 ROM.
On page 1 of that thread, go to the "Recommended Goodies" section and download TomTom v6.032.8351 at the link provided. This is the free, fully functional taster edition of TomTom 6. Install on your fuze then download the test map of your area when it asks.
Fire it up and go driving!
Got Positional Lag?
mindfrost82
8th January 2009, 04:29 PM
edit: I know this is asking a lot for the community, but if you do have more positional lag would it be possible to create a YouTube showing this? Simply set up a camera as I did then say "mark" as you pass side streets. This will show us all the amount of positional lag you are encountering and at what speed.
I might try this and have my Tilt next to it. Mine isn't unusable, but you can notice it.
I have a small handheld camcorder, so if I can position the phones in a good location I can use that to do the video.
I will be using the exact same iGo8 8.3.2 on both phones with the same configuration.
noellenchris
8th January 2009, 04:38 PM
@btprice2001:
Let me make sure that I've got your device correct:
AT&T Fuze SN HT843
Da_G 2.03-MSVC
Stock AT&T radio v1.02.25.32
TomTom v7.910.9185
You have position lag that's worse than whats shown in my clip
Try this: change PollInterval to 250 in HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers\GPSOneDevice
Still have more Position lag than the Video?
I'm going to say that this is the test here. You have almost my exact config and the exceptions shouldn't affect results because of the following points:
I never experienced positional lag with any radio I tested and yours, (1.02.25.32) is almost a dead ringer for the one I was using the most (1.02.25.28). My testing seemed to show that radios affect lock time and overall signal strength but had no effect on lag. So your radio is a wash IMHO.
You are runining the same ROM as me. Da_G already incorporates most of the tweaks I use with the exception of PollInterval above.
I never experienced positional lag with either TomTom version I tested with. It's reasonable to assume that your newer version of TomTom 7 wouldn't introduce lag either.
Let me know what you uncover with the PollInterval change!
edit: I know this is asking a lot for the community, but if you do have more positional lag would it be possible to create a YouTube showing this? Simply set up a camera as I did then say "mark" as you pass side streets. This will show us all the amount of positional lag you are encountering and at what speed.
I'm also using the stock radio & tried to change the polling from 250 to 1000 and no help. I thought that the screen redraw on Garmin Mobile XT was about 1sec so polling at 1000 should sync up. It actually seemed like more lag than 250. As soon as I security unlock my radio, I will load the latest BS radio and see if it makes a difference. OliPro hasn't responded to my PM, so I will donate tonight and give it a go. My radio is ser#HT844...
kk0813
8th January 2009, 05:33 PM
@kk0813: Evidence is mounting that Positional lag is hardware related. However, perhaps you might want to try this to help us all out:
Follow the link in my signature to my Kaiser Sleuth v3.0 ROM.
On page 1 of that thread, go to the "Recommended Goodies" section and download TomTom v6.032.8351 at the link provided. This is the free, fully functional taster edition of TomTom 6. Install on your fuze then download the test map of your area when it asks.
Fire it up and go driving!
Got Positional Lag?
Sorry I didn't find the Recommended Goodies so I installed Tomtom 7.910.9185 and the free map of my region, and went for a drive. I was driving at 40 mph and I still see lag, even at 20 mph. The pollinterval was set to 256.
Sleuth255
8th January 2009, 06:35 PM
I'm also using the stock radio & tried to change the polling from 250 to 1000 and no help. I thought that the screen redraw on Garmin Mobile XT was about 1sec so polling at 1000 should sync up. It actually seemed like more lag than 250. As soon as I security unlock my radio, I will load the latest BS radio and see if it makes a difference. OliPro hasn't responded to my PM, so I will donate tonight and give it a go. My radio is ser#HT844...
fwiw I don't see supported evidence that a radio upgrade cures position lag yet..
cmloo
8th January 2009, 07:51 PM
Hi Sleuth255,
Sorry to be a bit off topic here. Loved your ROMs in the Tytn and TytnII. Are you going to be cooking any for the Touch Pro? Maybe we can have a chance of your clean, fast and minimal GPS lag of your TP?
Thanks
Sleuth255
8th January 2009, 08:20 PM
I would but Da_G is already pretty much doing what I would have done. I'm running his build already. Whether or not this affects position lag is undetermined atm.
mindfrost82
9th January 2009, 03:26 AM
I completely got rid of my speed lag but I still have some positional lag.
As soon as I stop now my cursor in iGo stops and as I slow down its much more accurate.
These are the settings I just tried:
InputBufferSize = 128
OutputBufferSize = 128
SleepOnNoData = 100
Multiplexer MaxBufferSize = 256
PollInterval = 1000
land2634
9th January 2009, 06:19 AM
I am on a Sprint Touch Pro and have positional lag problems. Hoping to find a solution, as I would like this to be reliable for navigation.
maw
9th January 2009, 10:24 AM
Hmmm interesting.... I read in another thread that Da_G tested this and actually came to the conclusion that changing all these settings, except the pollinterval, made no difference whatsoever because the GPSOne chip only checks the pollinterval value and doesn't check the rest. So I think that you are getting better response with the pollinterval set at 1000 rather than 250 or 100.
Read my earlier post with my conclusions regarding the pollinterval.
I completely got rid of my speed lag but I still have some positional lag.
As soon as I stop now my cursor in iGo stops and as I slow down its much more accurate.
These are the settings I just tried:
InputBufferSize = 128
OutputBufferSize = 128
SleepOnNoData = 100
Multiplexer MaxBufferSize = 256
PollInterval = 1000
juwenio
9th January 2009, 01:30 PM
today i phoned htc europe support because i have to return my phone for repairing the g-sensor; by the way i asked if there is also a solution for the gps-lag and he told me that a new rom will come out in the next weeks (there are on testing it actually) and gps will be part of it; i donīt want to comment this statement but maybe a really solution will come :cool: - lets keep our fingers crossed
juwenio
mindfrost82
9th January 2009, 01:59 PM
Hmmm interesting.... I read in another thread that Da_G tested this and actually came to the conclusion that changing all these settings, except the pollinterval, made no difference whatsoever because the GPSOne chip only checks the pollinterval value and doesn't check the rest. So I think that you are getting better response with the pollinterval set at 1000 rather than 250 or 100.
Read my earlier post with my conclusions regarding the pollinterval.
Maybe its just coincidence then, but I still had the speed lag when I had the poll interval at 1000. I was trying the same values you were trying (1500, 1250, 1000, etc) and always had speed lag.
I just changed it down to 200 and I will test it on my way to work this morning (with the other values the same as I mentioned in my other post).
Sleuth255
9th January 2009, 02:36 PM
fwiw, the poll interval on my Kaiser is set to 500 (a value I've never used on my Fuze). I'll run my fuze with that setting and see if speed lag evens out between the two.
I'm unconvinced that the other values have no function. Its supported by MSDN documentation and disassembly investigations with ida, but empherical evidence seems to slant otherwise. Maybe it is a placebo effect, but speed lag should be easy to measure (stop the car, now how long before GPS says zero?).
maw
9th January 2009, 03:46 PM
I'm going to try the polling at 500 as well, I can't remember if I tried this already, but what the heck.....
Great news that HTC will be coming with a new ROM/radio! Lets hope that its true, and that it will help a lot of problems we are having with GPS, battery life, interface, and so on....
mindfrost82
9th January 2009, 04:00 PM
I set the PollInterval to 100 and it made no difference. The other settings seemed to have eliminated my speed lag completely though.
Today I had my Tilt running side by side with my Fuze. Using the DK4 ROM and the 1.71 radio (I think that's what it was). His ROM had all the default GPS settings I believe. Buffers at 4096 and PollInterval at 1000.
For passing intersections there's an obvious difference between the two. The Tilt was almost exact as I passed intersections. However, when I came to a stop sign the Tilt kept going and put me past the intersection whereas the Fuze stopped me in the right position and showed me just before the intersection.
Sleuth255
9th January 2009, 04:59 PM
I'll try your settings during the drive home. I should have results in 2-3 hours when I leave for lunch.
maw
9th January 2009, 05:19 PM
mindfrost, which buffers are you referring to that you have at 4096 ?
These are my settings:
InputBufferSize: 512
OutputBufferSize: 512
SleepOnNoData: 100
MaxBufferSize: 512
PollInterval: 1000
BTW, tested PollInterval 500 and the lag was enormous! So changed it back to 1000.....
Let me know which buffer you have at 4096, ok?
Thanks!
mindfrost82
9th January 2009, 05:22 PM
It was the InputBuffer and OutputBuffer on my Tilt, not my Fuze.
maw
9th January 2009, 05:23 PM
ah okay... I was wondering, so I will try your settings from the Fuze and see what it does. Have to go out now so I can test and report back later.....
EDIT: did you try the buffersize from the Tilt on the Fuze? If so, can you report what setting the buffer to 4096 did with the accuracy? Wouldn't making the buffersize greater increase the data processing of the information better than lowering it?
mindfrost82
9th January 2009, 05:30 PM
ah okay... I was wondering, so I will try your settings from the Fuze and see what it does. Have to go out now so I can test and report back later.....
EDIT: did you try the buffersize from the Tilt on the Fuze? If so, can you report what setting the buffer to 4096 did with the accuracy? Wouldn't making the buffersize greater increase the data processing of the information better than lowering it?
I did try it last night and I don't think it made it any better or worse than when it was at 256 or 512.
I did notice that the phone seemed slower than it was with the lower settings.
EDIT: BTW, which lag was enourmous with the PollInterval at 500? I'm happy with my settings for my speed lag, now I just need to figure out the positional lag.
maw
9th January 2009, 07:57 PM
I just got back, I changed my settings to match yours, and I must say the speed lag is now a lot less, however still have positional lag.... seems that can't be fixed with everything we tried.
I guess we will have to wait until HTC comes with that new ROM and radio to fix the GPS problems....
Edit: What if we put buffers at an even lower setting? Like 64 or 32 ? It might speed up the device... just a thought...
Sleuth255
9th January 2009, 08:16 PM
hmmm... I just finished the test myself and can't say that I'm noticing a lot of difference. We just got 5" of snow dumped on us however and the roads are packed snow. So when the position indicator slid into the intersection it was more often than not because I actually was sliding into the intersection.... :eek:
IOW, it's hard to see speed lag when you actually have it... I'll test more when the roads dry out.
mindfrost82
9th January 2009, 08:29 PM
I'm loading the new PROven ROM which is supposed to have new GPS drivers from the Diamond 2.03 ROM. I'll test it on my way home and see what happens.
maw
9th January 2009, 08:29 PM
Yeah I know the feeling... we have this weather for the last week! You can't really drive on this packed snow, the car goes sliding all over the damn road! Just drive slooooooow and don't make any sudden turns, better yet, don't go on the road if you don't need to!
Sleuth255
9th January 2009, 08:35 PM
I'm loading the new PROven ROM which is supposed to have new GPS drivers from the Diamond 2.03 ROM. I'll test it on my way home and see what happens.
Mine has the diamond drivers. I'd be interested to see if that makes a difference for you...
mindfrost82
9th January 2009, 08:44 PM
The previous versions used the drivers from the Diamond 2.00 OEM ROM, and now his 1.10 version is using the 2.03 Test ROM.
I'm stuck at work for another 2 hours before I can test lol
Da_G
9th January 2009, 08:52 PM
There's basically no difference between 2.03 and 2.00 drivers, all they did was add the 2.03 version string :(
noellenchris
9th January 2009, 09:05 PM
Mine has the diamond drivers. I'd be interested to see if that makes a difference for you...
Where could I get the newer drivers from without them cooked into a rom? Thanks.
I did load the Ausie Radio 20M1 and it finds the sats really quick, though that wasn't my issue. I'm still getting lag. I find it hard to believe its a hardware issue. I've been working on aircraft GPS systems for 19years in the Air Force and have never seen one fail for being slow... It usually cannot find the sats or the Almanac was lost due to dead batteries. Very strange problem indeed...hmm
Maybe the driver from the diamond will help or the latest BS radio. I'm leaning towards the driver.
Sleuth255
9th January 2009, 10:21 PM
Some portions may have to be cooked in since they would be a part of the RIL. GPSID may be cabbable. Its only a device driver.
mindfrost82
10th January 2009, 12:19 AM
My lag was still there with the new PROven version. Oh well, I guess we'll just wait for a hopefully official fix from HTC on this one.
btprice2001
10th January 2009, 02:08 AM
@kk0813: Evidence is mounting that Positional lag is hardware related. However, perhaps you might want to try this to help us all out:
Follow the link in my signature to my Kaiser Sleuth v3.0 ROM.
On page 1 of that thread, go to the "Recommended Goodies" section and download TomTom v6.032.8351 at the link provided. This is the free, fully functional taster edition of TomTom 6. Install on your fuze then download the test map of your area when it asks.
Fire it up and go driving!
Got Positional Lag?
Tried it. I see no difference in position lag with 6 vs. 7.910.
Sleuth255
10th January 2009, 02:37 AM
Looks like hardware to me then. Fixed in HT846. Aside for the radio, you're running an identical config to one I tested and you have position lag. The only thing I can suggest is to go with the 1.02.25.28 radio.
Sleuth255
10th January 2009, 03:11 AM
As promised.
Power usage: about the same as 1.02.25.28
Call quality: crystal clear, seems better than 1.02.25.28
Signal strength: the same or slightly better than 1.02.25.28
GPS lock acquisition time: where this radio really shines! I've never had a fix so fast!
All in all, an awsome radio. If you can get security unlocked, I highly recommend this. Otherwise, 1.02.25.28 is the best I've tried.
X2D
10th January 2009, 06:59 AM
Using my setup below and running GPSTest and locking into a signal before starting iGO (latest), results in a cold start of about 30 seconds tops, warm and hot almost instantly 1-5 seconds max for warm but trying all sorts of different tweaks nothing is fixing the 2-3 second delay when looking at my current position and even my speed appears to be off but i think that just goes with the delay and that my speedometer could just be slightly off (2mph average at ~35-40mph).
Haven't tried disabling TF3D but honestly I doubt it's software at this point.
Ugh! >_>
mindfrost82
10th January 2009, 03:11 PM
If X2D has HT847 with lag and Sleuth has HT846, I'm not so sure its a hardware problem since X2D's should be newer.
Sleuth and maw, have you done it with TF3D disabled? I haven't tried that, I've always had it running. I don't really think that's the issue either, but it could be anything at this point I guess.
Sleuth255
10th January 2009, 03:56 PM
Well X2D, you just blew the hardware theory to pieces... :)
Could you load TomTom Navigator (ftp://xda:xda@ftp.xda-developers.com/Kaiser/ttn_6_032_8351.cab) from this link so we have one less thing to blame?
This should give you:
HT847 Raphael running at least Da_G v2.05
TomTom v6.032.8351
1.02.25.28 Radio
over 2 second position lag
I do not run TF3D btw.
edit: If you are running the latest Da_G then you aren't afraid of hard resetting often. :) Maybe you could help us out with a baseline test: Hard reset but don't run UC (leave your sd card out). Now load TomTom v6 from the link above, get your free map and go driving. Got position lag?
Anyone can try this test btw. If you have a stock rom, reset your Raphael when you see the customizaton will load in 2 seconds dialog.
The only caveat is that you may need to wait forever to get that first fix since customization may load quickgps location URLs. Manually load a gps tool like VisualGPSce (http://www.visualgps.net/VisualGPSce/) and fire it up with your device in a location where it has a clear view of the sky. Disable auto sleep mode then wait up to 10-20 minutes for that first cold fix.
noellenchris
10th January 2009, 04:40 PM
The install w/TT above didn't go well. I found another version 7.910. loaded up and d/l the free map. I will test drive today and report back. I also security unlocked and loaded the newest BS radio. If this doesn't work who knows what it can be. Maybe a driver for the GPS since I'm using NATF's v1.1 rom. I've tweaked it to the max and eventually will update when I have more time. I also defragged my 8g mem card since I have about 6.5g worth of stuff all over it.
X2D
10th January 2009, 05:29 PM
I will be able to conduct more tests later this afternoon, I am currently installing the latest version of Garmin to see what happens, going to test with and without TF3D I doubt a hard reset is going to do anything for me because I keep my phone really tidy and don't install useless stuff, but the things I want to test:
TT 6/Garmin XT/TT 7/iGO 8/OCN8
*-W/ TF3D Enabled/W/ TF3D Disabled
*-before and after a hard reset
*-before and after any applicable registry tweaks?
*-with and without assisted GPS
(Radio - 28, Latest Da_G's)
Because I'm so OCD I have to pre-initialize the GPS via GPSTest after making sure my QuickGPS is updated. Any other suggested apps or tweaks loaded during this sort of test? The application used really so far isn't doing anything for me as far as "Tom Tom is better than iGO or Garmin is better than both", they all have their quirks and they all have a delay in both the speed I'm currently traveling at (could be slightly off on my car's speedometer though), and when I come to a stop it takes ~2-3 seconds average for my GPS to actually think I'm stopped.
Will post tonight if any of the above actually resulted in less or nonexistent "lag".
Sleuth255
10th January 2009, 05:50 PM
Hardware problem theory is back... You may be misunderstanding the kind of lag we're talking about X2D.
Speed lag as you just described it is present everywhere, even on older devices (check my video from this (http://forum.xda-developers.com/showpost.php?p=3132586&postcount=400) post to see it in action on a Tilt). What we're really concerned about here is position lag, whereby your position shown on the device lags behind your real time position as you're driving at a constant speed. You can tell how much this is by starting a stopwatch when you pass a side street then stop it when the position indicator on the map passes by the same side street. Do you actually have 3 seconds of this type of lag?
edit: It may be possible to correct "speed lag". We are currently looking at different registry settings that appear to affect this. I have the tweaks installed on my device and will be driving around a bit this morning now that the roads have dried off.
X2D
10th January 2009, 06:29 PM
Short answer YES
So annoying, I just tried Garmin and it's worse. Tried Garmin on the way to mcdonalds and then on the way back tried iGO again and I dunno. That's what I meant by position lag because you can pass a street and then look at your iGO and 2 seconds later your virtual car passes the street. TF3D disabled, everything above done except for hard reset and I have to go to work in like an hour so I'll do that after work unless you can think of something better to test.
Thats the main issue and position lag will correct everything else as far as speed lag I would assume, it's just picking up that I'm 2 seconds behind where I actually am. When I say speed lag I mean if I'm going 40 constantly for ~2-3 minutes straight (cruise control on a level straight ground), I would ASSUME that it would match 40, but it says 37 the entire time which makes me think about how car speedometers are slightly off sometimes and that the real issue is the positioning. (note I could be wrong about the car thing, still no solid evidence to back that up, I just know on my motorcycle it's way off but it's a known issue)
kk0813
10th January 2009, 06:44 PM
Short answer YES
So annoying, I just tried Garmin and it's worse. Tried Garmin on the way to mcdonalds and then on the way back tried iGO again and I dunno. That's what I meant by position lag because you can pass a street and then look at your iGO and 2 seconds later your virtual car passes the street. TF3D disabled, everything above done except for hard reset and I have to go to work in like an hour so I'll do that after work unless you can think of something better to test.
Thats the main issue and position lag will correct everything else as far as speed lag I would assume, it's just picking up that I'm 2 seconds behind where I actually am. When I say speed lag I mean if I'm going 40 constantly for ~2-3 minutes straight (cruise control on a level straight ground), I would ASSUME that it would match 40, but it says 37 the entire time which makes me think about how car speedometers are slightly off sometimes and that the real issue is the positioning. (note I could be wrong about the car thing, still no solid evidence to back that up, I just know on my motorcycle it's way off but it's a known issue)
Exactly this is what happening with my phone too. I just installed NATF 4.1 this morning. Did a hard reset, also did a reset when customization starts (So TouchFlo 3D is not installed). Installed Iguidance and TOMTOM v7.910.9185. Gps updats the position 2 -3 sec after I pass the street. Also when I make a complete stop, I can still see 20 mph on gps, slowly coming down to 7 mph, 1 mph, and then 0 mph. It's taking 2 - 3 sec to show 0 mph.
X2D
10th January 2009, 06:59 PM
I've never actually had the opportunity to see or use real-time GPS so this whole technology in the palm of my hand is freaking unreal and just being able to do it is a thrill. I can't imagine how cool it would be for it to be spot on with absolutely no delay, I think that's wishing too much and I expect some delay but so far iGO is the most accurate but it might be how far I have my map zoomed. =p~
The most significant thing that just jumps right out at you is when you come to a stop and your gps still thinks you're going, I think every day street driving around my local town is fine. I wonder how this would manage in a really busy busy part of the US where you are doing a lot of stopping and going and you absolutely need to know when to turn right (not 2 seconds later lol). The best thing so far I've found is to instead of just sit there and watch my phone and not the road, is to occasionally (..haha) glance at the road to see incoming intersections and zoom out more on my display to pre-guess which street is actually the right street. Can't forget to look at the road, sometimes the display is just too pretty to look at a dull street.
noellenchris
10th January 2009, 07:37 PM
Sleuth,,, what performance settings you using? File cache, etc? using Adv Config. This lag issue is really boggling. I may try to turn A-GPS back on and use the HTC test and see if I can fine align the GPS. It probably won't work. Also has anyone compared the AT&T Navigator to see if it lags?
Still searching...
Sleuth255
10th January 2009, 08:10 PM
Have I got the only Raphael without position lag? Damn! :confused:
Performances:
file system cache enabled
file system cache size auto
file system filter cache disabled
pnp unload delay 1500
pnp wait I/O delay 1500
glyph cache 32KB
nothing unusual.
Also: aGPS just helps with acquire time. If you're locking in a reasonable time period then QuickGPS, aGPS and your radio are working correctly.
Sleuth255
10th January 2009, 08:13 PM
I've never actually had the opportunity to see or use real-time GPS so this whole technology in the palm of my hand is freaking unreal and just being able to do it is a thrill. I can't imagine how cool it would be for it to be spot on with absolutely no delay, I think that's wishing too much and I expect some delay but so far iGO is the most accurate but it might be how far I have my map zoomed. =p~
How far do you have it zoomed compared to my video? Is your lag different from the video when zoomed at the same level?
Sleuth255
10th January 2009, 08:20 PM
Here's something:
When using GPS test, how fast are the NMEA strings going by on the display? Mine go by so fast you can't read them. This is how fast navigation software would be getting data. If it's got 2 seconds of position lag then its logical to assume that it is reading nmea data that is 2 seconds behind what's being output. So there's 2 seconds of buffered data somewhere.
Sleuth255
10th January 2009, 08:23 PM
It sure would be nice if somebody besides me would post a youtube of TomTom running on a raphael showing position lag... If I see position lag happening during a run like the one I made then maybe I can draw some additional conclusions.
noellenchris
10th January 2009, 08:26 PM
Thanks for your settings Sleuth, pretty close to mine. I changed anyhow to yours. Thanks for having the only working GPS on your TP...lol
Has anyone tried reducing the buffers to 0 or really low? Maybe just the output buffers.
HTC test has the data going by pretty quick. I think it went quicker when I changed to 38400. I think it slowed down when I selected 9600/4800.
I'm going for a quick drive to try TT 7 out for a test.
Sleuth255
10th January 2009, 08:34 PM
I use 115200 whenever I have to use a COM4 setting. TomTom 7 sees me as a built-in GPS due to the diamond GPS drivers however so I don't need to enter a port setting/speed there.
mindfrost82
10th January 2009, 08:35 PM
Here's something:
When using GPS test, how fast are the NMEA strings going by on the display? Mine go by so fast you can't read them. This is how fast navigation software would be getting data. If it's got 2 seconds of position lag then its logical to assume that it is reading nmea data that is 2 seconds behind what's being output. So there's 2 seconds of buffered data somewhere.
Does your's continuously scroll? Mine will scroll until the little window fills up, then its like it pauses for a second or two, then it'll scroll until it fills up again and pause again.
We just got a bunch of snow today, so I won't be able to do a video for a few days, hopefully sometime next week.
I could take a video of my HTC GPS Tool for you though.
Sleuth255
10th January 2009, 08:40 PM
Same here. It should be pausing on $PSTIS which is a proprietary NMEA sentence.
mindfrost82
10th January 2009, 08:43 PM
Same here. It should be pausing on $PSTIS which is a proprietary NMEA sentence.
It pauses there but its also pausing at $GPGSA.
This is inside though, so I don't have a lock.
Sleuth255
10th January 2009, 08:49 PM
Same here with no fix. $GPGSA shows the active satellites when fixed. While writing this, mine obtained a fix and its now only stopping on $PSTIS.
noellenchris
10th January 2009, 08:50 PM
Ok, back from test drive. TT7 had big lag at first, after a few it reduced to about 3sec after each street passing.
I'm changing the input buffers to 256 and the output to 128. Polling is at 250.
I did change to 115 / 57 / 96 etc for the comm settings, it all seems to fill the page the same. I will prime TT7 this time with the HTC tool alone. Then shut it off and give it another test drive..be back in a few.
Sleuth255
10th January 2009, 08:58 PM
Here's something that might provide a clue: When you start up from a dead stop, what heppens:
It takes 2-3 seconds for the map to start moving after you get going.
map starts moving when you do but the lag slowly increases until it reaches a constant delay. Delay is related to speed (less at low speed more at high speed).
edit: wife had an idea: how many bars do you have from a signal strength perspective? Mine's damn near always on 5 as shown in the video.
noellenchris
10th January 2009, 09:01 PM
Here's something that might provide a clue: When you start up from a dead stop, what heppens:
It takes 2-3 seconds for the map to start moving after you get going.
map starts moving when you do but the lag slowly increases until it reaches a constant delay. Delay is related to speed (less at low speed more at high speed).
Map doesn't move right away.
Seems to catch up slowly after coming to a stop. I complete a turn and I can then watch the screen make the turn and catch up.
Sleuth255
10th January 2009, 09:11 PM
Interesting. That points to 2-3 seconds of buffered nmea data that's slowly being read by the navigation software. Remember, even when stopped the nmea sentences are flying by so the map would delay. Let me check my GPSID settings...
edit
hmmm... nothing leaps out except multiplexer buffer size. I'll make a cab of my entire GPS Intermediate Driver key if somebody wants to test.
Theory here is that the buffer is filled up then made available to nav software in last-in last-out order. Buffer contains 3 seconds of nmea strings.
Edit2: Cab of my HKLM\System\CurrentControlSet\GPS Intermediate Driver key along with all subkeys/values is attached. Back yours up because I don't know if it will restore your old settings when you uninstall it. Also, power off then power back on after installing as this will make sure that the reg settings stick and that your GPSID is using them.
Edit3: In fact, to insure that you have only my settings, you should delete your entire GPS Intermediate Driver key before installing this cab.
Da_G
10th January 2009, 09:43 PM
I had experimented with buffer settings before, in my expierience when the buffer is set too low, it ends up starving and the gps disconnects, times out, and reconnects in an endless loop.. i never saw any improvements from it though :(
I was nosing around the RIL driver, and I noticed there's a registry setting it reads that doesn't exist in any ROM i've seen:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL]
"AGPSFeature"=dword:0
It defaults to 0 without a set value, wonder what it's for?
Sleuth255
10th January 2009, 09:45 PM
How does one mess with the buffer settings? Were you referring to multiplexer buffersize or some other setting?
edit: I would expect that FIFO buffering is exactly what noellenchris has perfectly described. Whether everybody else is affected the same way depends on how their experience matches his. As such I would attribute it to the GPSID.
X2D
10th January 2009, 10:33 PM
no matter how far i zoom im still getting a couple second delay from me passing an intersection or making a turn, testing htc gps tool to see if there are any noticable pauses and will report back
Sleuth255
10th January 2009, 10:48 PM
Could somebody experiencing position lag post a reg containing their HKLM\System\CurrentControlSet\GPS Intermediate Driver key along with the sub keys/values.
use dotFred and just export the key then attach. Thx!
Sleuth255
10th January 2009, 11:03 PM
Among the registry values it uses, try checking here:
HKLM\System\CurrentControlset\GPS Intermediate Driver\Multiplexer
You all do have MaxBufferSize set to 256 right?
noellenchris
10th January 2009, 11:14 PM
Among the registry values it uses, try checking here:
HKLM\System\CurrentControlset\GPS Intermediate Driver\Multiplexer
You all do have MaxBufferSize set to 256 right?
it was set to 512.....going to p/u chinese food and will report back.
I changed to 256. Along w/other buffer changes I mentioned above. Be back in 30min....
Sleuth255
10th January 2009, 11:16 PM
Power off/back on (do not just press reset) after making changes to insure that reg settings stick and that the GPSID uses them. Or you can use dotfred to stop/restart the gpsid device.
noellenchris
10th January 2009, 11:46 PM
Ok...good news finally. The position lag is a lot less. Now it's tough to remember when I stopped counting. Was it at the tip of the tomtom arrow...? lol. It's between 1-2sec pos lag.
input buffer = 256
output buffer = 128
max buff =256..
gonna eat my chinese food and will report more. also under usb settings in reg, I changed the serial hardware to enable. I will post details in a few.
It's not perfect but much better. thanks guys..
Da_G
10th January 2009, 11:47 PM
Right, yeah maxbuffersize was what i was referring to.. sorry I was on the road, so didn't want to type it out.. got that no texting while driving law in california now.. lol :P
Sleuth255
11th January 2009, 12:34 AM
I think its the MaxBufferSize value in Multiplexer that may make the most difference. My Tilt doesn't even have this setting. If you halved the value and your position lag is now half of what it was then try 128 and see if you can navigate....
The MSDN for this value indicates that NMEA data is stored there for software that uses the GPSID RAW data (COM port) interface. If TomTom isn't showing a built-in GPS device in your configuration, try setting your baud rate to the max it goes. I use 115200 for my software that uses COM4.
edit: GPSID also parses the NMEA strings itself and makes it available via an API.... VC!
Sleuth255
11th January 2009, 12:44 AM
.. sorry I was on the road, so didn't want to type it out.. got that no texting while driving law in california now.. lol :P
I can't even surf on my fuze while driving... I'd hit something for sure... :o
X2D
11th January 2009, 12:46 AM
I installed your cab and well not the best test yet but im inside a building and can get a fix on more satellites as long as im outside, going to go driving in about twenty min what would changing my baud to highest do over the 38400 that gpstest maxes out at? im still going to try just wondering for technical sake.
petard
11th January 2009, 12:49 AM
I think its the MaxBufferSize value in Multiplexer that may make the most difference. My Tilt doesn't even have this setting. If you halved the value and your position lag is now half of what it was then try 128 and see if you can navigate....
The MSDN for this value indicates that NMEA data is stored there for software that uses the GPSID RAW data (COM port) interface. If TomTom isn't showing a built-in GPS device in your configuration, try setting your baud rate to the max it goes. I use 115200 for my software that uses COM4.
edit: GPSID also parses the NMEA strings itself and makes it available via an API.... VC!
Did you ever try TomTom on the stock AT&T ROM and Radio? If you have lag there but none now, that would mean its a software issue. If you don't have lag there, it is a hardware issue.
DSF
11th January 2009, 12:50 AM
That would be the right turn onto davidson road. My thinking is that its speed lag that causes it. I think this way because the car overshoots the position because speed is too high and Tomtom is using both speed and position to plot. As the position changes, TomTom "snaps" the indicator back onto davidson road.
This might also be TomTom 7 related. I'll have to go back and check but I believe that when I originally ran the test with TomTom 6 loaded on both devices I didn't see that issue nearly as pronounced. It might have something to do with VGA refresh as well (4X as many pixels to update).
Haven't watched the whole video
Man, the lag is still present on your fuze. See 2:41. I got that too on igo, sometimes I have to wait seconds for "updating" when changing the direction.
it could be caused by the VGA refreshing
then Why only on corners/intersections happen that and otherwise is ok?
I think that there is a lag when changing directions. The direction isn't linear anymore, so the software/whatever must recalculate its interpolation
Try an route SIMULATION and you'll see that will be better when changing directions.
On linear routes (constant speed) the delay is not noticeable, because the software can interpolate position based on many variables (don't know all the involved variable, i'm not an expert nor a gps user). But if you have to change directions.. you can see the 'effect' in Sleuth255's video.
Sleuth255
11th January 2009, 12:54 AM
@X2D:
The raw interface (COM4) is completely virtual. The higher the baudrate setting, the faster the navigation software can pull nmea data out of the buffer defined by maxbuffersize in the multiplexer key. We want the navigation software to be waiting on the com port for more data so it is getting position info as its being presented by the GPSOne chip.
The current working theory I've got going is that if the setting is too low then it'll buffer up and you'll get lag/dropped data.
Sleuth255
11th January 2009, 01:00 AM
@DSF: actually, that's speed lag causing the effect. To see position lag, watch the cross streets scrolling by on both devices while I'm travelling at a constant rate. The "high speed run" at the end of the video is a good place to start.
It's within GPS position tolerances because both devices are in lock-step in this respect. Use me saying "mark" to help confirm this. This is especially easy to see on the last time I say "mark" near the end of the clip. You'll actually see the intersection streetlight reflection flash on both devices at the precise time I say mark and they will both show the position going by the cross street I name.
It won't be "perfect" through the entire video because GPS DIOP (accuracy) is 1-3 meters.
Sleuth255
11th January 2009, 01:12 AM
TomTom uses three things to show your positon on the map:
your speed from the $GPVTG sentence
your position from the $GPGGA sentence
"sticky" roads
When I made the right turn on Davidson, $GPVTG showed my heading and speed that was different from my $GPGGA position. This was due to speed lag expressed in the $GPVTG sentence. TomTom's algorithm has to use speed/heading info as well as position info because position precision is constantly changing due to signal. That's the "Dilution of Position" info.
So, I turn onto Davidson but heading/speed from $GPVTG shows me still going west on Greenfield for a while. What's a navigator to do when two sentences disagree? Exactly what you see in the clip: Eventually position data differences override speed/heading and I am "snapped" onto Davidson at the precise location that my Tilt shows me.
"Sticky" roads shows this same programming. Note how both devices run in lock step when I go "Field hopping" with the BMW (I'm on a new road that's not shown on the map). Each tries to keep me on the road then "snaps" me to the position when the difference finally gives it enough weight to make TomTom believe in it.
DSF
11th January 2009, 01:12 AM
@X2D:
The raw interface (COM4) is completely virtual. The higher the baudrate setting, the faster the navigation software can pull nmea data out of the buffer defined by maxbuffersize in the multiplexer key. We want the navigation software to be waiting on the com port for more data so it is getting position info as its being presented by the GPSOne chip.
The current working theory I've got going is that if the setting is too low then it'll buffer up and you'll get lag/dropped data.
I think even 9600 is enough. Will the buffer exceed 9600 bytes / sec in an optimized way?
@Sleuth255 yes, the position is pretty the same on both devices in linear (straight) direction. But when you have to change the direction.. fuze/touch pro is way bellow.
How is speed calculated? (coordinates prev - actual and consumed time between them?)
Edit: ok, we posted the same time :D. Thanks for the explanation.
Sleuth255
11th January 2009, 01:27 AM
Speed is calculated by the GPSOne chip by using a Doppler difference in satellite signals. I'm not knowledgeable on the specific way it accomplishes this. Both my tilt and my fuze have it though(watch the speed indicator on both devices on the clip when I stop). The fuze is more pronounced however.
That tracking artifact when turning onto a cross street may also be display related. TomTom has 4X as many pixels to update on my fuze. Hard to tell. I seem to remember that the 2:41 effect wasn't as pronounced when I tested TomTom v6. I'll have to re-test that. I also need to go driving with the current settings which have been purported to reduce speed lag.
DSF
11th January 2009, 01:30 AM
That tracking artifact when turning onto a cross street may also be display related. TomTom has 4X as many pixels to update on my fuze. Hard to tell. I seem to remember that the 2:41 effect wasn't as pronounced when I tested TomTom v6. I'll have to re-test that. I also need to go driving with the current settings which have been purported to reduce speed lag.
Why don't you try a route simulation? I'm waiting for the results :D.
I've tried on igo and routes simulation are ok (not perfect smooth, maybe due poor graphics drivers or software.. but it's definitely better than 'real-time routes')
X2D
11th January 2009, 01:48 AM
ok so the cab posted above or setting baud rate higher seemed to lessen the position lag somewhat so thanks going to test more
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.