[Captivate Android Development] Da_G:
Hey guys :) No, I didn't abandon anyone or the Captivate, just had some crazy busy times and no time to update!

I have not had time to be able to drill down further into this issue than I have already. But I can shed a little bit of light on the discussion since my last post.

Regarding the way the GPS functions, AGPS functions are handled both by the baseband and RIL. There's no problem with the AGPS functionality, it works great. In my testing the problem appears to lie with the GPS chip itself. From what limited information I could glean from broadcom, the chip is a monolithic device that handles all necessary calculations internally. It provides an interface via a typical UART, exposed by the kernel as a node in the /dev tree (the node is referenced in jupiter.xml)

The UART exposes data to the system via an undocumented (without signing an NDA, etc.) protocol called MEIF designed by nokia. The MEIF protocol, from what I can tell seems to pass all relevant data needed to do GPS fix calculation on the client side (ignoring the calculation the chip did) - but this data is only used by the glgps daemon to provide post-processing support (track smoothing via DYN_VEHICLE, etc.)

Neither the GLGPS daemon, the UART itself, or the kernel driver appear to have any issues regarding latency, starvation for CPU cycles, or anything of the sort. The reason I was tending toward an EMI issue is that with proper debugging output from glgps, you can visibly see the signal strengths drop below the "use in fix" threshold, and get dropped from the fix calculation, the moment you bring up my tracks, maps, or several other programs to the foreground. Other programs don't apppear to cause an issue. I was in the process of further narrowing that down when I ran out of time :)

If anyone is going to do any testing on it, i recommend using the following logging settings for the easiest readable output (this is on a 1920x1080 screen w/console maximized): LogPriMask="LOG_EMERG | LOG_ALERT | LOG_CRIT | LOG_ERR | LOG_WARNING | LOG_NOTICE | LOG_INFO | LOG_DEBUG | LOG_GLLAPI | LOG_DEVKF | LOG_DEVCV"

Toggle through various apps while watching the -dBm measurements on each satellite. You can visibly and instantly see the effect of switching to an app that it doesn't get along with. You can also instantly see the effect of switching back to an app that it does get along with. Simulating a high system load in the background (i made a quick app that ran an infinite loop to eat cpu) didn't seem to have an effect, but what was on the screen at the moment seemed to affect it, with the most visible difference being when the app uses the GPU extensively.

FrqPlan allows you to adjust the timings on the TCXO. I found that some frequency plans work better than others in the high GPU usage scenario, but ultimately result in lesser accuracy when in ideal conditions.

Anyway, in summary, with the limited access to knowledge and tools specific to this GPS chip, the claims by broadcom of it's sensitivity, tracking ability, and so forth don't seem to mesh up with what it is doing in the field. For example they claim tracking sensitivity to -162 dBm but in debug output it's clearly visible that tracking is dropping at -155 dBm. Speaking to my device of course, I haven't run the same tests on another SGS.