Ouster OS1-64-U13-SR Rev 7.1 sensor is producing corrupted synchronized IMU timestamps during PCAP recording

Hardware
1

Hello,

I need help diagnosing a timing problem with an Ouster OS1-64-U13-SR, Rev 7.1 (Rev071), running firmware 3.2.0.

The sensor is being used with an external PolyNav GNSS/INS system. The PolyNav PPS output is connected to the Ouster SYNC_PULSE_IN input, and the PolyNav serial NMEA output is connected to the Ouster MULTIPURPOSE_IO input.

Ouster configuration:

  • UDP profile: ACCEL32_GYRO32_NMEA
  • Timestamp mode: TIME_FROM_SYNC_PULSE_IN
  • MIO mode: INPUT_NMEA_UART
  • NMEA sentence: $GPRMC
  • Baud rate: 9600
  • NMEA polarity: ACTIVE_LOW
  • PPS polarity: ACTIVE_LOW
  • NMEA ignore-valid-character: 0
  • NMEA leap seconds: 0
  • Sync pulse polarity: ACTIVE_LOW

The problem is not a normal packet-loss problem.

The recorded PCAP contains:

  • 44,799 LiDAR packets
  • 5,600 IMU packets
  • 701 LiDAR frames
  • Continuous LiDAR frame IDs
  • No missing LiDAR frame IDs
  • No invalid LiDAR packets
  • Normal host packet-arrival timing

However, the timestamps assigned to the individual synchronized IMU measurements are not continuous.

Under normal operation, the eight IMU measurements in each packet should have approximately millisecond-level spacing. In this recording, consecutive IMU measurements suddenly become separated by multi-second intervals. The abnormal timestamp differences include approximately 3, 4, 5, 6, 7, 8, 9, 10, and 11 seconds.

The important distinction is:

  • The IMU packets arrive at the computer normally.
  • The LiDAR packets arrive normally.
  • The PolyNav navigation file remains continuous at 10 ms intervals.
  • The Ouster sensor timestamps assigned to the synchronized IMU measurements jump by several seconds.

When the PCAP is processed with the Ouster SDK/CLI using imu_deskew, the resulting SLAM trajectory becomes severely corrupted. The point cloud stretches, breaks apart, and collapses into disconnected or incorrectly placed sections. The failure is already present in the PCAP before any custom processing, external coordinate transformation, BestNav placement, or PoseOptimizer processing is performed.

This suggests that the problem is occurring at the Ouster sensor timing or synchronized IMU timestamping stage, rather than in the downstream SLAM code.

The external PolyNav UTC record is continuous during the affected period, but we do not yet know whether the exact same $GPRMC sentence was successfully decoded by the Ouster MIO input at that moment.

Could you please advise:

  1. Can Ouster synchronized IMU timestamps exhibit multi-second discontinuities when the sensor is configured for TIME_FROM_SYNC_PULSE_IN?

  2. Can the sensor report nmea.locked = 1 and sync_pulse_in.locked = 1 while the sensor clock is still being corrected or repeatedly resynchronized?

  3. Could an intermittent PPS/NMEA pairing problem cause the individual ACCEL32_GYRO32_NMEA measurement timestamps to jump while packet-arrival timing remains normal?

  4. What exact live diagnostic fields should be monitored to verify the MIO and PPS inputs?

We believe the following fields are relevant:

  • nmea.locked
  • sync_pulse_in.locked
  • last_read_message
  • utc_decoded_count
  • date_decoded_count
  • not_valid_count
  • sync pulse count
  • sync pulse period
  • timestamp.mode

Should last_read_message contain a complete $GPRMC sentence?

Should timestamp.mode report TIME_FROM_SYNC_PULSE_IN continuously during recording?

Is this behavior known with firmware 3.2.0, ACCEL32_GYRO32_NMEA, or TIME_FROM_SYNC_PULSE_IN? Would you recommend a firmware update or a different timing configuration?

Thank you.

2

Hi @mikehrub,

It’s possible this is an issue with your GPS time synching input and not the IMU. Can you first check to see if the lidar timestamps and imu timestamps are both jumping?

If both GPS and IMU timestamps are jumping together then this is probably an issue with the GPS time syncing resetting the lidar’s system time every couple seconds which the lidar then uses to timestamp both lidar and imu data.

You can access the IMU and lidar timestamps and other GPS information with the following in python SDK:

print(scan.timestamp)  # Lidar timestamps
print(scan.field("IMU_TIMESTAMP")  # IMU timestamps```
print(scan.field("POSITION_STRING")  # The most recent NMEA message string received from the sensor

You can see what other information is available for the IMU and GPS (“position”) here:

imu_and_gps_fields
imu_and_gps_fields1628×1022 58.7 KB

If you can share a PCAP or OSF file that would help debug if further debugging is needed.