Thanks for your feedback/tests.<br>Just one question<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">GTA02A5 with no capacitor on SD clock<br>
</blockquote><div>for me this 05 rev means there is a capacitor on µSD . no ?<br>In my case I have a GTA05 with capacitor.<br>I am on shr-u on NAND with kernel 2.6.32 so with Qi too and all uptodate.<br>I will test it like you tomorrow.<br>
CU<br>Sylvain <br><br> <br></div><div class="gmail_quote">2010/7/26 Al Johnson <span dir="ltr"><<a href="mailto:openmoko@mazikeen.demon.co.uk">openmoko@mazikeen.demon.co.uk</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Saturday 24 July 2010, Neil wrote:<br>
> If you read the SHR wiki page[1] you will find a list of features. The<br>
> ones with a red background are broken. GPS is broken and links to a<br>
> ticket on the SHR bug tracker[2]. GPS not working after suspend is a<br>
> known issue. If you have any insight into the bug (like "it stopped<br>
> working when I upgraded from the x.y.z kernel to the to the2.6.32<br>
> kernel), please post it to that thread.<br>
><br>
> Thanks,<br>
><br>
> Neil<br>
> Another who has the problem<br>
><br>
> [1]: <a href="http://wiki.openmoko.org/wiki/SHR" target="_blank">http://wiki.openmoko.org/wiki/SHR</a><br>
> [2]: <a href="http://www.shr-project.org/trac/ticket/1085" target="_blank">http://www.shr-project.org/trac/ticket/1085</a><br>
<br>
I just did some tests on a recently installed shr-u and had no problems<br>
getting a fix, even when trying to provoke a problem. Details:<br>
<br>
GTA02A5 with no capacitor on SD clock<br>
Qi<br>
shr-full-eglibc-ipk--20100721-om-gta02.rootfs.tar.gz on ext3 mmcblk0p1, no<br>
updates<br>
Time set manually to nearest minute (SIM is outdated so no time via GSM),<br>
timezone Europe/London set by SHR not by me<br>
WiFi off, bluetooth off, gsm antenna power initially off, then on in later<br>
tests<br>
<br>
Procedure:<br>
Press power button to resume from suspend<br>
Press power button and use quick settings to disable screen dimming and<br>
suspend since I don't want to have to keep poking the screen to see what's<br>
going on<br>
Use settings app to remove agps data<br>
Start tangogps and put phone by the window, keep watching to see how long it<br>
takes to get a fix.<br>
Shut down tangogps, enable dimming and suspend, manually suspend, and repeat.<br>
<br>
The constellation must have been favourable because all 3 tests got a fix in<br>
less than 2 minutes. Just in case there's a problem with restoring agps data I<br>
repeated the tests but without removing the agps data. Again 3 tests, each<br>
with fix in ~45s. I repeated the tests just over an hour later with the gsm<br>
antenna power on in case that made a difference, and hoping the constellation<br>
may be less advantageous, but the results were similar.<br>
<br>
Now to try provoking it in a way that used to cause problems...<br>
Delete agps data.<br>
Start tangogps, let it connect to the gps but exit before it has time to get a<br>
fix.<br>
Wait, check in settings that the gps is showing 'unknown' for everything, and<br>
that the 'remove agps data' button has appeared. Do not remove the agps data.<br>
Start tangogps and see how long it takes to get a fix.<br>
<br>
This used to cause problems by loading invalid almanac and ephemeris data<br>
after powering up the gps. Depending on how lucky you were this could cause<br>
delays in getting a fix, prevent it getting a fix at all, or even cause the<br>
gps to crash and restart, leaving ogpsd rejecting the NMEA data it then<br>
produced as invalid because it wasn't in the ubx format it was looking for.<br>
<br>
Either I was very lucky, or that problem is now fixed. Again all 3 tests got a<br>
fix in under 2 minutes.<br>
<br>
To some extent I have been lucky in these tests as it is unusual to get a fix<br>
that fast that often in that location. Does anyone have any suggestions as to<br>
how I might reproduce the problems people are reporting? Setting the time to<br>
something significantly incorrect or deliberately corrupting the agps data<br>
should do it, but those shouldn't be normal occurrences.<br>
<br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</blockquote></div><br>