MWorks integration with Open-Ephys

Support
1

Hi Chris,

I was wondering if you could give me some details about the output data formats in MWorks/OE integration. I am thinking about writing a set of functions in Matlab for online sorting and analysis (ex. PSTH). It would be great if I could have a sample data file for testing.
Please let me know.

Thanks,
Eghbal

2

Hi Eghbal,

I haven’t implemented the MWorks end of the MWorks/OE integration yet. My current thinking is that all OE spike events will be funneled in to the MWorks event stream via a single, user-provided variable. Each time a new spike comes in, MWorks will put the relevant parameters (time, electrode, etc.) into a dictionary and assign that dictionary to the variable. When imported in to MATLAB, these dictionaries will be converted in to structures.

However, as I said, this isn’t implemented yet, so if you have other ideas about how the spike data should be stored, I’m open to suggestions.

Also, can you tell me how you currently manage time stamp synchronization between MWorks and OE? I can think of a couple ways to implement it, but I’d like to know what works for you now.

Thanks,
Chris

3

Hi Mehrdad, Eghbal, & Evan,

Following up on yesterday’s meeting, here’s the list of fields included in each Open Ephys spike event. This was edited from the C++ source code, so the numbers/constants in square brackets indicate array sizes:

timestamp
timestamp_software
nChannels
nSamples
sortedId     // sorted unit ID (or 0 if unsorted)
electrodeID  // unique electrode ID
channel      // the channel in which threshold crossing was detected
color[3]
pcProj[2]
samplingFrequencyHz
data[MAX_NUMBER_OF_SPIKE_CHANNELS * MAX_NUMBER_OF_SPIKE_CHANNEL_SAMPLES]
gain[MAX_NUMBER_OF_SPIKE_CHANNELS]
threshold[MAX_NUMBER_OF_SPIKE_CHANNELS]

Currently, only electrodeID is included in the MWorks event for the spike. Are there other fields you’d like to see added?

Note that timestamp is already used to compute the MWorks timestamp for the spike. It would only need to be included in the MWorks spike data if you wanted the raw OE timestamp to be available to MWorks/MATLAB.

Thanks,
Chris

4

Chris,

I defer to Eghbal and Evan but it seems to me that timestamp and sortedId are useful.

Thanks,
-Mehrdad

5

Hi Chris,

I sortedId and either electrodeID or channel. I’m not sure how those
differ, but Eghbal can probably decide which is best.

Thanks,
Evan

6

Hi Chris,
Is sort ID independent of the channel ID?
Thanks,
Eghbal

7

Is sort ID independent of the channel ID?

It looks like channel is relevant only for stereotrodes and tetrodes. For single electrodes, the number of channels per electrode is one, so channel should always be zero.

I think the general relationship is that a given electrode ID can have 1, 2, or 4 different channels associated with it, and a given electrode/channel pair can have multiple sorted ID’s associated with it.

Chris

8

Based on this information, all are needed.

-Mehrdad

9

OK, so I’ll include timestamp, sortedId, electrodeID, and channel.

Thanks,
Chris

10

Hi all,

The MWorks nightly build now supports integration with Open Ephys. To use it, you’ll need a modified version of the Open Ephys GUI. (Eghbal, I’ve placed a copy for you in the “sample_kwik_data” folder on Dropbox. The file name is open-ephys-osx-mworks.zip.)

I’ve attached an example MWorks experiment and corresponding OE configuration file that demonstrate the integration. The MWorks experiment includes an “Open Ephys Interface” I/O device. The parameters of this device include the hostname and port for connecting to the OE GUI, the name of the clock sync variable, the line number(s) of the OE TTL input channel(s) to which the clock sync is sent, and the names of (optional) output variables for spikes and the computed OE-to-MWorks clock offset. The example uses a 2-bit word for the clock sync. As we discussed, the experiment is responsible for sending regular sync signals. (MWorks will warn if more than 5 seconds elapse without receiving a sync back from OE.)

The OE configuration includes an “Event Broadcaster” sink. For real recordings, this needs to appear after the spike detector/sorter in your signal chain.

Also per our discussions, it’s now possible to exclude specific variables from MWorks data files. To do this, add exclude_from_data_file="YES" to the variable definition. (This is done for the spike variable in the example experiment.) When this is done, no values for the excluded variable will be stored in the event file. However, variable updates will be accessible as usual via other channels (e.g. the variables window or MATLAB bridge).

When you have a chance, please try this out, and let me know if you have any questions or run in to any issues. We may need to iterate on this a bit before everything works to your satisfaction.

Cheers,
Chris

11

Attachments:

12

Hi all,

Just a quick update: My changes to support MWorks/Open Ephys integration have been integrated in to OE and should be included in standard releases going forward.

Note that a few implementation details changed during the integration process, and these changes are reflected in the current MWorks nightly build (as well as the forthcoming 0.6 release). Eghbal, when you move to a newer version of MWorks, you’ll need a new OE build, too. You can either build it yourself from source, or I can do it for you. (In the latter case, just let me know the OS X version of the machine you want to run OE on.)

Cheers,
Chris

13

Hi Chris,

Thanks, for your email.
Do you mind sending an OE build, the one I build from github has build errors. I am using OS 10.10.4.

Thanks,
Eghbal

14

Hi Eghbal,

Do you mind sending an OE build, the one I build from github has build errors. I am using OS 10.10.4.

No problem. The updated build is on Dropbox. The filename is open-ephys-osx-mworks-v2.zip.

Chris