Back to the main page.
Bug 2435 - error: different sampling rates in continuous data not supported
| Status | CLOSED WONTFIX |
| Reported | 2014-01-13 17:43:00 +0100 |
| Modified | 2014-02-24 10:56:21 +0100 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P5 major |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Ian Andolina - 2014-01-13 17:43:02 +0100
This is pretty minor, but does stop me loading any plexon data. The plexon omniplex can store LFPs and wideband data in the same file, so one ends up with channels with 1khz and 40khz frequencies. Currently ft_read_header(p.file,'headerformat','plexon_plx') causes an error and stops me reading the header, shouldn't this be a warning rather than an error? ~line 1659 if any(fsample~=fsample(1)) warning('different sampling rates in continuous data not supported, please select channels carefully'); end
Ian Andolina - 2014-01-13 17:47:16 +0100
or I suspect for consistency of the header, allow a user to pass an additional argument selecting a preferred sampling rate to return, i.e. only the information of the 40khz or 1khz data?
Robert Oostenveld - 2014-01-14 11:12:13 +0100
both ft_preprocessing and ft_read_data return data organized in matrices, one channel per row, one sample per column. Channels with different sampling rates don't fit in such a matrix. Hence it is a general limitation of fieldtrip (also for other data formats, such as edf). I don't know whether work-arounds have been documented, but don't think so. Work-arounds would have to be system specific and file format specific (e.g. plexon plx, ddt, nex all have to be treated differently). The solution would be to not use ft_read_header/data/event, but the low-level reading functions. If you want to pursue this (and probably you will have to), please share your experience with others by making a faq on the wiki. PS: the plx file format has an extremely inefficient internal data representation, making them very slow to read, especially whgen they are large. Much more convenient is to convert it to nex files, and then split the data of different channels (with different fsample) over different files. So in this case the work-around might be outside matlab/fieldtrip. I'll close this report, as it is not a "bug" but a known "feature" (i.e. known limitation by design) that cannot be fixed.
Ian Andolina - 2014-01-14 17:03:19 +0100
Thanks for this useful info. I suppose my theoretical workaround was to allow: ft_read_header(p.file,'headerformat','plexon_plx','preferred_rate',1000) and the same for the other functions to select the LFP data from plexon files without the hard error, but I understand how hard this will be to standardise across your supported data formats! My actual workaround will be to try and replace these functions with my own routines. Are ft_read_header, ft_preprocessing and ft_read_data the only functions which should cause problems? I'm happy to add info to a wiki once I know what my route through should be! Thanks again, Ian p.s. yes plx is non-optimal, however the current plexon SDK reads in continuous / spikes / header data pretty quickly; 'plexon_plx_v2' is ~1600X faster than 'plexon_plx'; it takes about ~0.2s to read a header vs. >300s for the old block based 'plexon_plx' routines and only ~1s to read in all continuous LFP data from a tetrode recording (I didn't even try 'plexon_plx' for that yet...)
Ian Andolina - 2014-01-24 13:40:40 +0100
Robert, as far as I can see plexon files even if they *only* contain channels sampled at 1Khz are read with a hdr.Fs as 40KHz, this means any plexon file which only contains non-wideband data which a user wants to analyse cannot use fieldtrip. I suspect most plexon users use fieldtrip to analyse LFPs, which makes the current fieldtrip plexon file support useless; they are forced to resave their data using nex or another format One part of this problem is due to a simple bug in where the if any(fsample~=fsample(1)) is, as it is testing fsample for all channels, including empty channels. If this if statement is further down in patched ft_read_header code then the error isn't triggered. As you have yet to merge the plexon_plx_v2 format code there is nothing I can currently fork and create a proper pull request on, but I do have a branch of the new plexon code on github with this change made allowing LFP-only PLX files to be read: https://github.com/iandol/fieldtrip/compare/plexonv2?expand=1#diff-5d1f098de11e1de47c7bbef657a1be32R1721