yashsingh1/xdaforums huggingface dataset:
[Touch Pro, Fuze General] Sleuth255:
How to measure lag

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.
[Touch Pro, Fuze General] pajaa:
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
[Touch Pro, Fuze General] Sleuth255:
Yep. I have several seconds of "Speed lag". Is this what everyone is referring to when they say "lag"?
[Touch Pro, Fuze General] maw:
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....
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] maw:
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....
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] petard:
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.
[Touch Pro, Fuze General] maw:
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.
[Touch Pro, Fuze General] pajaa:
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"
[Touch Pro, Fuze General] Sleuth255:
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

Tilt:

$GPVTG,,T,,M,0.0,N,0.0,K*4E

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...
[Touch Pro, Fuze General] maw:
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!
[Touch Pro, Fuze General] Sleuth255:
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...
[Touch Pro, Fuze General] maw:
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! ;)
[Touch Pro, Fuze General] maw:
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,205,*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.....
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] maw:
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!
[Touch Pro, Fuze General] Sleuth255:
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...
[Touch Pro, Fuze General] maw:
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!
[Touch Pro, Fuze General] maw:
I PM-ed Da G to check this thread, I hope he will reply!

I'll be keeping my fingers crossed........
[Touch Pro, Fuze General] Sleuth255:
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).
[Touch Pro, Fuze General] Sleuth255:
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...
[Touch Pro, Fuze General] maw:
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!
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] rcll:
How is 20M1 with regards to GPS? I was considering flashing from .32
[Touch Pro, Fuze General] ben1do1:
Here is the solution to the lock problem on touch pro

http://xdaforums.com/showthread.php?t=467374

ENJOY

mod edit from Sleuth: sorry, but we're working on lag, not lock atm.
[Touch Pro, Fuze General] Sleuth255:
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...
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] fiuner:
Have you used QuickGPS to download satellite data? Cold start should not take a long time after that.
[Touch Pro, Fuze General] rcll:
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.
[Touch Pro, Fuze General] Sleuth255:
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.
[Touch Pro, Fuze General] Sleuth255:
@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...
[Touch Pro, Fuze General] petard:
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?
[Touch Pro, Fuze General] hopper13:
Mine often takes from 1.5 to 9 minutes, even with fresh QuickGPS data.