Andy Green wrote:

> About the 600sec thing, you can get the GPS chip to report 4 times a
> second instead of once a second, maybe that can be to do with it.  But
> it is strange, noticing the heavy filtering on our results I wonder if a
> lot of those samples coming so quickly were actually synthetic.

It would seem that they are synthetic and have to do with how GPSD 
parses and interprets NMEA sentences. The other two reference receivers 
are put in SiRF mode and don't seem to suffer this effect. Has anyone 
figured out how to kick the GPS receiver into UBX mode? I would be 
curious to see if that changes anything.

> For the last result, it seems to show only 2 / 2500 results from GPS are
> within 20 Million meters of the location.  It's hard to square that with
> the other decent results that have been reported for tracking, including
> ones pulling maps from SD Card, although I guess you are spamming the
> card as hard as you can for this test.

It seems that gpsprof gets a value of 10,000,000,000 for NaN and doesn't 
check if lat/long values are in range before calculating the average. It 
doesn't take very many 10 Billion values to really screw up the average 
:-) I modified gpsprof to toss out invalid lat/long values.

> What actually happened when gpsd died?  With that and the extreme nature
> of the last result I wonder if something else goes on.
> One last thing, the voltage scaling and clock rate reduction patches
> aren't in the kernel you used, they should be around in tomorrow's
> packages: if you have 600 sec to spare it would be interesting to see if
> they made any change :-)

Additional test results (from 20080802) are up at

I did some more testing yesterday after compiling the latest version of 
GPSD for the FreeRunner (it no longer dies when I spam the SDCard... 
that's progress :-) but have not yet got the results pulled together.


Openmoko community mailing list

Reply via email to