GPS data from gllin

Ken Yale kyale at
Mon Aug 6 22:29:09 CEST 2007

Hello Jonathon,

I'm not too sure about the GPS page idea:
	cat /tmp/nmeaNP >> /tmp/gps.nmea &
	/home/root/DM2/gps/gllin -low 5
	/home/root/DM2/gps/gllin -periodic 3
Use gllin -help to see what those options actually do.  Two gllin
commands in a row is not how I'd use the GLLIN at all.

You're absolutely correct:  the best, long-lived approach would be to
use the officially sanctioned DBUS wrapper of the GPSD output.  But I
don't think the core team has all that ready to release.  I'm sure they
have most of the internal parts somewhat working (or at least that's the
word I heard a few months ago).

So here's my advice, depending on your goals and schedule:

1)  Gotta have GPS, whatever it takes, and need it NOW:

	decode NMEA from /tmp/nmeaNP yourself.   Can use GPSD internals
to start.
	example fork() and pipe code can be pulled from the

2)  Willing to put up with a little side-effort in an attempt to be
data-compatible with a future DBUS implementation:

	Take the code from step (1) and smush it into GPSD.
	Then have your code use GPSD output.
	The risk is that the planned DBUS GPS data formats differ
significantly from GPSD output.
	You get the added benefit that you can connect GPSD to a BT puck
for testing flexibility.
	Need to create a dummy DBUS wrapper to hide the DBUS connection.
Or do the DBUS yourself.
	This flexibility is what OpenMoko is all about, so help

3)  I'm a Fortune-500 company and can't afford even the appearance of
taking a wrong step:

	Wait for GPSD+DBUS release and documentation from OpenMoko team.
It could be soon.


> Thanks for the info, I'm looking into the gpds documentation right

[Ken]  Typo:  GPSD is correct.

> I'm somewhat familiar with DBUS, but will need to get my hands dirty
with it before I feel truly
> comfortable.  Any DBUS and/or GPS gurus out there?
> I know possibly premature, but what would be the "correct" way to get
gps information?
> You can get the raw output like is demonstrated in the wiki
> Or you could call d-bus methods (ie turnOn, turnOff, curPosition,
curElevation, curSpeed, etc).
> Do we have any idea what that address would be and/or has anyone
worked on those interfaces/methods?
> I would think something like the dbus interface could make for
> more (re)usable code, plus you could hide some of the underlying
complexities in the gpsd setup.

More information about the openmoko-devel mailing list