process_evt_read in "bit" mode doesn't work with the "current/beta" CTF format, with channel UDIO001 where the values are 16-bit positive integers.
I did some debugging and it seems to go wrong here:
% Determine the precise timing of the triggers (from FieldTrip's read_ctf_trigger)
upflank = [0 (diff(tracks)>0 & tracks(1:(end-1))==0)];
tracks = upflank(1:(end-trigshift)).*tracks((1+trigshift):end);
Looks like this only wants to keep transitions from 0 (full channel value) to something else. This is not the correct logic for "bit" mode.
It also happens before "Add the initial status of the tracks", which might also miss transitions right on a block boundary.
By the way, this is a minor detail, but the shift value seems odd to me. There is a delay in MEG and other analog channels due to the antialiasing filter, but I was told by CTF that it's 3 or 4 samples (and I think we verified that around 2009 in Toronto). This code adds a fixed duration delay instead of a fixed number of samples, and it's probably only correct at about 600 samples per sec.
By the way, this is a minor detail, but the shift value seems odd to me. There is a delay in MEG and other analog channels due to the antialiasing filter, but I was told by CTF that it's 3 or 4 samples (and I think we verified that around 2009 in Toronto).
One other problem I see here is that the file in the original CTF format would include these shifts, while running the same detection on a file converted to .bst format would not. Therefore this detection would perform differently before or after applying a notch filter, for instance.
Regarding CTF files, you are the expert, here.
Could you open a PR to propose a fix for these issues?
Please prepare an example dataset to test these changes.
This code adds a fixed duration delay instead of a fixed number of samples, and it's probably only correct at about 600 samples per sec.
This is coming from FieldTrip:
Could you please open an issue on the FieldTrip repo to ask about the variability of this shift with the sampling frequency?
I first thought the issue was related to a change in file format (hence the confusing start of my post), but it's really that "transition from 0" expectation that needs fixing.
To clarify about the shift, it's not a CTF file format issue. It is the group delay resulting from the online low pass antialiasing filter of all analog channels. This is always present in CTF data. I would vote for not attempting to correct this, and instead mention it in the delay tutorial as you suggested. For one, it's very small, and it's a group delay so it's not exactly corrected by time shifting Plus it might differ between systems. From the CTF documentation (for our current version of the electronics):
Data collection from the electronics is at a rate of 12kHz. When a lesser data rate is selected, all analog channels (MEG, EEG, Head Localization (HL), ADC, and DAC) are filtered to prevent aliasing. The filter is an IIR low pass with the cutoff at one quarter of the new sample rate. It is an 8th-order elliptic filter with 0.1db pass band ripple and 120db attenuation at Nyquist frequency (one half the sample rate). Note that the anti-aliasing filter has a group delay that adds a time delay to all analog channels (relative to digital channels) of four samples at the new sample rate.