[TangerineSDR] [HamSCI] Re: Magnetometer/Grape Raspberry Pi Image

Wed Nov 3 15:48:37 EDT 2021

Hi Bill,

I appreciate this! Take your time. I do recommend the use of gpsd because if you use something like the generic NMEA driver in ntpd, it will work fine, but you won’t have access to any GPS related information like location, GPS time, SNR and SV status, and fix status because the resources will be in use by the driver. If you use gpsd, you’ll have access to all of that via network socket.

Jules,

You mentioned that you were able to connect your GPSDO to your Pi to discipline the clock. How did you set up ntpd?

Gerry

I believe the developer just missed it. It’s easy to miss unless you simulate a GPS at a later date. Plus, it looks like there is only one primary contributor to the codebase right now and has a lot on his plate. 

Rob

No worries. I was happy there was a fix for that bug as well as a solution to the other bug I encountered when using a PPS source other than the serial port. When /dev/ttyAMA0 is used, gpsd assumes /dev/pps0 if it exists in devfs. 

I also agree that “tinker panic 0” can lead to problems and is far from ideal. A bad actor can easily mess with your system time and goes against how ntp is suppose to trust other peers and an RTC hat would remedy this. 

I had forgotten exactly how Debian’s packages were placed in certain categories since I haven’t used it regularly (or any Linux on a non-embedded system) since Potato. FreeBSD’s Ports works a little differently and since I use FreeBSD almost exclusively for the majority of my computing, I had forgotten about Debian. 

I’m a fan of package management myself and use it almost exclusively, (even on Solaris) but creating packages can be a time-consuming process especially when you don’t have a build environment set up. In FreeBSD and Linux, some packages don’t have active maintainers, so sometimes you are stuck compiling from source or setting up a build environment to build a package and installing it. 

My recommendation on building gpsd was based on getting the latest bug fixes in the minor versions busy compiling from the git. I believe Bill may use Ubuntu and Jules may use Raspbian, so they can either build from git or install the 3.22 package. But, they may not use gpsd, I’m not sure yet.

Thanks

Jonathan
KC3EEY

> On Nov 1, 2021, at 10:00 PM, Gerald Creager <gcreager at cap.gov> wrote:
> 
> You have to remember they were working with 10-bit shift registers when GPS was designed. That's pretty remarkable tech for the time it was brought to fruition!
> 
> The developers of gpsd have a new version out. There wasn't a good way to protect against the week roll-over problem prior to its occurrence, but I'm embarrassed it wasn't caught in regression testing.
> 
> gerry
> 
> Capt Gerry Creager, CAP
> SWR Health Services Officer
> Weather and Environmental Support Officer -- Incident Management Team
> OKWG Asst Dir Communications Planning
> (C) 979.229.5301
> Civil Air Patrol, U.S. Air Force Auxiliary
> gocivilairpatrol.com
> Southwest Region -- Civil Air Patrolhttps://swrcap.com/
> 
> 
>> On Mon, Nov 1, 2021 at 9:02 AM David G. McGaw <david.g.mcgaw at dartmouth.edu> wrote:
>> The cause of this "bug" is a recent GPS Week rollover, which was warned 
>> as happening for some versions of NTP running GPSD on October 24, 2021.  
>> In their infinite wisdom, the original designers of GPS gave 10 bits to 
>> the week counter which has it roll over every 1024 weeks which is about 
>> 20 years.  Some GPS receivers go back at the actual roll over, the most 
>> recent having been April 6, 2019, some at some arbitrary date set by the 
>> release date of the firmware or software and some handle it and keep 
>> going.  The Trimble Thunderbolts rolled over some time ago and report an 
>> incorrect date, but software, such as Lady Heather, can know about this 
>> and correct for it.  My Garmins just keep on trucking.
>> 
>> 73,
>> 
>> David N1HAC
>> 
>> On 11/1/21 8:51 AM, Jonathan wrote:
>> > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgpsd%2Fgpsd%2F-%2Fissues%2F144&data=04%7C01%7Cdavid.g.mcgaw%40dartmouth.edu%7Cc12f67dbc35547d1796508d99d364c3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637713678810911597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z0ggvJWcjtE%2FiKI9p2NAY9B5a0DPoZ%2Ff721j3f1YiFA%3D&reserved=0 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
>> 
>> -- 
>> Please follow the HamSCI Community Participation Guidelines at http://hamsci.org/hamsci-community-participation-guidelines.
>> --- 
>> You received this message because you are subscribed to the Google Groups "HamSCI" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to hamsci+unsubscribe at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci/c9294fb1-d19e-bb90-646a-ddb837423e91%40dartmouth.edu.
> 
> -- 
> Please follow the HamSCI Community Participation Guidelines at http://hamsci.org/hamsci-community-participation-guidelines.
> --- 
> You received this message because you are subscribed to the Google Groups "HamSCI" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hamsci+unsubscribe at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci/CAG3zga73KMdih0eAUSdfcD%2BsVpER%2BYx6SXZgZQ4SbgjGy-ZZQw%40mail.gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20211103/3b151c93/attachment-0001.html>