On Friday 15 May 2009 11:47:36 Vasco Névoa wrote: > Citando KaZeR <[email protected]>: > > 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 [email protected] http://lists.openmoko.org/mailman/listinfo/community
