[gpsd-dev] PPS from position hold / time-only modes

[Håkan Johansson]

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