My original NTP server was a Raspberry Pi B, Adafruit “Ultimate GPS” (not hat, but same chip on a separate board - https://www.adafruit.com/products/746) & PPS was working perfectly. This was before I moved my GPS & NTP service to my pfSense FW/Router.
One note, Adafruit states GPS hat is not compatible with Raspberry Pi 3: https://www.adafruit.com/products/2324. I bet this is because of the UART baud rate being linked to the CPU clock speed, and can be worked around ad I posted earlier.
I have always run Gentoo linux on all my Raspberry Pi’s. I avoid systemd as much as possible.
ttyAMA0 is what the Bluetooth is attached to on the Raspberry Pi 3. The mini-UART that is the serial port now, is ttyS0, unless you follow my original links to move ttyAMA0 back to the GPIO pin serial port...
Thanks, Frank
On Mon, 18 Apr 2016 18:46:39 -0500, Eric S. Raymond < address@hidden> wrote: I need field reports from GPSD users working with the Raspberry Pi
GPS/RTC hat. I've spent several days trying to turn a headless but
hatted Pi 3 into a pocket NTP server and I'm seeing mysterious bugs.
Full configuration: Raspberry Pi 3, Raspbian Jesse, Adafruit GPS HAT.
For reference, my configuration is Pi A+, Jesse, Adafruit. A superficial problem is that the Adafruit setup instructions are
badly out of date. They give the wrong device (my HAT is on ttyS0,
not ttyAMA0), the wrong set of boot options to edit out, and the wrong
set of systemd services to disable to tell it not to screw with the
ttyS0/console device.
It's after working around those problems that the real bad stuff
starts. Running "cat /dev/ttyS0" to look at the raw NMEA data yields
baud barf, unless you catch it in the first few seconds after reboot
in which case you get a few sentences of NMEA and then baud barf.
I was getting baud barf early on. Unfortunately, I don't really remember what solved it. Since you're on the 3 I'd probably check Frank Nicholas's thing about Bluetooth/Wi-fi first. Yes, I shut down any systemd service that might conceivably be
touching ttyS0. Then I audited using systemd to check what was
running. It isn't systemd messing with the port unless systemd is
lying or confused about what it's doing (a not implausible theory).
Did you install the Raspbian repository version of GPSD, by any chance? That is misconfigured for systemd, although the symptom I remember tracing back to that was different (systemd takes over TCP ports occupied by services it starts, then passes the data to the process. GPSD was dieing as a result of misconfiguration, but systemd wasn't releasing the port). In any case, I'd strip systemd, which is what I did in the end. I'd actually dealt with all of the systemd-related GPSD configuration issues, but then found that it was hogging CPU. I Googled the issue, found it to be a common complaint for systemd across different architectures, replaced systemd with sysvinit, and behold, no more CPU pegging. Gets more interesting when I run gpsd -D 5. First, gpsd takes a while to
get packet lock. It seems to miss the correct (9600 8N1) serial
parameters the first time and have to go back around.
It gets a handful of NMEA sentences, then the tty layer loses its
mind and gpsd has to go through the whole autobaud/packet-sync
sequence again. You can watch this sequence repeat for a long
as your patience lasts.
Gary Miller reports good operation on both Pi and Pi2 under wheezy.
Has anyone got GPSD working reliably on the Pi 3 under Jessie?
I can get location data and coarse time, but have not had any luck with GPSD and PPS so far. Once again, Pi A+ and Jessie. (My ultimate objective is NTPsec, but GPSD is the diagnostic tool I
know best.)
--
<a href=""http://www.catb.org/~esr/" class="">http://www.catb.org/~esr/">Eric S. Raymond</a>
-- Jon Brase
|