Re: [gpsd-dev] Field reports from Raspberry Pi GPS HAT users?

[Frank Nicholas]

Hello Eric,

The issue is that they made a design decision on the Raspberry Pi 3 that ties the serial baud rate to the CPU clock rate (by default).

This was done because the normal lines that fed the serial port were used for the built-in Bluetooth.

You have 2 x options - fix the CPU speed at a known, safe speed for serial IO to be consistent, or disable BT.

Most people opt to disable BT.  See these posts to disable BT & re-map the lines properly to the serial port:

http://www.briandorey.com/post/Raspberry-Pi-3-UART-Overlay-Workaround

https://openenergymonitor.org/emon/node/12311

There is an official Raspberry Pi post, but I couldn’t find it very quickly…

If you look around, you can probably find the post about fixing the CPU clock speed also.

Note that this does not affect ANY other Raspberry Pi (A, B, B+, Zero or 2), as they do not have built-in BT or WiFi.

Thanks,

Frank

On Apr 18, 2016, at 7:46 PM, 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.

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.

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).

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?

(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>