SCRC Data Capture and Analysis Software FAQ

Home › Software › FAQ

This FAQ is compiled by the Gilles Detillieux of the SCRC, based on questions posed at various times, mostly via e-mail, or sometimes in anticipation of questions likely to come up. The most recent version is available at "http://www.scrc.umanitoba.ca/doc/faq.html". Questions (and answers!) are greatly appreciated. Please send questions and/or answers to the SCRC Software support mailing list at <neuro@scrc.umanitoba.ca>. You can subscribe to this mailing list here: Software Support Mailing List.

Frequently Asked Questions

1. General

top

2. Getting the Software

top

3. Capture

top

4. Analysis Techniques

top

5. Import/Export

top

Answers

1. General

The official name of our software package is SCRC Data Capture and Analysis Software, but it's also unofficially known as the neuro package. Either name will do.

top

You currently have two options for bug-reporting. You can either mail the mailing list at <neuro@scrc.umanitoba.ca> or e-mail Gilles directly. Either way, he will see it and look into the problem. We may at some point add a bug reporting form and tracking system to our site, but for now e-mail is the preferred means. Please try to include as much information as possible, including the version of the package you are running (see question 2.1), the operating system you have on your computer, the program that failed, any error messages you saw displayed, and anything else that might be helpful in reproducing the problem.

top

Great! Development of this software continues through suggestions and improvements from users. If you have an idea (or even better, a tip or script to contribute), please send it to the mailing list so others can use it. If you'd like to make a feature request, you can do so through the mailing list as well.

top

While Gilles does his level best to answer all his e-mail, especially from users of the neuro package, he is often swamped, so messages may at times slip through the cracks. If you don't get a reply within 2 or 3 days, try sending a reminder. You may also find it preferable to send your questions to the mailing list, as you may be able to get help from other users more promptly. Note that when posting a followup to a message on the mailing list, you should use the "reply to all" or "group reply" feature of your mail program, to make sure the mailing list address is included in the reply, rather than replying only to the author of the message. See also question 1.6 and the mailing list page.

top

As for mail directly to Gilles, you may not always get a reply right away. Other users may also be to busy to respond, or may not be able to answer, and will just leave the question for someone else on the list. If you don't get a response after 2 or 3 days, then a reminder may help. See also question 1.4 above.

top

The neuro mailing list exists for dealing with questions about the software, techniques for using it effectively, and dealing with problems with it. E-mailing the developer, or any one particular user, circumvents this forum and everyone else on it. It also bypasses the mailing list archives which may help others with similar questions. Finally, it puts the onus on an individual to answer, even if that individual is not the best or most qualified person to answer. Some users have found ways of using the software that Gilles never envisioned, and may be able to provide answers to others more effectively than Gilles could.

Note also that when you reply to a message on the list, you should make sure the reply gets on the list as well, provided your reply is still on-topic. See question 1.7 below.

top

The simple answer is that, unlike some mailing lists, the lists on the SCRC server don't force replies back on the list. This is actually a good thing, because you can reply to the sender directly if you want to, or you can use your mail program's "reply to all" capability (sometimes called "group reply") to reply to the mailing list as well. It does mean you have to think before you post a reply, but some would argue that this is a good thing too. There are some compelling reasons to try to keep on-topic discussions on the list, though (see questions 1.6 and 1.4 above).

The technical answer is our "mailman" mailing list manager software is wisely configured by default not to do what's known as Reply-To: munging. If you want to find out more, you can read SourceForge's policy on Reply-To: munging, where you'll find all the gory details about the pros and cons of the two common ways of setting up a mailing list, and why SourceForge turns off Reply-To munging. It so happens that Gilles agrees with this rationale, and doesn't plan to turn this feature on.

top

Before you go anywhere else, think of other ways of phrasing your question. You have questions that are very similar to other questions answered here. While we try to phrase the entries in the FAQ closely to the most common questions, we can't get them all! The next place to check is the documentation itself. In particular, take a look at the list of analysis parameters. You should also try a search of our web site, which will include the contents of our online documentation, tutorials, help files, and mailing list archives. Finally, if you've exhausted all the online documentation, there's the neuro mailing list. There is a good chance that someone on the list has had a similar problem before or can suggest a solution.

top

2. Getting the Software

