Timing between laser and stimulus onset

Support
21

Hi Chris,

I tried to upload on the website but new users can’t upload files. So I’ve attached a pdf version of the file below. Let me know if this works.

Best,
Taylor

(attachments)

timing.pdf (21 KB)

22

Hi Taylor,

I tried to upload on the website but new users can’t upload files.

Sorry about that. I changed your permissions to “basic user”, so I think you’ll be able to upload files in the future.

I’ve attached a pdf version of the file below. Let me know if this works.

Yes, I received it. Thanks! I will take a look and get back to you.

Chris

23

Hi Taylor,

Are these times in milliseconds?

The numbers look a little suspect to me. Specifically: In rows 2-9, the value of actual_predicted_display_update_time is identical to the value of extrapolated_predicted_display_update_time from the previous row. That can’t be right.

Also, where in your experiment are you calling next_frame_time() and storing its value?

Thanks,
Chris

24

Hi Chris,

I am reporting all three times at the end of the “Stimulus-On” state. And yes, they are in milliseconds.

I just tried to put them right after I cued the delay_stim_onset and the attachment is what I got. I was indeed unsure about the placement. Where should I put them for the right report?

Best,
Taylor

(attachments)

timing2.txt (17 KB)

25

Hi Taylor,

You need to wait until actual_predicted_display_update_time is set, which doesn’t happen until the stimuli are revealed.

Probably the best approach would be to record the prediction error inside the body of delay_stim_onset. First, define a new variable:

var extrapolated_predicted_display_update_time = 0
var actual_predicted_display_update_time = 0
var predicted_display_update_time_error = 0  // This is new

then set it right after setting actual_predicted_display_update_time:

if (refreshes_until_stim_onset == 0) {
    // Record the actual predicted display update time for stimulus
    // onset
    actual_predicted_display_update_time = next_frame_time()

    // The next line is new
    predicted_display_update_time_error = extrapolated_predicted_display_update_time - actual_predicted_display_update_time

    // Reveal the stimulus
    stimulus_alpha_multiplier = 1
    distractor_alpha_multiplier = 1
}

There’s no need to record the value of next_frame_time() separately, since it’s already assigned to actual_predicted_display_update_time.

Sorry for not being clearer about this previously.

Chris

26

Hi Chris,

Thank you and I just recorded a file. The prediction error started at -0.144 and increased to 0.856, then 1.856, and stabilized at 2.856. I’ve attached a .txt of the console if that helps.

Best,
Taylor
timing3.txt (14.0 KB)

27

Hi Taylor,

Did you report predicted_display_update_time_error in milliseconds, or are the logged values in the raw microseconds?

Either way, I don’t think the prediction error explains any of the increased latency you observed in the time between laser onset and photodiode onset. Since the error eventually settles at a positive value (2.856), the extrapolated display update time is after the actual display update time. This will cause the experiment to wait too long before turning on the laser, meaning the time between laser onset and photodiode onset will be less than it would be if the error were zero. (This assumes you calculate the error as extrapolated minus actual, as I suggested. Is that correct?)

Since the prediction error stabilizes over time, you could try using it to improve the accuracy of your waits. Specifically, you could subtract the prediction error from the previous trial when determining how long to wait before turning on the laser in the current trial. In code:

wait ((extrapolated_predicted_display_update_time - predicted_display_update_time_error - target_laser_padding_time) - now())
vpixx_dout_laser_gate = true

But if what I said above is correct, this is only going to further increase the observed latency, which obviously doesn’t help with the problem you’re having.

Looking back through the discussion, I don’t think you answered my question about the photodiode location. Is it in the upper-left corner of the display, or somewhere else?

Thanks,
Chris

28

Hi Chris,

Thank you for the explanation.

I didn’t convert the time into milliseconds. And yes, I calculated it as following:
predicted_display_update_time_error = extrapolated_predicted_display_update_time - actual_predicted_display_update_time
report('predicted_display_update_time_error = $predicted_display_update_time_error’)

Sorry that I missed the question but yes, the photodiode is in the upper-left corner of the display.

Best,
Taylor

29

Hi Taylor,

I didn’t convert the time into milliseconds.

Oh, wow. So the extrapolated time matches the actual one to within a few microseconds? That’s a little hard to believe, but fantastic if true. Also, it confirms much more strongly that extrapolation error is not the source of the extra latency you’re seeing.

Sorry that I missed the question but yes, the photodiode is in the upper-left corner of the display.

OK, good. No worries about that, then.

Another question I should have asked sooner: When you’re talking about the laser onset time, what specific event are you measuring? I’ve been assuming that you mean the time of the e_laser_on event as recorded by the Blackrock. Is that correct? If not, are you looking at a signal from the laser itself (e.g. from one of its “Light Sensor” BNC outputs, presumably also connected to the Blackrock)? If the latter, then it’s possible that the changing latency is due to the laser hardware, rather than anything MWorks is doing.

Chris

30

Hi Chris,

I measure the laser onset in both ways: using event code and the light sensor. The difference between the event code and the actual light signal is very small though - on average about 0.7ms. So I don’t think using one or the other would vary the latency that much?

Best,
Taylor