3(3)

NAME
libgps - C service library for communicating with the GPS daemon

SYNOPSIS

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 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(flags=WATCH_JSON)

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 gpsd(1) 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 libgpsd(3).

    Warning

    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 gpsd(1). 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.

gps_send() writes a command to the daemon. The second argument must be a format string containing elements from the command set documented at gpsd(1). It may have % elements as for sprintf(3), 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.90) 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_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 xgps(1). 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

gpsd(8), gps(1), libgps(3). libgpsmm(3).

AUTHOR

Eric S. Raymond <esr@thyrsus.com>, Thread-callback methods in the C binding added by Alfredo Pironti <alfredo@users.sourceforge.net>.