Table of contents

Overview
Computer Hardware Requirements
Connecting the Data Acquisition System and the Computers
Installing Linux and RT-linux
Installing and Compiling the NSpike Code (without RT-Linux)
Running the NSpike Code (without RT-Linux)
Compiling and Testing the NSpike Code with RT-Linux
Collecting Data with the NSpike Hardware and Software
Troubleshooting
Working with the NSpike Code

---

Overview

This is the documentation for the NSpike Neural Data Acquisition hardware and associated open source software. This documentation includes descriptions of the data acquisition front end (the amplifier, digitial to analog converter, DSP processors and digitial input/output system) as well a set of instructions for setting up a network of computers to run the nspike data acquisition software.

If you want to test the NSpike code without RT-Linux on machines where linux is already installed, you will still need follow some of the instructions under Installing Linux and RT-linux:

• The network needs to be set up so that machines can see each other and lookup each others IP addresses
• The Kernel level networking settings must be correct.
• Direct Rendering must be on
• NFS must be working so the machines see the same code and have access to /usr/local/nspike.  Alternatively, you can install the software separately on each machine, but I strongly suggest using NFS instead.

You can then go on to Installing and Compiling the NSpike code.

Conventions: Instructions are in normal typeface, while commands that should be typed into a terminal window or into a file are in fixed width typeface. Directories are in bold face.

NSpike NDAQ Hardware Overview

The NDAQ hardware system consists of the following:

• 127 channel amplifier
• Amplifies both neural and, if desired, higher level signals, transmits data to
  
• 127 channel analog to digital converter
• Samples the amplified data at 30 KHz, 16 bits per sample, transmits data via optical fiber to
  
• Master DSP
• Maintains sample counter, outputs 10 KHz square wave for synchronization, outputs two analog channels for audio monitor / oscilloscope, passes data to
  
• Auxillary DSPs
• Each Aux DSP processes up to 16 channels of data. A user selectable reference is subtracted from each channel, the result is filtered, decimated if so desired, and sendt out in UDP ethernet packets (each containing a fixed number of samples from each channel) to one computer.

NSpike Computer Hardware Overview

The NSpike software package is designed to run on 1 or more computers. For the purpose of these instructions, we are assuming that are four computers, although additional slave computers can be added and we are currently experimenting to determine whether a single non-RT slave computer is sufficient. The computers consist of

1 main computer, 2 non-RT slave computers, and
1 RT slave computer.

These instructions should generalize to an arbitrary number of non-RT slave computers, as long as there is exactly one master computer and one RT slave computer. Each computer handles part of the data processing, displaying or saving as described below.

Tasks are divided among the computers as follows:

The RT slave computer

