gpsd

This is a rewrite of the C-based gpsd, which is pretty central to navigation. I use it to read packets from my NMEA2000 device as well as read from a backup GPS device; especially important to me is the NMEA 2000 canbus to GPS and AIS messages that opencpn can understand.

As it turns out, the C gpsd NMEA2000 driver doesn't currently parse AIS messages and translate them. It only seems to support GPS messages and some heading information. Looks like there is code there, it just doesn't seem to work. Worse yet, every now and then, it just quits. Restarting gpsd resolves the issue. The code is stricky, so it's just easier to start over in a memory safe language.

How to run it

Run with: cargo run --release -- -D 3 -N -s 4800 /dev/ttyUSB0 (use your device and speed though)

The -D 3 specifies debugging level messages, which include device open and close messages. If you just want info level, you can leave this off.

Current state

Currently it does just enough to make opencpn happy reading from it.

• The GPS device is opened and messages are forwarded to the channel, even if there are no subscribers. This is a waste of power. It shouldn't even open the GPS device until there is at least one listener, like what gpsd does, unless you specify nowait. As it turns out, though, nowait is the default in most distros. So maybe this isn't so bad.
• There's no working auto speed detection for serial devices yet, so you must specify a speed on the command line.

Hotlist of things to do next:

• Baudrate detection.
• Read NMEA 2000 messages and translate them to nmea 0183. In particular, I'd like to generate AIS messages.
• Implement hotplug. This should actually be pretty easy once baud rate detection is done.

Low priority stuff:

• SIRF devices aren't supported, but detection of them is implemented
• No support for json messages as expected by cgps and othere
• No support for polling
• No detection of GPS devices
• PPS devices aren't supported
• Several obscure devices aren't supported (Garmin TXT mode for example)

There are a few things we are already doing better than gpsd did:

• Connecting and then issuing some commands, but not actually getting any output, puts you on a 60 second timer for disconnection. This is more aggressive than gpsd, which seems to have some complex rules for whether to disconnect you or not. This might matter for clients that POLL, but if they aren't polling at least once per minute, they should probably disconnect and reconnect.
• Received requests don't have to come all at once. To see this error in gpsd, telnet to it, send ?W then hit CTRL-D which pushes that packet out to gpsd, without a newline, resulting in an "invalid command" error. This implementation parses "commands" which mean that partial commands will just wait for their completion.
• Rather than making so many system calls and delays to change the speed during auto baud rate detection, just close the device and reopen it at the new speed.

Timing info

So I can't even get more than a second of CPU after running for a few hours now. Compared to gpsd, which took about 1 minute of CPU every hour, I'm very happy wih the performance. Timings, on my Dell i5, YMMV.