The latest non-beta version in producton use is 20040716 as of this writing, although for analysis-only systems the 20031016 release is essentially equivalent. The latest beta release is 20111212 for Linux, Windows, or Mac OS X. The version number is in fact just the date the source code was packaged together before building into binary packages for installation. You can find out about the latest version we're running here by reading the What's New pages. The change log in particular will have the most recent changes.

To find out what version you're running, it's usually just a matter of running the "rpm" command on Red Hat Linux to query the "neuro" or "neuro-cap" package. The neuro-cap package is installed on data capture and analysis systems, while the neuro package is for analysis-only installations. The command "rpm -q neuro neuro-cap" will tell you what is installed. For non-Red Hat systems, you can just look at the date of the ChangeLog file that comes with the package, e.g.: "ls -l /usr/neuro/doc/ChangeLog" as this is the last file updated before the package is built. If you don't have a ChangeLog file, then your installation is from July 2000 or earlier. The date of /usr/neuro/bin/analysis should give you a rough idea of the release date.

top

The cost of the full SCRC Data Capture and Analysis Software package is $7000 (Canadian). For the analysis-only package, it is $5000 (Canadian). Researchers who have already obtained one such license for the full capture and analysis package or the analysis-only package, at full price, can then purchase additional sub-licenses for each additional analysis-only workstation they set up at their site, at a cost of $500 (Canadian) per workstation. See our fact sheet for more information about the software. Please e-mail us if you require a quotation for a software purchase.

top

Yes, full source code has always been included with the SCRC software. You can usually find it under the /usr/neuro/src directory on any system on which the software is installed.

top

While a number of systems have supported this software in the past, we currently recommend Intel Pentium or compatible PCs running Red Hat Linux, for data capture as well as analysis. See our fact sheet and O/S requirements page for more information about supported hardware and operating system software.

top

Until the summer of 2009, the answer was no. Because the software was written to run on UNIX-compatible operating systems, like QNX, Linux and Mac OS X (for the analysis portion), porting it to run directly on a Microsoft Windows system would have been rather difficult. But an emulation environment called Cygwin/X makes that task considerably easier, and has gotten to be reliable enough that we now support it. So, now the analysis portion of the software can run under Windows XP or Vista. Additionally, using some form of virtualization technique, you can run a Linux system as a virtual machine right on your Windows system.

Finally, because the software runs on the X Window System on Linux or UNIX compatible systems, it is possible to run the software remotely on any of these systems on the network, while displaying on any other system that supports the X Window System for display. As software is available for Microsoft Windows to turn a Windows PC into an X Window System terminal, you can run the software over the network from any Windows-based PC, using remote X11 display. If you already have a Linux system running our capture and analysis software at your site, then this may be the preferable way of running analysis from your Windows desktops, as it keeps your data centralized on your Linux server system.

top

The documentation for the most recent release we have installed is always posted at www.scrc.umanitoba.ca/doc. In all releases, much of the documentation is included in the /usr/neuro/doc subdirectory of the source distribution, so you have access to the documentation for your installed version. On Red Hat Linux installations, the RPM package will also install the manual pages in the appropriate directories so they can be accessed with the man command, e.g.: "man appendrun".

top

There are two ways to determine the answer to this question. The first, and likely most helpful one, is to have a look at the listing of SCRC Data Capture and Analysis Manual Pages on our web site, to see what's normally available in the current release. This will tell you not only what the comamnds are, but what they do, and will link to documentation for all of these commands.

The second way is to get a definitive list of all the commands installed on your system right now. You can do this by looking in the /usr/neuro/bin directory on any system on which the software is installed, e.g.: "ls -l /usr/neuro/bin". If the command you're looking for isn't listed there, chances are it's an add-on command or script as described below.

top

The analysis script archives on our web site are a collection of locally developed or user-contributed analysis scripts, which can be freely downloaded and installed on your system. In some cases, scripts on our web site are already included in the package, but in those cases the version on our site may be a newer version with added features. If in doubt, look in the /usr/neuro/bin directory, as described above, to see which commands are included in the analysis software package on your system. If the script you're looking for isn't listed there, or the size is different from that listed in the analysis script archive then you should probably download and install the needed script.

