[TangerineSDR] Magnetometer/Grape Raspberry Pi Image

[Jonathan]

Hi Rob,

I was running an old version of 3.20 on both my Raspbian and FreeBSD systems and was directly affected by this bug. The fix for the bug affected the regressions but Gary was able to work through that. As in my previous email, my systems showed a GPS date that was 20 years behind. I first noticed it on my Pi this past Friday when I went to check my ntp peers and the GPS peer had a huge offset. Updating to the latest (3.23.2) fixed the problem, however on my Pi where a use a separate PPS source and a USB serial adapter, it failed to do shm puts from the /dev/pps0 source. Using 3.23.1 fixed that problem for now.

On the Pi, I use “tinker panic 0” in /etc/ntp.conf so ntpd will still discipline the system clock after it receives the current time from one of its peers. I don’t use an RTC because I did not see a need for it, especially since it gets the time of day from the GPS peer if the network were to be down. Plus, adding another hat, more power consumption, and driver requirements seemed like it would add more unnecessary complexity. 

Many package maintainers fail to keep gpsd updated and many installations do not get updated on a regular basis. Back in March of 2020, Raspbian’s gpsd package was stuck at 3.17 when the latest was 3.20. If your distribution offers an up-to-date package, then you should use it, but if it doesn’t, the best option is to compile from source from a major version tarball or git pull and build from there. As far as distribution-specific patches, I usually leave it up to user discretion. 

3.22 is unaffected by the alternate Pi UART and PPS device bug that I experienced, but Gary recommended to me that I use 3.23.1. So far, it’s working reliably on my VLF SDR. 

Jonathan
KC3EEY



> On Nov 1, 2021, at 5:55 AM, Rob Wiesler <robert.wiesler at case.edu> wrote:
> 
> Hi, all.
> 
>> On Sun, Oct 31, 2021 at 21:00:42 -0400, Jonathan via TangerineSDR wrote:
>> If I remember correctly, you used a GPS hat for the Raspberry Pi on
>> the Magnetometer/Grape system. Is this true? If so, which one do you
>> use?
>> 
>> The reason I ask is that there was a bug in gpsd that caused the GPS
>> date to be erroneously reported as March of 2002 once October 23th
>> 2021 has passed.
> 
> To the best of my understanding, this is not exactly true.  The bug
> affects test cases (Gary refers to them as "regressions"), not live
> code.  Live code uses the current time and date to disambiguate
> rollover, but the regressions run on old NMEA captures and do not have
> that luxury.  So, if you were to take a buggy version of gpsd and run
> the regressions with "scons check", you would encounter the bug then,
> but not in normal operation.
> 
> (If you're running gpsd on a RPi with no RTC and no guarantee that ntp
> -g steps the time *before* gpsd starts, you have a buggy installation
> regardless of which version of gpsd you're using.)
> 
>>                 This has been fixed and you are encouraged to update
>> to gpsd version 3.23.1. To do so, do a git pull of the gpsd
>> repository, then type "git checkout release-3.23.1", then "scons -c &&
>> scons && scons install".
> 
> Please don't do this.  This bug report is months old, and has been
> addressed.  The maintainer of the gpsd package in your operating system
> should have backported this fix if it's relevant to the packaged
> version.  For Debian and Raspian (and likely Ubuntu), this patch is
> included in 3.22-4 (the -4 suffix is the Debian revision of the
> packaging), and a simple system update is sufficient to bring it in for
> bullseye and buster-backports (and bookworm, but I doubt you're running
> that).  Older versions of the package (in buster and older) are not
> patched, as this bug was caused by a commit first seen in version 3.20 .
> 
> The Debian packaging also includes several fixes that are pertinent for
> Debian installations.  If you do end up installing from source, I
> recommend pulling in the patches from Debian.
> 
>> Details about the bug can be found at:
>> https://gitlab.com/gpsd/gpsd/-/issues/144 or LWN, El Reg, or CERT
>> write ups.
> 
> I recommend reading Gary's comment in that bug report that starts with
> "GPS, by design, is a 1024 week time warp waiting to happen.".  This is
> the best place to start reading to verify if my initial statement in
> this email is correct or not.
> 
> (It's a good thread in general.  I was absolutely floored to learn that
> there was a bug in (a test case of) production software due to global
> warming causing a scheduled/expected leap second to be rescinded.)
> 
>> As of this email, version 3.32.2 is the most current, but there is a
>> bug that prevents using the GPIO PPS with another serial device than
>> /dev/ttyAMA0. Most GPS hats use /dev/ttyAMA0, so you can do a git
>> checkout and build/install of gpsd, but since I use /dev/ttyAMA0 for a
>> serial console (I still believe in out-of-band access), I utilize
>> /dev/ttyUSB0 from a FT230 USB serial interface IC that my GPS serial
>> port connects to, which then connects to the Pi USB port. In this
>> configuration, version 3.23.2 of gpsd cannot use the /dev/ttyUSB0
>> /dev/pps0 runtime option and capture PPS asserts/clears from the
>> pps_gpio driver. But, most GPS hats and users don't use this
>> configuration very often, so you won't be affected. A fix for this
>> issue will be pushed to the gpsd repository soon.
> 
> 3.22 should be unaffected by this.  In general, when an upstream
> maintainer recommends jumping straight to the bleeding edge, you might
> want to take that with a grain of salt.
> 
> -- AC8YV