diff options
author | Eric S. Raymond <esr@thyrsus.com> | 2006-06-07 21:25:41 +0000 |
---|---|---|
committer | Eric S. Raymond <esr@thyrsus.com> | 2006-06-07 21:25:41 +0000 |
commit | 0ef951364695b2b334ae97268a9f1dc72c507aa4 (patch) | |
tree | b5fcf1fcba78841ef08d17d14c3c0eee7d6bce6d /HACKING | |
parent | 7b2681152c7dd2d3fc9672d6098cb87b908de8fe (diff) | |
download | gpsd-0ef951364695b2b334ae97268a9f1dc72c507aa4.tar.gz |
More minor updates.
Diffstat (limited to 'HACKING')
-rw-r--r-- | HACKING | 12 |
1 files changed, 6 insertions, 6 deletions
@@ -951,9 +951,9 @@ 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. +guess good enough for it to deliver a 2D fix with confidence. 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 @@ -974,9 +974,9 @@ 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. 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. +have the same sort of prevarication problems as that policy, too. 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 |