Comments (4)
No matter how precise a TTL signal to control record is, recorded data will never match the exact expected sample count, independently of the file format.
This is due to two main reasons. First, the software gets data in blocks, and writes it in blocks as well. So recorded data will always be a full number of blocks, whose size might depend on different factors, but is never down to a simple sample. Secondly, the process of starting a recording takes some milliseconds, as the software has to open the files and prepare transfer to disk, so there is always a bit of a delay between the start signal and the actual start of acquisition.
What could be an issue is if the number of samples in the data differed from the number of timestamps, or if the number of samples were too different from the expected amount. Usually more than 2k samples starts meaning something is wrong. But differences smaller than that are perfectly normal.
Controlling recording through TTLs is offered as a manner to control the acquired data but is never meant to be a synchronization method. For that, we recommend start recording a bit before the moment of interest and then using a second TTL signal for synchronization, as TTL acquiring is synchronized to the neural signals by the hardware and thus free of any latency or jitter.
Best,
Aarón
from analysis-tools.
Thank you for the detailed explanation!
from analysis-tools.
Just to make sure I understood you correctly, to synchronize event and signal, I will need to send a second TTL after triggering recording by the first TTL, and then align the timestamp of the second TTL with recorded signal timestamp during analysis, right?
I looked into my one TTL-triggered recording data (saved in binary format), and tried to align TTL event with recorded signal using timestamps from .../event/TTL_1/timestamps.npy and .../continuous/Rhythm_FPGA-100.0/timestamps.npy. So I expected the TTL timestamp to be before the timestamp of the first recorded sample because of the delay between TTL trigger and actual acquisition, but it seems like TTL event timestamp is after the timestamp of the first recorded sample. Are the two timestamps referenced differently? I know there is a sync_message.text that has the Rhythm FPGA start time, but FPGA start timestamp is still after the timestamp of the first recorded sample. Could you please advice on what I might have done incorrectly? Any help would be appreciated.
Yu
from analysis-tools.
I figured out couple days ago. Just post here in case someone else has the same question. The record is 1024 sample per block, the actual acquisition may starts in the middle of the 1024, so the first sample timestamp in the sample block is before the acquisition start timestamp. I guess this is really a naive question after finally got what record block means...
from analysis-tools.
Related Issues (20)
- Splitting and Merging .dat Files HOT 3
- Trouble loading events data in matlab when saving in flat binary format with the updated GUI: load_open_ephys_binary.m looks for channels.npy HOT 3
- Binary dat files to Plexon Offline sorter HOT 7
- Failing to read metadata.npy for TTL events in this specific setup HOT 4
- Converting continuous.dat into SpikeGLX flat binary HOT 4
- data and timestamp length unequal using load_open_ephys_binary HOT 4
- Session? HOT 1
- How to convert .continuous format to flat binary for using in Klusta HOT 1
- How to display the specific time point for spikes ? HOT 1
- load_open_ephys_data_faster.m memory error HOT 5
- Import continuous data recorded by neuropixels HOT 11
- Opening the binary data HOT 4
- issue running TT openephys data recorded in binary to Mclust
- Using analysis tools in Jupyter Notebook HOT 4
- Merging multiple OpenEphys binary (continuous.dat) files HOT 1
- Info Channel Header Location HOT 2
- Missing Probeinterface file for Neuropixel 1.0 (Open Ephys)
- recovering timestamps HOT 1
- OEP v0.6.2 Python KeyError: 'source_processor_sub_idx HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from analysis-tools.