On Tuesday August 5, [EMAIL PROTECTED] 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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community