From 34c8b8255c3603c8fbb5f21c0a637b6104a8f2f4 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Tue, 7 Nov 2006 05:30:06 +0000 Subject: Minor markup fixes. --- www/writing-a-driver.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'www/writing-a-driver.xml') diff --git a/www/writing-a-driver.xml b/www/writing-a-driver.xml index 3eab6d56..c5c7bc12 100644 --- a/www/writing-a-driver.xml +++ b/www/writing-a-driver.xml @@ -183,14 +183,14 @@ ASCII string @@Nn followed by a payload of 0 to approx 300 binary bytes, a single byte binary checksum and an ASCII CR/LF pair. This particular structure was the cause of some headaches in the interpretation, but it means that the important -data is impressively dense. The first command ( -@@Bb) gives the status of all visible satellites -(up to 12) in 92 bytes and the second command ( -@@Ea) gives all the navigational data plus +data is impressively dense. The first command +(@@Bb) gives the status of all visible satellites +(up to 12) in 92 bytes and the second command +(@@Ea) gives all the navigational data plus receiver status in 76 bytes. Once I had determined the two commands and responses that were -needed ( a few others were needed for initialisation and +needed (a few others were needed for initialisation and administration), I set about writing the decoder to fill in the standard data structures that gpsduses. For this, the zodiac.cdriver was very helpful as it @@ -664,7 +664,7 @@ available. In my case, all the fields could be filled directly from the data shipped by the GPS in the two messages which I activated. The satellite status data was exactly as needed, except that the GPS provided data for all visible satellites whereas -gpsdwas interested only in those satellites +gpsd was interested only in those satellites whose signal was usable. The navigation data was all present but some fields did need some massaging; for example, my GPS reports location data in milliArcseconds whilst gpsdworks in -- cgit v1.2.1