Read the lower word of PLX timestamps as unsigned - #1904
Open
h-mayorquin wants to merge 1 commit into
Open
h-mayorquin wants to merge 1 commit into
h-mayorquin wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This came up in a conversion to NWB that we are working on in neuroconv, where the spike times of a sorted PLX file come from
PlexonRawIO. Some of the spike times in that file came out about 72 minutes earlier than Plexon's own MATLAB reader from their SDK gives for the same spikes.What is happening is a decoding error. PLX data block timestamps are 40 bits, with the lower 32 bits in
TimeStamp.PlexonRawIOreads that field asint32, but I checked the header in Plexon's SDK and the type there is unsigned. Withint32, a timestamp whose lower word is at or above 2^31 comes out 2^32 ticks early. I ran into this with a file sorted in Offline Sorter that has a 1 MHz clock, where that happens after about 36 minutes; withuint32the spike and event times match the file.I am preparing new Plexon test data for gin that includes a stub of that file, and I will add a test that reads it once the data is merged.