epoch times not aligned in pos and epoch interval lists for recording with disconnect

[jguides]

The IntervalList table is automatically populated with interval lists for epochs (e.g. "02_r1") and position valid times (e.g. "pos 1 valid times") when insertsessions is run on a nwb file. For peanut20201114.nwb, "19_h2" (epoch interval list) starts about 18 minutes earlier than "pos 18 valid times" (position valid times interval list), even though these correspond to the same recording. In case relevant, these intervals are roughly the same length. Also, this recording had a disconnect. @edeno or @lfrank, I was wondering if either of you may have an idea for what the cause of this offset could be. I can look into the rec to nwb code if not. Thanks in advance for any thoughts.

[lfrank]

@jguides This is most likely an edge case that the current position code doesn't deal with correctly. I'd suggest using readTrodesExtractedDataFile from the rec_to_binaries package to look at the original position file and to see if the times there match up with those in spyglass as a starting point.

[jguides]

Thanks @lfrank. The times in the continuoustime.dat file match those in the "epoch interval list" ("19_h2"). However, when I went into the .pos directory to read in the position files, I noticed there is a cameraHWFrameCount but not cameraHWSync file. I am under the impression that there should be a cameraHWSync and not a cameraHWFrameCount if PTP is being used. I will open a new issue about PTP not being used, and return to this issue once I can regenerate the nwb file with the correct position files.

[lfrank]

@jguides First, apologies: I was misremembering how this works. In any case, looking at the code for rec_to_nwb and rec_to_binaries, I don't see any place where the HWSync file is generated; it looks like it might be created by trodes itself when the data are collected. Is that possible?

[lfrank]

@jguides And as a follow up, I found references to the HWSync file in the trodes camera module code, and it really looks like it is created when the data are collected. Can you check your raw data directory and see if the file is there?

[jguides]

Thanks @lfrank, I'm just seeing this. My impression from a conversation with @edeno on May 3rd on Slack was that the HWSync files are created during recording (because they were in my raw directory), and that during rec_to_nwb conversation, they were copied over to the preprocessing directory but misnamed as HWFrameCount. @edeno if you can clarify if this is correct that would be great.

@lfrank as I mentioned in the other issue post, to your question about whether the HWFrameCount data matches that in the nwb file, it appears to. In particular, the last column of the HWFrameCount data (field called HWTimestamp) appears to be PTP time in nanoseconds, and matches the "19_h2" epoch interval start time within around 300 ms (guessing the offset has to do with a delay in camera acquisition?). Given this, it appears something happened during creation of the "pos 1 valid time" interval that led to an about 18 minute offset with the "19_h2" interval. @lfrank @edeno if either of you have suggestions for where to look next to hunt this down, please let me know.

[lfrank]

Got it. The code that generates those interval lists is pretty simple, so we should be able to figure this out. The code that generates them is in common_behav.py. Start with the PositionSource class which calls the function that gets all of the spatial series. That is where the interval lists are defined.

Let me know if you need additional pointers…

On Jul 9, 2022, at 4:29 PM, jguides @.***> wrote:

 Thanks @lfrank, I'm just seeing this. My impression from a conversation with @edeno on May 3rd on Slack was that the HWSync files are created during recording (because they were in my raw directory), and that during rec_to_nwb conversation, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Thanks @lfrankhttps://urldefense.com/v3/__https://github.com/lfrank__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hhfsEf2Q$, I'm just seeing this. My impression from a conversation with @edenohttps://urldefense.com/v3/__https://github.com/edeno__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hIOAtopw$ on May 3rd on Slack was that the HWSync files are created during recording (because they were in my raw directory), and that during rec_to_nwb conversation, they were copied over to the preprocessing directory but misnamed as HWFrameCount. @edenohttps://urldefense.com/v3/__https://github.com/edeno__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hIOAtopw$ if you can clarify if this is correct that would be great.

@lfrankhttps://urldefense.com/v3/__https://github.com/lfrank__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hhfsEf2Q$ as I mentioned in the other issue post, to your question about whether the HWFrameCount data matches that in the nwb file, it appears to. In particular, the last column of the HWFrameCount data (field called HWTimestamp) appears to be PTP time in nanoseconds, and matches the "19_h2" epoch interval start time within around 300 ms (guessing the offset has to do with a delay in camera acquisition?). Given this, it appears something happened during creation of the "pos 1 valid time" interval that led to an about 18 minute offset with the "19_h2" interval. @lfrankhttps://urldefense.com/v3/__https://github.com/lfrank__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hhfsEf2Q$ @edenohttps://urldefense.com/v3/__https://github.com/edeno__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hIOAtopw$ if either of you have suggestions for where to look next to hunt this down, please let me know.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/LorenFrankLab/rec_to_nwb/issues/32*issuecomment-1179621098__;Iw!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20hnfI46lg$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABV4PSPOWWEEA4MR2PLAX53VTIDMZANCNFSM52RWLWKQ__;!!LQC6Cpwp!viMXVnk4J3fqnHTBPcri-I-kn1OlU4QskTz312z0_khAB1kRKHmuahMO7eChnqula6pbKSAOA3cW66yk20i-nRMdaQ$. You are receiving this because you were mentioned.Message ID: @.***>

[jguides]

Thanks @lfrank. It looks like the "wrong" epoch start time is present in the spatial series. I'm guessing the next step would be to track down where the spatial_series gets defined? If so, do you know where I can look in the rec_to_nwb code (a search for "spatial_series" across the rec_to_nwb repo didn't turn up anything obvious).

[lfrank]

[cid:23CE6CEF-D2AC-4C30-B4A3-C002D3F442C7] @jguides The code above is, I believe, what you are looking for. The path as at the top of the screenshot. Not sure why this didn’t turn up in your search, though….

On Jul 10, 2022, at 9:54 AM, jguides @.**@.>> wrote:

This Message Is From an External Sender This message came from outside your organization.

Thanks @lfrankhttps://urldefense.com/v3/__https://github.com/lfrank__;!!LQC6Cpwp!qBfS502K9lt-D8jwbR7zQbvveKNgM-6rMEujUASyJBRnHaiD1gwCf04wV33X1aFQiny1CPRbkjfHPE-hgfMOfhaNlw$. It looks like the "wrong" epoch start time is present in the spatial series. I'm guessing the next step would be to track down where the spatial_series gets defined? If so, do you know where I can look in the rec_to_nwb code (a search for "spatial_series" across the rec_to_nwb repo didn't turn up anything obvious).

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/LorenFrankLab/rec_to_nwb/issues/32*issuecomment-1179762519__;Iw!!LQC6Cpwp!qBfS502K9lt-D8jwbR7zQbvveKNgM-6rMEujUASyJBRnHaiD1gwCf04wV33X1aFQiny1CPRbkjfHPE-hgfPf-tGQiw$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABV4PSP3ZPTJACUII2LALHDVTL53XANCNFSM52RWLWKQ__;!!LQC6Cpwp!qBfS502K9lt-D8jwbR7zQbvveKNgM-6rMEujUASyJBRnHaiD1gwCf04wV33X1aFQiny1CPRbkjfHPE-hgfOkUHHEKw$. You are receiving this because you were mentioned.