How to get exposure start time (UNIX/Epoch) and exposure duration in DriveWorks ? (IMX728, DriveOS 6.0.10.0)

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Environment

・DriveOS Linux: 6.0.10.0
・DriveWorks SDK: 5.20
・Camera: Smartlead Sony IMX728 (120deg)
・NITO file: R0SIM728S3RU2120NB2

Questions about exposure start timestamp and exposure time

1. Exposure start timestamp in DriveWorks

Is there a timestamp in the DriveWorks API that corresponds to the exposure start time (shutter open time)?

By “UNIX time” here, I mean an absolute time referenced to the Epoch (UTC), or a time synchronized to PTP / GPS / PPS
If such a timestamp exists, could you please point me to the relevant field or API?

2. Exposure duration in DriveWorks

Is it possible to obtain the exposure duration (i.e., the time interval from exposure start to exposure end) using the DriveWorks API?

3. Interpretation of dwImageTimestamps

I retrieved dwImageTimestamps in DriveWorks and obtained the following values:

(unit: microseconds)

  • sofTimestampUs: 1773216785276383
  • moeTimestampUs: 1773216785286662
  • eofTimestampUs: 1773216785306942
  • subExposureStartTimestampUs[0]: 1773216785276383
  • subExposureStartTimestampUs[1]: 1773216785276383
  • subExposureStartTimestampUs[2]: 1773216785276383
  • subExposureStartTimestampUs[3]: 1773216785286383

From these values:

  • eofTimestampUs - sofTimestampUs ≈ 30 ms

Does this difference represent the exposure time?

If not, what does this interval actually represent?
For example:

  • frame period
  • sensor readout time
  • ISP processing time
  • pipeline latency
  • or a combination of the above?

Additional note on timestamp availability

Initially, both sofTimestampUs and moeTimestampUs were always 0.
After granting permissions to /dev/nvpps0, these timestamps became valid (non-zero).

Based on this behavior, is it correct to assume that these timestamps depend on nvpps (PPS) or another time synchronization mechanism?

4. Exposure-related information in SIPL (nvsipl)

In case exposure-related information is not available in DriveWorks, I also investigated the SIPL (nvsipl) side.

Using nvsipl, I retrieved the following parameters:

  • DevBlkCDIExposure::exposureTime
  • DevBlkCDIExposure::sensorGain

The retrieved values are as follows:

exposureTime[0]: 0.0555556
exposureTime[1]: 10
exposureTime[2]: 10

sensorGain[0]: 15.8489
sensorGain[1]: 1
sensorGain[2]: 1

Based on these results, I have the following questions:

  1. Is it expected behavior that exposureTime[1] and exposureTime[2] (as well as sensorGain[1] and sensorGain[2]) have same values?
    Do these indices correspond to different exposure slots, such as those used for multi-exposure or HDR capture?
  2. I understand that exposureTime represents the exposure duration, but:
  • Under what conditions is each index ([0], [1], [2]) actually used?
  • Are there scenarios where multiple indices are used simultaneously (for example, in HDR or multi-exposure modes)?
4
  1. sofTimestampUs denotes time when the first row has finished its exposure. Does that mean you looking for time of beginning of the first row?
  2. Does https://developer.nvidia.com/docs/drive/drive-os/6.0.10/public/driveworks-nvsdk/nvsdk_dw_html/group__image__group.html#structdwExposureDuration helps ?
  3. The camera pipeline gets raw timestamps in TSC and then TSC → HOST conversion uses the time sensor. Time sensor is nvpps . So when permission to /dev/nvpps0 is not granted , then the time sensor is not available, so it is expected to get 0 in timestamps
  4. Please see DriveWorks SDK Reference: Image Extra Interface it if helps.
  5. In single-exposure mode, only exposureTime[0] and sensorGain[0] are meaningful. other indices are useful in multi exposure or HDR .
5

Dear @SivaRamaKrishnaNV

1. About sofTimestampUs and Exposure Start Time

sofTimestampUs denotes time when the first row has finished its exposure. Does that mean you are looking for the time of the beginning of the first row?

Yes. What we would like to know is the exposure start time (shutter‑open timing) of the first row.

Our use case is to align the exposure start timing between IMX728 and IMX623 cameras. Since we plan to use different exposure durations per camera, we are not trying to align the exposure end time, but rather the exposure start time across cameras.

According to the following document, frame synchronization across cameras is achieved:

In this document, it states that shutter/frame timing is synchronized across cameras.

In this context, does the term “shutter timing” refer to exposure start timing, or does it mean SOF timing?

If there is no API or field that directly provides the exposure start time (shutter timing), then for single‑exposure mode, would the following estimation be valid?

exposureStart = sofTimestampUs − exposureDurationUs[0]

2. About dwExposureDuration

Does https://developer.nvidia.com/docs/drive/drive-os/6.0.10/public/driveworks-nvsdk/nvsdk_dw_html/group__image__group.html#structdwExposureDuration help?

Thank you. I was able to get the expected value that matches the output from the nvsipl_camera:

exposureDurationUs[0] 10.000 ms
exposureDurationUs[1] 10.000 ms
exposureDurationUs[2] 0.055 ms

3. About TSC and Time Sensor

The camera pipeline gets raw timestamps in TSC and then TSC → HOST conversion uses the time sensor. Time sensor is nvpps. So when permission is not granted, the time sensor is not available, so it is expected to get zeros in timestamps.

Thank you for the explanation. We have confirmed the same behavior on our side: after granting permission to /dev/nvpps0, both sofTimestampUs and moeTimestampUs become valid.

4. About DevBlkCDIExposure and exposureDurationUs

Please see DriveWorks SDK Reference: Image Extra Interface if it helps.

