Changing sample rate timestamps to epoch timestamps

[cblaar...@gmail.com]

Hello,

I need epoch timestamps with millimeter precision as opposed to sample rate timestamps, what would be the best way to do this? Have spent some time looking through the code to find where timestamps are written to files, but haven't had any luck. Would be open to making a module that would pick up events, convert them into epoch time, then create a separate file for them if that would be easier. 

[Jan Zimmermann]

Do you mean epochs as in event triggered averages ?

[cblaar...@gmail.com]

I should have been more specific, I mean Unix time. Need to align timestamps from OE with oat (as in this oat: https://github.com/jonnew/Oat#recorder) timestamps with millisecond precision. As far as I know, we can't get that sort of precision with the information found in OE files, such as all_channels.events. It doesn't have to be Unix time necessarily, just some event both programs can create timestamps in relation to. 

[Jan Zimmermann]

Do you not have strobed TTL outputs from your cameras GPIO frame trigger?

[cblaar...@gmail.com]

We are using a webcam that doesn't have GPIO trigger capability, so trying to get around that.

[Jan Zimmermann]

I not fully certain but I think you need some kind of sync between the systems. System times alone will not be enough to get reliable time stamps.

[Josh Siegle]

It is possible to access Unix timestamps within the software (Juce Time::getHighResolutionTicks), but as Jan said, it may not be accurate enough for properly syncing with the video.

By the way, the messages.events file outputs the system time at the start of recording (as well as the hardware timestamp associated with it). Would that be enough to do an alignment with the video data?

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+...@googlegroups.com.
To post to this group, send email to open-...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-ephys.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/6c007d5e-9ffc-4d53-89b5-48a71aff0270%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Rodgers]

As an alternative approach, you can pulse an LED somewhere in your video frame, and record the timing of this pulse with an analog input or digital input on the OpenEphys box. This is how I sync my recordings to my video. (Actually, what I do is turn off the IR lamp that is illuminating the behavioral arena for 1ms, once per trial.) I am able to get the sync accurate to <1 frame at 300fps.

[cblaar...@gmail.com]

What is the reason for timestamps not being reliable? I would think with millisecond precision timestamps and a frames per second rate of 300, it could be done.

[cblaar...@gmail.com]

Didn't realize the messages.events file had that info, thanks for the tip!

[cblaar...@gmail.com]

That might be an easier way. What software do you use to alighn events on OE with frames?

[Chris Rodgers]

I don't know if the timestamps are reliable to milliseconds or not, I just prefer to do it myself and find that it is more fool-proof that way. The software is custom written but the algorithm is straightforward:

1. Take the frame time of each LED flash from your video. I do this by loading each frame and calculating mean luminance, then looking for sudden changes in this luminance.

