beifen / neurorighter

Automatically exported from code.google.com/p/neurorighter
0 stars 0 forks source link

SALPA not properly blanking stim artifacts when using 15 kHz sampling rate #65

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Do an open-loop stim protocol, using SALPA and a 15 kHz sampling rate (or at 
least some value not equal to 25 kHz)

What is the expected output? What do you see instead?
Expect to see stim artifacts blanked.  Blanking does not occur properly.  
Please see attached figure.

What version of the product are you using? On what operating system?
v 1.0.2.521 , winXP SP3, 32-bit

Please provide any additional information below.
Attached a figure to help illustrate what I am seeing for raw traces and the 
(improperly) blanked SALPA traces immediately after a stimulus. Figure shows 
raw data and same data segment from .salpa file.

Original issue reported on code.google.com by jonathan...@gmail.com on 7 Nov 2012 at 8:22

Attachments:

GoogleCodeExporter commented 9 years ago
I note that in the original SALPA paper, all data was presented for fs = 25 kHz 
and we just copied the parameters from that paper. Doug Bakkum noted to me, 
anecdotally, that it was easy to break SALPA with different sampling rates. 

Riley, you have the most insight here. What do you think the issue is? It seems 
like SALPA thinks it has a decent fit very prematurely.

Original comment by jonathan...@gmail.com on 8 Nov 2012 at 3:47

GoogleCodeExporter commented 9 years ago
Righto- I'll take a look at this Thursday.

Original comment by RZellerT...@gmail.com on 13 Nov 2012 at 2:32

GoogleCodeExporter commented 9 years ago
Riley, what is the status here?

Original comment by jonathan...@gmail.com on 10 Dec 2012 at 3:35

GoogleCodeExporter commented 9 years ago
still need to look into this on the rig, however:
biggest issue is that the artifact isn't being detected, either through 
thresholding or through the 'stim' stream.  Whether or not SALPA is fitting 
prematurely will be seen after we get blanking working again.  

Were their areas of the SALPA trace that were blanked, just not where the 
stimuli occurred?

Were stimuli recorded at all during this experiment?

Note that several of the SALPA parameters are based on samples, so changing 
sampling rate would very quickly alter their meaning.  It would probably be a 
good idea to switch to 'ms' as a measure for the curve length, blanking period, 
etc.  

Original comment by RZellerT...@gmail.com on 10 Dec 2012 at 7:59

GoogleCodeExporter commented 9 years ago
No. (I've previously verified that the stimulation times stay synced to the
expected delivery times to within about 20 us over an hour, so I've stopped
worrying about them).

Yes- agree.  I typically use a 15 kHz sampling rate, instead of 25 kHz, and
have always adjusted the default parameters appropriately.

Original comment by jonathan...@gmail.com on 10 Dec 2012 at 9:02

GoogleCodeExporter commented 9 years ago
Using the SALPA parameters you describe (45 sample half width, 0 post-peg, 6 
minimum peg, 3 pre peg, 6 min symmetric, right?), SALPA was able to run 
correctly on one of our rigs (AD rig).  
However, SALPA behaved as you described in your figure if electrical 
stimulation input was turned off.  Note that this only occurred if I disabled 
the 'Stimulation Timing' input in the 'Aux. Input' page of the Hardware 
Settings.  The Electrical Stim 'real time data stream' does not need to be 
activated (on the 'real time' page of Hardware Settings), and the Electrical 
Stim data data stream does not need to be recorded (in the Recording Stream 
Setup dialog).
SALPA gets a signal from the electrical stim recording set up, which it uses as 
way to determine when to blank the signal, IE when the signal is too distorted 
by stimulation artifact to recover. When the electrical stim input is not 
turned on, SALPA doesn't get that signal and just performs it's usual curve 
fitting.
Given that you aren't recording electrical stimulation, that seems like a 
probably culprit.  
Thanks a bunch and I'm sorry about the extreme delay on this.

Original comment by RZellerT...@gmail.com on 19 Dec 2012 at 11:06