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. * *
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; diff --git a/java/src/com/swiftnav/sbp/vehicle/MsgOdometry.java b/java/src/com/swiftnav/sbp/vehicle/MsgOdometry.java index 7efbdbfc62..875c0f803d 100644 --- a/java/src/com/swiftnav/sbp/vehicle/MsgOdometry.java +++ b/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; diff --git a/java/src/com/swiftnav/sbp/vehicle/MsgWheeltick.java b/java/src/com/swiftnav/sbp/vehicle/MsgWheeltick.java index afe0399bdd..a9b2432923 100644 --- a/java/src/com/swiftnav/sbp/vehicle/MsgWheeltick.java +++ b/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; diff --git a/javascript/sbp/imu.js b/javascript/sbp/imu.js index a6acbea0b5..2f5bba58a7 100644 --- a/javascript/sbp/imu.js +++ b/javascript/sbp/imu.js @@ -30,13 +30,12 @@ let UInt64 = require('cuint').UINT64; * 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. The time-tagging mode - * should not change throughout a run. + * 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. 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 in the SBP payload (`sbp.payload`): * @field tow number (unsigned 32-bit int, 4 bytes) Milliseconds since reference epoch and time status. diff --git a/javascript/sbp/system.js b/javascript/sbp/system.js index 9dd768ca91..fba08ae504 100644 --- a/javascript/sbp/system.js +++ b/javascript/sbp/system.js @@ -460,13 +460,14 @@ MsgGnssTimeOffset.prototype.fieldSpec.push(['flags', 'writeUInt8', 1]); * * 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 + * 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. + * 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 in the SBP payload (`sbp.payload`): * @field time number (unsigned 64-bit int, 8 bytes) Local time in microseconds diff --git a/javascript/sbp/vehicle.js b/javascript/sbp/vehicle.js index 44a84b2a78..d9f761d0f4 100644 --- a/javascript/sbp/vehicle.js +++ b/javascript/sbp/vehicle.js @@ -31,9 +31,9 @@ let UInt64 = require('cuint').UINT64; * 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. + * 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 in the SBP payload (`sbp.payload`): * @field tow number (unsigned 32-bit int, 4 bytes) Time field representing either milliseconds in the GPS Week or local CPU time @@ -75,9 +75,10 @@ MsgOdometry.prototype.fieldSpec.push(['flags', 'writeUInt8', 1]); * 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. + * 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. Local CPU time shall roll over to zero after one + * week. * * Fields in the SBP payload (`sbp.payload`): * @field time number (unsigned 64-bit int, 8 bytes) Time field representing either microseconds since the last PPS, microseconds in diff --git a/jsonschema/MsgImuRaw.json b/jsonschema/MsgImuRaw.json index 4285f84784..5f9b0dbe8e 100644 --- a/jsonschema/MsgImuRaw.json +++ b/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"}, diff --git a/jsonschema/MsgOdometry.json b/jsonschema/MsgOdometry.json index 7e55f74996..13bcd8fa99 100644 --- a/jsonschema/MsgOdometry.json +++ b/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"}, diff --git a/jsonschema/MsgPpsTime.json b/jsonschema/MsgPpsTime.json index 7dc75a7e8f..d62b658f60 100644 --- a/jsonschema/MsgPpsTime.json +++ b/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"}, diff --git a/jsonschema/MsgWheeltick.json b/jsonschema/MsgWheeltick.json index 1a16a3c859..0d88292c35 100644 --- a/jsonschema/MsgWheeltick.json +++ b/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"}, diff --git a/package-lock.json b/package-lock.json index 935cd2fd92..749b65e4cf 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,6 +1,6 @@ { "name": "sbp", - "version": "5.045-alpha", + "version": "5.0.4-alpha", "lockfileVersion": 2, "requires": true, "packages": { diff --git a/proto/imu.proto b/proto/imu.proto index ddf856951e..765a0bb4b0 100644 --- a/proto/imu.proto +++ b/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 { diff --git a/proto/system.proto b/proto/system.proto index 30383509ea..c27413a582 100644 --- a/proto/system.proto +++ b/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; diff --git a/proto/vehicle.proto b/proto/vehicle.proto index 05447b4eb4..d6c17e2fe1 100644 --- a/proto/vehicle.proto +++ b/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; diff --git a/python/sbp/imu.py b/python/sbp/imu.py index dd35cf611b..7145e2f697 100644 --- a/python/sbp/imu.py +++ b/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 diff --git a/python/sbp/system.py b/python/sbp/system.py index 67cf5614fa..4a095bf28c 100644 --- a/python/sbp/system.py +++ b/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 ---------- diff --git a/python/sbp/vehicle.py b/python/sbp/vehicle.py index b3d9b03de9..167a1d0497 100644 --- a/python/sbp/vehicle.py +++ b/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 ---------- diff --git a/rust/sbp/src/messages/imu.rs b/rust/sbp/src/messages/imu.rs index 97c3fa9392..429c5a8deb 100644 --- a/rust/sbp/src/messages/imu.rs +++ b/rust/sbp/src/messages/imu.rs @@ -315,12 +315,11 @@ pub mod msg_imu_raw { /// 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. /// #[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] diff --git a/rust/sbp/src/messages/system.rs b/rust/sbp/src/messages/system.rs index e2e091d6cb..47ea29c93a 100644 --- a/rust/sbp/src/messages/system.rs +++ b/rust/sbp/src/messages/system.rs @@ -1844,16 +1844,17 @@ pub mod msg_pps_time { /// /// 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. + /// 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. /// #[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] #[allow(clippy::derive_partial_eq_without_eq)] diff --git a/rust/sbp/src/messages/vehicle.rs b/rust/sbp/src/messages/vehicle.rs index 4018707d93..40b48053f9 100644 --- a/rust/sbp/src/messages/vehicle.rs +++ b/rust/sbp/src/messages/vehicle.rs @@ -29,10 +29,10 @@ pub mod msg_odometry { /// 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. /// #[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] #[allow(clippy::derive_partial_eq_without_eq)] @@ -312,9 +312,10 @@ pub mod msg_wheeltick { /// 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. + /// 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. /// #[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] #[allow(clippy::derive_partial_eq_without_eq)] diff --git a/sbpjson/elm/SbpJson.elm b/sbpjson/elm/SbpJson.elm index cd90548731..3cbc8c33e3 100644 --- a/sbpjson/elm/SbpJson.elm +++ b/sbpjson/elm/SbpJson.elm @@ -1790,11 +1790,10 @@ type alias MsgImuAux = 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., +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., +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. -} type alias MsgImuRaw = @@ -2096,10 +2095,10 @@ type alias CarrierPhase = 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. +labeled 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. -} type alias MsgOdometry = { flags : Int @@ -2414,15 +2413,16 @@ type alias MsgPoseRelative = } {-| 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 +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., , 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. +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. -} type alias MsgPpsTime = { flags : Int @@ -3450,9 +3450,9 @@ interface. The source of this message is identified by the source field, which i 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. +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. -} type alias MsgWheeltick = { flags : Int diff --git a/sbpjson/typescript/SbpJson.ts b/sbpjson/typescript/SbpJson.ts index 7c1aed47f0..844ef2152f 100644 --- a/sbpjson/typescript/SbpJson.ts +++ b/sbpjson/typescript/SbpJson.ts @@ -1268,11 +1268,10 @@ export interface MsgImuAux { * 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., + * 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., + * 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. */ export interface MsgImuRaw { @@ -1641,10 +1640,10 @@ export interface CarrierPhase { * 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. + * labeled 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. */ export interface MsgOdometry { flags: number; @@ -1992,15 +1991,16 @@ export interface MsgPoseRelative { /** * 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 + * 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., * , * 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. + * 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. */ export interface MsgPpsTime { flags: number; @@ -3188,9 +3188,9 @@ export interface MsgVelNEDGnss { * 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. + * 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. */ export interface MsgWheeltick { flags: number; diff --git a/spec/yaml/swiftnav/sbp/imu.yaml b/spec/yaml/swiftnav/sbp/imu.yaml index f8236cc25d..eba78675f6 100644 --- a/spec/yaml/swiftnav/sbp/imu.yaml +++ b/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: diff --git a/spec/yaml/swiftnav/sbp/system.yaml b/spec/yaml/swiftnav/sbp/system.yaml index f5bfd4fc45..3171abb1e4 100644 --- a/spec/yaml/swiftnav/sbp/system.yaml +++ b/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 diff --git a/spec/yaml/swiftnav/sbp/vehicle.yaml b/spec/yaml/swiftnav/sbp/vehicle.yaml index 6910a2323c..a2e8599e48 100644 --- a/spec/yaml/swiftnav/sbp/vehicle.yaml +++ b/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