14 Aug 2004
3
3
Linux
libgps
C service library for communicating with the GPS daemon
C:
#include <gps.h>
struct gps_data_t *gps_open
char *server
char * port
int gps_open_r
char *server
char * port
struct gps_data_t *gpsdata
int gps_send
struct gps_data_t *gpsdata
char *fmt...
void gps_set_raw_hook
struct gps_data_t *gpsdata
void (*hook)(struct gps_data_t *,
char *buf, size_t len)
int gps_poll
struct gps_data_t *gpsdata
void gps_close
struct gps_data_t *gpsdata
void gps_set_callback
struct gps_data_t *gpsdata
void (*callback)(struct
gps_data_t *sentence, char *buf, size_t len)
pthread_t *handler
void gps_del_callback
struct gps_data_t *gpsdata
pthread *handler
void rtcm2_unpack
struct rtcm_t *rtcmp
char *buf
int gps_stream
struct gps_data_t *gpsdata
unsigned intflags
void *data
char *gps_errstr
int err
Python:
import gps
session = gps.gps(host="127.0.0.1", port="2947")
session.set_raw_hook(raw_hook)
session.stream(WATCH_ENABLE)
for report in session:
process(report)
del session
DESCRIPTION
libgps is a service library which
supports querying GPS devices; link it with the linker option
-lgps. There are two interfaces supported in it; one high-level
interface that goes through
gpsd1
and is intended for concurrent use by several applications, and one
low-level interface that speaks directly with the serial or USB device
to which the GPS is attached. This page describes the high-level
interface that is safe for multiple applications to use simultaneously; it
is probably the one you want. The low-level interface is documented
at
libgpsd3.
The API described below may change incompatibly at API
version 4. Take care to conditionalize your code on the major and
minor API version symbols in gps.h; ideally,
force a compilation failure if the header is not exporting a version
you recognize. See the GPSD project website for more information on
the protocol and API changes.
Calling gps_open() initializes a GPS-data
structure to hold the data collected by the GPS, and returns a socket
attached to
gpsd1.
gps_open() returns NULL on errors. errno is
set depending on the error returned from the the socket layer; see
gps.h for values and explanations.
gps_open_r() is a reentrent-friendly
version That put the session storage where you wish to allocate it.
It returns 0 on success and -1 on failure, with errno set
appropriately.
gps_close() ends the session.
NB: ending the session does not destroy any threads created to handle
callbacks. You must delete all callbacks prior to
calling gps_close(). Failure to do so results in
undefined behavior. Currently it will leak a thread, and in the
future might result in aborting the program.
gps_send() writes a command to the daemon.
The second argument must be a format string containing elements from
the command set documented at
gpsd1.
It may have % elements as for
sprintf3,
which will be filled in from any following arguments. This function
returns a -1 if there was a Unix-level write error, otherwise
0. Please read the LIMITATIONS section for additional information and
cautions.
gps_poll() accepts a response, or sequence
of responses, from the daemon and interprets it as though it were a
query response (the return value is as for a query).
gps_poll() returns the validity mask of the
received structure. This function does a blocking read waiting for
data from the daemon; it returns 0 for success, or -1 on a Unix-level
read error.
gps_stream() asks
gpsd to stream the reports it has at you,
to be made available whenn you poll. It is preferable to the
older-style (pre-2.39) way of doing this,
gps_query() with a "w+" argument, because it
insulates your code from whether your client library and your
gpsd are using old or new protocol.
The second argument is a flag mask that sets various policy bits;
see gps.h for description. Calling gps_stream()
more than once with different flag masks is allowed.The third
argument is not presently used but reserved for expansion.
gps_set_raw_hook() takes a function you
specify and run it (synchronously) on the raw data pulled by a
gps_query() or gps_poll()
call. The arguments passed to this hook will be a pointer to a
structure containing parsed data, and a buffer containining the
raw gpsd response.
gps_set_callback() takes a function you
specify and runs it asynchronously each time new data arrives from
gpsd, using POSIX threads. For example,
you can call gps_set_callback(gpsdata, my_function, handler) once in
your program, and from there on your gpsdata structure will be parsed
by your my_function() each time new data are
available. my_function() could change some
global variables in your program based on received data; it is your
responsibility to ensure that your program uses mutexes or other
mechanisms to avoid race conditions.
NB: gps_set_callback() will create a new thread,
and contrary to what you might expect gps_close()
will not destroy that thread. You must therefore explicitly remove
the callback with gps_del_callback() before
calling gps_close().
gps_del_callback() deregisters the callback
function previously set with gps_set_callback().
After the invocation of this function no operation will be done when
new data arrives.
gps_errstr() returns an ASCII string (in
English) describing the error indicated by a nonzero return value from
gps_open().
Consult gps.h to learn more about the data members
and associated timestamps. Note that information will accumulate
in the session structure over time, and the 'valid' field is not
automatically zeroed by each poll. It is up to the client to
zero that field when appropriate and to keep an eye on the fix
and sentence timestamps.
The rtcm_unpack() will be useful when you
are connected to an RTCM-104 source in raw mode. Use it as part of a
raw hook, calling it with the address of the struct
rtcm_t element of your session structure buffer as first
argument and the buffer as the second. It will unpack a line of RTCM
data into the structure. This function returns 0 when it has read the
last line of an RTCM-104 message, a positive int when it expects more
dump lines, and a negative int on parse failure. You must zero out the
struct rtcm_t each time before this function
is called on a new header (H) line, as it relies on the message type
field being initially zero and uses it to track what kind of
following line is expected.
The Python implementation supports the same facilities as the C
library. gps_open() is replaced by the
initialization of a gps session object; the other calls are methods of
that object, and have the same names as the corresponding C functions.
Resources within the session object will be properly released when it
is garbage-collected.
CODE EXAMPLE
The following is an excerpted and simplified version of the
libgps interface code from
xgps1.
The function handle_input() is a trivial piece of
code that calls gps_poll(gpsdata).
gpsdata = gps_open(server, port);
build_gui(toplevel);
gps_set_raw_hook(gpsdata, update_panel);
(void)gps_stream(gpsdata, WATCH_ENABLE, NULL);
(void)XtAppAddInput(app, gpsdata->gps_fd,
(XtPointer)XtInputReadMask, handle_input, NULL);
(void)XtAppMainLoop(app);
(void)gps_close(gpsdata);
LIMITATIONS
Incautious use of gps_send() may lead to
subtle bugs. In order to not bloat struct
gps_data_t with space used by responses that are not
expected to be shipped in close sequence with each other, the storage
for fields associated with certain responses are combined in a union.
Sends that might invoke this set of responses need to be
sequenced carefully so the unpacking of multiple responses arriving in
the same socket read cannot result in later updates to the union
obliterating data from earlier ones before it becomes visible to the
client application.
The risky set of responses includes VERSION, DEVICELIST, RTCM2,
RTCM3, and AIS; it may not be limited to that set. The logic of the
daemon's watcher mode is careful to avoid dangerous sequences, but
you should read and understand the layout of struct
gps_data_t before using gps_send()
to request any of these responses.
COMPATIBILITY
The gps_query() supported in major versions
1 and 2 of this library has been removed. With the new
streaming-oriented wire protocol behind this library, it is extremely
unwise to assume that the first transmission from the damon after a
command is shipped to it will be the reponse to command.
If you must send commands to the daemon explicity, use
gps_send() but beware that this ties your code to
the GPSD wire protocol. It is not recommended.
SEE ALSO
gpsd8,
gps1,
libgps3.
libgpsmm3.
AUTHOR
Eric S. Raymond <esr@thyrsus.com>, Thread-callback methods
in the C binding added by Alfredo Pironti
<alfredo@users.sourceforge.net>.