Dear @SivaRamaKrishnaNV
Did a bit more testing yesterday. I start with the lidar in running mode and did a full capture of the parameters and then run the following command on TegraB that has DW 3.5:
./sample_lidar_replay --protocol=lidar.socket --params=device=OUSTER_OS2_128,ip=192.168.1.12,port=7502,scan-frequency=10,hres=1024,dip=192.168.1.10
The command tries to initialize the lidar but then the lidar enters error mode. Did a full capture of the config on the lidar also. As far as I can tell the only difference in config params is that the phase lock is enabled:
“phase_lock_enable”: true,
“phase_lock_offset”: 270000,
The Ouster error codes after:
{
“active”: true,
“category”: “INTERNAL_COMM”,
“cursor”: 2,
“id”: “0x01000042”,
“level”: “ERROR”,
“msg”: “Unit has experienced an internal COMM error; please contact Ouster at https://ouster.com/tech-support.”,
“msg_verbose”: “”,
“realtime”: “247880735879”
},
{
“active”: true,
“category”: “CONFIG_INVALID”,
“cursor”: 1,
“id”: “0x01000052”,
“level”: “ERROR”,
“msg”: “Configuration value is invalid or out of bounds.”,
“msg_verbose”: “timestamp_mode TIME_FROM_INTERNAL_OSC incompatible with phase_lock_enable. An external time sync source is required, see the documentation for details.”,
“realtime”: “247766906234”
}
Looks like we cannot use phase_lock_enable with TIME_FROM_INTERNAL_OSC. Do we need to setup an external ptp? Or can we force phase_lock_enable=false from the comand line? Seems that the parameter is set to true during the initialization from DW. Full log from DW is in nvidia_err_new.txt
Thank you in advance,
Gabriel
nvidia_err_new.txt (6.3 KB)
config_running.txt (2.1 KB) config_not_running.txt (3.4 KB)