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. _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
