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