Flat binary file has more/less samples than expected about analysis-tools HOT 4 CLOSED

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.