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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Wednesday 06 August 2008, Andy Green wrote:
|> | d i   min /  avg / max
|> | 0 0  35.20/ 55.33/144.30   <===
|> | 0 1  37.39/ 77.76/315.76
|> |
|> | 3 0  36.07/ 42.07/ 47.82   <===
|> | 3 1  97.46/173.09/359.69
|>
|> These relative numbers are a bit counterintuitive... it might be worth
|> trying it again from a "very cold boot" but with the script
|
| From experience writing the script I think they look within the normal
range
| of variation for a FR sitting near a window, and that if you increased
PASSES
| the stats for all of the IDLECLK=0  runs would look the same if the card
| wasn't being exercised. I got to see a lot of such apparently
| counterintuitive results before I forced access to the card after
writing the
| sysfs entries! From the same location some runs have a best ttff of ~150s

I guess it means there are "random" accesses to SD Card in background.

| I suspect from a couple of observations that a GSM register may make ttff
| longer, but I don't have any data to back that up - it may just have been
| unlucky. Any ideas on how GSM status could be factored in?

"Make a call and whistle" is what I would do.  But there is pretty much
no latitude (ha) for meddling with what GSM side is going to do.

| I suppose I should post some results too. Note the 2 results where
there seems
| to have been a GPRMC result sitting in a serial buffer or something.

I guess it won't hurt to sleep 3 after turning it off before turning it
back on.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiZeToACgkQOjLpvpq7dMrO4QCeLjWfOXDMVY+7ZgG0EEI8Ewv/
sw4An3067DpkKz4E1LEsGFDh4bz2Z19r
=xr+V
-----END PGP SIGNATURE-----