PTP Data Alignment

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 from previous communication between the digital hubs and the I/O signal processor, where a single clock driven by the Neural Signal Processor (NSP) would sample from the data streaming from the digital hubs via fiber optic, which resulted in data that was properly aligned by default.
Now, the Gemini hubs and I/O NSP each have their own clocks. This has the benefit of being able to run independently from the I/O module as needed but creates a necessity for ensuring that the data in recorded files is aligned with time.

 

Time Stamping Changes in Central 7.6.0 


Starting with Central 7.6.0, the data timestamping approach has changed, and special considerations apply to how the files are handled. Files saved with Central 7.6.0 now contain a vector with the PTP time in the metadata that correlates with each sample. These timestamps have precision in the sub-microsecond range.

A new tool has been added to NPMK, samplealign.m, to load the saved files and automatically realign the samples to a nominal 30 kHz clock. samplealign.m adds or removes samples in order to achieve alignment with the desired sampling rate (30 kS/s for NS5/NS6, 10 kS/s for NS4, etc). When a user loads in continuous data that utilized PTP timestamping via openNSx.m, the data-loading algorithm automatically incorporates samplealign.m. Loading in data that did not utilize PTP timestamping will not call samplealign.m. This default behavior preserves legacy data analysis pipelines, where the continuous data segments only have one timestamp at recording onset for an array of continuous data. Users will be able to see whether samples have been added or removed with automated warnings whenever samplealign.m is called and the function adds or removes data for alignment. In order to avoid this alignment behavior, call openNSx with the optional argument ‘noalign’ to load in the continuous data, which will load the aforementioned timestamp vector instead of one timestamp that marks the recording onset.

If you are having any trouble with handling the files or have additional questions about aligning the data, reach out to our support team at support@blackrockneuro.com. 

 

 


    • Related Articles

    • Signal Processing Flow Diagram

      The attached document shows how various signal processing steps and Central signal processing features are applied to the neural data stream from Blackrock analog and digital (CerePlex) systems.

    • Loading Data into MClust

      PS: for MClust 4.0+ please download and use NPMK 4.2.2 Please also find attached PDF version with screenshots -------------------------------------------------------------------------------------- 1, Download MClust (V3.5 or later) and the latest ...

    • How to Interpret Digital Input Data

      Introduction In Raster Plot, Central can visualize digital inputs as separate pins, but the data is not saved as separate channels for each pin. Rather, the state of all sixteen pins makes up a single 16-bit integer value. Additional information can ...

    • Broadcasting Data from nPlayServer to Multiple Computers

      Introduction This article will cover how to make nPlayServer, Blackrock's data playback program, send data out from a computer as if it were a Neural Signal Processor. This can be done whether you own a CerePlex Direct or Neural Signal Processor ...

    • 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 ...