generate everything else

java/src/com/swiftnav/sbp/imu/MsgImuRaw.java

@@ -28,11 +28,10 @@
  * The sense of the measurements are to be aligned 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.
- * The time-tagging mode should not change throughout a run.
+ * 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.
  */
 public class MsgImuRaw extends SBPMessage {
     public static final int TYPE = 0x0900;

java/src/com/swiftnav/sbp/system/MsgPpsTime.java

@@ -26,15 +26,15 @@
  * construct it inline using a dict of its fields.
  *
  * <p>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 (e.g. IMU or wheeltick messages) where GNSS time is unknown to the
- * sender.
+ * moment a pulse is detected on the PPS input. This 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.
  *
  * <p>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.
+ * used to timestamp the IMU/wheel sensor data and 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.
  */
 public class MsgPpsTime extends SBPMessage {
     public static final int TYPE = 0xFF08;

java/src/com/swiftnav/sbp/vehicle/MsgOdometry.java

@@ -28,9 +28,9 @@
  * reference point(s) specified by the user. The 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.
+ * 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.
  */
 public class MsgOdometry extends SBPMessage {
     public static final int TYPE = 0x0903;

java/src/com/swiftnav/sbp/vehicle/MsgWheeltick.java

@@ -31,9 +31,9 @@
  * source of this message is identified by the source field, which is an integer ranging 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.
  */
 public class MsgWheeltick extends SBPMessage {
     public static final int TYPE = 0x0904;

jsonschema/MsgImuRaw.json

@@ -13,7 +13,7 @@
   "$schema": "http://json-schema.org/draft-06/schema#",
   "$id": "#MsgImuRaw",
   "title":"MsgImuRaw",
-  "description":"Raw data from the Inertial Measurement Unit, containing accelerometer and gyroscope readings. The sense of the measurements are to be aligned 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.,\nThe time-tagging mode should not change throughout a run.\n",
+  "description":"Raw data from the Inertial Measurement Unit, containing accelerometer and gyroscope readings. The sense of the measurements are to be aligned 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 either a MSG_GNSS_TIME_OFFSET or MSG_PPS_TIME to establish the relationship between IMU time and GNSS time.,\nRegardless of the timestamping mode, the timestamp is required to roll over to zero when reaching one week (604800 seconds, or 604800000 milliseconds).,\nThe time-tagging mode should not change throughout a run.\n",
   "type": "object",
   "properties": {
     "tow": {"type": "integer"},

jsonschema/MsgOdometry.json

@@ -13,7 +13,7 @@
   "$schema": "http://json-schema.org/draft-06/schema#",
   "$id": "#MsgOdometry",
   "title":"MsgOdometry",
-  "description":"Message representing the x component of vehicle velocity in the user frame at the odometry reference point(s) specified by the user. The 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.\n",
+  "description":"Message representing the x component of vehicle velocity in the user frame at the odometry reference point(s) specified by the user. The 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.,\nIf 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.\n",
   "type": "object",
   "properties": {
     "tow": {"type": "integer"},

jsonschema/MsgPpsTime.json

@@ -13,7 +13,7 @@
   "$schema": "http://json-schema.org/draft-06/schema#",
   "$id": "#MsgPpsTime",
   "title":"MsgPpsTime",
-  "description":"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 (e.g. IMU or wheeltick messages) where GNSS time is unknown to the sender.,\n,\nThe 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.\n",
+  "description":"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 synchronisation of sensor data sampled with a local timestamp (e.g. IMU or wheeltick messages) where GNSS time is unknown to the sender.,\n,\nThe 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 (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.\n",
   "type": "object",
   "properties": {
     "time": {"type": "integer"},

jsonschema/MsgWheeltick.json

@@ -13,7 +13,7 @@
   "$schema": "http://json-schema.org/draft-06/schema#",
   "$id": "#MsgWheeltick",
   "title":"MsgWheeltick",
-  "description":"Message containing the accumulated distance travelled by a wheel located at an odometry reference point defined by the user. The offset for the odometry reference point and the definition and origin of the user frame are defined through the device settings interface. The source of this message is identified by the source field, which is an integer ranging 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.\n",
+  "description":"Message containing the accumulated distance travelled by a wheel located at an odometry reference point defined by the user. The offset for the odometry reference point and the definition and origin of the user frame are defined through the device settings interface. The source of this message is identified by the source field, which is an integer ranging 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 also expect either `MSG_GNSS_TIME_OFFSET` or `MSG_PPS_TIME` to sync incoming wheeltick data to GNSS time.,\nLocal CPU time shall roll over to zero after one week.\n",
   "type": "object",
   "properties": {
     "time": {"type": "integer"},

proto/imu.proto

@@ -27,12 +27,10 @@ package swiftnav.sbp.imu;
  * 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.
  */
 message MsgImuRaw {

proto/system.proto

@@ -179,15 +179,16 @@ message MsgGnssTimeOffset {
  *
  * 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.
  */
 message MsgPpsTime {
     uint64 time = 1;

proto/vehicle.proto

@@ -27,10 +27,10 @@ package swiftnav.sbp.vehicle;
  * 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.
  */
 message MsgOdometry {
     uint32 tow = 1;
@@ -48,9 +48,10 @@ message MsgOdometry {
  * 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.
  */
 message MsgWheeltick {
     uint64 time = 1;

python/sbp/imu.py

@@ -39,12 +39,10 @@ class MsgImuRaw(SBP):
   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.
 
   Parameters

python/sbp/system.py

@@ -1219,15 +1219,16 @@ class MsgPpsTime(SBP):
   
   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.
+  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.
 
   Parameters
   ----------

python/sbp/vehicle.py

@@ -39,10 +39,10 @@ class MsgOdometry(SBP):
   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.
+  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.
 
   Parameters
   ----------
@@ -157,9 +157,9 @@ class MsgWheeltick(SBP):
   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.
+  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.
 
   Parameters
   ----------