Allign ML and single spikes timestamps

Hi,
I am conducting single unit recordings using the CED Spike2.8 software, which is well synchronized with MonkeyLogic (ML). However, I am currently facing challenges in aligning the timestamps between these two systems. The main issue arises from the inability to save the recording and behavioral data simultaneously, resulting in a potential lack of data for the initial 20 trials in one of the files.

To resolve this misalignment, I need to determine the trial times for each trial and identify the first instance where the timestamps match between the two datasets. However, a complicating factor is that ML timestamps for each trial are referenced to the event code 9 for that trial, rather than being measured from the start of the task. Consequently, the ML timestamps do not progress as consecutive and increasing numbers. On the other hand, Spike2 timestamps for each event code represent the time elapsed from the actual beginning of the task and are saved in an increasing order.

Is there anyone who faced the same problem?
thank you
Anna

I think using trial-unique identifiers or comparing the intervals between the timestamps would be easier, but it is up to you.

First of all, ML timestamps are not referenced to the event 9 of that trial. See this manual page.
https://monkeylogic.nimh.nih.gov/docs_GettingStarted.html#AlignTimestampsAndAnalogData

All ML timestamps, including the events 9 and 18, are referenced to the AbsoluteTrialStartTime of that trial, which is the milliseconds elapsed from the task start. If you want to align all timestamps on one continuous timeline, add AbsoluteTrialStartTime to them or simply read the datafile with mlconcatenate.
https://monkeylogic.nimh.nih.gov/docs_RuntimeFunctions.html#mlconcatenate

Thank you.
I tried "manually" to align the two timestamps. It looks like it works (if it is correct I will write the code)
Here is one trial:
first column: events codes;
2nd column: ML time stamp.
Third column: recording timestamps of event codes.
The 4th column represents the times when each event occurs from the code 9 in spike 8. For instance: the value 146.74 in the 4th column corresponds to the difference between the time of the fix point and the time of code 9, plus the time of fix point obtained in ML. And so forth.
It looks like the timestamps are virtually the same. Do you think it is correct?


Event codes ML timeStamp Spik8timestamp Difference spike8 timestamps
9 0.76 8219.76
10 13.43 8353.07
20 146.74 9186.2 146.74 Time onset cue: Time code 10 ( Fix point) - time code 9 + ML time code 10
40 979.9 9577.64 979.87 Time onset target: Time code20 - time code 9+ ML time code 10
50 1371.34 10178.62 1371.31 Time first reward : Time code40 - time code 9 + ML time code 10
50 1972.33 10280.83 1972.29 Time second reward Time code50 - time code 9 + ML time code 10
18 2074.55 12283.28 2074.5 End of trial:

thank you!

I have no idea what you are trying to do. If you are comparing the timestamp intervals, you can do diff(2nd column) and diff(3rd column) and compare the result.

I apologize for the confusion. Here I attached the timestamps of ML and the analog data for one trial.


I've noticed a distinct discrepancy between the timestamps of Monkey Logic (ML) and the analog data. In Table 1, column C details the event times from the onset of the trial, calculated by subtracting the trial onset time (marked by code 9) from the timestamp of each event.

Table 2's column C shows similar temporal differences for the corresponding event codes but also includes the value of the fixation point from Monkey Logic (found in C2). However, there is a notable inconsistency. The time when the timestamps are aligned with code 20 (C3) corresponds to the time in ML when the timestamps align with code 40, indicative of the onset of taskObject#3. This suggests a deviation from the expected mapping: in Table 2, the onset of object 2 is found to be aligned with code 10 rather than the anticipated code 20. This pattern of shift persists across other events as well.

In simpler terms, there appears to be a systematic shift in all event codes, as demonstrated in Table 3.

Does your recording system read eventcodes on the rising edge or falling edge of the triggers or by change detection? Did you set the Strobe option of NIMH ML accordingly?
https://monkeylogic.nimh.nih.gov/docs_MainMenu.html#Strobe