[FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate

Helge Hafting helge.hafting at hist.no
Thu May 14 18:11:54 CEST 2009


Jozef Siska wrote:
> On Wed, May 13, 2009 at 04:58:20PM +0100, Vasco Névoa wrote:
>> I've tried configuring (via frameworkd's om.py) the chip with a 3000ms  
>> period between samples, and sure enough gpspipe is outputting only one  
>> set of messages per every 3 seconds - so this proves my CFG-RATE  
>> message is correctly delivered.
>>
>> However, I also see that the gpspipe output is... chaotic. Although  
>> the NMEA timestamps are always correct (they skip 3 seconds),  
>> sometimes the messages are delayed and then delivered in batches. For  
>> example, there is nothing for 6 seconds, and both messages are  
>> delivered together.
>>
>> If I set the period to 5.25 seconds, I can see that all the timestamps  
>> coming out of gpspipe end with ".00", which is obviously wrong.
>> Many of the sentences are repeated, like the SW couldn't wait for the  
>> next UBX data block and just repeated the last data block.
>>
>> Who is doing this sample mangling?
>>
> 
> fso-gpsd creates new ("fake") NMEA messages from data that it gets
> throug DBUS from frameworkd... My gues is that frameworkd would not send
> the data more often that once per second.

Ouch.
Having the framework _managing_ the gps (turn on/off, configure,...) is 
fine. But why regenerate the data, what is wrong with pass-through?  The 
more cpu work, the more delays. And the gps may very well be used for 
real-time purposes. And of course, 100% of the cpu is not available, so 
it is hard to know how much extra work is "too much".

> You could try uninstalling fso-gpsd, installing "normal" gpsd and
> somehow persuading frameworkd to not touch the gps (don't konw if
> setting the GPS to off is enough...)

And the ideal fix would be framework support, so you just tell it you 
want 4HZ updates and from then on you get that.


Helge Hafting




More information about the community mailing list