Release v5.0.5

Author: Matt Woodward

c/include/libsbp/version.h

@@ -25,10 +25,10 @@
 /** Protocol minor version. */
 #define SBP_MINOR_VERSION 0
 /** Protocol patch version. */
-#define SBP_PATCH_VERSION 3
+#define SBP_PATCH_VERSION 5
 
 /** Full SBP version string. */
-#define SBP_VERSION "5.0.4-alpha"
+#define SBP_VERSION "5.0.5"
 
 /** Is this a staging branch? */
 #define SBP_STAGING 0

docs/sbp.pdf

@@ -1,5 +1,5 @@
 name:                  sbp
-version:               5.0.4-alpha
+version:               5.0.5
 synopsis:              SwiftNav's SBP Library
 homepage:              https://github.com/swift-nav/libsbp
 license:               MIT

haskell/sbp.cabal

@@ -1 +1 @@
-5.0.4-alpha
+5.0.5

javascript/sbp/RELEASE-VERSION

@@ -27,12 +27,11 @@ types:
       with the indications on the device itself. Measurement units, which are
       specific to the device hardware and settings, are communicated via the
       MSG_IMU_AUX message. If using "time since startup" local time tags, the
-      receiving end will expect a `MSG_PPS_TIME` regardless of GNSS fix state.
-      This also requires that the MSG_PPS_TIME message be sent prior to any
-      IMU RAW messages that are based on the current (as measured at the PPS
-      edge) local time timestamps. The local time (as defined in the
-      MSG_PPS_TIME message) must wrap around to zero when reaching the extent
-      of the u64 "Local time in microseconds" parameter.
+      receiving end will expect either a MSG_GNSS_TIME_OFFSET or MSG_PPS_TIME
+      to establish the relationship between IMU time and GNSS time.
+      Regardless of the timestamping mode, the timestamp is required to roll
+      over to zero when reaching one week (604800 seconds, or 604800000
+      milliseconds).
       The time-tagging mode should not change throughout a run.
     seq:
       - id: tow

kaitai/ksy/imu.ksy

@@ -8,7 +8,7 @@
 # EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
 # WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Kaitai Struct definition file for Swift Binary Protocol 5.0.5-alpha
+# Kaitai Struct definition file for Swift Binary Protocol 5.0.5
 #
 # Automatically generated with generate.py.  Do not hand edit!
 

kaitai/ksy/sbp.ksy

@@ -283,16 +283,17 @@ types:
     doc: |
       The PPS time message contains the value of the sender's local time in
       microseconds at the moment a pulse is detected on the PPS input. This is
-      to be used for syncronisation of sensor data sampled with a local
+      to be used for synchronisation of sensor data sampled with a local
       timestamp (e.g. IMU or wheeltick messages) where GNSS time is unknown to
       the sender.
 
       The local time used to timestamp the PPS pulse must be generated by the
       same clock which is used to timestamp the IMU/wheel sensor data and
-      should follow the same roll-over rules.  A separate MSG_PPS_TIME message
-      should be sent for each source of sensor data which uses PPS-relative
-      timestamping.  The sender ID for each of these MSG_PPS_TIME messages
-      should match the sender ID of the respective sensor data.
+      should follow the same roll-over rules (i.e. it should roll over to zero
+      after 604800 seconds). A separate MSG_PPS_TIME message should be sent
+      for each source of sensor data which uses local timestamping.  The
+      sender ID for each of these MSG_PPS_TIME messages should match the
+      sender ID of the respective sensor data.
     seq:
       - id: time
         doc: |

kaitai/ksy/system.ksy

@@ -27,10 +27,11 @@ types:
       offset for the odometry reference point and the definition and origin of
       the user frame are defined through the device settings interface. There
       are 4 possible user-defined sources of this message which are labeled
-      arbitrarily source 0 through 3. If using "processor time" time tags, the
-      receiving end will expect a `MSG_GNSS_TIME_OFFSET` when a PVT fix
-      becomes available to synchronise odometry measurements with GNSS.
-      Processor time shall roll over to zero after one week.
+      arbitrarily source 0 through 3.
+      If using "processor time" time tags, the receiving end will expect
+      either  `MSG_GNSS_TIME_OFFSET` or `MSG_PPS_TIME` to sync incoming
+      odometry data to GNSS time.  Processor time shall roll over to zero
+      after one week.
     seq:
       - id: tow
         doc: |
@@ -57,10 +58,10 @@ types:
       from 0 to 255. The timestamp associated with this message should
       represent the time when the accumulated tick count reached the value
       given by the contents of this message as accurately as possible. If
-      using "local CPU time" time tags, the receiving end will expect a
-      `MSG_GNSS_TIME_OFFSET` when a PVT fix becomes available to synchronise
-      wheeltick measurements with GNSS. Local CPU time shall roll over to zero
-      after one week.
+      using "local CPU time" time tags, the receiving end will also expect
+      either `MSG_GNSS_TIME_OFFSET` or `MSG_PPS_TIME` to sync incoming
+      wheeltick data to GNSS time.
+      Local CPU time shall roll over to zero after one week.
     seq:
       - id: time
         doc: |

kaitai/ksy/vehicle.ksy

@@ -23,12 +23,11 @@ class MsgImuRaw(KaitaiStruct):
         with the indications on the device itself. Measurement units, which are
         specific to the device hardware and settings, are communicated via the
         MSG_IMU_AUX message. If using "time since startup" local time tags, the
-        receiving end will expect a `MSG_PPS_TIME` regardless of GNSS fix state.
-        This also requires that the MSG_PPS_TIME message be sent prior to any
-        IMU RAW messages that are based on the current (as measured at the PPS
-        edge) local time timestamps. The local time (as defined in the
-        MSG_PPS_TIME message) must wrap around to zero when reaching the extent
-        of the u64 "Local time in microseconds" parameter.
+        receiving end will expect either a MSG_GNSS_TIME_OFFSET or MSG_PPS_TIME
+        to establish the relationship between IMU time and GNSS time.
+        Regardless of the timestamping mode, the timestamp is required to roll
+        over to zero when reaching one week (604800 seconds, or 604800000
+        milliseconds).
         The time-tagging mode should not change throughout a run.
         """
         def __init__(self, _io, _parent=None, _root=None):

kaitai/python/kaitai_sbp/imu.py

@@ -113,16 +113,17 @@ def _read(self):
     class MsgPpsTime(KaitaiStruct):
         """The PPS time message contains the value of the sender's local time in
         microseconds at the moment a pulse is detected on the PPS input. This is
-        to be used for syncronisation of sensor data sampled with a local
+        to be used for synchronisation of sensor data sampled with a local
         timestamp (e.g. IMU or wheeltick messages) where GNSS time is unknown to
         the sender.
         
         The local time used to timestamp the PPS pulse must be generated by the
         same clock which is used to timestamp the IMU/wheel sensor data and
-        should follow the same roll-over rules.  A separate MSG_PPS_TIME message
-        should be sent for each source of sensor data which uses PPS-relative
-        timestamping.  The sender ID for each of these MSG_PPS_TIME messages
-        should match the sender ID of the respective sensor data.
+        should follow the same roll-over rules (i.e. it should roll over to zero
+        after 604800 seconds). A separate MSG_PPS_TIME message should be sent
+        for each source of sensor data which uses local timestamping.  The
+        sender ID for each of these MSG_PPS_TIME messages should match the
+        sender ID of the respective sensor data.
         """
         def __init__(self, _io, _parent=None, _root=None):
             self._io = _io