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

Michael 'Mickey' Lauer mickey at vanille-media.de
Sat May 16 00:54:04 CEST 2009

On Friday 15 May 2009 11:47:36 Vasco Névoa wrote:
> Citando KaZeR <kazer at 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.


More information about the community mailing list