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

[Al Johnson]

On Wednesday 06 August 2008, Andy Green wrote:
> | 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.

Perhaps, but I think I saw similar variation from the same location with the 
SD card removed when the link was first discovered. It may be the GSM, the 
constellation, or a neighbour using some crappy device that spews 
interference too. I might try a few runs with the SD removed to get a 
baseline for variation not attributable to the SD.

> | 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 was thinking more of recording when the reregisters were taking place or 
something. I know we don't have control over it, but I would like to rule it 
in or out as a cause of interference. I wouldn't want you scratching your 
head over further ways to reduce interference from the SD if GSM or some 
other source was now the dominant factor.

> | 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.

It already sleeps 20 after switch off as an attempt to get a properly cold 
start, but I don't know if it's long enough for the ublox chip to lose its 
memory.