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

[Vasco Névoa]

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
>