yashsingh1/xdaforums huggingface dataset:
[Touch Pro, Fuze General] btprice2001:
So I finally flashed the 1.10.25.25 Blackstone radio. First I tested with Tomtom using the default reg entries in Da_G's 2.06 rom (should've noted what they were). It might have just been a placebo effect, but I think position lag improved slightly. I feel like time to first fix improved too. I haven't noticed any difference (better or worse) in cell signal strength or battery life. Then I tried these settings:

HKLM\System\CurrentControlSet\GPS Intermediate Driver

CurrentLogFile: blank

MaxLogFileSize: 0

OldLogFile: blank

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

InputBufferSize: 128

OutputBufferSize: 128

SleepOnNoData: 1000

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

PollInterval: 250

Position lag was definitely improved if not completely gone! I seem to remember reading that PollInterval influeces battery life so I then tried increasing PollInterval to 500. Again, position lag definitely improved from before flashing this radio and using these settings, but maybe a little worse than PollInterval 250. PollInterval 500 seems to be very usable for navigation though and I'm going to test more with both values. Is it true that setting PollInterval higher will result in lower battery life?

[Edit] Leaving VisualGPSce running, my current is listed as -272 in TBattery at PollInterval 500 and -267 at PollInterval 250.
[Touch Pro, Fuze General] Da_G:
Got my buddy with a kaiser to do some digging in his radio rom while I dig in the blackstone one, so far i'm not finding any GPS related configurations that are significantly different..

His tilt is configured to use a different AGPS server, and the radio rom doesn't have support for AGPS TLS..

but AT@setgps returns the same, as do a few other gps related commands..

Although I notice a setting the radio rom is pulling from sonewhere, htc_nmea_format, i think its stored in NV though.. so far the only nv related commands i've found is AT+HTCNV? which returns AT+HTCNV=1,12,8 on my ROM.. i broke that down and the params are param1=DTM support, 1 enabled 0 not, param2 = MCS support, valid values 8, 10, 12, and param3 = hsdpa category, valid values 6,8,12.. too bad it doesnt support 10 (hsdpa 14.4)

But i digress.. none of those particular settings are related.. digging further..
[Touch Pro, Fuze General] mindfrost82:
I don't think the aGPS matters. I don't have data with AT&T, and I didn't use aGPS on my Kaiser and I don't on my TP either and my Kaiser is still much more accurate when talking about lag.
[Touch Pro, Fuze General] Da_G:
That's a 10-4, it doesn't matter to our lag problem, hence why I said nothing significantly different.. yet

I'm pretty convinced it's a simple NV bit that needs to be flipped.. for some kind of filtering.. especially since it seems the qualcomm equivilant of static navigation is on..
[Touch Pro, Fuze General] Da_G:
$GPVTG is definitely in the radio rom, I wonder why it doesn't get sent by ms gpsid..

Check out these NV items, we need QPST so bad :P or use RegisterEditor from http://xdaforums.com/showthread.php?t=451646 to dump nv and find address for these values.. so we can write new value :)

NV_AAGPS_DEVELOPMENT_TEST_CONTROL5_I

NV_CGPS_USE_FDIC_I

NV_GPS1_XTRA_ENABLED_I

NV_CGPS_DGPS_CORRECTIONS_ALLOWED_I

NV_CGPS_ALTITUDE_HOLD_MODE_I

NV_CGPS_REFERENCE_MODE_I

NV_CGPS_OPERATION_MODE_I

NV_AAGPS_IPC_DM_THREAD_MASK_I

NV_CGPS_ELEVATION_MASK_I

NV_CGPS_2D_PDOP_MASK_I

NV_CGPS_PDOP_MASK_I

NV_CGPS_MAXIMUM_DGPS_INTERVAL_I

NV_CGPS_STEERING_ON_STARTUP_I

NV_CGPS_MAX_ALMANAC_AGE_IN_WEEKS_I

NV_AAGPS_IPC_DM_THREAD_MASK_I
[Touch Pro, Fuze General] kavi:
Been following this thread for a while and finally got myself a Fuze a few days ago.

