'nozeropad' in openNSx()
Occasionally in Blackrock continuous files, the timestamp of the first datapoint written to the file will be non-zero.
By default, when opening files with non-zero first timestamp using the openNSx() function from NPMK, the function will modify the timestamp in the file header to zero, then pad the data matrix with the corresponding number of zero-valued datapoints. When this is done, the index of each datapoint will directly correspond with its timestamp and timestamps can be directly compared between the .nev file and .nsX file.
By default, when opening files with non-zero first timestamp using the openNSx() function from NPMK, the function will modify the timestamp in the file header to zero, then pad the data matrix with the corresponding number of zero-valued datapoints. When this is done, the index of each datapoint will directly correspond with its timestamp and timestamps can be directly compared between the .nev file and .nsX file.
If the 'nozeropad' input parameter (i.e., openNSx('nozeropad') ) is used, then the Timestamp and the data matrix are unmodified. If 'nozeropad' is used, the index of each datapoint will NOT directly correspond to its timestamp. The index will be offset from the timestamp by the value of NSx.MetaTags.Timestamp and this will need to be implemented in any comparisons between .nev file timestamps and .nsX file indices.
Specifically, to correlate the timestamp of an event in the NEV file, NSx.MetaTags.Timestamp value must be subtracted from it.
For example, if you would like to look at the continuous data around the 100th spike in the NEV file (e.g., NEV.Data.Spikes(100).Timestamp is 120450), the reference in the NSx file for channel 1 should look like: NSx.Data(NEV.Data.Spikes(100).Timestamp - NSx.MetaTags.Timestamp - 500 : NEV.Data.Spikes(100).Timestamp - NSx.MetaTags.Timestamp + 500). This will show 500 points before and 500 points after the exact moment the 100th spike was recorded in the NEV file.
FileSpec 3.0
In earlier versions of FileSpec 1.x and 2.x, the proc-time of the NSP would reset to 0 before recording start. This would result in a very small mismatch between the NEV timestamps and NSx data
indices, typically around 100 samples. By default, this was always compensated automatically in openNSx script and the performance was not affected. However, in Central 7.5.0 and later, a new FileSpec version 3.0 is used. In this new version the clock does not reset in the beginning of the recording, resulting a very large discrepancy between NEV timestamps and NSx
indices. While openNSx can continue to compensate for this by adding zeros to the beginning of the file, this can take a long time and result in much larger memory consumption. It's best practice to use 'nozeropad' while using openNSx and instead compensate for the timestamp difference by using the information above.
Related Articles
PTP Data Alignment
Note: If you are recording data with both the NSP and Gemini hubs, update to 7.6.1. Background Timestamping has fundamentally changed from operating on a nominal 30 kHz clock to Precision Time Protocol (PTP) on Gemini hardware. This is a departure ...MATLAB Interfaces For Blackrock Microsystems Data Acquisition Systems
Introduction Blackrock has several functions for looking at and interacting with data collected through our neural signal processors. These functions are available for post-recording processing (Neural Processing MATLAB Kit - NPMK) or for interacting ...