Several years ago I had gpsd working on a Rocket M5. But I had to modify the source code to get it usable. I kicked off a build of gpsd a couple days ago with the default source on the current nightly build branch and it compiled. I ran out of time to install and test. Now out of town again and back home next weekend. No guarantees, but I wouldn't mind getting thus working on my rocket again. In my configuration, the GPS hardware was accessed via serial port which isn't the highly accurate way. More drivers needed to be installed at the time to have more time accuracy. This isn't something that would likely be released as part of AREDN, as it's desirable to not run services on the mesh node that can readily be hosted on a LAN device. We're all motivated to keep mesh nodes to be lean mean routing machines.
Isn't accurate network time pretty critical to the effective operation of the network? I think the required packages a pretty lightweight, and with the new smaller AREDN firmware, I hope there's sufficient room to make what you set up standard on devices that have GPS built in.
Bill, the easy way to keep time with AREDN is just point your node to a local NTP server. It's more than accurate enough, considering the only thing time is used for with AREDN is for accurate timestamps for the logs.
My question actually has nothing to do with keeping time. We have a separate device in several locations running gpsd to share with other devices. It would be nice to just use that one instead.
I tested and installed gpsd within the last ~year and it worked with the latest version of AREDN firmware at the time. Note, however, the configuration to the serial port does not give a stratum 0 clock. It is good, but not perfect. To have more accurate timing the I2C packages need installed and gpsd configured accordingly.
Orv W6BI