Timestamps problems?

[rcpeene]

Eli Sennesh from GLO said

In the following files:
sub-1199273437_ses-1214578117.nwb  sub-1210326253_ses-1221092548.nwb  sub-1214404694_ses-1224930300.nwb  sub-1214890319_ses-1226526314.nwb  sub-1218586779_ses-1227858756.nwb  sub-1223032979_ses-1232959154.nwb
the sampling timestamps for LFPs and the event timestamps used for tracking the start/end of trials and the onset/offset of stimuli don't seem to use the same zero-point or scale.  For instance, in some files there are negative timestamps leading up to a few seconds' worth of positive timestamps in the timestamps array, and then entirely positive timestamps (going up to the hundreds of seconds) for events.

[rcpeene]

I checked the stim file and probe file for sub_1199273437sess_1214578117/sub_1199273437+sess_1214578117 Here are the stim timestamps and LFP timestamps

And this indeed looks off. The LFP timestamps start at 5000, long after the stim timestamps begin

[rcpeene]

For sub_1210326253/sub_1210326253sess_1221092548/sub_1210326253+sess_1221092548_ecephys.nwb, I received these timestamp results

First timestamp stimulus data:  75.29793470943362
Last timestamp stimulus data:  6837.985915177345
First timestamp LFP data:  3.5540781836822246
Last timestamp LFP data:  3.5667492072474234

[jeromelecoq]

We need to look at AllenSDK code for How downsampling is managed.

[Ahad-Allen]

We figured out that this was being caused by the switch to a newer open ephys pipeline for later GLO sessions, it has been resolved by using the same packaging trick of looking at the sample numbers.npy that we use for vippo and barcoding.

[jeromelecoq]

@rcpeene to confirm that alignment still has issues.

[rcpeene]

@Ahad-Allen close if confirmed