To download a script from our web site, you can view the list at http://www.scrc.umanitoba.ca/archives/viewscript.cgi, then right-click on the link to the script you want and choose "Save Link As..." or some equivalent selection from the pop-up menu, or you can left-click the link to view the script, and then do a "File->Save As..." to save a copy of the script. Note that on some systems, the web browser may add a .txt extension to the script file name, in which case you will then need to rename the file to remove the extension. Then, the script should be installed in /usr/local/bin or /usr/neuro/bin on your analysis system, and made executable with the command "chmod +x filename", where filename is the full pathname of the installed script, e.g. /usr/local/bin/gensspp. This will enable the script to be run as a command on your system. You will need to be logged in as "root", or raise yourself to administrator status with the "su" command, in order to install scripts in either of these two directories. The choice is yours which of the two you prefer to use, but you should probably be consistent to avoid losing track of what you've installed.

While it might be a bit of a bother to have to install your own add-on commands, it allows for quicker updates than what you can get strictly from the packages of distributed software. Having access to our script archive gives you updates to the latest features and user contributions as they happen, without having to wait for them to be packaged in the next analysis software release.

top

3. Capture

This is largely dictated by the hardware you are running, and which operating system version, as well as a number of capture parameter settings. There are no hard and fast limits on the number, apart from the fact that the only supported A/D cards until recently have been 16 channel cards, and the software had a limit of 16 traces and 16 waveforms for a given run file. For the Linux-based data capture systems, we have tried to preserve reliable performance capturing 16 channels at 20 KHz per channel.

Until recently, the only supported A/D cards have also been 12 bit cards. Support for 16 bit cards has been developed, as has support for cards with up to 64 channels. This is currently in beta test, but has been working quite reliably in one of our labs for just over a year. See our item on Expanded Channel Capability for details.

top

4. Analysis Techniques

If you're still learning the software, the best way to learn various analysis techniques is to look at the on-line tutorials on our web site. In time, we will be expanding these to include more techniques. We will also be describing specific analysis techniques briefly below, as the need arises, for techniques not covered by the tutorials. For techniques not in the tutorials or the FAQ below, we recommend you browse through the Analysis User's Manual, or the list of Analysis Methods in the analysis help facility, to find something close to what you need. Then, explore the analysis parameters for that method, to see if you can get it to produce the type of graph you want. Finally, you can always ask the mailing list. See also question 1.8.

top

What we often refer to as "integrating" in electrophysiology is really not integration at all, but simply rectifying and filtering, in order to obtain the linear envelope of a signal. True numerical integration is the reverse of differentiation, in which successive samples are summed up. This summing up continues over the whole duration of the signal, such that at any point in time, the value of the integrated signal is the area under the curve of the non-integrated signal from time 0 up to the current point in time. This technique, in and of itself, is not generally used in processing raw ENG or EMG signals.

A variant of this numerical integration is to perform it on time slices of the signal, where you integrate for some short amount of time, after which you zero out the sum and start over integrating the next time slice. This technique, which can be performed in software or hardware, is sometimes used in electrophysiology, as it produces a signal that can approximate the envelope of the signal being integrated.

The more common technique, and the one which we use in our labs, involves full-wave rectification of the signal followed by low-pass filtering. It is often referred to as integration, even though that term isn't exactly correct, because it somewhat approximates the time-sliced integration technique. This is because the low-pass filter accumulates charge from the signal (like summing it up) and slowly bleeds it off (like resetting the sum, only gradually rather than at fixed time increments). Again, this technique can be performed in hardware or software, and we use both methods in our labs. Some labs are equipped with hardware "integrators" (rectifier/filter units) which can process the raw ENGs into signals that give the ENG envelope, which can then be captured at a lower sampling rate than raw ENGs. More commonly, we will capture the raw ENGs and rectify and filter them in the analysis program.

The trick to this approach is to find the appropriate cutoff frequency for the filter, which will vary depending on the source of your signal. The cutoff frequency must be low enough to filter out individual spikes, but not so low as to attenuate the pattern of bursts of spikes. Our analysis program's Maint/Filter section can perform the rectification and filtering in one operation. Tutorials 13 and 14 on our web site give some pointers on how we do this in the analysis software.

top

Unfortunately, the term "raster" suffers from overload, and means different things in different contexts, which leads to confusion. Even in electrophysiology it has two different meanings:

a) a "waterfall" plot of triggered sweeps of data, plotted front to back with an offset and optional hidden line removal; and

b) a graph of action potential positions, with each line in the graph representing a different cycle, and with each dot marked on the line indicating the action potential position within that cycle.

The raster program in our software suite produces the first type of raster plot, not the second. You can produce the second type within the analysis program, using the graph of action potential position vs cycle (or the sorted version of this). For this analysis, it helps to turn off the Normalization option, and turn on the Display cycle activity option, so you can see the varying cycle lengths and how the spikes line up with them.