We checked this, and observed that DevBlkCDIExposure[] remains 0 even though expTimeValid = 1, as shown below.

Could you please clarify the relationship between DevBlkCDIExposure and exposureDurationUs? Are these supposed to contain the same values, or do they represent different information?

dwImage_getNvSIPLMetadata()
 ・expTimeValid        : 1
 ・DevBlkCDIExposur[0]: 0.000 ms
 ・DevBlkCDIExposur[1]: 0.000 ms
 ・DevBlkCDIExposur[2]: 0.000 ms
 ・DevBlkCDIExposur[3]: 0.000 ms

5. About Exposure Modes

In single‑exposure mode, only exposureTime[0] and sensorGain[0] are meaningful. Other indices are useful in multi‑exposure or HDR.

  • Is there a way to determine which exposure mode (single‑exposure vs multi‑exposure/HDR) is currently active?
    • Is the fact that dwImageNvSIPLMetadata.numExposures = 3 relevant for this determination?
    • Also, is it relevant that numExposures = 3 and only exposureDurationUs[0-2] have values set?
  • Is there any way to switch between single‑exposure and HDR modes via the DriveWorks API?

6. Reference: Captured Frame Information

Below is the captured frame information for IMX728 (R0SIM728S3RU2120NB2.nito) and IMX623 (R0SIM623S4RU1197NB2.nito).

IMX728

dwImage_getTimestamp()                 : 1773739055.961 s
dwSensorCamera_getImageTimestamps()
  sofTimestampUs                       : 1773739055.931 s
  moeTimestampUs                       : 1773739055.941 s
  eofTimestampUs                       : 1773739055.961 s
  subExposureStartTimestampUs[0]       : 1773739055.931 s
  subExposureStartTimestampUs[1]       : 1773739055.931 s
  subExposureStartTimestampUs[2]       : 1773739055.931 s
  subExposureStartTimestampUs[3]       : 1773739055.941 s
  tscEofTimestampUs                    : 2158733.342 s
dwImage_getMetaData()
  frameSequenceNumber                  : 63
  exposureTime                         : 0.000 ms
  sensorStatistics.exposureDurationUs[0]: 10.000 ms
  sensorStatistics.exposureDurationUs[1]: 10.000 ms
  sensorStatistics.exposureDurationUs[2]: 0.055 ms
  sensorStatistics.exposureDurationUs[3]: 0.000 ms
dwImage_getNvSIPLMetadata()
  numExposures                         : 3
  expTimeValid                         : 1
  DevBlkCDIExposur[0]                  : 0.000 ms
  DevBlkCDIExposur[1]                  : 0.000 ms
  DevBlkCDIExposur[2]                  : 0.000 ms
  DevBlkCDIExposur[3]                  : 0.000 ms

IMX623

dwImage_getTimestamp()                 : 1773739055.960 s
dwSensorCamera_getImageTimestamps()
  sofTimestampUs                       : 1773739055.930 s
  moeTimestampUs                       : 1773739055.940 s
  eofTimestampUs                       : 1773739055.960 s
  subExposureStartTimestampUs[0]       : 1773739055.930 s
  subExposureStartTimestampUs[1]       : 1773739055.930 s
  subExposureStartTimestampUs[2]       : 1773739055.930 s
  subExposureStartTimestampUs[3]       : 1773739055.930 s
  tscEofTimestampUs                    : 2158733.342 s
dwImage_getMetaData()
  frameSequenceNumber                  : 62
  exposureTime                         : 0.000 ms
  sensorStatistics.exposureDurationUs[0]: 10.000 ms
  sensorStatistics.exposureDurationUs[1]: 10.000 ms
  sensorStatistics.exposureDurationUs[2]: 10.000 ms
  sensorStatistics.exposureDurationUs[3]: 0.000 ms
dwImage_getNvSIPLMetadata()
  numExposures                         : 3
  expTimeValid                         : 1
  DevBlkCDIExposur[0]                  : 0.000 ms
  DevBlkCDIExposur[1]                  : 0.000 ms
  DevBlkCDIExposur[2]                  : 0.000 ms
  DevBlkCDIExposur[3]                  : 0.000 ms
7

Dear @SivaRamaKrishnaNV

1 About sofTimestampUs and exposure start time

Is there any update on this topic?

When you refer to “shutter timing”, do you mean the exposure start time (shutter start), or the SOF (Start Of Frame) timing?

Is there any API or metadata field that directly provides the exposure start time (shutter start time)?

If not, is it correct to approximate the exposure start time as:


exposureStart ≈ sofTimestampUs - exposureDurationUs[0]

Additional Questions

My goal is to synchronize shutter timing across multiple Orin devices.

Can calling dwSAL_start() simultaneously on multiple Orin devices be used to synchronize shutter timing across devices? I understand that actual sensor streaming begins with dwSensor_start(), but can dwSAL_start() serve as a synchronization point across devices?

Reference:

Regarding ImageMetaData.sensorExpInfo.exposureTime:

Is ImageMetaData.sensorExpInfo.exposureTime a measured (observed) value reported by the sensor, or is it the configured/requested exposure time?

I observed this field for tens of seconds using nvsipl_camera, and the value was identical across all frames down to the 1μs level. For comparison, on DriveOS 6.0.8.1 the same observation showed fluctuations of about 100 μs.

If this field represents a measured value, are there any known improvements in timing accuracy or stability between DriveOS 6.0.8.1 and DriveOS 6.0.10.0?

Similarly, for dwImageMetaData.sensorStatistics.exposureDurationUs:

Is this value a measured exposure duration, or a configured/requested value?

8

Dear @Natsuha_Shishido ,
Could you please file a new topic for new queries to avoid cluttering of queries/issues?

9

Dear @SivaRamaKrishnaNV
OK.
I create another topic and ask question there.