Test results.

Radio 1.02.25.32

Tomom 7.910 (9185)

Map USA_Canada V725.1905 - No POI's enabled in MAP

1. Stock ATT ROM/Radio including bloatware + QGPS Updated

Cold Fix 1 - 2 min using gps test

Warm Fix - Under a min

TT7 drops signal every 10 -15 seconds not usable.

2. Stock ATT ROM/Radio + Bloatware + GPS Fixes (in the thread) - QGPS Updated

Cold fix - under a min

Warm Fix - under 30 seconds

TT7 works ok, 100 - 200 yards lag

Google maps works, 100 - 200 yards lag

3. Stock ATT ROM/Radio without running UC + QGPS Updated + AGPS ON (default settings)

Cold fix - under a min

Warm Fix - under 30 seconds

TT7 works, 100 - 200 yards lag

Google maps works, 100 - 200 yards lag

I was surprised to see the TP perform almost identical in scenario 2 & 3

Hope this will help the pros in finding the ultimate solution.

Side by comparison of my 100% Kaiser and TP (Scenario 3) Registry
[Touch Pro, Fuze General] Ninja1:
OK, tested some stuff on the way home from work. Settings are as Noellenchris posted. Tested using iGuidance, which requires a com address and does not "see" the intermediate driver. Also used my Sirf III BT GPS puck as a check for the internal GPS. ROM is DaG 2.06.

Results:

Position in Google and MS Live is now about 30 feet east instead of west (WTF?).

Positional lag is better, but still proportional to vehicle speed and up to 100 feet off at 65mph.

Speed lag is about 3 to 4 seconds.

BT GPS shows the same results as the internal GPS.

So, maybe a graphics driver delay for some of this? iiGuidance does not use D3D, so is running on the unaccelerated 2D drivers. What do you think?
[Touch Pro, Fuze General] kavi:
Correct me if I am wrong but does Live and GMM use D3D? They both have lag issues even on mine.
[Touch Pro, Fuze General] Ninja1:
AFAIK about the only thing that uses the D3D drivers are games.
[Touch Pro, Fuze General] noellenchris:
do they use OpenGL....there's a lot of talk on other posts about this. I'm still looking to reduce the lag w/Garmin.
[Touch Pro, Fuze General] Sleuth255:
There are reports of reduced battery life that I've not been able to verify. What was your maxbuffersize setting in multiplexer?
[Touch Pro, Fuze General] Sleuth255:
It seems to be looking like graphics related lag contribution can be re-visited in light of the fact that different navigation products appear to show lag differently. A good test suggested earlier would be to use route simulation to see the effects of screen updates. Does it look ok when running simulated? Then maybe its GPS related...
[Touch Pro, Fuze General] Sleuth255:
So, I actually observed position lag today. It happened right after I got a fix while I was driving. I was testing some changes that were purported to reduce speed lag. The issue cleared itself up automatically in less than a minute but not before I was able to closely observe it. Visually, when the problem cleared, the map "snapped" to the new position. By "snapped" I'm referring to the updates. If you look at my fuze/tilt comparison video, you can see that the movement of the fuze map is a bit "jerkier" than the Tilt. When my position lag corrected itself, the "jerk" moved the map ahead several hundred yards. I'm reviewing the reg changes now and will attempt to reproduce this again tomorrow.
[Touch Pro, Fuze General] btprice2001:
My maxbuffersize is 256.

Btw, did more testing of pollinterval at 250 on the way home. Position lag seems to be all but gone at lower speeds, but seems to reappear/get worse at higher speeds. My max speed during this drive was probably ~ 30mph. Still the lag was nowhere near as bad as before.
[Touch Pro, Fuze General] btprice2001:
I've meant to ask you about this before but always forget:rolleyes: Have you ever tried to use someone's settings that has position lag to try to reproduce it?
[Touch Pro, Fuze General] Ninja1:
Don't think so. I'll look around and try to figure it out.
[Touch Pro, Fuze General] Sleuth255:
You can bet on that happening now. :)
[Touch Pro, Fuze General] Ninja1:
From whaat I can tell it looks like only the PC versions of iGuidance use D3D or OpenGL. Can't find anything that touts accelerated graphocs on the PPC.