• maintains current time (clock module)
• takes in video frames (for tracking the animal's behavior) and sends
• processed position data to the master computer

The RT slave can also manage digital IO in conjunction with a UEI 64 channel DIO card, but as the nSpike hardware includes digital IO, this functionality is not being maintained.

The non-RT slave computer(s)

• process, save and display from one or more aux DSPs
  

The master computer

• processes, saves and displays continuous EEG data from one or more aux DSPs
• controls the Master DSP
• controls file I/O and data acquisition for all computers
  
• processes, saves and displays position data (video) from the RT slave

Things to Buy

 You need to purchase or make

• Five 6 - 12' BNC cables
• Two BNC T connectors
• One Female DB37 connector for the clock cable
• An audio monitor (we recommend buying a powered speaker with a volume control (total cost ~$350) rather than spending $1200 or so on a Grass Audio Monitor; it's cheaper and the sound is better)
• A two channel oscilloscope (if desired)
• Cables to connect the preamplifiers on the animal to the amplifier
• One or more black and white CCD cameras for position monitoring
• Preamps (if you would like simple and cheap 27 channel preamps, email Loren)
• Computers (see below)

---

Computer Hardware Requirements

The computer hardware consists of four computers and several auxillary devices. Below are recommended specifications:

Computer specifications:

Non RT-computers (3):

• Fast processor (> 2 GHz), multiple processor is fine, 32 or 64 bit (we use AMD systems)
  
• 512 MB RAM minimum
• high-performance accelerated graphics card (e.g. NVidia GeForce 4, 64 MB RAM)
• One reasonable size hard drive (we suggest > 100 GB)
• DVD-ROM drive for linux installation
• 19" or larger LCD monitor (CRT is fine, but takes up more space)
• Gigabit ethernet
• The master should have three gigabit ethernet cards
• The two slaves should have two gigabit ethernet cards
  

RT computer

• Reasonably fast processor (> 1 GHz) that is supported by RT-linuxfree (www.rtlinuxfree.com). As far as I can tell, any computer whose hardware is supported by the linux kernel version 2.6.9 will be fine, including AMD 64 bit computers, but we have yet to try a 64 processor with RT-linuxfree ourselves, so I cannot guarantee it.
• 256 MB RAM or more (there is no advantage in more unless you add your own programs that use large amounts of RAM)
  
• Any graphics card; rtlinux is NOT compatible with accelerated graphics, and in fact it is best to run the program outside of X windows (e.g. from a login shell)
• Small hard drive (no data will be written to the hard drive on this machine)
• DVD-ROM drive for linux installation
• 15" LCD screen
  
• One gigabit ethernet card.
  
• One frame grabber card with a Brooktree BT878 video capture chip (e.g., Hauppage WinTV-GO card, http://www.haupppage.com). See below for important instructions on the placement of this card.
• One PCI-CTR05 clock card, from Measurement Computing Corporation (www.measurementcomputing.com)
• If you want to have the RT computer handle digital IO, one PD-DIO-64 digital I/O card, from United Electronic Industries (www.ueidaq.com)
  

Other devices

• Two gigabit ethernet switches, one 16 port and one with 4 or more ports.
  
• The first hub will be used for data from the DSPs.
• The second hub will be used for communications between computers, including the transmission of position frames from the RT computer to the Master computer.\
• Do not use a hub, as it is essential that packets get routed to their destination and are not seen by other systems.
• One four port KVM switch to allow you the use of a single keyboard and mouse (and monitor, if you prefer)
• One keyboard
• One mouse
  
• Ethernet cables
• For a 128 channel system (8 aux DSPS) you will need a total of 16 short (5-10 foot) Cat 5e or Cat6 ethernet cables plus a single cable to connect the Master to the rest of your network.

---

Connecting the Data Acquisition System and the Computers

The diagrams below shows the overall organization of the data acquisition system as it is used in our lab, including the networking setup and the resulting data flow.



Network Connections:



Data Flow:






Building the Clock Cable

The clock cable connects the 10 KHz output of the Master DSP to the PCI-CTR05 card in the RT system. Take a 6 foot or longer BNC cable, chop off one end, and strip the other so that you have access to both the signal and ground lines. Solder the lines to the female DB37 as follows:

Use hot glue gun glue to cover the solder cups of all of the pins of the connector after soldering to pin 36 and wrap aluminum foil around the back of the connector and the BNC cable. You may want to fill the space around the back of the connector with hot glue. Make sure the foil makes good contact with the shielding of the cable and the metal outside of the connector. Finally, wrap the foil with electrical tape. If you have synchronization problems, check the shielding of the cable.





Connecting the Data Acquisition System components


Amplifier / Analog to Digital Converter Boxes:
The amplifier and the A/D box should be eventually placed in or at the ceiling, but for initial testing purposes we recommend putting them on a table top. The back of the Amplifier box has four 50 pin SCSI connectors on it and one input for a power cable. Make sure the power supply is off and attach the bare wire end of the power cable to the one of the 6V power supplies and the other to the Amplifier box.  Repeat for the A/D box. Plug one SCSI cable into each connector on the Amplifier box and attach the other end of each cable to the A/D box. Make sure output 1 from the Amplifier connects to input 1 on the A/D box, output 2 goes to input 2 and so on.

The Amplifier box has four rows of connectors on the front panel. These can be either Mill-max connectors (2x15 pins) and SMA connectors or DB-37 connectors. Here we assume you have the Mill-max version, each of which carries 27 channels of data, +5V and ground. The other connectors can be connected to either neural signals or line level signals (+/- 5V) but the amplitude ranges must be specified when you order the system. The pin numbers for each Mill-max and the mapping to the DSP channels is given in Appendix 1. Plug your fine wire cables into the Mill-max inputs.

Plug the long fiber optic cable into the TX fiber optic connector on the A/D box.

Master and Aux DSP Boxes:
Plug the other end of the long fiber optic cable into the RX fiber optic connector on the Master DSP box. Use the short fiber optic cable to connect the TX connector of the Master DSP box to the RX connector of the Aux DSP box. Connect the power supplies for the Master and Aux DSP boxes. Use Cat5, Cat5e or Cat6 ethernet cables to connect the ethernet ports on the Master DSP and on each Aux DSP to the 16 port hub.





Connecting the Computers

Master Computer:
There are three ethernet ports on the master. Generally the number of the corresponding ethernet device will increase as you move from the top to the bottom of the case, so the port closest to the top of computer is usually the first ethernet device (eth0). Plug the cable connecting the Master to the rest of your network into the first ethernet port. Plug the cable connecting the Master to the 16 port data hub into the next port (eth1) and the cable to the smaller, computer only hub into the last port (eth2).

Non-RT Slave computers
Plug the cable connecting each computer to the 16 port data hub into topport (eth0) and the cable to the smaller, computer only hub into the last port (eth1).

RT Slave computer
The BT878 framegrabber card must be in a PCI slot that allows it to have its own interrupt (IRQ). Generally, all PCI slots share interrupts (see motherboard documentation to see which ones are shared), so you will need to pick a slot whose interrupt is not shared by anything in use during data collection. Put the card in such a slot, and, if you are using the UEI digital I/O card, put it in as well. Plug the ethernet cable connecting the computer tothe smaller, computer only hub into the only port (eth0). Connect the BNC end of the clock cable into the 10 KHz output of the Master DSP and connect the female DB37 end of the clock cable to the back of the PCI-CTR05 card.

---

Installing Linux and RT-Linux

 This document assumes some familiarity with linux installation. The goal of this process is to

• Install Linux (we use Mandriva) on each computer
• Set up networking
• Set the kernel variables related to networking properly
• Ensure that accelerated graphics are available on the non-RT machines (Direct Rendering)

Linux Installation (all computers)

Get a DVD withthe latest version of your favorite distribution (we use Mandriva linux). Start the installation process. We recommend the following for installation:

• Set aside 6GB for the / (root) partition and 1GB for a swap partition. On the master computer, set aside an additional 6GB for a /homepartition. (NFS will be set up so that all slave computers mount the /home directory that resides on the master computer.) The remainingdisk space on each computer should be assigned as a /data partition. The ext3 file system seems to work fine.
• Be sure to install kernel source files.
• Install your favorite shell, text editor, etc.
• Install X11 and a low overhead window manager (e.g. fvwm or blackbox). You should have XFree86 / Xorgversion 4.3 or later.
• With any luck, your installation will correctly set up accelerated networking. If not, you will probably need to go to the NVidia or ATI website and download and install the correct drivers. We use NVidia cards, and the installation process is fairly straight forward, so it is not covered here.
• We have found that the Gnome window causes problems for the software related to some port numbers, so we do not use it.  We have not tested KDE, the other popular window manager.
• Select the Development packages so that you get gcc, the gnu debugger, and so on
• Install the Qt and Qt development libraries.
• Install the Mesa OpenGL, Glut, and Glut development libraries.
• If you cannot find these packages during installation, you can install them later using your distributions software configuration tools (drakconf for Mandrake)
• Install the libmpeg2dec and libfame libraries if you plan to use collect and analyze video data.
• Choose lilo as the boot loader
  

Networking Setup
Set up the network settings as follows. Here we assume there are four machines: drizzle (the master), rain (slave 1), mist (slave 2) and fog (RT-slave).

drizzle (master)
eth0 10.1.1.110  #connection to outside world; This is your ethernet address on your global network
eth1 10.1.2.1    #data connection for DSPs
eth2 10.1.3.1    #local network
netmask 255.255.255.0
gateway your_gateway (e.g. 10.1.1.1 for us)
name server your_nameserver (also 10.1.1.1 for us)

rain (slave 1)
eth0 10.1.2.2     #data connection to DSPs
eth1 10.1.3.2     #connection to drizzle
netmask 255.255.255.0
gateway 10.1.3.1
gateway device eth1
name server 10.1.3.1

mist (slave 2)
eth0 10.1.2.3     #data connection for DSPs
eth1 10.1.2.3     #connection to drizzle
netmask 255.255.255.0
gateway 10.1.3.1
gateway device eth1
name server 10.1.3.1

fog (slave 3, real time linux system)
eth0 10.1.3.4     #connection to drizzle
netmask 255.255.255.0
gateway 10.1.3.1
gateway device eth1
name server 10.1.3.1

Once the networking setup is complete, boot each machine into linux.

Edit /etc/hosts on each machine to include the other machines. Note that you can leave out the DSPs for the real time machine.

/etc/hosts should look something like this:
127.0.0.1 localhost

10.1.3.1 drizzle
10.1.3.2 rain
10.1.3.3 mist
10.1.3.4 fog

10.1.2.1 drizzle
10.1.2.2 rain
10.1.2.3 mist
10.1.2.10 dsp0
10.1.2.11 dsp1
10.1.2.12 dsp2
10.1.2.13 dsp3
10.1.2.14 dsp4
10.1.2.15 dsp5
10.1.2.16 dsp6
10.1.2.17 dsp7
10.1.2.18 dsp8
10.1.2.254 fakedsp

Note that it is essential that you have fakedsp listed.  As UDP packets are not acknowledged, your ethernet switch can lose track of the location of each machine and start broadcasting packets to all ports after some time (in our case about 9 minutes).  The code prevents this by sending empty packets to fakedsp once a minute.

Kernel Networking Setup

As superuser, add the following four lines to /etc/sysctl.conf:

net.core.rmem_max=8388607
net.core.rmem_default=8388607
net.core.wmem_max=8388607
net.core.wmem_default=8388607

Alternatively, you can open /etc/rc.d/rc.local in a text editor and add the following lines at the end:

sysctl -w net.core.rmem_max=8388607
sysctl -w net.core.rmem_default=8388607
sysctl -w net.core.wmem_max=8388607
sysctl -w net.core.wmem_default=8388607

These settingsincreases the socket buffer read and write sizes so that we will not lose data if any of the programs fall temporarily behind. 

Direct Rendering Check
Open up a terminal window and run the glxinfo program. There should be a line near the top of the output that says

Direct Rendering: Yes

If so, try runningglxgears and look at the framerate that the program reports. You should see > 500 frames/sec (ideally you'll see a few thousand or more).

If not, you need to get it working by installing the correct driver for your card.

RT-Linux Installation
The following additional instructions apply only to the RT slave computer:

In the BIOS, disable all of the devices that you won't need. These include USB ports (unless you are using a USB keyboard or mouse), parallel ports, serial ports, etc. Also disablepower management (sleep) support.

Make sure that the BT878 card has its own interrupt. To determinewhich interrupt each board is using, try cat /proc/pci.

RTLinux basically consists of two parts:

(2) a basic linux kernel which has been patched for compatibility with the rtlinux kernel. The patched linux kernel handles all of the typical linux kernelbusiness, except that it is subject to interruption by the rtlinuxkernel. The rtlinux kernel is autonomous add-on which is able topre-empt the linux kernel when there is real-time demand that needs tobe fulfilled. To get RTLinux working on the RT slave computer, youwill need to (1) install a patched linux kernel which is compatiblewith rtlinux, and (2) install the rtlinux modules which ride on topof this patched linux kernel.

www.rtlinuxfree.comis the current repository for the free RT-Linux code. Download a most recent "prepatched" kernel from their download area as well as the rtlinux modules.  We have had better luck with the 2.4 series kernel, and we are now using 2.4.28 rtlinux kernel and rtlinux-3.2-rc1.tgz.  Put both of these files in /usr/src (you will need to be root to do this).   You can also get our kernel and rtlinux code off the NSpike website, but it might be safer to start with the official versions.  

 Once you've put the kernel and the rtlinux files in /usr/src, do the following:

cd /usr/src
rm linux
tar xvzf linux-2.4.28-rtl3.2-rc1.tgz
ln -s  inux-2.4.28-rtl3.2-rc1 linux
tar xvzf rtlinux-3.2-rc1
ln -s rtlinux-3.2-rc1 rtl

We suggest that you follow the installation directions in the rtlinux-3.2-rc1/doc directory from this point on. Below we have a few additional notes for compilation:

NOTE: You MUST use gcc-2.95.3 or gcc-2.95.6 to get the rtlinux kernel and modules to compile.  You can download this from the gcc website.  Follow their installation instructions.

When configuring the kernel with

make xconfig (if you are in X windows)
or
make menuconfig (if you are in a text login shell)

do the following:

• Make sure that the processor type is i586 (even if you have a different processor). It should work with SMP enabled, even on single processor machines, but you may want to disable SMP support.
• DISABLE the following:
• power management support (it may be in the "General setup" group or a separate item)
• USB support (unless you need it for keyboard / mouse)
• parallel port support
• I2C support (in the Character devices group)
• Video for Linux (in the Multimedial Devices group)

• ENABLE the following:
• Network File Systems (in the File Systems group)
• Network device support (in Networking Support)
• Pick the ethernet modules appropriate to your hardware, or if in doubt, compile everything in (as a module).
  

We make the kernel by typing the following at the command line:

make bzImage; make modules; make modules_install

This make take a while. Note any error mesages that appear. Things can go wrong, depending onthe particulars of your system. Some experience with building linux kernels will make troubleshooting easier, as will looking around the web for similar problems.

You will nowl need to install the new kernel image by hand. It will be in /usr/src/linux/arch/i386/boot/bzImage, and you will need to find instructions relevant to your boot loader for the installation.  For lilo, brief instructions follow:

As root:

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-rtl2.4.28

Now edit /etc/lilo.conf.  Add a section at the bottom of the file that says the following:

image=/boot/vmlinuz-rtl2.4.28
    label="linux-rtl"
    root=/dev/hda1
    initrd=/boot/initrd.img
    read-only



The entry for root= may be different depending on your hard drive setup.  Copy the value from another entry.  We recommend changing the

default="linux"
to
default="rtlinux"

so that the system boots into rtlinux automatically.  Now run

lilo

You should see that there is an entry for linux-rtl and that it has a "*" after it (if you made it default).



Now you need to make the RT-linux modules.  

cd /usr/src/rtl
make

Make sure you include shared memory (mbuff) support, and otherwise choose the default build options. (There may be a license agreement to read.) Then

make ; make devices

We have found that some of the programs in the examples directory will not compile.  If the compilation works until you get to this stage (take a look at the output on the screen to see which file it is compiling) you are fine and you can ignore the error.  If the process fails earlier, you may need to start looking around the web for help.

Now open /etc/rc.d/rc.local in a text editor and add the following lines at the end:

pushd /usr/src/rtl
scripts/insrtl
insmod modules/mbuff.o
popd

Change the permission on the rtlinux FIFOs and the mbuff device so that they can be written to by any user:

chmod a+w /dev/rtf*
chmod a+rw /dev/mbuff

Reboot, choosing the new RT-linux kernel if it is not the default, and make sure that it all works.  To do so, become root and try the example modules in the /usr/src/rtl/examples directory.



NFS Setup
Now set up the shared filesystems. The home directory (/home/lorenlab for us) should be exported from drizzle and nfs mounted by the other systems.

Edit /etc/exports on drizzle to be

/home rain(rw,no_root_sqaush,sync) mist(rw,no_root_squash,sync) fog(rw,no_root_squash,sync)
/usr/local rain(rw,no_root_sqaush,sync) mist(rw,no_root_squash,sync) fog(rw,no_root_squash,sync)

Add the following line to /etc/fstab on rain, mist, and fog:

drizzle:/home /home nfs rw,suid,bg 1 1
drizzle:/usr/local /usr/local nfs rw,suid,bg 1 1

Now set up the data directory exports so you can copy the data off the system. Edit /etc/exports on the non-RT slaves to be

/data drizzle(rw,no_root_squash,sync)

Add the following lines to /etc/fstab on drizzle:

mist:/data /mistdata nfs rw,suid,bg 1 1
rain:/data /raindata nfs rw,suid,bg 1 1

In a terminal window on drizzle, create those directories:

mkdir /mistdata
mkdir /raindata





Copying RT-Linux to the Master
Finally, put the compiled rtlinux-3.2-rc1 code in /usr/src on the Master  so that you can compile the NSpike code on the Master.  On to the rtlinux slave, do the following:

cd /usr/src
tar cvzf rtlinuxnew-3.2.tgz rtlinux-3.2-rc1


Copy rtlinuxnew-3.2.tgz to the master and expand it in /usr/src:

cd /usr/src
tar xvzf rtlinuxnew-3.2.tgz
ln -s rtlinux-3.2-rc1 rtl

---

Installing and Compiling the NSpike Code (without RT-Linux)

Note that you will need to have set up networking correctly as described in the computer setup section before the code can be run on multiple machines. You will also need to have nfs exported /home and /usr/local directories that are available on all machines. All of the commands below assume that “.” (the current directory) is in your path. If it is not, add a “./” before each local command (e.g. make and configure).

First, unpack the compressed tar archive in the directory where you would like it to live. On our systems we store the source in /home/lorenlab/, so the commands are

cd /home/lorenlab
tar xvzf NSpike_x.x.x.tgz
ln -s NSpike_.x.x.x NSpike

This will create the NSpike_x.x.x directory, a link called NSpike and the various subdirectories. 0

Before compiling nspike you will need to install the mpeg encoding library on the computer that you will be using to compile the code (this is normally the master computer). The version of this library used for the code is included in the tar archive and is called “libfame-0.9.1.tar.gz”. libfame also exists in rpm form for most linux distributions, so if possible, download the rpm and install it. If not, not that the version of libfame provided doesn't compile on 64 bit systems. If you have a 32 bit system, you may want to move the libfake-0.9.1.tar.gz file somewhere else to unpack it (/usr/src for example). Unpack the archive and compile it (more detail instructions are in the INSTALL file that is extracted into the libfame-0.9.1 directory).

tar xvzf libfame-0.9.1.tar.gz
cd libfame-0.9.1
If you are on intel system that supports the MMX instruction set, run

configure

If you are on an AMD system (the type we prefer), use

configure --disable-mmx

next, become root and enter

make install

Return to the directory where you installed nspike (for us /home/lorenlab/NSpike). The nspike program can be run in one of two ways: with and without RT-linux. You should first get everything working without RT-linux (all data will be simulated) and only then try the code with RT-linux.

First examine the file “spike_defines.h” in the include subdirectory. Near the top of the file you will see a line that says

#define NO_RT_DEBUG

When that line is present (e.g. not commented out) the code will compile without the sections that interact with RT-linux. Make sure this line is not commented out, return to the nspike base directory and run the QT Makefile generating utility

qmake

to create the local Makefile. This depends on having qt installed, so if this doesn't work, make sure that the qt and qt development libraries are installed. Now do

makeallclean

to get rid of old files and

make

to compile the main program. This will compile the nspike code in the NSpike base directory and some, but not all of the code in the Modules subdirectory. You should see a few warnings but no errors. The warnings result from the -Wall compiler flag and can be ignored. If there are errors, they are most likely due to the absence of libraries that are necessary, and you will have to track these down and install them.

NOTE: For reasons that are not clear to me, the make utility does not always properly detect cases when the header files (e.g. spike_defines.h) are changed, so after changing a header file, make sure to do “makeallclean” and then “make” or “makeall”.

Now change to the Modules subdirectory and configure the makefile:

cd Modules
configure

If configure gives errors they are once again likely to be due to the absence of necessary libraries. Once it works it will generates the local makefile for the modules using Makefile.am as the automake template file. Now run
 
make

to compile the modules.

When both nspike and the modules have been compiled, go back to the Nspike directory and install the code in /usr/local/nspike by running the makeallinstall script as root. Note that for future reference, the makeall script is available to compile both nspike and the modules in one command.

cd /home/lorenlab/Nspike
makeallinstall

Check to see that the follow files exist in /usr/local/nspike (Note that the “*” after each file means that it is executable and is not part of the name):

ls /usr/local/nspike

should produce a listing like this:

nspike2 spike_behav spike_fixpos spike_process_posdata
nspike_matlab spike_daq spike_matlab spike_rgbcolor
nspike_rt spike_extract spike_posdaq spike_save_data

---

Running the NSpike Code (without RT-Linux)

Make sure that /usr/local/nspike is in your path.

NSpike Configuration files

The majority of the program configuration is specified in the configuration files. nspikeconfig is the default name of the main configuration file. The various options for each item are given within that file.
 
NOTE: at the moment, while it is possible to save configuration files within the main program, those saved configuration files can only be edited (and then used) if you delete the binary characters at the beginning and end. The program write out all files using the zlib compression library, and the header and final binary code need to go away if the contents of the file change. If you edit the file without removing the necessary characters and then try to run the program with the new configuration, it will die with a segmentation fault.

To get the program working, you will need to designate a master machine and some number (0-n) of slave machines. That designation, along with port numbers for communication between the machines, is given near the top of configuration file.

If you have 1 or more slaves, note that they will not begin acquisition until they recieve a message from the master, and similarly, exiting from the program requires exiting on the master machine.

The NSpike directory has a number of example configuration files which are named “nspikeconfig#”. These files are internally documented (comments begin with '%') and contain all of the configuration information to set datatypes, channel numbers, position tracking variables and behavior / digital IO variables. 

Running the Program on One Computer

First modify all of the nspikeconfig* files, changing the names of the machine(s) to fit your local setup. For nspikeconfig1-2, there is only one machine. For nspikeconfig3-4 there are two machines, so make sure to change all instances in both files to the two machines on your network.
Start in the NSpike directory and try the software with “nspikeconfig1”:

nspike –config nspikeconfig1

You will see quite a bit of output, as shown below.  This is normal, but can be changed so that each program sends output to its own configuration file by changing the #define STATUSFILE in NSpike/include/spike_defines.h.  The module numbers refer to numbers for each program defined in NSpike/include/spike_defines.h.

spike_main: Reading config file
machine num 0, type 0
Launching modules
spike main program getting client /tmp/spike_message_16_to_14
spike_daq: starting
spike_daq: starting messaging
module 12 starting server /tmp/spike_message_16_to_12
spike_save_data: starting messaging
module 14 starting server /tmp/spike_message_16_to_14
module 14 starting display client /tmp/spike_message_14_to_16
spike main program got client /tmp/spike_message_16_to_14
spike main program getting client /tmp/spike_message_16_to_12
spike main program got client /tmp/spike_message_16_to_12
spike main program getting server /tmp/spike_message_14_to_16
module 12 starting display client /tmp/spike_message_12_to_16
spike main program got server /tmp/spike_message_14_to_16
spike main program getting server /tmp/spike_message_12_to_16
spike main program got server /tmp/spike_message_12_to_16
getting data server /tmp/spike_data_12_to_16 from 12
sent message for data server /tmp/spike_data_12_to_16
program 12 got message 8, socket name /tmp/spike_data_12_to_16, protocol 0, type 1, connection from virga 12 to virga 16
sending START_NETWORK_SERVER to 14 for 16 to 14 DATA socket
getting client server /tmp/spike_data_16_to_14 from 16
program 14 got message 7, socket name /tmp/spike_data_16_to_14, protocol 0, type 1, connection from virga 16 to virga 14
sending START_NETWORK_SERVER to 14 for 12 to 14 DATA socket
sending START_NETWORK_CLIENT to 12 for 12 to 14 DATA socket
Waiting for CONNECTION_ESTABLISHED message on 14
got CONNECTION ESTABLISHED message from 14
program 14 got message 7, socket name /tmp/spike_data_12_to_14, protocol 0, type 1, connection from virga 12 to virga 14
Waiting for CONNECTION_ESTABLISHED message on 12
program 12 got message 8, socket name /tmp/spike_data_12_to_14, protocol 0, type 1, connection from virga 12 to virga 14
program 12 got message 2, socket name , protocol 0, type 0, connection from  0 to  0
program 12 sending out CONNECTION ESTABLISHED message to main program
Finished establishing messaging in program 12
program 14 got message 2, socket name , protocol 0, type 0, connection from  0 to  0
program 14 sending out CONNECTION ESTABLISHED message to main program
Finished establishing messaging in program 14
got CONNECTION ESTABLISHED message from 12
Finished establishing messaging in program 16
Sending system config
QLayout "unnamed" added to SpikeMainForm "unnamed", which already has a layout
Programming DSPs
Programming Master DSP
Programming Aux DSP 1
Programming Aux DSP 2
Programed DSPs
Status message: Clock Reset
Starting acquisition
Acquistion started

 You should now have a simulated EEG display with 24 channels. Every channel should have a 8 or so Hz sinewave on it. If it doesn’t work, the problem is likely to be in your modification to the config file, and you should carefully look through the output of the program to identify any errors it caught. To quit, select "Quit" from the Master menu.

Similarly,

nspike2 –config nspikeconfig2

should bring up a simulated spike display with four tetrodes per screen (6 total) and the opportunity to switch between spiking and continuous modes using the tabs near the bottom of the window. The data are once again a simulated sine wave, so the spike windows show the part of the sine wave above threshold.  





Running the Program on Two Networked Computers

Now you should test the networking between machines. Run

nspike2 –config nspikeconfig3

on both the master and the slave machine (the names must, of course, match the names you put into nspikeconfig3, and you will need to run it from a directory where you can see spikeconfig3 on both machines e.g. /home/lorenlab/NSpike for us). You should see 8 channels of EEG on the master and simulated spike data on the slave.

Finally, try

nspike2 –config nspikeconfig4

on the master and
 
nspike_rt -config nspikeconfig4 

on the slave. Note that if you want position data you must use nspike_rt instead of nspike and that the nspikeconfig4 file specifies the second computer as an “rtslave” rather than a normal slave.

You should get a position and EEG display on the master and no display on the slave. The slave will be generating position frames 30 times / sec and sending them to the master as well as simulating responses to behavior control (digitial IO messages; look at the Behavior menu on the master).  The current time (in the upper right corner of the display) may wander around a bit; this is due to the simulated nature of the data, and is not a bug.  You should also have access to the Digital IO menu on the Master. 

---

Compiling and Testing the NSpike Code with RT-Linux

First examine the file “spike_defines.h” in the NSpike/include subdirectory. Near the top of the file you will see a line that says

#define NO_RT_DEBUG 
or
//#define NO_RT_DEBUG 

Make sure this line is commented out (e.g. that it is the second version with the '//'), return to the nspike base directory and run the QT Makefile generating utility

qmake

to create the local Makefile.  Now do

makeallclean; makeall

Go to the NSpike/KernalMod-2.4 directory on the RT-Linux machine.  From here, go into each subdirectory (Spike_BT878_Module/  and Spike_Clock_Module/) and type

make

to compile the two RT-linux modules: spike_clock_module.o and spike_bt878_module.o. Then become root and run the following script to insert the modules:

./loadall

You may get a few warnings about a tainted kernel, which you can ignore, but you should not get any other error messages. Take a look at the end of /var/log/messages to make sure that nothing went wrong. (less /var/log/messages). 

We suggest putting the contents of the loadall script (with the addition of absolute paths) into /etc/rc.d/rc.local on the RT-Linux machine so that the NSpike real time modules are loaded automatically at boot time.

Hook up a camera to the RCA input on the back of the frame grabber card and run

nspike  -config nspikeconfig5

on the master and

nspike_rt –config nspikeconfig5

on the RT-Linux machine.  Note that nspikeconfig5 has a line that says

dspclock 0

Indicating that it should not use the external DSP clock. Be very careful with this setting, as it is only appropriate when you are not recording any electrophysiological data.
 
You should see the video from the camera in the upper left hand corner of the master window. You should also be able to trigger digital ouputs using the Digital IO menu on the master.

---

Collecting Data with the NSpike Hardware and Software



Setting up Your Configuration File

As discussed above, the configuration files set most of the parameters associated with data collection.  The remaining parameters (e.g. the number of points to collect when a threshold crossing is detected) are defined in the spike_defines.h file in the include subdirectory.  If you want to change those parameters, substantial recoding of a number of files will be required. 

An example of an actual configuration file for a microdrive with 8 tetrodes (6 spike tetrodes, one eeg tetrode, and one reference tetrode) is in the franklab8tetconfig file.  This configuration file sets the master (snow) to display 7 channels of EEG data (one channel from each tetrode with the exception of the reference), position data from the frame-grabber on the rtslave (graupel) and behavioral data (digital I/O) from the UEI card on graupel.  Hail, the non-rt slave, processes spike data from the 6 spike tetrodes (24 channels of data total).  Here we go through the most complex parts of the configuration file, the mapping from the tetrodes on the animal to the dsp channels and the specification of channels for each machine.

To understand the mapping it is important to know that each channel of input on the front end Amplifier box corresponds to 1 of 127 channels on the fiber optic bus.  These channels (refered to as DSP channels) are numbered 0 to 126, and each Aux DSP has access to all of these channels and can filter and send out up data from and arbitrary set of up to 16 of these channels at 30 KHz per channel (the fixed sampling rate of the A/D box).  The "electmap" lines in the configuration file define the relationship between individual input channels and DSP channels.  This mapping is given in the DSP Channel Mapping section below.



DSP Channel Mapping

Looking down into the inputs to the preamplifies, the dsp channels for each pin on each Mill-max connector are as follows:


Notes:

The above mappings can also be applied to the connectors on the top of the microdrive array, omitting the +V pin which only goes into the preamplifier.

The Group Number corresponds to the number of the row of connectors (Mill-max and SMA or a single DB-37) on the front of the Amplifier box.

The J1-8 designations refer to the SMA connectors on the front panel of the Amplifier box.

DSP Channel 127 is the block count, which counts the high work of the current sample number (16 bit).  This channel is used by the DSPs to remain synchronized and is not used for neural data.  


Alternatively, from the front of the Amplifier box, the Mill-max pin numbers and their associated DSP channls are as follows: