On Fri, 06 Mar 2009 14:39:33 +0100 GNUtoo <[email protected]> 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 [email protected] http://lists.openmoko.org/mailman/listinfo/community
