From a8df311f71c69ad29f44733aef89e407b5679a10 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Tue, 6 Apr 2010 11:34:53 -0400 Subject: Update for the fact that drivers now put fix information in newdata. --- www/hacking.html | 43 ++++++++++++++++--------------------------- 1 file changed, 16 insertions(+), 27 deletions(-) (limited to 'www') diff --git a/www/hacking.html b/www/hacking.html index 9dcb0876..aa6718b0 100644 --- a/www/hacking.html +++ b/www/hacking.html @@ -108,20 +108,7 @@ file in the source distribution.

  • Report errors with a 95% confidence interval
  • Log files for regression testing
  • -
  • The buffering problem
  • -
      -
    1. Mapping the design space
    2. -
        -
      1. Report then clear per packet
      2. -
      3. Buffer all, report then clear on trigger
      4. -
      5. Buffer all, report on every packet, clear at start-of-cycle
      6. -
      7. Buffer all, report on every packet, never clear data
      8. -
      9. Buffer all, report on every packet, time out old data
      10. -
      -
    3. There is no perfect option
    4. -
    5. Combining buffering with interpolation: a speculative design
    6. -
    -
  • Designing Ahead
  • +
  • Future Protocol Directions
    1. Non-TPV Data
    2. Design Sketch for GPSD-NG, the Next-Generation GPSD Protocol
    3. @@ -1065,15 +1052,16 @@ See the Garmin binary driver for an example.

      Where to put the data you get from the GPS

      -

      Your driver should put new data from each incoming packet or sentence -in the 'gpsdata' member of the GPS, and return a validity flag mask -telling what members were updated (all float members are initially set --> -to not-a-number. as well). There is driver-independent code -that will be responsible for merging that new data into the existing -fix. To assist this, the CYCLE_START_SET flag is special. Set this -when the driver returns the first timestamped message containing fix -data in an update cycle. (This excludes satellite-picture messages -and messages about GPS status that don't contain fix data.)

      +

      Your driver should put new data from each incoming packet or +sentence in the 'gpsdata' member of the GPS (fixes go in the 'newdata' +member), and return a validity flag mask telling what members were +updated (all float members are initially set to not-a-number. as +well). There is driver-independent code that will be responsible for +merging that new data into the existing fix. To assist this, the +CYCLE_START_SET flag is special. Set this when the driver returns the +first timestamped message containing fix data in an update cycle. +(This excludes satellite-picture messages and messages about GPS +status that don't contain fix data.)

      Your packet parser must return field-validity mask bits (using the _SET macros in gps.h), suitable to be put in session->gpsdata.valid. @@ -1378,10 +1366,11 @@ the following order:

      href="http://developer.berlios.de/bugs/?group_id=2116">Berlios bug tracker for release blockers.
      -
      2. Run the stable regression tests and other checks
      If it -doesn't pass regressions, it isn't ready to ship. This is the time to -run valgrind-audit, 'make splint', and 'make cppcheck' as well and -check that those reports are clean.
      +
      2. Run the stable regression tests and other checks
      +
      If it doesn't pass regressions, it isn't ready to ship. This is +the time to run valgrind-audit, 'make splint', and 'make cppcheck' as +well and check that those reports are clean. Use flocktest to +verify operation on the remote test machines.
      3. Issue the pre-release heads-up
      About 48 hours before release, announce that it's coming so people -- cgit v1.2.1