| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
Many people confuse rejecting the trainling PPS edge as rejecting
the entire PPS pulse. Change reject to ignore to soften the blow.
Still needs more clarity.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a header for os_compat.c, and moves the related
prototypes into it from gpsd_config.h (as created by SConstruct),
after adding references to it to gpsd.h (via gpsd.h-tail) and a few
other sources that need it but don't include gpsd.h.
It also removes includes of <time.h> in the places where they were
only needed for the code now removed from gpsd_config.h.
TESTED:
Ran "scons build-all check" on OSX 10.9 (with strlcat/strlcpy but no
clock_gettime), OSX 10.12 (with strlcat/strlcpy and clock_gettime),
and Ubuntu 14 (with clock_gettime but no strlcat/strlcpy). Also
verified that fallback versions were not being included where
unnecessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the Linux kernel is built with CONFIG_PPS_CLIENT_KTIMER=y, then a
synthetic PPS source is added to allow testing without a real PPS
source. However, this source doesn't even run at exactly 1Hz, so any
attempt to use it for real time synchronization is disastrous.
To make matters worse, this is usually the first PPS driver
configured, causing it to appear as /dev/pps0, which is the implied
PPS device used by the "Magic HAT" kludge.
This change adds detection for the fake source (based on its name),
both to provide a warning if it is configured explicitly, and to skip
over it when applying the "Magic HAT" kludge.
TESTED:
Tested both gpsmon and gpsd on a Beaglebone Black with added symlinks
for testing "Magic HAT". Did this with kernels with and without the
KTIMER enabled. Verified that the proper PPS device is selected by
"Magic HAT", and that a warning is generated when expected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pps_thread_activate() code uses a single structure to pass
information to the monitor thread. The latter copies the data during
its initialization, so there's no long-term conflict across threads,
but there's no guarantee that the thread runs and gets far enough to
do that before the structure is reused. Note that this bug is fairly
unlikely to affect a multicore machine unless it's heavily loaded, but
easily causes trouble on a single-core machine.
A variety of strange PPS misbehaviors were observed on a Beaglebone
Black in the presence of this bug, including various nonreproducible
PPS initialization problems and failures, and duplicate PPS reports.
This change uses the pps_thread field as a flag to communicate a "copy
acknowledgment" back to pps_thread_activate(), which waits for it
before proceeding.
TESTED:
Launched several times on a Beaglebone Black with KPPS support, and
no longer observed flaky PPS startup in the logs, as well as no
longer observing duplicate PPS events in gpsmon. Not tested on
other platforms due to the lack of PPS availability.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
| |
Now that ntpshmmon works better, ppsthread can use better
constants.
Add comments on why the PPS constants are what they are.
|
| |
|
|
|
|
| |
This might solve a common problem.
|
| |
|
| |
|
| |
|
|
|
|
| |
If the file descriptor is negative, no way it can be a tty.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Anonymous found a bug in my logic...
This would have caused rejection of valid PPS pulses in the length of
1.00 Sec to 1.100 Sec, and the inclusion of bad PPS of length 1.101 Sec
to 1.999 Sec.
|
|
|
|
|
|
| |
Failure to get a time stamp is not an error, at worst it is a WARN
and at best an INFO. Since some GPS do not emit PPS when they have
no time lock it is just a state with no valid time.
|
| |
|
|
|
|
|
|
|
|
|
| |
Timespec is a 62 bit number, it does not fit in the 32 bits of
a long. Use 'long long' instead. 'long long' is always at least
64 bits long and is the same as a native int when compiled as 64 bit.
Note that many 64 bit OS still run 32 bit binaries, and many small
devices like RasPi's are 32 bit.
|
| |
|
| |
|
|
|
|
| |
This cancels the change that broke a lot of logging.
|
| |
|
|
|
|
|
|
|
|
| |
Instead, pass out real time of last PPS as it was actually seen. We can then
correct it using the device's actual cycle time.
The correction currently only works for cycle times that are integral
multiples of a second.
|
| |
|
|
|
|
|
|
| |
Remove the wrap hook. The only thing it was doing was closing the chrony fd.
which can be done just as cleanly by whatever calls the pps_thread_deactivate()
function.
|
| |
|
|
|
|
|
|
| |
With a bit of refactoring we can eliminate one of the hooks.
PPS observed live, telnetting to localhost:2947 with gpsd running.
|
| |
|
| |
|
| |
|
|
|
|
| |
pps_canwait and pps_caps now persistent.
|
|
|
|
|
| |
Also some commment on why ppsthread uses a 10% detection window
on what would seemingly be a 1e-3 or 1e-9 quantity.
|
|
|
|
|
|
| |
...stash it in an inner context.
PPS observed live on GR601-W.
|
|
|
|
|
| |
The old code broke invisible pulse on 5Hz and 0.5 Hz PPS.
Also did not catch many of the chattering modes.
|
|
|
|
|
|
| |
This means they could be dropped into NTP or another time-service program.
The only requirement is to set -DHAVE_SYS_TIMEPPS_H if you want the RFC2783
code compiled in.
|
|
|
|
|
|
|
|
|
| |
Soon, being able to drop it into NTP may be valuable.
The only remaining adhesion is that it needs gpsd_config.h for the
status of HAVE_SYS_TIMEPPS_H.
No code changes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Promote scan-build to be onere of the stock pre-release checks.
Fix one minor cppcheck nit.
|
|
|
|
| |
Plus a ton of logging tweaks
|
| |
|
| |
|