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

[Vasco Névoa]

Thanks for the hints, GUYS.
Yes, I usually do disable all the message types I don't need, leaving  
only GPRMC and GPGGA. :)
I think I've found the bottleneck on this issue, and filed bug #431 on FSO.
http://trac.freesmartphone.org/ticket/431


Citando mqy <meng.qingyou at gmail.com>:

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