On Fri, 06 Mar 2009 14:39:33 +0100
GNUtoo <GNUtoo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/community/attachments/20090308/79bf2529/attachment.pgp