Experimental Physics and
Industrial Control System

Tamas Kerenyi via Tech-talk <[email protected]> · Fri, 13 Dec 2019 12:13:07 +0000

Hi Mark!

Thank you for your emails! I'm using a BlackflyS BFS-PGE-50S5C camera. For now I used your second solution with the conversion of the timestamps and looks good.

Tamas

-----Original Message-----
From: Mark Rivers <[email protected]> 
Sent: Tuesday, December 10, 2019 11:10 PM
To: Tamas Kerenyi <[email protected]>
Cc: [email protected]
Subject: Re: ADSpinnaker timestamp

Hi Tamas,

These are the values of the ChunkTimeStamp you measured.  They are coming every 2 seconds, plus or minus a few ms.
labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:34.642297 1557832136 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:36.640736 -737150176 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:38.641100 1262848184 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:40.643660 -1032134232 I just realized we can make sense of those as timestamps in ns, but we are missing the high-order bits which increment about every 4 seconds.

Here I convert the 4 times above to unsigned 32-bit numbers.

IDL> t1 = 1557832136
IDL> t2 = ulong(-737150176)
IDL> t3 = 1262848184
IDL> t4 = ulong(-1032134232)
IDL> print, t1, t2, t3, t4
  1557832136  3557817120  1262848184  3262833064

Note that times 1 and 2 are separated by about 2000000000 counts, as are times 3 and 4.  Clearly the 32-bit integer overflowed between times 2 and 3.  So we add 2^32 to times 3 and 4 to compensate for this overflow and convert them to 64-bit integers.

IDL> t3 = t3 + 2LL^32
IDL> t4 = t4 + 2LL^32
IDL> print, t1, t2, t3, t4
  1557832136  3557817120            5557815480            7557800360

Now we look at the difference between the timestamps.

IDL> print, t2-t1, t3-t2, t4-t3
  1999984984            1999998360            1999984880

Note that they are all very close to 2000000000 = 2e9.  Since your images were 2 seconds apart, this means these timestamps are indeed ns, and the jitter looks likes it is about 500 ns.

Mark

________________________________
From: Mark Rivers
Sent: Tuesday, December 10, 2019 1:30 PM
To: Tamas Kerenyi
Cc: [email protected]
Subject: Re: ADSpinnaker timestamp

I think I understand why the ChunkTimestamp is jumping between positive and negative. GenICam integers are 64 bits. ADGenICam truncates them to 32 bits.

EPICS base, asyn, and ADCore have all recently added support for 64 bit integers. I could thus change ADGenICam to use int64in and int64out records for GenICam integers. This would however require EPICS base 3.16.1 or later.

Sent from my iPhone

On Dec 10, 2019, at 10:32 AM, Mark Rivers <[email protected]<mailto:[email protected]>> wrote:

Hi Tamas,

What camera are you using?

In ADSpinnaker there is a PV to tell the driver to use the embedded time stamp from the camera for the timeStamp property of the NDArray.  If you select this you may not need the ChunkTimestamp.

The timeStamp is saved in the TIFF, HDF5, and netCDF file writing plugins.

Mark

Sent from my iPhone

On Dec 10, 2019, at 8:28 AM, Tamas Kerenyi via Tech-talk <[email protected]<mailto:[email protected]>> wrote:

Hi!

I'm using ADSpinnaker. How should I interpret the "ChunkTimestamp"? I'd like to know the timestamp of the pictures in nanoseconds.

labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:34.642297 1557832136 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:36.640736 -737150176 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:38.641100 1262848184 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:40.643660 -1032134232

Best Regards,
Tamas Kerenyi
ICS Division, HW and Integration Group

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System