A Simple and Inexpensive System for Multichannel, Closed Loop Electrophysiological Experimentation

Experimentation

There is growing need for multichannel electrophysiological systems that record from and interact with neuronal systems in near real-time. Ideally, such systems would be inexpensive, reliable, user friendly, easy to set-up, open and expandable, and possess long life cycles in face of rapidly changing computing environments. Finally, they should provide powerful yet reasonably easy to implement facilities for developing closed-loop protocols for interacting with neuronal systems.

Here we provide full sources for a solution we created referred to as Closed Loop Experiments Manager (CLEM). CLEM is a soft real-time, Microsoft Windows desktop application based on an inexpensive, general-purpose 64-channel data acquisition board (UEI PD2-MF-64-3M/12L) and a generic personal computer. CLEM provides a fully functional, user-friendly graphical interface, possesses facilities for recording, presenting and logging electrophysiological data from up to 64 analog channels, and facilities for interacting with external devices, such as stimulators, through digital and analog interfaces. Importantly, it includes facilities for loading “plugins” containing functions for running closed-loop protocols. Such plugins can be written in any programming language that can generate dynamic link libraries (DLLs) as long as they conform with CLEMs requirements.

CLEM is a 64bit Windows desktop application written in C and C++ using Visual Studio 2013 and is based on the generic Win32 API and GDI. It thus does not require external code libraries, beyond those provided by the boards’ vendor. The project generates a single executable file, which does not depend on registry entries but does require a configuration file (provided). In addition to source files, the project contains setup files for installing an executable version.

Example code and further information needed for creating Plugins can be found in a related project: CLEM Plugin Template

Benchmarks

The system described here uses interrupts generated by the data acquisition card to clock sample-analyze-output loops. To measure the sample-analyze-output execution times this approach allows, and, importantly, the jitter in such times, we wrote a small plugin in which the real-time closed loop procedure:

1) recorded time intervals (in sample units) between consecutive calls (“timestamp based measurements”)

2) changed an output signal based on the input signal, and then measured the time (in analog to digital sample units) since the command was issued until an actual change was physically detected in a subsequent iteration (“I/O based measurements”).

For the latter tests, we connected an Analog-out channel to one of the 64 Analog-in channels. During each iteration, the real-time closed loop procedure examined the value of the input channel, and set the analog output accordingly: For input values < 1V, the output was set to 5V; conversely, for input values >1V the output was set to 0V. Because the minimal time interval between consecutive interrupts was determined by the time needed to collect the smallest allowable number of samples (64 samples for each of the 64 input channels), sample-analyze-output loop time intervals depended on sampling frequency (i.e. higher sampling frequencies resulted in tighter loops). We thus tested system performance at two sampling frequencies (16Khz and 45Khz). As shown in the image bellow, mean interval times were 3.94ms and 1.40ms at 16Khz and 45Khz, respectively (102,085 and 259,952 loops/iteration, ~6 min runs) with almost negligible jitter. Note the greatly expanded Y axis range. These data thus suggest that the system can perform sample-analyze-output loops at repetition rates exceeding 700 Hz in a very reliable fashion.

Benchkmark dll and its source code is located in Benchmark directory.

Demonstration of closed-loop execution

As a demonstration of closed-loop procedure execution, we wrote a DLL which carries out two concomitant tasks. The first, carried out by the real-time closed-loop procedure, scans recent spikes for a predefined motif; upon its detection, it triggers an external device through one of the digital-out lines. The second, carried out by the slow periodic procedure (called once a second), counts the number of spikes detected during the last 60 seconds and updates the User data graph accordingly.

-Motifs were then defined as sequences of action potentials recorded from 5 different active electrodes within inter-spike intervals that did not exceed 10ms. The task assigned to the real-time closed loop procedure was to 1) scan the spike history repository in search of the predefined motif; 2) upon identifying one, set a digital out line to high; 3) set the digital line back to low after 5 msec, and 4) impose a refractory period such that no triggers will be issued within 1 sec of the prior signaled event, even if motif recurrences are detected. The task assigned to the slow periodic closed loop procedure was to 1) scan the spike history repository and count all spikes recorded within the last one minute; 2) scale the value and 3) send the value to the first user data graph. All code was written in C, compiled and tested by loading (and unloading) the DLL into CLEM without leaving CLEM.

For more details on the materials and method of the experiment please refer to the paper