[Gearbox-commit] SF.net SVN: gearbox: [288] gearbox/trunk/submitted/gbxnovatelacfr/novatel. dox

[<rum...@us...>]

Revision: 288
          http://gearbox.svn.sourceforge.net/gearbox/?rev=288&view=rev
Author:   rumataxyz
Date:     2008-07-12 00:19:38 -0700 (Sat, 12 Jul 2008)

Log Message:
-----------
cosmetics, expanded/updated limitations

Modified Paths:
--------------
    gearbox/trunk/submitted/gbxnovatelacfr/novatel.dox

Modified: gearbox/trunk/submitted/gbxnovatelacfr/novatel.dox
===================================================================
--- gearbox/trunk/submitted/gbxnovatelacfr/novatel.dox	2008-07-12 07:16:06 UTC (rev 287)
+++ gearbox/trunk/submitted/gbxnovatelacfr/novatel.dox	2008-07-12 07:19:38 UTC (rev 288)
@@ -16,7 +16,8 @@
 @defgroup gbx_library_gbxnovatelacfr GbxNovatelAcfr
 @brief ACFR driver for a Novatel(SPAN) system.
 
-This is a proprietary Novatel navigation system. It minimally consists out of a Novatel OEMV GPS receiver (OEM4 receivers should be compatible).
+NovatelSPAN is a proprietary Novatel navigation system.
+It minimally consists out of a Novatel OEMV GPS receiver (OEM4 receivers should be compatible).
 If combined with an IMU, a SPAN system can provide an INS navigation solution at high rate (up to 100Hz).
 The driver initialises the hardware and reports navigation data continously.
 
@@ -43,7 +44,7 @@
   LGPL
 
 @par Dependencies.
--  @ref gbx_library_gbxserialacfr
+  @ref gbx_library_gbxserialacfr
 
 @par Example
 
@@ -64,8 +65,8 @@
 @par Minimal Example
 
 This example (no error checking for clarity, but fully functional) shows the driver's intended usage:
-- create configuration
-- create driver
+- create configuration (see @ref gbxnovatelacfr::Config, @ref gbxnovatelacfr::SimpleConfig and @ref gbxnovatelacfr::GpsOnlyConfig)
+- create driver (@ref gbxnovatelacfr::Driver)
 - read from driver and wait for external termination
 
 @verbatim
@@ -139,7 +140,8 @@
 
 @par References
 
-This driver was programmed based on the protocoll/message descriptions in Novatel manuals, it does not contain any code from Novatel. The main source for information was:
+This driver was programmed based on the protocoll/message descriptions in Novatel's manuals, it does not contain any code from Novatel.
+The main source for information was:
 - http://www.novatel.com/Documents/Manuals/om-20000094.pdf (Novatel OEMV reference)
 - http://www.novatel.com/Documents/Manuals/om-20000104.pdf (SPAN-system manual)
 
@@ -150,10 +152,25 @@
 
 @par Limitations
 
-- This is a Linux-only implementation (because of the serial library and the system-calls for timestamps)
-- Only supports a subset of the messages a NovatelSPAN system can provide.
+- This is a Linux-only implementation (because of the serial library and the system-calls for timestamps,
+this might change in the future, particularly if there is user-demand)
+- Only supports a subset of the messages a NovatelSPAN system can provide, this can be extended, but only if there is demand.
+- The binary parser currently works on little endian architectures (e.g. x86) only. This is checked at run-time.
 - Driver currently treats the hardware as data-source only, communication _to_ the hardware is possible only during initialization.
-- Driver doesn't check if configuring the receiver was successful/as-intended
+- Driver does limited checking if configuring the receiver was successful/as-intended:
+    - Driver checks for 'acks' for commands, reports 'no-acks' and retries
+    - This detects malformed commands _only_
+    - The receiver (and hence the driver) will accept commands to e.g. setup an IMU, even if no IMU is present
+- Driver does not deal with persistent storage:
+    - It is possible to make settings persistent between sessions (receiver command 'saveconfig').
+    Our driver does not use this command, but it could have been used manually.
+    - There are cases where persistent settings could interfere with normal operation of the driver. This is particularly likely
+    to happen when the hardware is shared between projects. There is no easy way to test for this, and the current implementation
+    ignores the problem completely (the user is always right).
+    - Workaround: To make sure that there are no lingering persisten settings,
+    use the receiver's 'freset' command to bring it back to factory-defaults.  The driver itself does not do this,
+    on the grounds that it also might delete settings that were made persistent with good reason and purpose.
+    If you are shareing equipment, check with everybody involved, before you use this approach.
 */
 
 /*!


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.