<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><span></span></div><div dir="ltr"><div dir="ltr"></div><div dir="ltr">Hi Jules,</div><div dir="ltr"><br></div><div dir="ltr">I remember you mentioned something like that. That is an excellent idea! </div><div dir="ltr"><br></div><div dir="ltr">Thanks!</div><div dir="ltr"><br></div><div dir="ltr">Jonathan</div><div dir="ltr">KC3EEY</div><div dir="ltr"><br>On Nov 3, 2021, at 4:36 PM, Julius Madey <<a href="mailto:hillfox@fairpoint.net">hillfox@fairpoint.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<font face="Arial">Jonathan,<br>
My connection to the Pi was an interrupt generated by the 1pps
output of a ublox LEA-MF8 GPSDO, no com link to the Pi for ntpd
update. The one pps 100ms pulse drove GPIO23 and was used in a
Python script to sample the RM3100 on each 1pps pulse rather than
the method I had used previously with Blocking Scheduler for 1
second sample timing. Blocking Scheduler usually delivered 86400
1 second samples every 24 hours but I was looking for something
which would be sync'd closer to the GPS 1pps pulse. So far, so
good. <br>
Jules <br>
</font><br>
<div class="moz-cite-prefix">On 11/3/2021 3:48 PM, Jonathan wrote:<br>
</div>
<blockquote type="cite" cite="mid:6A4B8BB3-4E4C-414A-833C-514B4244DCE7@gmail.com">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr"><span></span></div>
<div dir="ltr">
<div dir="ltr">Hi Bill,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Jules,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">You mentioned that you were able
to connect your GPSDO to your Pi to discipline
the clock. How did you set up ntpd?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Gerry</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Rob</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Thanks</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Jonathan</div>
<div dir="ltr">KC3EEY</div>
<div dir="ltr"><br>
On Nov 1, 2021, at 10:00 PM, Gerald Creager
<<a href="mailto:gcreager@cap.gov" moz-do-not-send="true" class="moz-txt-link-freetext">gcreager@cap.gov</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default">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!</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">gerry</div>
<div class="gmail_default"><br>
</div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<p class="MsoNormal"><b><span></span></b></p>
<p class="MsoNormal"><b><span>Capt
Gerry Creager, CAP</span></b></p>
<span>SWR Health
Services Officer</span></div>
<div dir="ltr"><span>Weather
and Environmental
Support Officer --
Incident Management
Team<br>
</span></div>
<div><span>OKWG Asst Dir
Communications
Planning</span><br>
</div>
<div dir="ltr">
<p class="MsoNormal"><span><span>(C)
979.229.5301</span><br>
</span><span>Civil Air
Patrol, U.S. Air
Force Auxiliary<br>
</span><span><a href="http://www.gocivilairpatrol.com/" target="_blank" moz-do-not-send="true"><span>gocivilairpatrol.com</span></a></span><br>
</p>
<p class="MsoNormal"><a href="https://swrcap.com/" target="_blank" moz-do-not-send="true">Southwest
Region -- Civil Air
Patrolhttps://swrcap.com/</a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon,
Nov 1, 2021 at 9:02 AM David G. McGaw
<<a href="mailto:david.g.mcgaw@dartmouth.edu" moz-do-not-send="true" class="moz-txt-link-freetext">david.g.mcgaw@dartmouth.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">The cause
of this "bug" is a recent GPS Week
rollover, which was warned <br>
as happening for some versions of NTP
running GPSD on October 24, 2021. <br>
In their infinite wisdom, the original
designers of GPS gave 10 bits to <br>
the week counter which has it roll over
every 1024 weeks which is about <br>
20 years. Some GPS receivers go back at
the actual roll over, the most <br>
recent having been April 6, 2019, some
at some arbitrary date set by the <br>
release date of the firmware or software
and some handle it and keep <br>
going. The Trimble Thunderbolts rolled
over some time ago and report an <br>
incorrect date, but software, such as
Lady Heather, can know about this <br>
and correct for it. My Garmins just
keep on trucking.<br>
<br>
73,<br>
<br>
David N1HAC<br>
<br>
On 11/1/21 8:51 AM, Jonathan wrote:<br>
> Hi Rob,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Jonathan<br>
> KC3EEY<br>
><br>
><br>
><br>
>> On Nov 1, 2021, at 5:55 AM, Rob
Wiesler <<a href="mailto:robert.wiesler@case.edu" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">robert.wiesler@case.edu</a>>
wrote:<br>
>><br>
>> Hi, all.<br>
>><br>
>>> On Sun, Oct 31, 2021 at
21:00:42 -0400, Jonathan via
TangerineSDR wrote:<br>
>>> If I remember correctly,
you used a GPS hat for the Raspberry Pi
on<br>
>>> the Magnetometer/Grape
system. Is this true? If so, which one
do you<br>
>>> use?<br>
>>><br>
>>> The reason I ask is that
there was a bug in gpsd that caused the
GPS<br>
>>> date to be erroneously
reported as March of 2002 once October
23th<br>
>>> 2021 has passed.<br>
>> To the best of my
understanding, this is not exactly
true. The bug<br>
>> affects test cases (Gary refers
to them as "regressions"), not live<br>
>> code. Live code uses the
current time and date to disambiguate<br>
>> rollover, but the regressions
run on old NMEA captures and do not have<br>
>> that luxury. So, if you were
to take a buggy version of gpsd and run<br>
>> the regressions with "scons
check", you would encounter the bug
then,<br>
>> but not in normal operation.<br>
>><br>
>> (If you're running gpsd on a
RPi with no RTC and no guarantee that
ntp<br>
>> -g steps the time *before* gpsd
starts, you have a buggy installation<br>
>> regardless of which version of
gpsd you're using.)<br>
>><br>
>>> This has
been fixed and you are encouraged to
update<br>
>>> to gpsd version 3.23.1. To
do so, do a git pull of the gpsd<br>
>>> repository, then type "git
checkout release-3.23.1", then "scons -c
&&<br>
>>> scons && scons
install".<br>
>> Please don't do this. This bug
report is months old, and has been<br>
>> addressed. The maintainer of
the gpsd package in your operating
system<br>
>> should have backported this fix
if it's relevant to the packaged<br>
>> version. For Debian and
Raspian (and likely Ubuntu), this patch
is<br>
>> included in 3.22-4 (the -4
suffix is the Debian revision of the<br>
>> packaging), and a simple system
update is sufficient to bring it in for<br>
>> bullseye and buster-backports
(and bookworm, but I doubt you're
running<br>
>> that). Older versions of the
package (in buster and older) are not<br>
>> patched, as this bug was caused
by a commit first seen in version 3.20 .<br>
>><br>
>> The Debian packaging also
includes several fixes that are
pertinent for<br>
>> Debian installations. If you
do end up installing from source, I<br>
>> recommend pulling in the
patches from Debian.<br>
>><br>
>>> Details about the bug can
be found at:<br>
>>> <a href="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" rel="noreferrer" target="_blank" moz-do-not-send="true">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</a>
or LWN, El Reg, or CERT<br>
>>> write ups.<br>
>> I recommend reading Gary's
comment in that bug report that starts
with<br>
>> "GPS, by design, is a 1024 week
time warp waiting to happen.". This is<br>
>> the best place to start reading
to verify if my initial statement in<br>
>> this email is correct or not.<br>
>><br>
>> (It's a good thread in
general. I was absolutely floored to
learn that<br>
>> there was a bug in (a test case
of) production software due to global<br>
>> warming causing a
scheduled/expected leap second to be
rescinded.)<br>
>><br>
>>> As of this email, version
3.32.2 is the most current, but there is
a<br>
>>> bug that prevents using the
GPIO PPS with another serial device than<br>
>>> /dev/ttyAMA0. Most GPS hats
use /dev/ttyAMA0, so you can do a git<br>
>>> checkout and build/install
of gpsd, but since I use /dev/ttyAMA0
for a<br>
>>> serial console (I still
believe in out-of-band access), I
utilize<br>
>>> /dev/ttyUSB0 from a FT230
USB serial interface IC that my GPS
serial<br>
>>> port connects to, which
then connects to the Pi USB port. In
this<br>
>>> configuration, version
3.23.2 of gpsd cannot use the
/dev/ttyUSB0<br>
>>> /dev/pps0 runtime option
and capture PPS asserts/clears from the<br>
>>> pps_gpio driver. But, most
GPS hats and users don't use this<br>
>>> configuration very often,
so you won't be affected. A fix for this<br>
>>> issue will be pushed to the
gpsd repository soon.<br>
>> 3.22 should be unaffected by
this. In general, when an upstream<br>
>> maintainer recommends jumping
straight to the bleeding edge, you might<br>
>> want to take that with a grain
of salt.<br>
>><br>
>> -- AC8YV<br>
<br>
-- <br>
Please follow the HamSCI Community
Participation Guidelines at <a href="http://hamsci.org/hamsci-community-participation-guidelines" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://hamsci.org/hamsci-community-participation-guidelines</a>.<br>
--- <br>
You received this message because you
are subscribed to the Google Groups
"HamSCI" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email
to <a href="mailto:hamsci%2Bunsubscribe@googlegroups.com" target="_blank" moz-do-not-send="true">hamsci+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit
<a href="https://groups.google.com/d/msgid/hamsci/c9294fb1-d19e-bb90-646a-ddb837423e91%40dartmouth.edu" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://groups.google.com/d/msgid/hamsci/c9294fb1-d19e-bb90-646a-ddb837423e91%40dartmouth.edu</a>.<br>
</blockquote>
</div>
-- <br>
Please follow the HamSCI Community
Participation Guidelines at <a href="http://hamsci.org/hamsci-community-participation-guidelines" moz-do-not-send="true" class="moz-txt-link-freetext">http://hamsci.org/hamsci-community-participation-guidelines</a>.<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "HamSCI"
group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to <a href="mailto:hamsci+unsubscribe@googlegroups.com" moz-do-not-send="true" class="moz-txt-link-freetext">hamsci+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/hamsci/CAG3zga73KMdih0eAUSdfcD%2BsVpER%2BYx6SXZgZQ4SbgjGy-ZZQw%40mail.gmail.com?utm_medium=email&utm_source=footer" moz-do-not-send="true">https://groups.google.com/d/msgid/hamsci/CAG3zga73KMdih0eAUSdfcD%2BsVpER%2BYx6SXZgZQ4SbgjGy-ZZQw%40mail.gmail.com</a>.<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
-- <br>
Please follow the HamSCI Community Participation Guidelines at <a href="http://hamsci.org/hamsci-community-participation-guidelines" moz-do-not-send="true" class="moz-txt-link-freetext">http://hamsci.org/hamsci-community-participation-guidelines</a>.<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "HamSCI" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href="mailto:hamsci+unsubscribe@googlegroups.com" moz-do-not-send="true" class="moz-txt-link-freetext">hamsci+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/hamsci/6A4B8BB3-4E4C-414A-833C-514B4244DCE7%40gmail.com?utm_medium=email&utm_source=footer" moz-do-not-send="true">https://groups.google.com/d/msgid/hamsci/6A4B8BB3-4E4C-414A-833C-514B4244DCE7%40gmail.com</a>.<br>
</blockquote>
<br>
<p></p>
-- <br>
Please follow the HamSCI Community Participation Guidelines at <a href="http://hamsci.org/hamsci-community-participation-guidelines">http://hamsci.org/hamsci-community-participation-guidelines</a>.<br>
--- <br>
You received this message because you are subscribed to the Google Groups "HamSCI" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:hamsci+unsubscribe@googlegroups.com">hamsci+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/hamsci/4cb66758-96fc-0bfb-8e84-431a6acb03df%40fairpoint.net?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/hamsci/4cb66758-96fc-0bfb-8e84-431a6acb03df%40fairpoint.net</a>.<br>
</div></blockquote></div></body></html>