On Fri, 06 Mar 2009 14:39:33 +0100 GNUtoo <gnu...@no-log.org> wrote: > On Thu, 2009-03-05 at 22:27 +0100, Francesco de Virgilio wrote: > > It seems not work on SHR-testing :( > That's normal...you are using the gpsd bindings on your desktop > computer. > They permit you to talk to a gpsd compatible device > I tested it with fso-gpsd(python on my desktop with the gpsd > bindings(so I needed to install gpsd on my desktop to get the > bindings) and fso-gpsd on the openmoko)
Oh, that's interesting. fso-gpsd should actually be gpsd compatible. Could you explain more why it's not working/what is not working or what gps.py actually does to talk to gpsd. One problem you might encounter is that ogpsd and fso-gpsd only switch on the GPS when there's actually a program that needs GPS. In the case of fso-gpsd that happens when you connect to the gpsd port. My guess is that the connection is either made at the constructor (g = gps.gps()) or for every call (g.query("admosy")). At this point the chip will not have any fix for sure, even with hotstart working it usually takes ~16 seconds. What you can do to test my hypothesis is start a different program like the GPS view in zhone and wait until GPS actually has a fix and then try with your program. If you get a fix then you can request the resource GPS to make sure GPS stays on. > So you have 2 solutions: > 1)replace fso-gpsd by gpsd > 2)use dbus to talk to the GPS 3)Make fso-gpsd compatible with gpsd so gps.py works. Regards, Daniel Willmann
signature.asc
Description: PGP signature
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community