Sync GMSL cameras via PTP from ETH0

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX Xavier General
1

Hello,

how to synchronize the GMSL camera by a PTP clock coming from ETH0?

On Xavier A and Xavier B we have a PTP slave running using “/usr/sbin/ptpd -c /etc/ptpd2.conf”

The /etc/ptpd2.conf has following settings:

; interface has to be specified
ptpengine:interface=eth0

; PTP domain
ptpengine:domain=0

; available presets are slaveonly, masteronly and masterslave (full IEEE 1588 implementation)
ptpengine:preset=slaveonly

; multicast for both sync and delay requests - use hybrid for unicast delay requests
ptpengine:ip_mode=multicast

; when enabled, sniffing is used instead of sockets to send and receive packets
ptpengine:use_libpcap=n

; log file, event log only. if timing statistics are needed, see statistics_file
global:log_file=/var/log/ptpd2.log

; status file providing an overview of ptpd's operation and statistics
global:log_status=y

Using wireshark we see the PTP messages exchanged and using date we see the Xavier’s clock in sync with host PC.

The dwImage_getTimestamp() timestamps from GMSL cameras look pretty weak with high jitter.

dwInitialize()outputs:

[25-11-2021 17:56:39] TimeSource: Could not detect valid PTP time source at nvpps. Fallback to eth0
[25-11-2021 17:56:39] TimeSource Eth: Lost PTP time synchronizaton. Synchronized time will not be available from this timesource.
[25-11-2021 17:56:39] TimeSource: Could not detect valid PTP time source at 'eth0'. Fallback to CLOCK_MONOTONIC.

How to sync the GMSL cameras?

GMSL camera sync uses an external trigger and GMSL cameras are connected to one group, only. We like to use PTP via ETH0 as source clock and use all groups.

We tried the recommendation from What's the GlobalTimeStamp

./phc2sys -s /dev/ptp0 -w -S 1.0 -O 0 &
./ptp4l -f ./gPTP_slave.cfg -p /dev/ptp0 -i eth0 -m

but how to specify ETH0 as the clock source ?

Thanks for your support
Andreas

Please provide the following info (check/uncheck the boxes after creating this topic):
Software Version
DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
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.7.0.8846
other

Host Machine Version
native Ubuntu 18.04
other

3

Dear @andreas.schwager,
The dwImage_getTimestamp() timestamps from GMSL cameras look pretty weak with high jitter

Could you provide more details on this.

Also, may I know why you are looking for this use case?

4

Dear SivaRamaKrishnaNV,

we expect the timestamps received from images to be equidistant and constant over a very long time. If the distance between timestamps varies, this causes issues to the post processing.

We expect that the camera has a very reproducible behavioral. The Exposure time, readout of image sensor, transmitting data to host, camera’s frame-rate, etc should be constant. We expect the jitter (variations between timestamps) to be caused at data receiving point.
This is why the camera has to have a precise clock, which should be synced with host PC. Cameras have to add the time of shutter open to the image stream. So post-processing will be able to localize the image on the time-axis.

My question was how to synchronize GMSL cameras?
The Xaviers are synced via PTP on EHT0 from Logger-PC. How to transport this clock to cameras?

Thanks
Andreas

5

Dear @andreas.schwager,
how to synchronize GMSL cameras?

The camera are synchrized already via a PWM signal on a GPIO pin that is connected to all deserializers. We expect to have no issue with camera sync in general. If you see issue with camera timestamps, could you share steps/sample to reproduce this

The Xaviers are synced via PTP on EHT0 from Logger-PC. How to transport this clock to cameras?

We will check internally on this and update you

6

Dear @andreas.schwager,
Could you share steps to reproduce the jitter in camera timestamps?

7

Dear SivaRamaKrishnaNV,

The camera timestamps are copied into the header of the ROS messages.

We compare the difference between the time stamps at the host PC receiving the ROS topics.

Why do we see after calling dwInitialize() this output:

TimeSource: Could not detect valid PTP time source at 'eth0'. Fallback to CLOCK_MONOTONIC.

The Xavier’s system clock is synchronized via ETH0. So why can dwInitialize() not utilize the same source than the system clock?

Thanks

Andreas

8

Dear @andreas.schwager,
We expect the GMSL camera to be in sync. Could you modify DW GMSL camera sample, check the dwImage_getTimestamp() for camera frames and confirm if you see difference in timestamps. This help us to debug the issue on our side.

9

Dear SivaRamaKrishnaNV,

in the meantime, I agree: the GMSL cameras are in sync.
I was uncertain, because of the error message described, above.

Thanks a lot for your support
Andreas