2. Take the time of each LED voltage pulse from your OE analog input (or in theory digital input though I haven't done this)

3. Fit a linear regression between the datasets from steps 1 and 2. This will give you the temporal offset, and importantly, the slope of this fit accounts for any difference in clock speed between the OE board and your video source. I have found that most computers/webcams/devices have clocks that differ by about 0.1% from each other. It's not a huge difference but it can add up to a couple seconds over an entire behavioral session, if you don't account for it.

[Jon Newman]

Sorry I'm late to this.

1. millisecond synchronization between system clocks is possible using NTP

2. oat-record provides a field in entry within a position file called 'usec'. 

  - For hardware that supports it (e.g. Point Grey devices), this is the number of microseconds elapsed between the first _shutter opening_ and that resulting in a given entry. This will be monotonic and has nothing to do with the system clock.

  - For hardware that does not support hardware timing (e.g. webcams), it is the number of microseconds elapsed  between the first _buffer read_ and that of a given entry as measured using a http://en.cppreference.com/w/cpp/chrono/high_resolution_clock. This may or may not default to the system clock and is not guaranteed to be monotonic.

3. I'm refactoring oat-record and I'm thinking of adding an option to inject system clock timestamps into each entry. If I was to do this, what would be the easiest to parse format? E.g. do people want time since 1970 in milliseconds or some datetime string?

Jon

--

You received this message because you are subscribed to the Google Groups "Open Ephys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+unsubscribe@googlegroups.com.

To post to this group, send email to open-...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-ephys.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/2cd06f23-47f6-443e-9532-c11a1f4e4e80%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jonathan Newman

Postdoctoral Fellow, MIT

http://www.mit.edu/~jpnewman/

[Jon Newman]

I thought about this and the problem is that these timestamps will reflect the time of file writes, which could have considerable delays for complex pipelines. I'm starting to think this is just not a good strategy for synchronization.

The IR LED idea, which is a poor mans version of a master clock driving the shutter of the camera, is probably the way to go even though it requires tons of post processing.

Other than that, I would just invest in camera whose shutter is trigger-able using a GPIO (common master clock) or that produces a strobe on shutter opens that can be recorded and used for post-hoc verification of synchronization. I actually do both of these. This means that frames in my recordings are reliably aligned to my ephys data only using offsets and I can verify this post hoc.

Jon

[maxym myroshnychenko]

Jon, 

I think if this option is to be available, it would be easier to work with time since 1970 in milliseconds. 

What do you use for strobing GPIO pins? Is it something like PulsePal that's set to the maximum FPS specified by camera manufacturer?

Thanks

Max

On Monday, 15 August 2016 22:22:15 UTC-4, Jon Newman wrote:

I thought about this and the problem is that these timestamps will reflect the time of file writes, which could have considerable delays for complex pipelines. I'm starting to think this is just not a good strategy for synchronization.

The IR LED idea, which is a poor mans version of a master clock driving the shutter of the camera, is probably the way to go even though it requires tons of post processing.

Other than that, I would just invest in camera whose shutter is trigger-able using a GPIO (common master clock) or that produces a strobe on shutter opens that can be recorded and used for post-hoc verification of synchronization. I actually do both of these. This means that frames in my recordings are reliably aligned to my ephys data only using offsets and I can verify this post hoc.

Jon

On Mon, Aug 15, 2016 at 9:18 PM, Jon Newman <jpne...@mit.edu> wrote:

Sorry I'm late to this.

1. millisecond synchronization between system clocks is possible using NTP

2. oat-record provides a field in entry within a position file called 'usec'. 

  - For hardware that supports it (e.g. Point Grey devices), this is the number of microseconds elapsed between the first _shutter opening_ and that resulting in a given entry. This will be monotonic and has nothing to do with the system clock.

  - For hardware that does not support hardware timing (e.g. webcams), it is the number of microseconds elapsed  between the first _buffer read_ and that of a given entry as measured using a http://en.cppreference.com/w/cpp/chrono/high_resolution_clock. This may or may not default to the system clock and is not guaranteed to be monotonic.

3. I'm refactoring oat-record and I'm thinking of adding an option to inject system clock timestamps into each entry. If I was to do this, what would be the easiest to parse format? E.g. do people want time since 1970 in milliseconds or some datetime string?

Jon

On Sat, Aug 6, 2016 at 6:20 PM, Chris Rodgers <xrod...@gmail.com> wrote:

I don't know if the timestamps are reliable to milliseconds or not, I just prefer to do it myself and find that it is more fool-proof that way. The software is custom written but the algorithm is straightforward:

1. Take the frame time of each LED flash from your video. I do this by loading each frame and calculating mean luminance, then looking for sudden changes in this luminance.

2. Take the time of each LED voltage pulse from your OE analog input (or in theory digital input though I haven't done this)

3. Fit a linear regression between the datasets from steps 1 and 2. This will give you the temporal offset, and importantly, the slope of this fit accounts for any difference in clock speed between the OE board and your video source. I have found that most computers/webcams/devices have clocks that differ by about 0.1% from each other. It's not a huge difference but it can add up to a couple seconds over an entire behavioral session, if you don't account for it.

On Saturday, August 6, 2016 at 6:12:21 PM UTC-4, cblaar...@gmail.com wrote:

That might be an easier way. What software do you use to alighn events on OE with frames?

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+...@googlegroups.com.

To post to this group, send email to open-...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-ephys.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/2cd06f23-47f6-443e-9532-c11a1f4e4e80%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jonathan Newman

Postdoctoral Fellow, MIT

http://www.mit.edu/~jpnewman/

[cblaar...@gmail.com]

Hey Jon,

Unfortunately we cannot go the IR LED route, so one more effort before we give in to buying the proper camera.

Could position info be transferred from Oat over a port to OE's Network Events module? If there is a substantial variable lag between obtaining a frame and sending its positioning data I could see a problem, but if not it seems feasible.

On Monday, August 15, 2016 at 10:22:15 PM UTC-4, Jon Newman wrote:

I thought about this and the problem is that these timestamps will reflect the time of file writes, which could have considerable delays for complex pipelines. I'm starting to think this is just not a good strategy for synchronization.

The IR LED idea, which is a poor mans version of a master clock driving the shutter of the camera, is probably the way to go even though it requires tons of post processing.

Other than that, I would just invest in camera whose shutter is trigger-able using a GPIO (common master clock) or that produces a strobe on shutter opens that can be recorded and used for post-hoc verification of synchronization. I actually do both of these. This means that frames in my recordings are reliably aligned to my ephys data only using offsets and I can verify this post hoc.

Jon

On Mon, Aug 15, 2016 at 9:18 PM, Jon Newman <jpne...@mit.edu> wrote:

Sorry I'm late to this.

1. millisecond synchronization between system clocks is possible using NTP

2. oat-record provides a field in entry within a position file called 'usec'. 

  - For hardware that supports it (e.g. Point Grey devices), this is the number of microseconds elapsed between the first _shutter opening_ and that resulting in a given entry. This will be monotonic and has nothing to do with the system clock.

  - For hardware that does not support hardware timing (e.g. webcams), it is the number of microseconds elapsed  between the first _buffer read_ and that of a given entry as measured using a http://en.cppreference.com/w/cpp/chrono/high_resolution_clock. This may or may not default to the system clock and is not guaranteed to be monotonic.

3. I'm refactoring oat-record and I'm thinking of adding an option to inject system clock timestamps into each entry. If I was to do this, what would be the easiest to parse format? E.g. do people want time since 1970 in milliseconds or some datetime string?

Jon

On Sat, Aug 6, 2016 at 6:20 PM, Chris Rodgers <xrod...@gmail.com> wrote:

I don't know if the timestamps are reliable to milliseconds or not, I just prefer to do it myself and find that it is more fool-proof that way. The software is custom written but the algorithm is straightforward:

1. Take the frame time of each LED flash from your video. I do this by loading each frame and calculating mean luminance, then looking for sudden changes in this luminance.

2. Take the time of each LED voltage pulse from your OE analog input (or in theory digital input though I haven't done this)

3. Fit a linear regression between the datasets from steps 1 and 2. This will give you the temporal offset, and importantly, the slope of this fit accounts for any difference in clock speed between the OE board and your video source. I have found that most computers/webcams/devices have clocks that differ by about 0.1% from each other. It's not a huge difference but it can add up to a couple seconds over an entire behavioral session, if you don't account for it.

On Saturday, August 6, 2016 at 6:12:21 PM UTC-4, cblaar...@gmail.com wrote:

That might be an easier way. What software do you use to alighn events on OE with frames?

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+...@googlegroups.com.

To post to this group, send email to open-...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-ephys.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/2cd06f23-47f6-443e-9532-c11a1f4e4e80%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jonathan Newman

Postdoctoral Fellow, MIT

http://www.mit.edu/~jpnewman/