Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Finding absolute time of trial/session start
Ahoy, I'm trying to convert the timestamps coming out of Bpod from relative to absolute so I can align them with other processes.

I thought that `SessionData.Info.SessionStartTime` would store the time from which Bpod's clock begins, but it turns out this isn't the case. `SessionStartTime` is calculated by Matlab after the first trial is run.

It seems to me the best point at which to estimate when the trial began in Matlab is immediately before `RunStateMatrix` is called, but is there something more precise?

I'm also curious about when the state machine's clock starts running. Sometimes the first `TrialStartTimestamp` is a few or even several seconds (rather than 0 as I would expect). Is the state machine's 0-time tied to something specific that Matlab has access to?
Aye aye mate, I've got the answer.

In your data, TrialStartTimestamp is the instant the first state of your trial begins, on the state machine clock.
The launch manager resets the state machine clock to 0 just before running the protocol (BpodSystem.resetSessionClock(), on line 713 of NewLaunchManager.m). Next, the launch manager runs your protocol .m file, which takes some time to run setup before the first call to RunStateMachine (or TrialManager.startTrial if using TrialManager) - so after the clock reset, a variable amount of time passes before the first state begins.
If you want a MATLAB timestamp as close as possible to state machine time 0, you can reset the clock again in your protocol just before your main loop with:
matlabStartTime = now;
BpodSystem.SerialPort.write('*', 'uint8'); % Reset bpod session clock
Confirmed =,'uint8');
if Confirmed ~= 1
   error('Error: confirm not returned after resetting session clock.')

Unfortunately, since Windows, OSX and Ubuntu are non-Realtime operating systems, the actual time the '*' command gets written to Bpod via USB will vary, and on a busy PC latency can be 10s of milliseconds. The best policy is to synchronize clocks of separate acquisition systems using TTL pulses.
If you need to use MATLAB's clocks for timing, I'd also look into use of now() vs. PsychToolbox GetSecs.
I hope this helps!
Awesome, thanks Josh!

Forum Jump: