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

mqy meng.qingyou at gmail.com
Thu May 14 00:00:27 CEST 2009

read this: http://www.nabble.com/GPS-at-4-Hz-td17096809.html

NOTE about "baud rate".  If you can't change it, you can disable some NMEA
messages to make sure 
the default baud rate (9600) is ok for 4hz rate.

On page 106, u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf says:

"... The calculation of the navigation solution will always be aligned to
the top of a second."

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?
> Citando Vasco Névoa <vasco.nevoa at sapo.pt>:
>> Hi all.
>> I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
>> research projects, but ever since I started using FSO and derivatives
>> I can't get it to spit out anything other than 1Hz samples - so I just
>> stop "fso-gpsd", configure the chip at my own will, and read directly
>> from /dev/ttySAC1.
>> However, this is the unfriendly way to do it, and I'd like to
>> integrate this option with FSO.
>> So I found the initialization sequence inside
>> "/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py"
>> and added this to the end of "def initializeDevice", just before the
>> "self.huiTimeout = gobject.timeout_add_seconds( 300,
>> self.requestHuiTimer )":
>>         # increase sample data rate to 4Hz:
>>          self.send("CFG-RATE", 6, {"Meas" : 0x00fa, "Nav" : 0x0001,
>> "Time" : 0x0000})
>> Unfortunately, it doesn't change anything. "gpspipe -r" will still put
>> out a single set of messages per second, even though the GPS chip is
>> (hopefuly) configured for 4 sets per second. When used with the
>> original gpsd in other older distros, this didn't happen; gpspipe -r
>> outputs whatever the the gpsd delivers. So the problem is most likely
>> in FSO's ogpsd implementation.
>> Sending a u-blox binary string into /dev/ttySAC1 with the same config
>> message while fso-gpsd is working also doesn't work out (I've tried
>> many times just in case I'm racing with the framework and messages get
>> mangled).
>> I've combed the framework code in that folder trying to find any 1s
>> cycle hardcoded, but everything looks as it should: event-triggered by
>> available data.
>> So the 1M€ question is: where the heck is this 1s polling cycle
>> defined? How can I get the ogpsd framework to output 4 samples per
>> second instead of 1?
>> Any hints will be appreciated.
>> Thx,
>> V.
>> _______________________________________________
>> Openmoko community mailing list
>> community at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2886833.html
Sent from the Openmoko Community mailing list archive at Nabble.com.

More information about the community mailing list