Noisy Spike Generator

On this page we provide

• a .zip file of the MATLAB m-files for version 1.2 (last updated 24 July 2017, a minor update from the 1.1 released 29 Feb 2012 (minor bug fix)). Release 1.2 fixes an issue of failure when there were directories with particular names in the same directory as the files (issue with the use iof exist()).
• a user manual (pdf format) for version 1.1 (last updated 16 June 2006)
• a draft paper which contains the analysis etc., as well as an example (published in J. Neurosci. Methods, 159 (2007), 170-180)
• a Mac OSX Application for generating part of the materials for the noisy spike generator. Note that this provides a (reasonably nice) GUI for one part of the system: it is, however, not necessary to use it (you don't need Mac OSX to run the MATLAB software, and there is a MATLAB function included which has the same functionality).
• an abstract and the poster from CNS2006, which give a good introduction to the software.

This version has a lot more functionality than earlier versions: in particular, it allows emulation of the delay in generation of spikes over the neuron's spiking surface, so that the spike shape received can depend on the relative location of the electrode and the neuron's spiking surface. It also runs a lot faster (and has fewer (or possibly only different) bugs). We would appreciate any comments and reports of bugs in this software. There's also some .m files for use in assessing different spike sorting techniques.

We believe it to work.

We are always interested in feedback on these routines. Email lss at cs.stir.ac.uk.

Note 1: The use of the communications toolbox is restricted to the use of the awgn function, which I use to add some white noise at the end of the data generation. If you can do without that function, simply comment out the line that uses it (line 539 of generatenoisysamples.m), and the software will, I believe, work without the communications tollbox.

Note 2 (added 25 March 2009): The generator generates a waveform made up from spikes, some of which are the target spikes, some noisy spikes whose times are correlated with the target spikes, and some other noisy spikes whose times are not correlated with the target spikes. In the code as made available here, the noisy correlated spikes have their waveform slghtly smoothed relative to that of the target spikes, and the uncorrelated noisy spikes have their waveform further smoothed. We did this because we believed that the signals wouls be somwhat smoothed on their way from neuron to electrode. We now realise that this can give certain types of spike detection algorithms a particular advantage. We intend to introduce a new release in which the degree of this type of smoothing can be adjusted by the user. The relevant code lies between lines 140 and 160 of generatenoisyspikes.m. If you need assistance with this, please contact me.

Note 3 (29 Feb 2012): There's a minor change about lines 77-82, so that the program now expects the directory example6 to be in a subdirectory of where the rest of the software is. In addition, the noise level for the white noise added at the end is now in the varargin setup: so adding
'NoiseSNR', 10
to the command will alter the white noise level to -10dB, for example. Default remains -100dB. As an aside, this means that the command line
[signals1 target1 r1]= generatenoisysamples('Duration',2,'SampleRate',10000, 'N_Jitter', 0, 'N_Uncorr', 0, 'NoiseSNR', 10) ;
will generate a two second long signal, with two targets (default), no jittered or uncorrelated noise and -10dB white noise added.

Note 3 (7 July 2017): Some questions and answers.

Q: How do I determine the number of actual spikes I should expect to detect from a noisy signal simulation or any other information on firing rates?

A: This depends on the parameters used in the calls to the two spike generation functions, genspikespoisson and genspikesgaussian.
Each spike train has either a Gaussian or a Poisson distribution, and which is determined by the number of the spike train (starting, because it's Matlab and not C at 1), using the value spikedist(spike train number). This is either a "G"(Gaussian) or a "P" (Poisson).
The actual values used for the Poisson distribution are set in the code, in the variables poissonnumber, and poissonmeanISI. These are used in the call to genspikespoisson as lambda and mean inter-spike interval.
The actual values for Gaussian distributed spike train are set in the variables gaussmeanITD (I should have called this gaussmeanISI, but I didn't) and gaussstdev. These set the mean inter-spike interval and the standard deviation of this inter-spike interval.
This isn't exactly what's done - we also set the minimum inter-spike interval to default at 1 millisecond (value for refractoryperiod), unless reset in the call by setting "RefractoryPeriod" as a varargin.
Note that genspikespoisson and genspikesgaussian are also used (in a similar manner) in the generation of uncorrelated spike trains. In that code, u_poissionnumber(nu), and u_poissmeanISI(nu) are used in the poisson spike trains, and u_gaussmeanITD(nu), u_gaussstdev(nu) are used in the Gaussian spike trains.

Q: The size of actualpeaks contained in the target structure changes with every simulation, why?

A: There's randomisation (call to poissrnd in genspikesgaussian, and call to randn in genspikesgaussian) so that what's generated will be different each time.

Q: The program crashes at line 365:
[samples target r1]=generatenoisysamples;
Undefined function or variable "targets".
Error in generatenoisysamples (line 365)
if (length(targets) ~= n_targets)

A: I had used calls to exist() with only 1 paramater. This was not a good idea. Fixed in release 1.2. I'm hoping I haven't introduced any new bugs!

What we'd like to do with this software (updated July 2010)

The user interface

The current user interface is, well, nasty. Purely command line, and what is worse, needing the user to get in amongst the code to alter many of the parameters. Yes, I did make some of the aalterable from the command line, but not all. I'm hoping that a student from here will do some work on creating a usable GUI for the project

Non-stationary data

As matters stand, the statistics of the output are constant for the duration of the signal generated. But this is not realistic - these change in real datasets, both due to alterations within the neural tissue (in vivo or in vitro), and perhaps also due to relative movement of the electrode(s) and the tissue. And then one might even incorporate the effect of someartefacts, since these are hardly uncommon in real recordings, and it's useful if the spike detection/sorting system can cope with these.

Bursting neurons

Many neurons generate bursts of output, rather than single spikes. Currently, the genertor can only generate spikes. There's an interesting issue about detecting bursts that is of interest to me - is it best to detect the spikes, and the group them into bursts, or is it better to detect the bursts, and then find the spikes inside them? For detectors that work in the frequency domain, the latter might be better (but I'd lkke to find out).

Tetrodes

Many modern systems for recording consist of polytrodes - a set of electrodes close together: that is, sufficiently close together that the same neuron may be recorded from by more than one electrode. It would be good to make this system able to generate data which could be used for testing spike detectors and sorters for such recording systems.

Dipoles

After listening to Prof. Gaute T. Einevoll at MEA 2010 in Reutlingen I wondered if I should alter the ways in which I compute the signal shapes. I'm not yet entirely convinced ...