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
- Replies:
- RE: ADSpinnaker timestamp Tamas Kerenyi via Tech-talk
- References:
- ADSpinnaker timestamp Tamas Kerenyi via Tech-talk
- Re: ADSpinnaker timestamp Mark Rivers via Tech-talk
- Re: ADSpinnaker timestamp Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Re: ADSpinnaker timestamp Mark Rivers via Tech-talk
- Next:
Old base version bug in configure/os/CONFIG_SITE.linux-x86_64.UnixCommon Di Wang via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: ADSpinnaker timestamp Mark Rivers via Tech-talk
- Next:
RE: ADSpinnaker timestamp Tamas Kerenyi via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|