Freeze before pulling the session-faking stuff into its own module.

3 files changed, 15 insertions, 3 deletions

diff --git a/gpsfake b/gpsfake
index b60d4863..1fee8492 100755
--- a/gpsfake
+++ b/gpsfake
@@ -271,7 +271,7 @@ if __name__ == "__main__":
         except OSError:
             sys.stderr.write("gpsfake: '%s' failed.\n" % spawncmd)
             os.kill(child, signal.SIGTERM)
-            raise SytemExit,1
+            raise SystemExit,1
         os.kill(child, signal.SIGTERM)
         raise SystemExit,0
     else:
diff --git a/www/faq.html b/www/faq.html
index c543a371..6a3884d2 100644
--- a/www/faq.html
+++ b/www/faq.html
@@ -92,7 +92,8 @@ that.</p>
 your GPS is SiRF-based, include the firmware version as well.  You can
 find out what that is by running at the daemon at -D 4.</p>
 
-<h1 id='date_flicker'>The date in <code>xgps</code> flickers to "n/a" part of the time</h1>
+<h1 id='flicker'>The date and other fields in <code>xgps</code> flicker 
+to "n/a" part of the time even when there's a fix.</h1>
 
 <p>The sentence or packet your GPS uses to report satellite
 bearing/elevation has no timestamp. The <code>xgps</code>
@@ -109,6 +110,15 @@ no date. That's its job.  The libgps library is doing its bit by
 passing everything from <code>gpsd</code> on to the client application
 as it arrives, including the lack of date.</p>
 
+<p>Other fields may flicker as well; latitude is prone to this on NMEA
+devices.  It's the same problem.  In theory, a client could accumulate
+data through an entire send cycle from the GPS, and change the display
+only once at end of cycle.  The problem with this is that there is
+so much variation in the order GPS sends sentences that there is no
+no way to spot end-of-cycle &mdash; the best you could do would be
+to wait until a sentence-timestamp change signals the start of a new
+cycle, at which time the buffered data is by definition obsolete.</p>
+
 <p>It's the <em>client's</em> job to interpret/interpolate/fill in
 gaps, to do policy.  What you're seeing as a bug only looks like one
 because <code>xgps</code>, as is proper for a test client, has as
diff --git a/www/index.html.in b/www/index.html.in
index 8749364e..893a20e6 100644
--- a/www/index.html.in
+++ b/www/index.html.in
@@ -151,6 +151,8 @@ and fix latency.</dd>
 <dd>The <code>sirfmon</code> packet monitor for SiRF GPSes.</dd>
 </dl>
 
+<p>Also, see the <a href="faq.html">FAQ</a>.</p>
+
 <p>We have a <a href='hardware.html'>list of compatible GPSses</a>
 with some technical information.  We also have <a href='NMEA.txt'>a
 list of NMEA sentences</a>.</p>
@@ -196,7 +198,7 @@ development. There haven't been any releases since early 2002.</p>
 
 <p>There is a <a href='http://www.crs4.it:8000/gpsweb/14'>GPSd</a>
 project that is a GPS daemon written in Java and apparently intended
-to provide location informtion for browsers.</p>
+to provide location information for browsers.</p>
 
 <p>There is a <code>gpsd</code>-like hack hosted under <a
 href='http://www2.musatcha.com/musatcha/computers/software/gpsd/'>Microsoft