Some questions to new SHR images (ubifs, gps)
openmoko at mazikeen.demon.co.uk
Mon Jul 26 00:18:35 CEST 2010
On Saturday 24 July 2010, Neil wrote:
> If you read the SHR wiki page you will find a list of features. The
> ones with a red background are broken. GPS is broken and links to a
> ticket on the SHR bug tracker. GPS not working after suspend is a
> known issue. If you have any insight into the bug (like "it stopped
> working when I upgraded from the x.y.z kernel to the to the2.6.32
> kernel), please post it to that thread.
> Another who has the problem
> : http://wiki.openmoko.org/wiki/SHR
> : http://www.shr-project.org/trac/ticket/1085
I just did some tests on a recently installed shr-u and had no problems
getting a fix, even when trying to provoke a problem. Details:
GTA02A5 with no capacitor on SD clock
shr-full-eglibc-ipk--20100721-om-gta02.rootfs.tar.gz on ext3 mmcblk0p1, no
Time set manually to nearest minute (SIM is outdated so no time via GSM),
timezone Europe/London set by SHR not by me
WiFi off, bluetooth off, gsm antenna power initially off, then on in later
Press power button to resume from suspend
Press power button and use quick settings to disable screen dimming and
suspend since I don't want to have to keep poking the screen to see what's
Use settings app to remove agps data
Start tangogps and put phone by the window, keep watching to see how long it
takes to get a fix.
Shut down tangogps, enable dimming and suspend, manually suspend, and repeat.
The constellation must have been favourable because all 3 tests got a fix in
less than 2 minutes. Just in case there's a problem with restoring agps data I
repeated the tests but without removing the agps data. Again 3 tests, each
with fix in ~45s. I repeated the tests just over an hour later with the gsm
antenna power on in case that made a difference, and hoping the constellation
may be less advantageous, but the results were similar.
Now to try provoking it in a way that used to cause problems...
Delete agps data.
Start tangogps, let it connect to the gps but exit before it has time to get a
Wait, check in settings that the gps is showing 'unknown' for everything, and
that the 'remove agps data' button has appeared. Do not remove the agps data.
Start tangogps and see how long it takes to get a fix.
This used to cause problems by loading invalid almanac and ephemeris data
after powering up the gps. Depending on how lucky you were this could cause
delays in getting a fix, prevent it getting a fix at all, or even cause the
gps to crash and restart, leaving ogpsd rejecting the NMEA data it then
produced as invalid because it wasn't in the ubx format it was looking for.
Either I was very lucky, or that problem is now fixed. Again all 3 tests got a
fix in under 2 minutes.
To some extent I have been lucky in these tests as it is unusual to get a fix
that fast that often in that location. Does anyone have any suggestions as to
how I might reproduce the problems people are reporting? Setting the time to
something significantly incorrect or deliberately corrupting the agps data
should do it, but those shouldn't be normal occurrences.
More information about the community