[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] PPS from position hold / time-only modes
From: |
Håkan Johansson |
Subject: |
[gpsd-dev] PPS from position hold / time-only modes |
Date: |
Sun, 13 Mar 2016 13:00:46 +0100 |
User-agent: |
Alpine 2.11 (DEB 23 2013-08-11) |
After doing a site survey (averaging 2D and 3D fixes), an oncore receiver
can go into 'position hold'-mode, where it only solves for the time. The
navigation message does not report a valid position fix in this case.
The u-blox seems to have a corresponding mode (UBX_MODE_TMONLY).
I believe this has worked long ago, but does not do that now.
Analysis:
This is thwarted by commit 82d4eb48 (in all_reports() in gpsd.c) which
does not pass the fix-time to the pps thread if there is no fixcnt.
The basically same check is also performed in report_hook() in
timehint.c, but against PPS_MIN_FIXES instead of 0.
(Removing these two checks, the PPS pulses from the oncore device make it
through to chrony.)
There is a flag in gpsd.h:
#define PPSTIME_IS INTERNAL_SET(7) /* precision time is available
*/
and a comment in driver_oncore.c:
/*
* The PPSTIME_IS mask bit exists distinctly from TIME_SET exactly
* so an OnCore running in time-service mode (and other GPS clocks)
* can signal that it's returning time even though no position fixes
* have been available.
*/
which would imply that PPSTIME_IS actually means that we have a good time
value despite having no position fix reported. But grepping for
PPSTIME_IS in the source shows that it is set in very many drivers, so its
meaning is likely rather that of the comment in gpsd.h and nothing more.
Also, the checks inside #ifdef NTP_ENABLE in all_reports() actually
require it to be set to for any PPS signal at all to be used.
Cleanup:
Before going to the solution, I believe the two checks in
report_hook() in timehint.c inside the
/* FIXME! these two validations need to move back into ppsthread.c */
are duplicates of the (longer) check block in gpsd.c, and could possibly
be removed? (Saving the comment in gpsd.c and also using PPS_MIN_FIXES
instead of 0 for the check.)
Solution:
A flag with the meaning 'time is available and good despite no position
fix' is required, such that it can overrule the check on fixcnt.
Question would be if PPSTIME_IS in its current sense is useful and should
be kept as is and a new flag introduced, or just repurposed.
Personally, I would rather go for a one-more-flag solution, as there could
be a use to mark that the time with a fix is good enough for PPS purposes.
The garmin driver seems to use it in that way (and thus itself also
duplicate the fixcnt check....).
Cheers,
Håkan
- [gpsd-dev] PPS from position hold / time-only modes,
Håkan Johansson <=