Fix a typo.

Note that receivers do not exchange handshakes with satellites,
they merely track codes. Also, getting time-of-week right is more important
than week number as the codes reset themselves at TOW=0, and the receiver is
looking for the PRN codes. Of course, I would not be surprised if receivers
accepted human-readable time (Y/M/D hh:mm:ss) and turned it into week/tow
internally.

1 files changed, 6 insertions, 4 deletions

diff --git a/www/hacking.html b/www/hacking.html
index 28b192ff..7a456ca3 100644
--- a/www/hacking.html
+++ b/www/hacking.html
@@ -813,9 +813,11 @@ start").</p>
 
 <p>If the GPS-Week/TOW fields are required, as on the Evermore chip,
 don't just zero them.  GPSes do eventually converge on the correct
-time when they've exchanged handshakes with enough satellites, but the
-time required for convergence is proportional to how far off the
-initial value is.  So make a point of getting the GPS week right.</p>
+time when they've tracked the code from enough satellites, but the
+time required for convergence is related to how far off the initial
+value is. Most modern receivers can cold start in 45 seconds given
+good reception; under suboptimal conditions this can take upwards of
+ten minutes. So make a point of getting the time of week right.</p>
 
 <h2 id="invoked">How drivers are invoked</h2>
 
@@ -921,7 +923,7 @@ representative log for your GPS.  This will help ensure that support
 for your device is never broken in any gpsd release, because we will
 run the full regression before we ship.</p>
 
-<p>The correct format for a capture fiilr is described in the
+<p>The correct format for a capture file is described in the
 <a href='faq.html#logformat'>FAQ entry on reporting bugs</a>.</p>
 
 <p>See the header comment of the gpsfake.py module for more about the