can we save normalizer values from cursortask?

[dthomp]

Hello,

Is it possible to save the parameters (gain and offset) of the normalizer every time it changes/every run? What would be a suggested way to do this, or would you consider saving them as a state variable in the standard distribution?

Thanks,

Dave

[gschalk]

Dave,

After each run, the normalizer values are being updated. When you then press Set Config and Resume, they are being stored in the data file of that new run.

Gerv

[dthomp]

But the normalizer does update during the run, correct? (between trials?). If I run twenty trials, does it just save the final value?

Thank you

[gschalk]

Dave,

Please see the documentation on the Normalizer on the Wiki.

In default configuration, it updates the values at the end of each trial. The final values at the end of each run, which will be the beginning values of the next run, are stored in the data file.

Gerv

[janeh]

I know that the normalizer values are saved at the beginning of each run. However, my understanding is that they may change multiple times within a run based (I think) on the value of the UpdateTrigger parameter on the Filtering Tab for CursorTask. For example, they may change after each trial, so if there are 22 trials in a run, that would be 22 changes that appear to be unsaved. Or they could change continuously (not sure how many changes per run that could be). From a scientific point of view, we are curious to see what the variance of the normalizer values are and would therefore like to inspect the values each time they change.

Are the values saved each time they are updated, or only at the end of a run (which may encompass multiple changes)?

Or am I confused and they only change once per run regardless of the UpdateTrigger parameter?

[gschalk]

Hi,

You are correct. The normalizer values are updated based on UpdateTrigger. This is typically after the end of each trial, but could be (if set for continuous updating) after every sample block (e.g., 50 ms depending on SampleBlockSize and SamplingRate).

In case you are interested in inspecting the gain/offset more often than once per run, you have one of two choices.
1) Stick the values into state variables. This will require very minor changes to the Normalizer code. The advantage is that you know what the values were in real time. The disadvantage is that this won't help you in trying to find out whether you should be using a different method (e.g., different time constants for the adaptation).

2) Analyze data offline. The behavior of the Normalizer is clearly defined based on the documentation and its parameterization. You could analyze the data offline to determine whether a different method to determine these parameters could work better. Actually, there is a McFarland/Wolpaw paper from the late 90's (I think) that did compare different methods. To my understanding, the current default parameterization of the Normalizer is based on the best method found back then.

Gerv

[dthomp]

I believe we'll try option 1 for now. Should I just make the change in our version, or would this be something that will cause us problems with updates in the future?

[gschalk]

Dave,

Based on our current plans, we do not anticipate updating the normalizer code any time soon. However, when you make a change to BCI2000, and then update to the most recent version, you will have to retrofit the most recent version with your changes, or 2) leave your version of the signal processing module as is.

Gerv