From: Rob Sacks (editor_at_realization.org)
Date: 2002-01-22 12:25:49
Hi Jim,
Thanks very much for the long explanation. Sounds like
you've done something quite wonderful. I don't
understand all of it but I'm very glad to read it. I'm quite
interested because I know very little about DSP
and would like to learn more. I've played a bit with
digital filters (changing coefficients and watching
the shape of the response curve shift with filter-
design software), and I used FFT in ElectricGuru,
and that about sums up my DSP experience.
> Well, I wanted something that had evenly spaced bins in log-frequency
> space, i.e. an equal number of bins per octave. I'm using 6 at the
> moment, and 10 octaves. Also, I don't want too much overlap between
> bins.
That's very interesting. It would not have occurred to
me simply because I'm so accustomed to hearing
of EEG results measured in constant units all the way
up and down the spectrum. I wonder how this matches
the needs of our future users.
Users will expect and need to define (at run time) a
number of bands that they want to boost, reduce, or
phase-shift. They will want to be able to define the width of
these bands arbitrarily and nudge the whole
bands up and down.
And they will want to nudge these parameters up
and down dynamically, on the fly, while wearing
the electrodes and actually doing neurofeedback
(in other words, they will want to change the
parameters without interrupting the session).
For instance, very typically, a user might say to the
program, "help me boost my magnitude in the range
14.2- 16.4Hz," and then, after trying it for a while,
nudge that whole band up a half hertz and try again.
(Maybe the decimal points aren't so typical but I
include them to make the point that we might want to
permit fairly fine resolution.)
So the two relevant user parameters are: (1) the
minimum increment of a change in bandwidth and
(2) the minimum increment of a change in frequency.
> This is all coded in integer maths, and I've tested the filter code
> with impulses of various magnitudes to check the response, and it
> looks good so far. Input is 16-bit data, which should be good enough
> for our purposes, I hope.
Good enough? Maybe, I don't know, but why
not take advantage of the additional accuracy provided
by floating point?
Is this intended for a computer CPU? On a fairly recent
computer (four, five years old?) I think this amount of math
can easily be done in floating point. Didn't math-intensive
PC programs like 3D games give up integer math several
years ago?
ElectricGuru uses floating point math, and when I
profile its execution on a 200 MHz Pentium, the
percentage of CPU time used for the math is so tiny
that it almost makes me laugh.
(I began programming in 1983 on 8088 machines, back
when arithmetic was so slow that integer divisions and
multiplications had to be avoided, so this enormous
increase in mathematical power is really quite striking to
me.) (Incidentally, the operation in EG that takes the most
time, in actual profiling, is sending graphics instructions
to the video card with DirectX. Not doing the drawing,
mind you... simply sending the instructions with a small
number of function calls, without waiting for the functions
to return. This is obviously a very fast thing to do, and the
fact that it's the most time intensive part of the program,
suggests how incredibly fast a four year old computer is.)
I think you said you wrote this in C? Perhaps you
could typedef the data type so programmers can
change it at compile time?
> They're based on IIR filters, so in theory the `epoch length' is
> infinite (if I understand your terminology). In practice it is of
> course finite, as can be seen by putting an impulse through the filter
> (it goes to 0 eventually). The length for lower frequency bins is
> much much longer, as you would expect.
I see. I was having a stupid moment when I asked
that question... I forgot that IIR filters have elephant memories.
What I really wanted to know is this. (I'll try to ask
this time without technical terms so I don't say
something silly again.)
Suppose the signal suddenly changes so a new frequency is
present. How much time passes before the filter bank tells
us that the frequency is present? Can we measure this time
in cycles? Is this time the same for all frequencies (when
measured in cycles)?
What is the correct term for this delay that I'm asking about?
This subject is constantly mentioned in advertising for
neurofeedback systems... manufacturers brag about their
"fast filters."
By the way, however, from my own experience wearing
electrodes, it seems to me to be a completely irrelevant
factor, because I've found that results have to be integrated
over at least a second in order to be useful for training. If
you provide a reward signal that jiggles on and off
too quickly, it's hard to train with it.
I've discussed this with some experienced clinicians, and
they tell me the same thing. Given the advertising, I'm
quite mystified by this subject.
I had to put a user feature into ElectricGuru to average FFT results
over an even longer time than the FFT epoch to make the signal
stable enough for training. Waveware has a similar feature.
If I recall correctly, a fairly famous early neurofeedback
researcher once told me in an e-mail that his system only
plays a reward signal if some percentage of the most
recent FFT results show a result on the desired side of
the threshold... another method of "averaging" over time.
(Regardless of any of this, certainly, let's use the fastest
filters we can.)
> Once I get this graphical displayer working, I will be able to check
> that the phases are all working properly. It would be nice to tune
> the bin-widths so that a tone half-way between two bins gives the same
> total magnitude (more or less) as one centred on a bin. I'll have to
> wait and see how this goes. This is not 100% necessary for the whole
> thing to work, though.
Does this mean we can extract information for any
arbitrary frequency band by interpolating the results?
Thanks again for explaining at such length.
Best regards,
Rob
----- Original Message -----
From: "Jim Peters" <jim_at_uazu.net>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Monday, January 21, 2002 6:16 PM
Subject: Re: [buildcheapeeg] Filter bank
> Rob Sacks wrote:
> > Great, congrats. I wonder if you could explain a bit
> > more about the output of your filter bank? What is
> > the advantage over an FFT? I know of course that
> > the response is faster, but I wonder if you could go
> > into a little more detail.
>
> Well, I wanted something that had evenly spaced bins in log-frequency
> space, i.e. an equal number of bins per octave. I'm using 6 at the
> moment, and 10 octaves. Also, I don't want too much overlap between
> bins.> ...
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:36 BST