Also, FYI for those who are interested...iNav is unbundling the PC and PPC versions of iGuidance. Thay are now seperate products...time to look for a new GPS program that will run on both platforms.
[Touch Pro, Fuze General] mindfrost82:
My tests have been with iGo and Garmin 5.00.20 (the newest version, whatever that is).

One thing I've noticed with Garmin is that it constantly loses the GPS signal. If you stay on the main screen where the signal bars are you might notice this. While driving I'll go from 5 bars down to 3, then down to 1 red one, then it'll jump back up to 5. If I'm on the map I'll notice it getting stuck then jumping down the road, this is probably when it loses GPS.

I don't have this problem with iGo. It shows the signal strength on the map screen and its always full.

So this could be causing the lag with Garmin if you have the same problems...just no idea why its happening.

My latest test was with:

- PROven 1.11 ROM

- Blackstone 1.10.25.25 radio

- Sleuth's latest cab of GPS tweaks

- Applied to SD TuneUp cab from here

I still had lag with Garmin, but I think its due to the problem I mentioned earlier.

My lag with iGo has probably been cut in half, now its down to about 1/2 second or so.
[Touch Pro, Fuze General] noellenchris:
My Garmin is like that too, I think it did that more when I lowered the polling to 250.

While driving my wife's car tonight, she has a stand alone Garmin unit. I noticed it too has about 2sec lag...lol. I never really noticed. So if I minus that 2 sec lag from my 3-4 sec lag on the TP it's about the same as with TomTom. The lag did seem less on my way home w/garmin on my TP. It's still on 128 for maxbuffersize. I don't really notice a difference between 128 & 256. I may change the polling to 500 again and see how that affects the lag. I think Garmin is updating (map refresh) at about once a sec. Kinda slow compared to iGuidance (my old favorite for routes), TT7 and I used to run a version of MioMap (loved the display and POI's but maps were older and no traffic) MioMap used to run the smoothest on my Hermes w/ext antenna.
[Touch Pro, Fuze General] mindfrost82:
I think my Tilt had a little lag with Garmin too, I just don't like how it keeps dropping the connection, I think that makes it worse.
[Touch Pro, Fuze General] noellenchris:
try changing the polling to 500. It did hold the signal good for me before, something I changed affected it. TT7 is steady with any of my settings. Garmin is finicky.... Wish they would update the refresh so it would be smooth like TT7/MioMap etc.
[Touch Pro, Fuze General] p50kombi:
xperia radio works good

Hey guys.

I'm using the xperia radio, 1.10.25.18

Works a treat, fast lock and almost no lag.

It's still there, using tomtom7, but hardly noticable.

I think I can recognize sleuth's post that sometimes it starts lagging, and then "snaps" to place.

On highway the lag is nearly zero, driving 120 kmh.

When passing under bridge, Tomtom is almost spot on.

In the city ddriving between 30 and 50 kmh, it seems to be lagging a bit.

Using the settings from the cab (manually changed them though, didn't use the cab)

So in short, xperia radio performs great in Holland.

Great battery life as well and good quality.

Using Lantis OS 3.0 RC1 from pfcsabre..

If you want to know anything else, ask me...

Good luck in the search, I hope we'll be able to eliminate lag completely.
[Touch Pro, Fuze General] Sleuth255:
Yep, you can see a bit of that in the video. That's the primary difference between my Raphael and my Tilt. That behavior would lead me to infer that the positional data from $GPGGA was just plain wrong for a while then suddenly corrected itself . I may write a test application to capture &parse fix data then throw up an alert dialog if adjacent $GPGGA sentence change vectors are outside of a given set of parameters. At the speed I was traveling, my position was off 40m or so during the time I was experiencing position lag.
[Touch Pro, Fuze General] hopper13:
HKLM\System\CurrentControlSet\GPS Intermediate Driver

CurrentLogFile: blank

MaxLogFileSize: 0

OldLogFile: blank

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

InputBufferSize: 256

OutputBufferSize: 256

SleepOnNoData: 1000

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

PollInterval: 250

Sleuth,

After applying your cab, I modifed the inputbuffer, outputbuffer and sleeponnodata settings as above. Now when observing (in TomTom 7.9) the process of obtaining satellite reception, I see the signal strength bars as steady instead of going up and down and the time to lock after a reset this morning was under 2 minutes! Position latency seemed negligeble (sub 1 sec). Moving the input/output buffers above 128 seems to have helped a great deal.

Warning - this is emperically derived data with a sample size of ONE! Further testing is needed.
[Touch Pro, Fuze General] mindfrost82:
Alright, with this setup I'm pretty satisfied I think. I have yet to go on the highway to test though.

I did change the PollInterval to 500 as suggested, and now Garmin will hold the signal instead of constantly losing it.

Garmin is pretty even with my Tilt now. I wish Garmin would make an update to make the map flow instead of updating every second or so, but that's a Garmin thing, not the internal GPS.

iGo still has a little lag, but its less than 1 second for me most of the time.

PollInterval = 500

InputBufferSize = 256

OutputBufferSize = 128

SleepOnNoData = 1000

RetryWaitOnError = 3 (I don't think this one has been mentioned before, anyone know what it actually does?)

Mutliplexer MaxBufferSize = 256

MaxLogFileSize = 0

Current & Old Log Files are null

So at this point I'm satisfied, but I'm still willing to test further if any other suggestions come up.
[Touch Pro, Fuze General] pandaboyy:
It's this the Cab that you use?
[Touch Pro, Fuze General] nitroblu:
sorry if this is a repeat question, but based on what I interpreted from you post Sleuth, does this mean that if I am using a ROM with v.20 Diamond drivers, I do not have to apply the .cab you've posted to fix GPS lag? (btw thanks for all your works :))
[Touch Pro, Fuze General] JJKameR:
Something damn wrong with my diamond...

GPS is working good with barely noticeable lag now on both iGo and Tom Tom.

But in Tom Tom instead of showing the satellites bars in the gps screen nothing is shown but position. Btw gps works good. Really better than before.

If it continues working like this I don't care... :D

I was just wondering if I am the only one that has this bug.

This settings in the reg:

HKLM\System\CurrentControlSet\GPS Intermediate Driver

CurrentLogFile: blank

MaxLogFileSize: 0

OldLogFile: blank

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

InputBufferSize: 256

OutputBufferSize: 128

SleepOnNoData: 1000

HKLM\System\CurrentControlSet\GPS Intermediate Driver\Drivers

PollInterval: 250
[Touch Pro, Fuze General] noellenchris:
That happened to me too..lol... haven't found out why though..I will keep playing with settings and see... If the darn thing would just work as advertized! lol
[Touch Pro, Fuze General] Sleuth255:
You do need to apply the cab as well.
[Touch Pro, Fuze General] Da_G:
Did some more gpsdriver.dll debugging..

The radio rom is only spitting out a set of strings once per second. So when the pollinterval is cranked up higher, really we aren't getting a benefit..

Here's the debug output at 500: (2x per second)

17:09:49 [D:GPS] GPS: [ProcessPollData] --- g_hStateChangeEvent Received!
17:09:49 [D:GPS] GPS: [ProcessPollData] GPS data was received.
17:09:49 [D:GPS] GPS: [ProcessPollData] +++ Wait for g_hStateChangeEvent
17:09:50 [D:GPS] GPS: [ProcessPollData] --- g_hStateChangeEvent Received!
17:09:50 [D:GPS] GPS: [ProcessPollData] No GPS data was retrieved!
17:09:50 [D:GPS] GPS: [ProcessPollData] +++ Wait for g_hStateChangeEvent
17:09:50 [D:GPS] GPS: [ProcessPollData] --- g_hStateChangeEvent Received!
17:09:50 [D:GPS] GPS: [ProcessPollData] GPS data was received.
17:09:50 [D:GPS] GPS: [ProcessPollData] +++ Wait for g_hStateChangeEvent

You'll note that when polling twice per second, the gpsid ends up just hanging out on every other poll event, sucking up cycles for no particular reason because there's no data there to be had.

I haven't yet actually tested pollinterval 1000 and 100, but i can imagine at 1000 it'll be getting data every poll event, and at 100 there will be 9 poll events with no data and 1 with data.. but rather than conjecture, i'm off to test now :P
[Touch Pro, Fuze General] Sleuth255:
Interesting. I'm sure seeing nmea data streaming at far faster than one sentence per second though. How to correlate this? Nmea data doesn't appear to be generated within gpsdriver (winhex only at this point, looking for strings). My xp with Hermes shows its generated by either the chip or the radio. Maybe gpsdata available is a buffer full of nmea strings, if so a single miss might cause 1 seconds worth of updates to be lost...
[Touch Pro, Fuze General] noellenchris:
this would explain the Garmin switching back and forth from no sats to sats when set at 250....I'm gonna change from 500 to 1000 and test it out. I think the maxbuffer setting and input/output buffers helped reduce the lag. It would also probably explain the speed lag most are seing... Now if we can figure out how to gpsdriver to tell the radio to spit out 2x a sec or more, I think we'll reduce both speed and position lag! Excellent work ! Thanks.....getting closer..
[Touch Pro, Fuze General] Da_G:
Sleuth255: not 1 sentence per second, one set of sentences per second..

when the gpsid goes to poll, it checks for new data and doesn't find any (because on a poll interface, the data is updated 'all at once' vs. streaming like on a COMM interface)

as for getting the gps unit to spit out more than 1 set of strings per second, i dont think it's gonna be possible, but who knows. at the least we'll need access to the NVRAM to flip some bits.. we've pretty much exhausted all configuration data that is read from the registry.

And yes, it is definitely the radio rom that generates all gps strings, I have been debugging that for a couple days now, which is why i say we have exhausted what we're going to do with registry settings.. AT commands and NV params are what we need to look at now.

While i've been at it I was debugging AGPS process to understand how it works. When GPSMode is set to 1 (MS Assisted) or 2 (MS Based), quickgps data is only used if agps data fails. process goes as follows:

gpsdriver issues at command to radio to poll cellid

radio returns cellid to gpsdriver

gpsdriver looks up following reg keys:

[/code]

[HKEY_LOCAL_MACHINE\SOFTWARE\HTC\SUPL AGPS]

"ServerIP" ; ip address, string

"ServerPort" port, string

[/code]

gpsdriver then sends your cellid info to this server (aka the PDE)

PDE server calculates estimated position based on cell id data and returns this info to gpsdriver

gpsdriver then looks at epheremis data from quickgps and guesses what it should be seeing in the sky from location/epheremis correlation

so people with nonfunctioning agps probably the issue is incorrect serverip/serverport settings, for example on my at&t rom the agps server is set to AT&T's agps server, which is only accessible from GPRS media net connection. so using my rom on another provider would require this to be changed to the proper pde server for that provider (or a public one, there are several, if u dont mind sharing your location data with them)

GPSMode set to 3, EnableAGPS to 0, and EnableReAiding to 0 is only true way to get fully standalone GPS operation - perhaps this should also be tested with the lag since every rom i have looked at has gpsmode set to 2.
[Touch Pro, Fuze General] Sleuth255:
That will affect fix but not lag IMO. Once the chip is tracking birds assisted ephemeris data isn't needed since its getting it directly from overhead satellites.
[Touch Pro, Fuze General] Da_G:
Depends on the mode and the registry settings.. with ReAiding enabled there's a periodic re-injection of assistance data.. with GPSMode set to 1 assistance data is used for every single fix.. but yeah, i agree not likely to affect the lag. just sharing the info since i learned it in the process of digging :)
[Touch Pro, Fuze General] Sleuth255:
It is interesting stuff. I was under the impression that the aGPS server returns precise ephemeris data based on tower info. QuickGPS returns generalized ephemeris data. Both seem to be able to work independently... aGPS should result in consistent hot-starts. I wonder why this isn't the case on GSM but is the case on CDMA...

possible answer?

AT&T aGPS PDE = POS

Verizon aGPS PDE = works as advertised
[Touch Pro, Fuze General] Da_G:
Also check out QOSAccuracy and QOSPerformance under SUPL AGPS.. if you set QOSPerformance to 0 you get no strings other than $PSTIS.. documentation i have for this is old and refers to it being one value that controls the amount of time chip spends searching for sats.. obviously not the case here.
[Touch Pro, Fuze General] btprice2001:
Hi, Da_G. I just flashed your latest rom and I don't have most of these registry entries. Is that normal? Should I just use Sleuth's cab or add them? Specifically I don't have the following in my registry:

MaxLogFileSize

SleepOnNoData

OutputBufferSize

InputBufferSize

MaxBufferSize
[Touch Pro, Fuze General] Da_G:
Yep it's normal, the entries aren't required for it to work, just tweaks to hopefully make it work better :) Add em manually or cab!
[Touch Pro, Fuze General] noellenchris:
Have you tested with QOSPerformance to 0? Do you think this would reduce the lag? Thanks...:)
[Touch Pro, Fuze General] dizzyraider:
What's weird is that when I added those registries either manually or through cab, it breaks my Garmin XT. To get it working again, I had to remove these new registries. I'm running the 2.06 non MSVC version.
[Touch Pro, Fuze General] mindfrost82:
What breaks on it? I had to set the PollInterval to 500 instead of 250.
[Touch Pro, Fuze General] Da_G:
Sure, QOSAccuracy to 0 eliminates position lag entirely.

How you ask? It doesn't report a position at all. LOL

I think this value is used so that if the 'dilution of precision' is too high, it won't report a position at all, until the DOP is low enough to be under the threshhold.. that'd be my guess, but i haven't tested it much yet. Since I don't think that'll help our lag issue.

One thing I observed that might be a coincidence, is that when I got a fix in motion, i had pretty much zero position lag until i stopped at an intersection, and the 'static navigation'-esque feature kicks in that locks your position until you move xx meters away, then starts updating again.. it's not very common to get a fix in motion though.. (fast enough motion not to trigger static navigation)
[Touch Pro, Fuze General] btprice2001:
I've never been able to leave aGPS enabled without getting the problem where the GPS goes back and forth between having a fix and then seeing zero satellites every few seconds. I tried disabling ReAiding and enabling aGPS and so far I have not had any issues! Btw, I left GPSMode at 2. I don't know if my fixes are any faster , but it can't hurt, right?
[Touch Pro, Fuze General] Da_G:
Yes, i'm seeing this behavior too.. in fact I don't think i've seen AGPS function as intended once yet.. this leads me to believe more and more that, like sleuth was saying, AT&T's PDE server is feeding us bogus data..

It might be worth our time to see if a public assistance server actually feeds correct data.. while it's not likely to help with the lag issue, being fed proper AGPS data would certainly help other functionality..

I'm tinkering now :)
[Touch Pro, Fuze General] kk0813:
Iguidance 2009 was announced recently and was scheduled to start shiping from 01/05/2009. I am currently using Iguidance 3.01 and Copilot Live 7, both have old map data. I didn't find much change in Iguidance 4.0 so I skipped upgrading it. IGuidance 2009 (with 2008 Q4 map data) looks interesting, did any one order it yet?

I have speed lag in Iguidance more compared to copilot 7. If screen draw is causing any issue in terms of speed lag, according to IGuidance 2009 site, it uses eGML graphic engine for smooth lines, does it make any improvement in moving the map while driving to avoid speed lag?