[Captivate Android Development] Rrryan2:
Guh. Complicated questions, not even sure I can answer and still stay within my skill level without BSing excessively. I'm not an expert and I'm hardly a developer relative to most others here. I'm just a motivated amateur with sufficient determination and background experience to have happened upon a configuration that seems to help my GPS and enough others that I thought it worth sharing. But here goes anyway:

Regarding your moving tests:

First of all, for a true "hot start" to apply you really have to be pretty close to the last known position. When moving at vehicle speeds this often isn't the case. And in that sense your moving "warm start" test times are really pretty non-terrible depending on how much time/distance passed between them. Even the maker of your Bluetooth receiver gives a warm start spec of 38 sec: http://amzn.to/hbHjUd

Depending on how it's being handled, if an AGPS update was necessary (or rather, perhaps inappropriately determined to be necessary and initiated anyway) the responsiveness could well be influenced by the quality of your 3G data connection while on the move. And of course, it's unlikely to be the same between successive moving tests...

I don't know what's up with the ephemeris/almanac data recording and without being able to see Samsung's driver source code it's difficult to sniff out. It seems like the AGPS-provided ephemeris data persists up to 4 or so hours like it should *sometimes*, but from what I can tell it doesn't seem like ephemeris and/or almanac data is being properly retained/utilized in all scenarios. Bizarrely, as stated in the OPs some users report better performance if a self-contained GPS app like the AT&T Navigator (just let it sit at the disclaimer screen for 15 min or so) or something like Runnet is used long enough it might properly update ephemeris and almanac in spite of the bad implementation. Such apps apparently (might?) bypass the onboard GPS settings and manage to properly store almanac and ephemeris on their own independent of FUBARed configuration/driver. So, it seems like Samsung's driver for the BCM4571 chip isn't really up to snuff and really isn't always doing all the things a proper GPS controller ought to do, but some apps might be able to bypass this shortcoming. Maybe. Sometimes. Hell, I just work here. Oh, wait...

Of course, it could also be that AGPS data obtained over the data connection isn't being stored/retained/applied properly too, and manually updating the almanac by letting GPS run while in airplane mode every now and again could "force" a complete almanac update. From what I can tell it seems like once AGPS is working the driver gets a little lazy about doing its GPS homework since it thinks it will have AGPS supplement next time around anyway. But to be honest, I haven't experimented with this over a long enough period (it would take several days without using AGPS/SUPL/LBS to test) and I've been working under the assumption so far that getting AGPS and other augmentations properly optimized is probably the best strategy for most users in most scenarios.

As for the SNR seeming to be better on the Captivate: hell, iono. Could be that the silly Samsung driver is mis-computing the SNR reporting for the NMEA sentences. Could be that it's actually correct but the problem(s) are elsewhere. Could be that your BT receiver is just even crappier, or else its positioning (cupholder?) didn't let it work optimally either. ;)

In short, I think Samsung has borked the implementation of the driver at a minimum, and there may be hardware design issues besides. But without being able to see or modify Samsung's closed-source driver there's only so much we can do or determine. My configurations might be able to help at least some users get better performance in the meantime though. That's my story and I'm sticking to it.