Division of Computing Science and Mathematics University of Stirling

Noisy Spike Generator

This page describes a biophysically justifiable noisy spike generator, written in MATLAB (note: it needs the Statistics Toolbox, and the Communications Toolbox (but see note 1 below)). Essentially, the functions here are used to generate the sort of data that might be expected to be provided by a single electrode in a multi-electrode array (MEA), used to record spiking neural cells, probably in vitro. As part of an EPSRC funded project (Talking with Nerve Cells), we were trying to detect spikes (and later classify (or sort) them) in noisy data from extracellular MEAs. This set of routines allows generation of data for which the actual spike train times ("ground truth") are known. It also allows generation of realistic background noise.

On this page we provide

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)

After using this software a little, and talking to others using this software, there are number of upgrades that I'd really like to do.
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).
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.
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 ...

Back to Professor Smith's home page.

Last updated: Monday, 24-Jul-2017 10:08:15 BST

If you have any difficulties accessing this page, or you have any queries/suggestions arising from this page, please email:
Prof Leslie S Smith (lss(nospam_please)@cs.stir.ac.uk)

computing logos