Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Vasco Névoa wrote: I don't have much of a problem there... see this: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate However, you must remember that frameworkd sends a lot of configurations into the chip, and it keeps talking to it, so it might be a bit of a hassle to get the chip to listen to you without shutting down the framework. Usually, I just do /etc/init.d/fso-gpsd stop and avoid launching any GPS application. This makes sure the frameworkd shuts down the GPS chip and lays off it. Then I can send in UBX packets into /dev/ttySAC1 and tail -f /dev/ttySAC1 without problems. Indeed, stopping fso-gps made it work, thanks for the hint. The drawback is that you loose all the benefits of fso's gps handling : on demand statup, shared access, etc. I hope the guys from FSO will solve this soon. Thanks again, useful tip. -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2906705.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Vasco Névoa wrote: Citando Helge Hafting helge.haft...@hist.no: 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, you're quite right, but gpspipe is a legacy application, and the preferred way is to sit on the DBUS interface for signals. I'm just using gpspipe because I already had a nice script to import data in NMEA format. ;) I suppose the FSO people will strongly suggest that users stick to the DBUS instead of consuming NMEA text, and that's what makes sense (even according to your own optimization rationale). So, asap, I'm going to code my app in python to use DBUS and avoid all this NMEA nonsense from the start. But the problem remains: ogpsd does not accept more than one position change per second and so I opened the ticket. http://trac.freesmartphone.org/ticket/431 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Does anyone know a program/script that converts the dbus messages to gpx format? Now i us gpspipe to get nmea and gpsbabel to create gpx files. Kind regards, Ed -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2906733.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando KaZeR ka...@altern.org: Indeed, stopping fso-gps made it work, thanks for the hint. The drawback is that you loose all the benefits of fso's gps handling : on demand statup, shared access, etc. That's more or less true. You see, when you stop the fso-gpsd, you only stop the gpsd compatibility layer daemon. The framework is still working. This means that if you connect to DBUS Gypsy service the framework will open the device again. fso-gpsd is just another client for the Gypsy service. However, if you are in fact reading directly from /dev/ttySAC1 and simultaneously try to read from Gypsy DBUS, the info probably will get mangled for both clients. Besides, I forgot to mention this: the framework talks binary UBX with the chip, so reading from /dev/ttySAC1 at the same time gives you UBX binary garbage, not NMEA ASCII text. So the current workaround that allows us to fully control the chip and have NMEA output is to stop fso-gpsd _and_ any other DBUS listener so that the framework releases the device; then we can power it off and on via /sys to reset the default config (NMEA mode) just in case; and then we can safely play around with cat and tail and /dev/ttySAC1. But as soon as any other app requests the Gypsy DBUS service, hell brakes loose. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Ed Kapitein e...@kapitein.org: Does anyone know a program/script that converts the dbus messages to gpx format? Now i us gpspipe to get nmea and gpsbabel to create gpx files. Ideally, _someone_ should join the effort in FSO and expand fso-gpsd to produce GPX output... ;) (I'm presuming gpspipe is just a dumb socket listener). V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
On Friday 15 May 2009 11:47:36 Vasco Névoa wrote: Citando KaZeR ka...@altern.org: Indeed, stopping fso-gps made it work, thanks for the hint. The drawback is that you loose all the benefits of fso's gps handling : on demand statup, shared access, etc. That's more or less true. You see, when you stop the fso-gpsd, you only stop the gpsd compatibility layer daemon. The framework is still working. This means that if you connect to DBUS Gypsy service the framework will open the device again. fso-gpsd is just another client for the Gypsy service. However, if you are in fact reading directly from /dev/ttySAC1 and simultaneously try to read from Gypsy DBUS, the info probably will get mangled for both clients. Besides, I forgot to mention this: the framework talks binary UBX with the chip, so reading from /dev/ttySAC1 at the same time gives you UBX binary garbage, not NMEA ASCII text. So the current workaround that allows us to fully control the chip and have NMEA output is to stop fso-gpsd _and_ any other DBUS listener so that the framework releases the device; then we can power it off and on via /sys to reset the default config (NMEA mode) just in case; and then we can safely play around with cat and tail and /dev/ttySAC1. But as soon as any other app requests the Gypsy DBUS service, hell brakes loose. You can always disable ogpsd in the config, if you don't want it. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Hello list, I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA and friends using the ubxgen script from the wiki. Is it related? -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2888680.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I tried again, it works as expected. KaZeR wrote: Hello list, I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA and friends using the ubxgen script from the wiki. Is it related? -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2889709.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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.qing...@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.ne...@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 : 0x})
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I don't have much of a problem there... see this: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate However, you must remember that frameworkd sends a lot of configurations into the chip, and it keeps talking to it, so it might be a bit of a hassle to get the chip to listen to you without shutting down the framework. Usually, I just do /etc/init.d/fso-gpsd stop and avoid launching any GPS application. This makes sure the frameworkd shuts down the GPS chip and lays off it. Then I can send in UBX packets into /dev/ttySAC1 and tail -f /dev/ttySAC1 without problems. Citando KaZeR ka...@altern.org: Hello list, I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA and friends using the ubxgen script from the wiki. Is it related? -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2888680.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Helge Hafting helge.haft...@hist.no: 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, you're quite right, but gpspipe is a legacy application, and the preferred way is to sit on the DBUS interface for signals. I'm just using gpspipe because I already had a nice script to import data in NMEA format. ;) I suppose the FSO people will strongly suggest that users stick to the DBUS instead of consuming NMEA text, and that's what makes sense (even according to your own optimization rationale). So, asap, I'm going to code my app in python to use DBUS and avoid all this NMEA nonsense from the start. But the problem remains: ogpsd does not accept more than one position change per second and so I opened the ticket. http://trac.freesmartphone.org/ticket/431 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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 : 0x})
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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.ne...@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 : 0x})
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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.
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...)
yoyo
Citando Vasco Névoa vasco.ne...@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 : 0x})
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
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.ne...@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 : 0x})
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