You can also produce a waterfall plot of waveform spikes, rather than just spike positions, by converting the waveform to triggered sweeps, which can then be displayed in the raster program. You do this by setting up a cycle triggered average, with a single bin per cycle but with a window duration as long as the longest cycle, so that you can get each full cycle as a triggered sweep. This cycle-triggered reframing technique is described in a little more detail in question 4.5 below. You then set the Preview average data option and Bins-save the preview (raw) data. See Tutorial 9 for an introduction to reframing and the raster program.

top

In the general case, a polar plot is essentially just an X-Y graph wrapped around in a circle, with the X coordinate representing the angle and the Y coordinate representing the radial distance from the centre. So, when you say you want a polar plot of your data, the question becomes what are the data for the X and Y axes of this graph? What these data are will determine the best approach to producing the graph, as there are essentially 3 different approaches to making polar plots in the SCRC software, and one of them can be applied to any cyclical graph in the analysis program.

Most of the polar plots made with the SCRC analysis software are generated by the gensspp script from our script archives. This script can plot the times of onset of activity on one waveform (usually a rectified and filtered ENG) on a cycle defined by the activity on another, or spike (action potential) onset times on a cycle. You will need to install this script on your system (see question 2.8), then follow Tutorial 13 for the procedure to use for making these polar plots, including the work you need to do to prepare the data for analysis (e.g. rectifying and filtering raw ENGs and marking up cycles). Tutorial 3 also explains the procedure for marking up cycles, if you need to go into more detail on the ins and outs of that technique, and the 5th and 6th sections of Tutorial 11 show how you can put the resulting HPGL plot files into final figures.

There are also some polar plotting capabilities right in the analysis program, as well as in our genplot program. A search for "polar plot" on our web site should find all the relevant documentation. The analysis program can turn any normalized cycle graph into a polar plot by setting the Cycles on graph and Normalization parameters. The genplot program can plot data from an ASCII text file into a cartesian or polar graph, and is the engine under the hood of our gensspp script.

top

The Maint/Reframe operation only uses a spike trigger, so you have to use a somewhat roundabout technique to reframe using a cycle trigger. You do this by setting up a cycle triggered average, with a single bin per cycle. You will need to set the window duration to an appropriate length. For example you can set it to be as long as the longest cycle so that you can get each full cycle as a triggered sweep. You then set the Preview average data option and when you perform a Bins-save operation, you can tell the analysis program to save the preview (raw) data. The end result is similar to reframing, but the resulting run file will only have the frame (trace) data, and no copies of the waveforms, like when you reframe with the "Without-W.F." selection.

top

5. Import/Export

There are a number of different methods of exporting data from the analysis program. Check out Tutorial 11 for an introduction to exporting data. Also, you can get a raw dump of an entire waveform file, as A/D levels, using the dumpwf script from our script archives, or you can use the new getwfdata script to dump several waveforms as a CSV file of millivolt values, downsampled to a frequency of your choice.

top

