GPS program module for raspberry.pi

RTFM - gpsd is a server, not a command line utility.

Why do you need to use gpsd anyway? Its main use is to let other client programs, possibly on other computers, share access to the GPS module.

Read this:

This is Unix, though: a program which shares data with a remote computer can also share it locally.

My car track logger uses gpsd/gpspipe as that's the cleanest way of getting data from an arbitrary GPS receiver into the local machine.

That is a good reason to use it, isn't it? Without gpsd, only a single program on the computer can access the GPS module. So, when you have more than one program that wants to know the position, or when you want to let the GPS module sync the clock and you also want to know the position, you are out of luck.

gpsd also translates the output of different types of GPS receiver to a single common format, so the application program does not need to do that itself.

Maybe, maybe not. We don't know what the OP is trying to achieve, which is why I asked him why he wanted to use it. If we knew that we might be able to give more directed help.

'RTFM' is intended as advice: since he has succeeded in downloading and installing gpsd, but seems not to know how to use it, that's about the best advice I can give from what he told us.

Yeah, all that became obvious as soon as I looked at the gps website. In the past I've seen what NMEA-speaking units (Garmin GPS-35) output by pointing cat at the serial port it was attached to. It looks as though, that by using gpsd the same could be achieved with a generic chain like:

GPS-->gpsd-->netcat

Indeed, and I can see uses for myself in my glider. If I was to run the LK8000[*] navigation program on an RPi with an attached Adafruit 3.5" toch screen and a USB-connected GPS puck, it would make sense to use gpsd because this way I could feed one GPS data stream into LK8000 and point a second stream into my SDI C4 flight computer. [*] I'm currently running in on a Medion PDA, but it runs under both WM5/6 and Linux.

The problem with serial devices is that only a single program can read them at any time. So when you have two programs that need the information, you need a single service that reads the serial port and then many programs can connect to that service. That is what gpsd is doing.

Also, NMEA is easily readable and commonly available, but it lacks the detail available in the binary protocol specific to each manufacturer, so gpsd can talk to the device in binary protocols.

Did it occur to you that I was describing a TEST SYSTEM to see exactly what data items the GPS was outputting and in what order?

With the documentation standard of some GPS receivers you'd need to do that so you'd know what sequence of data items it produces before designing and coding the consuming program. IIRC the GPS-35, which defaults to NMEA output, had a manual which lists the NMEA sentences it outputs but said nothing about their output ordering, so running it up with cat as the data consumer was a worthwhile test. I'd do the same with any new type of GPS receiver that I'd expect to be feeding one or more data consumers via gpsd, but in this case netcat is the most suitable program for displaying the output.

There's some information on using GPS/PPS and a suitable hardware module here:

and some background notes here: