diff --git a/sbp.cabal b/sbp.cabal
--- a/sbp.cabal
+++ b/sbp.cabal
@@ -1,5 +1,5 @@
 name:                  sbp
-version:               5.0.4
+version:               5.0.5
 synopsis:              SwiftNav's SBP Library
 homepage:              https://github.com/swift-nav/libsbp
 license:               MIT
diff --git a/src/SwiftNav/SBP/Imu.hs b/src/SwiftNav/SBP/Imu.hs
--- a/src/SwiftNav/SBP/Imu.hs
+++ b/src/SwiftNav/SBP/Imu.hs
@@ -45,12 +45,10 @@
 -- 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.
+-- 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.
 data MsgImuRaw = MsgImuRaw
   { _msgImuRaw_tow :: !Word32
diff --git a/src/SwiftNav/SBP/System.hs b/src/SwiftNav/SBP/System.hs
--- a/src/SwiftNav/SBP/System.hs
+++ b/src/SwiftNav/SBP/System.hs
@@ -454,15 +454,16 @@
 --
 -- 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 timestamp
+-- 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.
+-- 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.
 data MsgPpsTime = MsgPpsTime
   { _msgPpsTime_time :: !Word64
     -- ^ Local time in microseconds
diff --git a/src/SwiftNav/SBP/Vehicle.hs b/src/SwiftNav/SBP/Vehicle.hs
--- a/src/SwiftNav/SBP/Vehicle.hs
+++ b/src/SwiftNav/SBP/Vehicle.hs
@@ -44,10 +44,10 @@
 -- 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.
+-- 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.
 data MsgOdometry = MsgOdometry
   { _msgOdometry_tow    :: !Word32
     -- ^ Time field representing either milliseconds in the GPS Week or local
@@ -88,9 +88,10 @@
 -- 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.
+-- 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.
 data MsgWheeltick = MsgWheeltick
   { _msgWheeltick_time :: !Word64
     -- ^ Time field representing either microseconds since the last PPS,