You can use either axon2run, to convert an ABF format file, or atf2run to convert an ATF format file. The usage of atf2run is the same as that of axon2run, except for the expected input file format. As Axon Instruments has changed its ABF file format since axon2run was written (using Axon's File Support Pack for DOS), this program may have difficulties converting newer files from their software, as detailed in question 5.3 below.

top

The axon2run program was written with Axon Instruments' older DOS-based file support pack, which handled the ABF (Axon binary file) format in use in Axotape and other programs as of the mid-nineties. They have since changed the ABF file format, so axon2run has problems with some newer files that make use of the extensions to their file format.

One important point to note is that there are now two types of ABF files: Binary Integer and Binary Floating Point. Pre-May 17, 2007 versions of axon2run could not convert Binary Floating Point ABF files. Be sure to save your files using Binary Integer, as Binary Floating Point will not work in old versions of axon2run. Files which have been analyzed in pCLAMP are saved in floating point by default. If you are experiencing problems with ABF floating point data files, you may wish to upgrade your software to the latest (May 17, 2007 or later) beta release, or just update the axon2run program on your Linux system (RH6.2 or later) by running the following command as root:

wget -qrO /usr/neuro/bin/axon2run http://www.scrc.umanitoba.ca/data/download/axon2run

However, there does appear to be some newer Binary Integer ABF files which also pose problems for axon2run. In those cases, you should convert them to ATF by opening them in Axoscope or whatever program you used, and saving them in the Axon Text File format. You can then convert the text files with atf2run. Note also that in Axoscope and Clampex version 10, they have changed to a new ABF2 file format which is completely incompatible with the File Support Pack we've used, so even the latest axon2run will not recognize these files. If you use version 10, you must save your files in version 9 format. These version 9 format files will be ABF floating point data, which the newest axon2run can convert directly. For older versions of axon2run, you'll need to reopen the version 9 file in Axoscope 9, and save as binary integer. In version 10.1 and later of Axoscope, you can directly "Save As" or "Export" to the older version binary integer ABF file type: for Save As, select ABF 1.8 (integer), and for Export, select pCLAMP9 ABF (integer).

Finally, the pCLAMP 9.0 manual also has this to say, which is relevant for axon2run and likely as well for any other third-party program that can read ABF files: "In order for Clampex 9 binary integer data files to be recognized by software packages compatible with pCLAMP 6 binary data files, it may be necessary to record the data with the Clampex Program Option configured to 'Ensure data files and protocols are compatible with pCLAMP 6', and to change the data file's extension from 'abf' to 'dat'." Older versions of axon2run did require the .dat extension, but current versions allow either. However, check to see if this option has been set. Note: this option also exists in Axoscope 9's Program Options, so you should set it there too, if using Axoscope to capture data. However, this option has no effect in Axoscope or Clampex version 10.

top

In addition to the axon2run program mentioned above, we have a number of other programs for importing data from other sources. The bin2run and dat2run programs were written to deal with lagacy data files at the SCRC, but could be used as the starting point for other conversion programs. They both deal with averaged triggered sweeps, which go into a .frm file, so this is the sort of data for which they'd best be adapted. You can find the source files for these under the /usr/neuro/src/bin2run directory on any system on which the software is installed. Also in that directory is a script called pp2run, which had been used at one point for importing data from Peak Performance software.

Our script archives also have a few more recent scripts, nsm2run and raw2run, which convert data from custom formats we've had to deal with. These scripts make use of the dsepr program, to convert interleaved 16-bit binary numbers into our run file format. These could be adapted to other similar formats, by changing the code that parses the custom header.

For dealing with programs that have an ASCII export capability, you may have better luck with the asc2run program. We've used it for importing data from the GENESIS neural simulation, but it is flexible and generic enough to be suitable for many ASCII export formats.

Finally, you can download and use Synaptosoft Inc.'s ABF Utility to convert other file formats, such as CED's Spike2 exported binary files, or Igor Text or Binary files, into ABF files. These can then be converted by axon2run. The ABF Utility can be downloaded separately, or as part of demo of their Mini Analysis program. This utility runs on Windows systems, so you'll then need to transfer the ABF files to your analysis system via FTP or some other means before running axon2run on them.

top

There are a few wrikles to printing support on the Mac, depending on which version of Mac OS X you're running.

• It's set up by default for a PostScript printer, and should print to the user's currently selected default printer.
• For OS X 10.2, printing to non-PostScript printers is a bit tricky, as you then have to use selectlp to pick a different printer type from the very limited set of printers the software supports directly. Effectively, only PostScript and PCL printers are supported by the software, as the other printer drivers are for more specialized or obsolete devices. We haven't expanded this list because a) we tend to use PostScript printers almost exclusively now, and b) on Linux systems (at least Red Hat ones), and newer OS X releases, the printing system emulates PostScript for any non-PostScript printer, so from the analysis software's perspective it's almost always printing to a PostScript printer.
• For OS X 10.3 and up, the printing system should emulate a PostScript printer when printing to non-PS printers, as most current Linux systems do.
• We've had reports that every so often, printing on 10.3 simply stops working until you restart the system. We haven't been able to reproduce this problem on 10.2, nor isolate the cause on 10.3.

If you are unable to print directly from the analysis software to your printer, we recommend plotting to files, and then using hpgl2pdf to convert to PDF files, which you should then be able to open and print in the Preview application on the Mac, or in Acrobat Reader on any other system. For hpgl2pdf to work on OS X 10.2, you need to install the ghostscript package on your Mac. It's available from a number of different sources, but probably the easiest way is to download the "ESP Ghostscript" (espgs) package from the gimp-print site, then edit your .profile file to add /usr/local/bin to your PATH environment variable (e.g.: export PATH="$PATH:/usr/local/bin" ).

top