Ouster OS2-128 Logging Issue

I am attempting to log an Ouster OS2-128, first by using the ./sample_lidar_replay :

./sample_lidar_replay --protocol=lidar.socket --params=device=OUSTER_OS2_128,ip=192.168.1.81,dip=192.168.1.54,port=7502,hres=512,scan-frequency=10

I am getting following output in the terminal:

[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3133 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3135 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3125 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3133 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3136 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3127 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3134 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3139 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3122 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3133 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3131 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3116 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3134 us, assuming 8 packets dropped
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3123 us, assuming 8 packets dropped

Any thoughts?

Thanks

Please provide the following info:
Software Version
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.4.0.7363
other

Host Machine Version
native Ubuntu 18.04
other

Dear @mae25 ,
Could you check with frequency value 20 as well. Please share lidar configuration page picture to confirm the parameter values.

Same issue with 20Hz, please see below:

get_config_txt
{“udp_ip”: “192.168.1.54”, “udp_port_lidar”: 7502, “udp_port_imu”: 7503, “timestamp_mode”: “TIME_FROM_PTP_1588”, “sync_pulse_in_polarity”: “ACTIVE_HIGH”, “nmea_in_polarity”: “ACTIVE_HIGH”, “nmea_ignore_valid_char”: 0, “nmea_baud_rate”: “BAUD_9600”, “nmea_leap_seconds”: 0, “multipurpose_io_mode”: “OFF”, “sync_pulse_out_polarity”: “ACTIVE_HIGH”, “sync_pulse_out_frequency”: 1, “sync_pulse_out_angle”: 360, “sync_pulse_out_pulse_width”: 10, “auto_start_flag”: 1, “lidar_mode”: “512x20”, “azimuth_window”: [0, 36000], “phase_lock_enable”: true, “phase_lock_offset”: 270000}

curl -s http://curl -s http://192.168.1.81/api/v1/system/time/ptp
{“parent_data_set”: {“observed_parent_offset_scaled_log_variance”: 65535, “parent_stats”: 0, “grandmaster_identity”: “00044b.fffe.f654f7”, “gm_offset_scaled_log_variance”: 65535, “gm_clock_accuracy”: 254, “gm_clock_class”: 248, “parent_port_identity”: “00044b.fffe.f654f7-1”, “observed_parent_clock_phase_change_rate”: 2147483647, “grandmaster_priority2”: 128, “grandmaster_priority1”: 128}, “current_data_set”: {“steps_removed”: 1, “mean_path_delay”: 37444.0, “offset_from_master”: 92958.0}, “port_data_set”: {“log_announce_interval”: 1, “peer_mean_path_delay”: 0, “log_min_delay_req_interval”: 0, “port_identity”: “bc0fa7.fffe.001a66-1”, “delay_mechanism”: 1, “version_number”: 2, “announce_receipt_timeout”: 3, “log_sync_interval”: 0, “port_state”: “SLAVE”, “log_min_pdelay_req_interval”: 0}, “profile”: “default”, “time_properties_data_set”: {“leap61”: 0, “ptp_timescale”: 1, “leap59”: 0, “current_utc_offset_valid”: 0, “frequency_traceable”: 0, “current_utc_offset”: 36, “time_source”: 160, “time_traceable”: 0}, “time_status_np”: {“gm_present”: true, “scaled_last_gm_phase_change”: 0, “cumulative_scaled_rate_offset”: 0.0, “last_gm_phase_change”: “0x0000’0000000000000000.0000”, “gm_time_base_indicator”: 0, “gm_identity”: “00044b.fffe.f654f7”, “master_offset”: 92958, “ingress_time”: 1612480008727437244}}

./sample_lidar_replay --protocol=lidar.socket --params=device=OUSTER_OS2_128,ip=192.168.1.81,dip=192.168.1.54,port=7502,hres=512,scan-frequency=20

Thank you.

Dear @mae25 ,
We will look into it and get back to you soon. Can you share the lidar FW version too. Also, do you notice such issue with other lidars too?

See below for FW version. I have not experienced this with other lidars.

fw ousteros-image-prod-aries-v2.0.0+20201124065024

Thank you.

FYI Wireshark output:

No. Time Source Destination Protocol Length Info
2891 3.055671079 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=11840, ID=f324) [Reassembled in #2899]
2892 3.055674503 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=13320, ID=f324) [Reassembled in #2899]
2893 3.055677927 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=14800, ID=f324) [Reassembled in #2899]
2894 3.055681191 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=16280, ID=f324) [Reassembled in #2899]
2895 3.055684647 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=17760, ID=f324) [Reassembled in #2899]
2896 3.055687815 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=19240, ID=f324) [Reassembled in #2899]
2897 3.055691527 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=20720, ID=f324) [Reassembled in #2899]
2898 3.055694919 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=22200, ID=f324) [Reassembled in #2899]
2899 3.055698343 192.168.1.81 192.168.1.54 UDP 1258 39393 → 7502 Len=24896
2900 3.058844468 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=f325) [Reassembled in #2916]
2901 3.058851924 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=f325) [Reassembled in #2916]
2902 3.058874836 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=2960, ID=f325) [Reassembled in #2916]
2903 3.058879668 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=4440, ID=f325) [Reassembled in #2916]
2904 3.058883348 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=5920, ID=f325) [Reassembled in #2916]
2905 3.058887252 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=7400, ID=f325) [Reassembled in #2916]
2906 3.058890676 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=8880, ID=f325) [Reassembled in #2916]
2907 3.058894100 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=10360, ID=f325) [Reassembled in #2916]
2908 3.058898036 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=11840, ID=f325) [Reassembled in #2916]
2909 3.058901461 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=13320, ID=f325) [Reassembled in #2916]
2910 3.058905141 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=14800, ID=f325) [Reassembled in #2916]
2911 3.058908469 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=16280, ID=f325) [Reassembled in #2916]
2912 3.058911893 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=17760, ID=f325) [Reassembled in #2916]
2913 3.058915029 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=19240, ID=f325) [Reassembled in #2916]
2914 3.058918485 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=20720, ID=f325) [Reassembled in #2916]
2915 3.058922421 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=22200, ID=f325) [Reassembled in #2916]
2916 3.058925877 192.168.1.81 192.168.1.54 UDP 1258 39393 → 7502 Len=24896
2917 3.060383049 192.168.1.81 192.168.1.54 UDP 90 47678 → 7503 Len=48
2918 3.061530426 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=f327) [Reassembled in #2934]
2919 3.061536954 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=f327) [Reassembled in #2934]
2920 3.061540634 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=2960, ID=f327) [Reassembled in #2934]
2921 3.061544218 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=4440, ID=f327) [Reassembled in #2934]
2922 3.061547706 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=5920, ID=f327) [Reassembled in #2934]
2923 3.061550938 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=7400, ID=f327) [Reassembled in #2934]
2924 3.061554042 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=8880, ID=f327) [Reassembled in #2934]
2925 3.061557370 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=10360, ID=f327) [Reassembled in #2934]
2926 3.061560890 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=11840, ID=f327) [Reassembled in #2934]
2927 3.061564378 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=13320, ID=f327) [Reassembled in #2934]
2928 3.061567546 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=14800, ID=f327) [Reassembled in #2934]
2929 3.061571162 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=16280, ID=f327) [Reassembled in #2934]
2930 3.061574330 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=17760, ID=f327) [Reassembled in #2934]
2931 3.061577850 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=19240, ID=f327) [Reassembled in #2934]
2932 3.061581146 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=20720, ID=f327) [Reassembled in #2934]
2933 3.061584506 192.168.1.81 192.168.1.54 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=22200, ID=f327) [Reassembled in #2934]
2934 3.061603995 192.168.1.81 192.168.1.54 UDP 1258 39393 → 7502 Len=24896

Also more terminal output:

sudo ./sample_lidar_replay --protocol=lidar.socket --params=device=OUSTER_OS2_128,ip=192.168.1.81,dip=192.168.1.54,port=7502,hres=512,scan-frequency=10
Starting my sample application…
[08-02-2021 12:37:40] Platform: Detected DDPX - Tegra A
[08-02-2021 12:37:40] TimeSource: monotonic epoch time offset is 1612798328626817
[08-02-2021 12:37:40] PTP Time is available from NVPPS Driver
[08-02-2021 12:37:40] Platform: number of GPU devices detected 1
[08-02-2021 12:37:40] Platform: currently selected GPU device integrated ID 0
[08-02-2021 12:37:40] Context::getDataPathFromSelfLocation DATA_ROOT found at: /usr/local/driveworks-3.5/data
[08-02-2021 12:37:40] SDK: No resources(.pak) mounted, some modules will not function properly
[08-02-2021 12:37:40] SDK: Create NvMediaDevice
[08-02-2021 12:37:40] SDK: Create NvMedia2D
[08-02-2021 12:37:40] SDK: use EGL display as provided
[08-02-2021 12:37:40] TimeSource: monotonic epoch time offset is 1612798328626817
[08-02-2021 12:37:40] PTP Time is available from NVPPS Driver
[08-02-2021 12:37:40] Initialize DriveWorks SDK v3.5.75
[08-02-2021 12:37:40] Release build with GNU 7.3.1 from heads/buildbrain-branch-0-gc61a9a35bd0 against Drive PDK v5.2.0.0
[08-02-2021 12:37:40] SensorFactory::createSensor() → lidar.socket, device=OUSTER_OS2_128,ip=192.168.1.81,dip=192.168.1.54,port=7502,hres=512,scan-frequency=10
[08-02-2021 12:37:40] LidarSocket::getParameters, return-mode not specified. Using default value DUAL
[08-02-2021 12:37:40] hfov-start is empty, default value 0 will be used
[08-02-2021 12:37:40] hfov-end is empty, default value 360 will be used
[08-02-2021 12:37:40] Destination IP address, Horizontal Resolution is used only by OUSTER Lidar
[08-02-2021 12:37:40] Return Mode is used only by Velodyne Lidar
[08-02-2021 12:37:40] Horizontal FOV is used only by Ouster and Velodyne Lidars
[08-02-2021 12:37:40] , Device magic number = 3235826430
[08-02-2021 12:37:40] Sensor RUNNING
[08-02-2021 12:37:40] Serial number = 992032000332
Firmware version = ousteros-image-prod-aries-v2.0.0+20201124065024
[08-02-2021 12:37:40] LidarSocket::LidarSocket, connected to 192.168.1.81:7502
[08-02-2021 12:37:40] Initialize DriveWorks VisualizationSDK v3.5.75
[08-02-2021 12:37:40] Initialize DriveWorksGL SDK v3.5.75
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3122 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3124 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3125 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 87454 us, assuming 224 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3133 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3120 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3126 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 3126 us, assuming 8 packets dropped
[08-02-2021 12:37:40] LidarUdp: detected a gap in sensor timestamps: 87483 us, assuming 224 packets dropped

Dear @mae25 ,
The command seems to be correct. Could you share cat /proc/interrupts | grep eth0.rx

cat /proc/interrupts | grep eth0.rx
90: 1013397 0 0 0 0 0 0 GIC-0 222 Level eth0.rx0
91: 3183 0 0 0 0 0 0 GIC-0 223 Level eth0.rx1
92: 0 0 0 0 0 0 0 GIC-0 224 Level eth0.rx2
93: 0 0 0 0 0 0 0 GIC-0 225 Level eth0.rx3

Any other info I can provide?

Dear @mae25 ,
Could you confirm if any other load on CPU? Make sure CPU is standalone when running this task and profile the CPU load while running this task.

No other load except Ubuntu Desktop, I can check the CPU load today. Can you explain how to make sure CPU is standalone?

Thanks,

Marc

Dear @mae25,
You can check CPU load with top utility while running the application.
Could you check with hres=2048 parameter and provide feedback.
Also please check the below value.

watch -n 1 'ethtool -S eth0 | grep fifo'

expected value: mmc_rx_fifo_overflow: 0

Same issue with 2048x10 and 1024x20 etc.

top output below:

top - 01:46:15 up 10 min, 1 user, load average: 4.43, 4.24, 2.64
Tasks: 461 total, 2 running, 396 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.7 us, 3.9 sy, 0.0 ni, 90.3 id, 0.0 wa, 0.4 hi, 0.8 si, 0.0 st
KiB Mem : 28984432 total, 25688576 free, 2103336 used, 1192520 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 26109340 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1232 root 20 0 24.249g 69124 53416 S 15.1 0.2 0:32.53 Xorg
2102 nvidia 20 0 872920 111324 68720 R 14.5 0.4 0:34.76 compiz
2642 nvidia 20 0 598280 35632 26076 S 7.9 0.1 0:07.76 gnome-term+
1934 nvidia 20 0 260196 26320 20224 S 4.6 0.1 0:03.43 bamfdaemon
142 root -51 0 0 0 0 S 3.3 0.0 0:06.32 irq/111-ho+
3828 nvidia 20 0 29.583g 436756 160528 S 3.3 1.5 0:01.68 sample_lid+
948 root -51 0 0 0 0 S 2.3 0.0 0:11.84 irq/90-eth+
208 root 20 0 0 0 0 I 2.0 0.0 0:02.96 kworker/u1+
1250 root 20 0 0 0 0 S 2.0 0.0 0:03.32 nvgpu_chan+
2282 nvidia 20 0 2855400 413420 182660 S 2.0 1.4 1:16.95 firefox
2483 nvidia 20 0 2751772 355388 123676 S 1.6 1.2 1:56.13 Web Content
3734 root 20 0 0 0 0 I 1.6 0.0 0:00.33 kworker/u1+
3825 nvidia 20 0 7972 3564 2580 R 1.0 0.0 0:00.81 top
220 root -51 0 0 0 0 S 0.7 0.0 0:01.96 irq/116-15+
573 root -51 0 0 0 0 S 0.7 0.0 0:00.75 irq/41-gr-+
9 root -2 0 0 0 0 S 0.3 0.0 0:01.07 ktimersoft+
10 root -2 0 0 0 0 I 0.3 0.0 0:00.98 rcu_preempt
32 root -2 0 0 0 0 S 0.3 0.0 0:00.16 rcuc/2
33 root -2 0 0 0 0 S 0.3 0.0 0:00.97 ktimersoft+
60 root -2 0 0 0 0 S 0.3 0.0 0:00.73 ktimersoft+
213 root -2 0 0 0 0 S 0.3 0.0 0:00.82 tegradc.0/a
221 root 20 0 0 0 0 S 0.3 0.0 0:00.66 nvmap-bz
269 root -51 0 0 0 0 S 0.3 0.0 0:00.87 irq/490-xh+
571 root -51 0 0 0 0 S 0.3 0.0 0:01.01 irq/40-gr-+
572 root -50 0 0 0 0 S 0.3 0.0 0:00.34 irq/40-s-g+
1102 root 20 0 94692 1712 1500 S 0.3 0.0 0:00.20 nvccp_daem+
1178 root 20 0 22124 1632 1372 S 0.3 0.0 0:00.11 fanctrl
1682 nvidia 20 0 7544 4664 3092 S 0.3 0.0 0:01.25 dbus-daemon
2115 nvidia 20 0 369080 32352 22756 S 0.3 0.1 0:01.50 unity-pane+

watch -n 1 ‘ethtool -S eth0 | grep fifo’ output below:

mmc_rx_fifo_overflow: 0

Thanks,

Marc

Also, I noticed that the sample_lidar_replay example default azimuth_window is: requested setting is “[0, 36000]”

Looking at the OS2-128 documentation from Ouster:

azimuth_window <[min_bound_millideg, max_bound_millideg]>
Sets the visible region of interest of the sensor in millidegrees. Only data from the within the specified azimuth window bounds is sent.
[0,360000] (defaults to an azimuth window of 360°)

Seems like these setting may be off by a factor of 10… Could this be part of the issue? If I try to test this by changing one setting by a factor of 10 I get an error like this: “initializeOuster: Current get_config_param active azimuth_window is “[0, 360000]”, requested setting is “[0, 36000]” !!!”

Thanks,

Marc

Also, I am curious about the time gap in the error messages:

$ ./sample_lidar_replay --protocol=lidar.socket --params=device=OUSTER_OS2_128,ip=192.168.1.81,dip=192.168.1.54,port=7502,hres=1024,scan-frequency=20

[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 777 us, assuming 8 packets dropped
[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 782 us, assuming 8 packets dropped
[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 782 us, assuming 8 packets dropped
[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 781 us, assuming 8 packets dropped
[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 784 us, assuming 8 packets dropped
[20-02-2021 02:48:09] LidarUdp: detected a gap in sensor timestamps: 781 us, assuming 8 packets dropped

The errors states “assuming 8 packets dropped” but I believe ~780us should only be one packet: 20Hz is 0.05s per revolution (frame) with 1024 columns per frame and 16 columns per packet… so 16/1024 x .05 = 0.000781s or 781us…

get_lidar_data_format
{“pixels_per_column”: 128, “columns_per_packet”: 16, “columns_per_frame”: 1024…

What do you think?

It does seem that the detected gap in sensor timestamp is correct for 1 packet in all of these setting cases.

Ex, for hres=512,scan-frequency=10 the error message is:
[03-02-2021 22:00:24] LidarUdp: detected a gap in sensor timestamps: 3133 us, assuming 8 packets dropped

But 16/512 x 1/10Hz = 3125us.

It seems that the sample is looking for too many packets in time…

Just to reiterate my last couple posts. The time gap between sensor timestamps is as expected for each configuration, ie 3124 us for 512x10 (16/512 x 1/10Hz). The larger time gaps seem like they could be related to the difference in horizontal field of view notation between the sample and the sensor, ie factor of 10 difference 360000 vs 36000. I think the sample is looking for 360 degrees while the OS2 to match the setting (in milli-degrees) is only outputting 0-36 degrees. Hence in the example below there are 4 packets and then a larger gap. 4 packets is what it would take the sensor to output 36 degrees: 16/512 x 360 = 11.25deg/packet so 3+ packets for 36 degrees.

Thank you.

Dear @mae25 ,
mmc_rx_fifo_overflow: 0 indicates no packet drop from tegra.
We support FW version which should have only 2 packets per column. 16 columns per packet version of FW is not supported by us. Can you reach out to Ouster.

Can you let me know what FW version you have had the Driveworks sample working with an OS-128 so I can talk to Ouster? The Ouster software user manual for the previous FW v1.13 also states 16 columns per packet: