Clarify timestamping descriptions [AP-1087]

spec/yaml/swiftnav/sbp/imu.yaml

@@ -25,12 +25,11 @@ definitions:
       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.
     fields:

spec/yaml/swiftnav/sbp/system.yaml

@@ -451,18 +451,18 @@ definitions:
     desc: >
       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
+      is 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.
     fields:
         - time:
             type: u64

spec/yaml/swiftnav/sbp/vehicle.yaml

@@ -23,9 +23,10 @@ definitions:
       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.
+
+      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.
     fields:
         - tow:
             type: u32
@@ -77,9 +78,10 @@ definitions:
       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.
+      If 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.
     fields:
         - time:
             type: u64