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