Explanation of clear-at-start-of-cycle for HACKING.

Don't stumble over initializing with NAN in the ntrip support.

1 files changed, 27 insertions, 12 deletions

diff --git a/HACKING b/HACKING
index 766f9023..211fbba6 100644
--- a/HACKING
+++ b/HACKING
@@ -464,7 +464,7 @@ designed by fools who weren't looking past the ends of their noses)
 this code unavoidably includes some assumptions that will turn around
 and bite on various future dates. 
 
-The two specific problms are:
+The two specific problems are:
 
 1) NMEA delivers only two-digit years.
 
@@ -480,7 +480,7 @@ is so you can use it to set the system clock.
 *** Hotplug interface problems
 
 The hotplug interface works pretty nicely for telling gpsd which
-device to look at, at least on my FC3 and FC4 Linux machines.  The fly
+device to look at, at least on my FC3/FC4/FC5 Linux machines.  The fly
 in the ointment is that I'm using a deprecated version of the
 interface, the old-style /etc/hotplug version with usermap files.
 
@@ -941,13 +941,27 @@ This is the policy gpsd currently follows.
 **** Buffer all, report on every packet, never clear data
 
 Has all the advantages of the previous policy and avoids the flicker 
-problem.  However, it means the user will often see data that is up to one 
-cycle time stale.   If the mode changes due to the device losing 
-satellite lock, it will continue to report stale PVT data with
-only the changed mode field to indicate that it's no longer good.
-
-In the intermediate case where the device loses 3D lock but keeps
-2D lock, altitude could go bad without any indication but the mode.
+problem.  However, it would mean the user often sees data that is up to one 
+cycle time stale.  This might be OK except that it could happen even if
+the GPS has just lost lock -- that is, in the interval between start
+of cycle and receipt of sentence with the mode field invalidating the,
+bad data, gpsd would be pretending to know something it doesn't.
+
+GPSes sometimes do this, delivering data from dead-reckoning or
+interpolation when they've lost lock.  This comes up most often with
+altitude; because of the tall skinny shape of the tetrahedra defined
+by GPS range data, a GPS can lose 3D lock but still have an altitude
+guess good enough for it to deliver 2D permission.  But just because
+GPSes fudge is no good reason for gpsd to add a layer of prevarication
+on top of that.
+
+But the conclusive argument against this policy is that, while it can be
+simulated by buffering data delivered according to a clear-every-cycle 
+policy, the reverse is not true.  Under this policy there would be
+no way to distinguish in gpsd's reports between data valid now and
+data held over from a previous cycle; on the other hand, under
+a clear-at-start-of-cycle policy the client can still do whatever
+buffering and smoothing it wants to.
 
 **** Buffer all, report on every packet, time out old data
 
@@ -959,9 +973,10 @@ greater than the cycle time.
 
 When the device is returning fixes steadily, this policy will look
 exactly like "buffer all, report on every packet, never clear data",
-because every piece of data will be refreshed once per cycle.  If
-the device loses lock, the user will see that the PVT data is 
-undefined only when the timeout expires.
+because every piece of data will be refreshed once per cycle.  It will
+have the same sort of prevarication problems.  If the device loses
+lock, the user will see that the PVT data is undefined only when the
+timeout expires.
 
 Fine-grained timeouts using per-field aging wouldn't change this 
 picture much.  They'd mainly be useful for matching the timeout