GPS rework: Please test and report on software fix prior to attempting any hardware fix

[Neil Brown]

On Tuesday August 5, openmoko at mazikeen.demon.co.uk wrote:
> 
> For a bit more consistency of timing, less manual intervention, and enough 
> readings to get an idea of the run to run variation in that location, can I 
> suggest a script? It could do with a timeout when waiting for a fix since 
> with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly 
> forever in some locations!

Thanks for the script.
After wondering for a while why it didn't work at all for me, I
added
   stty min 1 < /dev/ttySAC1

because either frameworkd in FSO or openmoko-agpsui did an
   stty min 0 < /dev/ttySAC1
and that caused grep to exit immediately.

Anyway, I haven't let it run completely yet, but the first result is

d i time
0 0 real 9m 52.15s


Yes, nearly 10 minutes.  This is indoors, but I have had problems
getting a GPS fix everywhere, inside, outside, in a car, in the park.
Once it fixes it tracks OK (though it doesn't recover from going into
a shopping complex and coming out again).

It seems a lot like the originally reported problem, but this is with
a kernel that has the fix and the magic sysfs files:

Linux om-gta02 2.6.24 #1 PREEMPT Tue Jul 29 01:19:38 UTC 2008 armv4tl unknown

I have the wireless going, but GSM is possibly turned off as I killed
frameworkd to make sure it wasn't touching the GPS.

I know someone who I trust to solder the capacitor - should I try that
(if I can get hold of him)?


Another result just came in:

d i time
0 0 real 9m 52.15s
0 1 real 8m 29.79s


These numbers are actually pretty good.  openmoko-agpsui was giving me
1000 or 2100 seconds!

I decided to take out the SD card (and the SIM card) and try again.
(just chat quietly among yourselves while we wait for the first
result).

d i time
0 0 real 5m 14.32s
0 1 real 2m 56.78s
1 0 real 5m 37.79s

Well, that wasn't so bad.  But still not what I hoped for.

I'm wondering if I got a lemon :-(
NeilBrown