You can subscribe to this list here.
2008 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}
(4) 
_{May}
(5) 
_{Jun}
(5) 
_{Jul}
(13) 
_{Aug}
(2) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}

_{Dec}


2009 
_{Jan}
(1) 
_{Feb}
(4) 
_{Mar}
(3) 
_{Apr}
(3) 
_{May}
(3) 
_{Jun}

_{Jul}

_{Aug}
(6) 
_{Sep}
(4) 
_{Oct}
(6) 
_{Nov}
(1) 
_{Dec}
(11) 
2010 
_{Jan}
(3) 
_{Feb}
(5) 
_{Mar}
(9) 
_{Apr}
(8) 
_{May}
(6) 
_{Jun}
(6) 
_{Jul}
(2) 
_{Aug}
(13) 
_{Sep}
(4) 
_{Oct}
(2) 
_{Nov}
(1) 
_{Dec}
(1) 
2011 
_{Jan}
(3) 
_{Feb}
(4) 
_{Mar}
(4) 
_{Apr}
(1) 
_{May}
(3) 
_{Jun}
(10) 
_{Jul}

_{Aug}
(2) 
_{Sep}
(4) 
_{Oct}
(6) 
_{Nov}
(8) 
_{Dec}
(4) 
2012 
_{Jan}
(6) 
_{Feb}

_{Mar}
(1) 
_{Apr}
(6) 
_{May}
(3) 
_{Jun}

_{Jul}
(6) 
_{Aug}
(17) 
_{Sep}
(7) 
_{Oct}
(4) 
_{Nov}
(8) 
_{Dec}
(11) 
2013 
_{Jan}
(8) 
_{Feb}
(4) 
_{Mar}
(7) 
_{Apr}
(1) 
_{May}
(4) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(1) 
_{Sep}
(2) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2014 
_{Jan}
(5) 
_{Feb}
(2) 
_{Mar}
(10) 
_{Apr}
(1) 
_{May}
(1) 
_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(10) 
_{Dec}
(3) 
2015 
_{Jan}
(12) 
_{Feb}

_{Mar}
(5) 
_{Apr}
(2) 
_{May}

_{Jun}
(2) 
_{Jul}

_{Aug}
(2) 
_{Sep}
(3) 
_{Oct}
(3) 
_{Nov}
(10) 
_{Dec}
(6) 
2016 
_{Jan}
(2) 
_{Feb}
(2) 
_{Mar}
(4) 
_{Apr}
(1) 
_{May}
(2) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(1) 
2017 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}
(2) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3

4

5

6

7

8

9

10

11

12

13

14
(1) 
15
(1) 
16
(4) 
17
(2) 
18
(1) 
19

20

21

22

23

24

25

26

27
(2) 
28
(1) 
29
(3) 
30
(1) 
31
(1) 

From: Meerwijk, Esther <Esther.Meerwijk@uc...>  20120831 17:35:39

On Aug 29, 2012, at 12:12 AM, Alois Schloegl wrote: > I suspect that, perhaps using the geometric mean (lines 222224, Footnote 6 Brentson et al. 1997) instead of the arithmetic mean > would improve the analysis. Of course, the Berger resampling (lines 230235) might also help. In my data (5 minute resting state), the difference between the two is small (< 1%). I would not expect that to result in significant differences in HRV. The conversion in the Biosig HRV function works with 1/mean(RRI), which I think is correct. Doing the conversion with mean(1/RRI) would give a biased estimate of the average heart rate, as is illustrated in that footnote. Esther 
From: Alois Schloegl <alois.schloegl@is...>  20120830 07:56:41

On 08/29/12 23:33, Meerwijk, Esther wrote: > > On Aug 29, 2012, at 12:12 AM, Alois Schloegl wrote: > >> On 08/29/12 02:45, Meerwijk, Esther wrote: >>> Hi >>> >>> I'm using the heartratevariability function within Biosig 2.61. >>> I noticed that the array of frequencies that is used in the >>> process of assigning power to frequency bins compensates for the >>> average heart beat interval (line 224, 228, 234), probably as an >>> approximation to get cycles/second rather than cycles/beat. >> >> >> Hi Esther, >> >> >> to avoid any ambiguity, you are talking about the lines in this >> segment, right ? >> >> 221 if 0, 222 y = log(NN); 223 [y,m]=center(y); >> 224 f0= exp(m)/t_scale; 225 elseif 1, 226 y = >> NN; 227 [y,m] = center(y); 228 f0= >> 1/(m*t_scale); 229 else 230 %% factor 1000 because [ms], >> berger expects [s] 231 OS = 4; 232 f0 = >> OS*1000/(X.meanNN);%% fourtimes oversampling 233 [hrv,y] >> = berger(on/1000,f0); % resampleing 234 [y,m] = >> center(y*1000); %%% use RRI spectral estimates 235 %% >> [y,m] = center(hrv); %%% use HRV spectral estimates 236 >> end; >> >> >> Within this array, there is no "array of frequencies", f0 is a >> scalar and represents the (average) sampling rate in Hertz. f0 is >> basically used for scaling of the xaxis when plotting the spectral >> density function. This does not weight each interval individually. > > You are right, I wasn't clear enough about that. Yes, these lines > contain the conversion in question. For the FFT option, f0 is then > passed on to periodogram which returns an array with frequencies f. > Without the conversion this would run upto 0.5. With the conversion, > I have cases (people with slow heart beat of about 47 bpm) where it > stops at about 0.4. Consequently, the same power is distributed over > a shorter range, which affects the HRV spectral components. Now, if > this conversion is the right thing to do, mathematically speaking, > we're good. But the publications I mentioned seem to suggest > otherwise. I didn't check for the AR option, but judging by the > spectral density plot, it's doing the same thing. Yes, the range on the spectral axis is for both methods (AR and FFT) from 0 to fs/2, and the sampling rate (fs) is determined by the average(RRI). The idea of using Hertz instead of 1/beats scale on the xaxis is related to the idea that LF and HF components can be related to sympathetic and parasympathetic activity. Assuming that the physiological mechanism have a fixed time scale, it makes sense to associate these with fixed frequency bands. The phrase that "the translation ... is not precise ..." is perhaps easy to misread, but the imprecision is not caused "by multiplying by the mean heart period". Instead "[the] translation is not precise ... because beats differ in duration ..." and violate the assumption of equidistant sampling. The approach of Berger et al. is an attempt to fix this problem. >> >> While the article by >>> Berger (1986), which is cited in the function, mentions this >>> conversion, I do not think they actually use it. Moreover, they >>> seem to say it changes the spectrum in ways that are unwanted. A >>> well known committee publication by Berntson et al (1997) 'Heart >>> rate variability: Origins, methods, and interpretive caveats' >>> Psychophysiology (34), also mentions the conversion (page 633), >>> and warns that it 'is not precise and becomes less accurate as >>> heart period varies'. >>> >>> In my own data, I noticed that this conversion can cause a >>> significant shift of power from the HF to LF component, which >>> would greatly affect interpretation. >> >> >> I suspect that, perhaps using the geometric mean (lines 222224, >> Footnote 6 Brentson et al. 1997) instead of the arithmetic mean >> would improve the analysis. Of course, the Berger resampling (lines >> 230235) might also help. >> >> >> Is there scientific evidence that this >>> conversion should actually be used? >>> >> >> >> As far as I see it, there is no consensus on the "correct" way of >> doing HRV analysis. For example in case if children, or high >> frequency conditions (e.g. 180 beats/min) a Berger resampling with >> 4 Hz does not work due to spectral aliasing (Nyquist frequency is 2 >> Hz). Berger adds also some high "frequency noise" due to the >> rectangular shape of the resulting data series. >> >> Personally I prefer doing the spectrum on the logscaled RRI >> series; it overcomes a number of issues including (1) spectrum of >> RRI and 1./RRI is the same, (2) the sampling rate is the geometric, >> not arithmethic mean. >> >> From software engineering point of view: The code contains all >> three options, and you can use them by changing the conditions in >> the code (lines 221, 225 and 229). Probably, the user should be >> able to select the different options through the function >> interface. What's your suggestion about this ? > > It is wonderful to have all the options available. What worries me > most is compatibility with studies that use different implementations > to determine HRV spectral components.I did a quick check against the > HRV toolkit available from physionet, which is supposed to be well > validated. Biosig's heartratevariability function produced similar > LF/HF ratios as Physionet's HRV toolkit, so appears to use the same > conversion I asked about. That at least gives it some validation. > I guess that is the most widely accepted solution, but whether this is the best way of analyzing HRV data is subject to debate. Anyway, its good to know that Biosig's heartratevariability function is validated by you, too. >> >> >>> thanks, Esther >>> >> >> >> You are welcome, Alois >> 
From: Meerwijk, Esther <Esther.Meerwijk@uc...>  20120829 21:32:40

On Aug 29, 2012, at 12:12 AM, Alois Schloegl wrote: > On 08/29/12 02:45, Meerwijk, Esther wrote: >> Hi >> >> I'm using the heartratevariability function within Biosig 2.61. I >> noticed that the array of frequencies that is used in the process of >> assigning power to frequency bins compensates for the average heart >> beat interval (line 224, 228, 234), probably as an approximation to >> get cycles/second rather than cycles/beat. > > > Hi Esther, > > > to avoid any ambiguity, you are talking about the lines in this segment, right ? > > 221 if 0, > 222 y = log(NN); > 223 [y,m]=center(y); > 224 f0= exp(m)/t_scale; > 225 elseif 1, > 226 y = NN; > 227 [y,m] = center(y); > 228 f0= 1/(m*t_scale); > 229 else > 230 %% factor 1000 because [ms], berger expects [s] > 231 OS = 4; > 232 f0 = OS*1000/(X.meanNN);%% fourtimes oversampling > 233 [hrv,y] = berger(on/1000,f0); % resampleing > 234 [y,m] = center(y*1000); %%% use RRI spectral estimates > 235 %% [y,m] = center(hrv); %%% use HRV spectral estimates > 236 end; > > > Within this array, there is no "array of frequencies", f0 is a scalar and represents the (average) sampling rate in Hertz. f0 is basically used for scaling of the xaxis when plotting the spectral density function. This does not weight each interval individually. You are right, I wasn't clear enough about that. Yes, these lines contain the conversion in question. For the FFT option, f0 is then passed on to periodogram which returns an array with frequencies f. Without the conversion this would run upto 0.5. With the conversion, I have cases (people with slow heart beat of about 47 bpm) where it stops at about 0.4. Consequently, the same power is distributed over a shorter range, which affects the HRV spectral components. Now, if this conversion is the right thing to do, mathematically speaking, we're good. But the publications I mentioned seem to suggest otherwise. I didn't check for the AR option, but judging by the spectral density plot, it's doing the same thing. > > While the article by >> Berger (1986), which is cited in the function, mentions this >> conversion, I do not think they actually use it. Moreover, they seem >> to say it changes the spectrum in ways that are unwanted. A well >> known committee publication by Berntson et al (1997) 'Heart rate >> variability: Origins, methods, and interpretive caveats' >> Psychophysiology (34), also mentions the conversion (page 633), and >> warns that it 'is not precise and becomes less accurate as heart >> period varies'. >> >> In my own data, I noticed that this conversion can cause a >> significant shift of power from the HF to LF component, which would >> greatly affect interpretation. > > > I suspect that, perhaps using the geometric mean (lines 222224, Footnote 6 Brentson et al. 1997) instead of the arithmetic mean > would improve the analysis. Of course, the Berger resampling (lines 230235) might also help. > > > Is there scientific evidence that this >> conversion should actually be used? >> > > > As far as I see it, there is no consensus on the "correct" way of doing HRV analysis. For example in case if children, or high frequency conditions (e.g. 180 beats/min) a Berger resampling with 4 Hz does not work due to spectral aliasing (Nyquist frequency is 2 Hz). > Berger adds also some high "frequency noise" due to the rectangular shape of the resulting data series. > > Personally I prefer doing the spectrum on the logscaled RRI series; it overcomes a number of issues including (1) spectrum of RRI and 1./RRI is the same, (2) the sampling rate is the geometric, not arithmethic mean. > > From software engineering point of view: The code contains all three options, and you can use them by changing the conditions in the code (lines 221, 225 and 229). Probably, the user should be able to select the different options through the function interface. What's your suggestion about this ? It is wonderful to have all the options available. What worries me most is compatibility with studies that use different implementations to determine HRV spectral components. I did a quick check against the HRV toolkit available from physionet, which is supposed to be well validated. Biosig's heartratevariability function produced similar LF/HF ratios as Physionet's HRV toolkit, so appears to use the same conversion I asked about. That at least gives it some validation. > > >> thanks, Esther >> > > > You are welcome, > Alois > 
From: Alois Schloegl <alois.schloegl@is...>  20120829 07:12:59

On 08/29/12 02:45, Meerwijk, Esther wrote: > Hi > > I'm using the heartratevariability function within Biosig 2.61. I > noticed that the array of frequencies that is used in the process of > assigning power to frequency bins compensates for the average heart > beat interval (line 224, 228, 234), probably as an approximation to > get cycles/second rather than cycles/beat. Hi Esther, to avoid any ambiguity, you are talking about the lines in this segment, right ? 221 if 0, 222 y = log(NN); 223 [y,m]=center(y); 224 f0= exp(m)/t_scale; 225 elseif 1, 226 y = NN; 227 [y,m] = center(y); 228 f0= 1/(m*t_scale); 229 else 230 %% factor 1000 because [ms], berger expects [s] 231 OS = 4; 232 f0 = OS*1000/(X.meanNN);%% fourtimes oversampling 233 [hrv,y] = berger(on/1000,f0); % resampleing 234 [y,m] = center(y*1000); %%% use RRI spectral estimates 235 %% [y,m] = center(hrv); %%% use HRV spectral estimates 236 end; Within this array, there is no "array of frequencies", f0 is a scalar and represents the (average) sampling rate in Hertz. f0 is basically used for scaling of the xaxis when plotting the spectral density function. This does not weight each interval individually. While the article by > Berger (1986), which is cited in the function, mentions this > conversion, I do not think they actually use it. Moreover, they seem > to say it changes the spectrum in ways that are unwanted. A well > known committee publication by Berntson et al (1997) 'Heart rate > variability: Origins, methods, and interpretive caveats' > Psychophysiology (34), also mentions the conversion (page 633), and > warns that it 'is not precise and becomes less accurate as heart > period varies'. > > In my own data, I noticed that this conversion can cause a > significant shift of power from the HF to LF component, which would > greatly affect interpretation. I suspect that, perhaps using the geometric mean (lines 222224, Footnote 6 Brentson et al. 1997) instead of the arithmetic mean would improve the analysis. Of course, the Berger resampling (lines 230235) might also help. Is there scientific evidence that this > conversion should actually be used? > As far as I see it, there is no consensus on the "correct" way of doing HRV analysis. For example in case if children, or high frequency conditions (e.g. 180 beats/min) a Berger resampling with 4 Hz does not work due to spectral aliasing (Nyquist frequency is 2 Hz). Berger adds also some high "frequency noise" due to the rectangular shape of the resulting data series. Personally I prefer doing the spectrum on the logscaled RRI series; it overcomes a number of issues including (1) spectrum of RRI and 1./RRI is the same, (2) the sampling rate is the geometric, not arithmethic mean. From software engineering point of view: The code contains all three options, and you can use them by changing the conditions in the code (lines 221, 225 and 229). Probably, the user should be able to select the different options through the function interface. What's your suggestion about this ? > thanks, Esther > You are welcome, Alois 
From: Meerwijk, Esther <Esther.Meerwijk@uc...>  20120829 00:44:27

Hi I'm using the heartratevariability function within Biosig 2.61. I noticed that the array of frequencies that is used in the process of assigning power to frequency bins compensates for the average heart beat interval (line 224, 228, 234), probably as an approximation to get cycles/second rather than cycles/beat. While the article by Berger (1986), which is cited in the function, mentions this conversion, I do not think they actually use it. Moreover, they seem to say it changes the spectrum in ways that are unwanted. A well known committee publication by Berntson et al (1997) 'Heart rate variability: Origins, methods, and interpretive caveats' Psychophysiology (34), also mentions the conversion (page 633), and warns that it 'is not precise and becomes less accurate as heart period varies'. In my own data, I noticed that this conversion can cause a significant shift of power from the HF to LF component, which would greatly affect interpretation. Is there scientific evidence that this conversion should actually be used? thanks, Esther 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120828 13:11:45

Dear Alois, I am so grateful for your extensive answer to my question. Thank you very much. Bethel. ________________________________________ From: Bethel Osuagwu Sent: 27 August 2012 11:36 To: Alois Schloegl Cc: biosiggeneral@... Subject: RE: [Biosiggeneral] The Time domain parameters Dear Alois, Thank you very much for your help. I have modified the Biosig function tdp() in order to have it give the same result with simulink inplementation. I noticed that I could not work with NaN in Simulink and therfore all my first order difference blocks have initial values of zeroes instead of NaNs as it is in the tdp() function. So I made the following changes in the tdp() function: 1: After using the diff() function, add a leading row of zeroes instaed of a leading row of NaN. ie this line: d = diff([repmat(NaN,[1,K]);d],[],1); was changed to d = diff([repmat(0,[1,K]);d],[],1); 2: The line F = log(filter(B,A,d.^2)./filter(B,A,double(~isnan(d0)))); and the kind was changed to F = log(filter(B,A,d.^2)); With these changes in place, I could test that the tdp() function and its simulink inplementation outputs the same values. My question here is, is there any thing fundamentaly wrong with what I have done? If it is wrong, I would like to go back and replace those changes and find another way to make the simulink implementation give the same values as the original tdp(). By the way in one of your papers, you showed that tdp performed better than bandpower, also in our preliminary experiment, tdp also performed better in an offline classification using Biosig. My question is, is there any known reason why we cannot implement a good online BCI using tdp? I am actully asking because I am just wondering why bandpower is still more popular than tdp. Thank you. Bethel ________________________________________ From: Alois Schloegl [alois.schloegl@...] Sent: 17 August 2012 23:18 To: Bethel Osuagwu Cc: biosiggeneral@... Subject: Re: [Biosiggeneral] The Time domain parameters On 20120816 18:59, Bethel Osuagwu wrote: > Dear Alois, > > Thank you very much for your reply. I will try to implement what you > described. But what I am having problem with is the line in tdp() > thus: > > filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; > //for example B = UC; A = [1, UC1]; and d=d0 is the pth > derivative > > The line with the filter is the line confusing me due to the division > because I do not know much about filters for now. But from your > description, the line is low pass filtering. So will I achieve what > this line is doing if I implement a simulink filter using only 'A' > and 'B' (i.e doing only filter(B,A,d.^2)) That should to it, except when your data contains missing values encoded as NaN's. or do I need to divide by an > output of another filter as in ./filter(B,A,double(~isnan(d0))) > ? This part is only needed when your data can contain missing values encoded as NaN's. In that case, then NaN's in d need to be replaced by 0 and the denominated need to account for the fact, that some samples have been ignored. Alois > > Thank you again for you time Bethel > > ________________________________________ From: Alois Schloegl > [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel > Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The Time > domain parameters > > Dear Bethel, > > > the rtsBCI simulink implements currently only the time domain > parameters of Hjorth and Barlow. Implementing tdp.m in simulink is > quite simple. you just need to connect 1st order difference blocks in > a sequential manner (output of pth difference block is the input of > the next differential block). Then connect the output of each block, > take the square, do a lowpass filter, and take the logarithm. > > I'll forward your request also Reinhold, the maintainer of rtsBCI. > > > I hope this helps, Alois > > > > > > > On 08/14/12 17:12, Bethel Osuagwu wrote: >> Dear Sir, >> >> I just realized that there's no simulink block in rtsBCI for >> calculating the Time Domain Parameter(TDP) Features implemented in >> Biosig. This TDP were used in 'demo2.m' of Biosig for >> demonstration. I tried reading the tdp() function so that I can >> implement the simulink block but I could not understand some part >> of the function when it takes multiple derivatives. Any help for >> implementing this TDP as a simulink block will be most >> appreciated. >> >> Thanks Bethel. >>  >> >> > >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and >> the latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ Biosiggeneral >> mailing list Biosiggeneral@... >> https://lists.sourceforge.net/lists/listinfo/biosiggeneral > 
From: Alois Schloegl <alois.schloegl@is...>  20120827 14:05:48

On 08/27/12 12:36, Bethel Osuagwu wrote: > Dear Alois, > > Thank you very much for your help. > > I have modified the Biosig function tdp() in order to have it give > the same result with simulink inplementation. I noticed that I could > not work with NaN in Simulink and therfore all my first order > difference blocks have initial values of zeroes instead of NaNs as > it is in the tdp() function. So I made the following changes in the > tdp() function: 1: After using the diff() function, add a leading > row of zeroes instaed of a leading row of NaN. ie this line: d = > diff([repmat(NaN,[1,K]);d],[],1); was changed to d = > diff([repmat(0,[1,K]);d],[],1); > > 2: The line F = > log(filter(B,A,d.^2)./filter(B,A,double(~isnan(d0)))); and the kind > was changed to F = log(filter(B,A,d.^2)); > > With these changes in place, I could test that the tdp() function and > its simulink inplementation outputs the same values. My question > here is, is there any thing fundamentaly wrong with what I have done? > If it is wrong, I would like to go back and replace those changes > and find another way to make the simulink implementation give the > same values as the original tdp(). > Dear Bethel, I do not see any thing wrong here. > > By the way in one of your papers, you showed that tdp performed > better than bandpower, also in our preliminary experiment, tdp also > performed better in an offline classification using Biosig. My > question is, is there any known reason why we cannot implement a good > online BCI using tdp? I do not see any reason why this could not be done. Actually, it was developed for online BCI usage. I am actully asking because I am just wondering > why bandpower is still more popular than tdp. I see the following two reasons: 1) Bandpass filtering can have advantages when noneeg noise sources (like 1/f noise caused by amplifier provide large noise in the very low frequency range, or oversampling results in large spectral areas in the upper frequency range) contribute significantly to the total power. Therefore, the low frequency filter should not be too low (0.5 Hz or larger), and the sampling rate should not be to high. This implies also that antialiasing filter is set accordingly. This might explain way TDP or AAR does not perform well in some cases. 2) There is a long tradition in eeg analysis in bandbased spectral analysis. There is certainly some reluctance to replace this concept. The question that arises is are always what is the meaning of a high or low value of tdp(i) ? Spectral parameters have been used to quantify and characterize the EEG in huge number of research questions, and many scholares have associations with the meaning of large or small alpha activity. This is not the case for parameters like TDP or AAR. So part of the explanation is the inertia of eeg community. Of course, most of the past spectral analysis has been done by averaging multiple repeations. This is very different to online analysis were single trial analysis (i.e. without averaging) has to be done. There concept of some fixed frequency band becomes very dubious (see principle of uncertainty between time and frequency analysis). There are also studies that show shifts in the center frequency of some components, these can not be adequately captured by looking at the power of fixed frequency bands. Therefore I see a lot of reasons for going beyond bandpower analysis. Alois > > Thank you. Bethel > > ________________________________________ From: Alois Schloegl > [alois.schloegl@...] Sent: 17 August 2012 23:18 To: Bethel > Osuagwu Cc: biosiggeneral@... Subject: Re: > [Biosiggeneral] The Time domain parameters > > On 20120816 18:59, Bethel Osuagwu wrote: >> Dear Alois, >> >> Thank you very much for your reply. I will try to implement what >> you described. But what I am having problem with is the line in >> tdp() thus: >> >> filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; >> //for example B = UC; A = [1, UC1]; and d=d0 is the pth >> derivative >> >> The line with the filter is the line confusing me due to the >> division because I do not know much about filters for now. But from >> your description, the line is low pass filtering. So will I achieve >> what this line is doing if I implement a simulink filter using only >> 'A' and 'B' (i.e doing only filter(B,A,d.^2)) > > That should to it, except when your data contains missing values > encoded as NaN's. > > or do I need to divide by an >> output of another filter as in ./filter(B,A,double(~isnan(d0))) ? > > This part is only needed when your data can contain missing values > encoded as NaN's. > > In that case, then NaN's in d need to be replaced by 0 and the > denominated need to account for the fact, that some samples have > been ignored. > > Alois > > >> >> Thank you again for you time Bethel >> >> ________________________________________ From: Alois Schloegl >> [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel >> Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The >> Time domain parameters >> >> Dear Bethel, >> >> >> the rtsBCI simulink implements currently only the time domain >> parameters of Hjorth and Barlow. Implementing tdp.m in simulink is >> quite simple. you just need to connect 1st order difference blocks >> in a sequential manner (output of pth difference block is the >> input of the next differential block). Then connect the output of >> each block, take the square, do a lowpass filter, and take the >> logarithm. >> >> I'll forward your request also Reinhold, the maintainer of rtsBCI. >> >> >> I hope this helps, Alois >> >> >> >> >> >> >> On 08/14/12 17:12, Bethel Osuagwu wrote: >>> Dear Sir, >>> >>> I just realized that there's no simulink block in rtsBCI for >>> calculating the Time Domain Parameter(TDP) Features implemented >>> in Biosig. This TDP were used in 'demo2.m' of Biosig for >>> demonstration. I tried reading the tdp() function so that I can >>> implement the simulink block but I could not understand some >>> part of the function when it takes multiple derivatives. Any help >>> for implementing this TDP as a simulink block will be most >>> appreciated. >>> >>> Thanks Bethel. >>>  >>> >>> >> >>> > >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security >>> and threat landscape has changed and how IT managers can >>> respond. Discussions will include endpoint security, mobile >>> security and the latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ Biosiggeneral >>> mailing list Biosiggeneral@... >>> https://lists.sourceforge.net/lists/listinfo/biosiggeneral >> 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120827 10:37:07

Dear Alois, Thank you very much for your help. I have modified the Biosig function tdp() in order to have it give the same result with simulink inplementation. I noticed that I could not work with NaN in Simulink and therfore all my first order difference blocks have initial values of zeroes instead of NaNs as it is in the tdp() function. So I made the following changes in the tdp() function: 1: After using the diff() function, add a leading row of zeroes instaed of a leading row of NaN. ie this line: d = diff([repmat(NaN,[1,K]);d],[],1); was changed to d = diff([repmat(0,[1,K]);d],[],1); 2: The line F = log(filter(B,A,d.^2)./filter(B,A,double(~isnan(d0)))); and the kind was changed to F = log(filter(B,A,d.^2)); With these changes in place, I could test that the tdp() function and its simulink inplementation outputs the same values. My question here is, is there any thing fundamentaly wrong with what I have done? If it is wrong, I would like to go back and replace those changes and find another way to make the simulink implementation give the same values as the original tdp(). By the way in one of your papers, you showed that tdp performed better than bandpower, also in our preliminary experiment, tdp also performed better in an offline classification using Biosig. My question is, is there any known reason why we cannot implement a good online BCI using tdp? I am actully asking because I am just wondering why bandpower is still more popular than tdp. Thank you. Bethel ________________________________________ From: Alois Schloegl [alois.schloegl@...] Sent: 17 August 2012 23:18 To: Bethel Osuagwu Cc: biosiggeneral@... Subject: Re: [Biosiggeneral] The Time domain parameters On 20120816 18:59, Bethel Osuagwu wrote: > Dear Alois, > > Thank you very much for your reply. I will try to implement what you > described. But what I am having problem with is the line in tdp() > thus: > > filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; > //for example B = UC; A = [1, UC1]; and d=d0 is the pth > derivative > > The line with the filter is the line confusing me due to the division > because I do not know much about filters for now. But from your > description, the line is low pass filtering. So will I achieve what > this line is doing if I implement a simulink filter using only 'A' > and 'B' (i.e doing only filter(B,A,d.^2)) That should to it, except when your data contains missing values encoded as NaN's. or do I need to divide by an > output of another filter as in ./filter(B,A,double(~isnan(d0))) > ? This part is only needed when your data can contain missing values encoded as NaN's. In that case, then NaN's in d need to be replaced by 0 and the denominated need to account for the fact, that some samples have been ignored. Alois > > Thank you again for you time Bethel > > ________________________________________ From: Alois Schloegl > [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel > Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The Time > domain parameters > > Dear Bethel, > > > the rtsBCI simulink implements currently only the time domain > parameters of Hjorth and Barlow. Implementing tdp.m in simulink is > quite simple. you just need to connect 1st order difference blocks in > a sequential manner (output of pth difference block is the input of > the next differential block). Then connect the output of each block, > take the square, do a lowpass filter, and take the logarithm. > > I'll forward your request also Reinhold, the maintainer of rtsBCI. > > > I hope this helps, Alois > > > > > > > On 08/14/12 17:12, Bethel Osuagwu wrote: >> Dear Sir, >> >> I just realized that there's no simulink block in rtsBCI for >> calculating the Time Domain Parameter(TDP) Features implemented in >> Biosig. This TDP were used in 'demo2.m' of Biosig for >> demonstration. I tried reading the tdp() function so that I can >> implement the simulink block but I could not understand some part >> of the function when it takes multiple derivatives. Any help for >> implementing this TDP as a simulink block will be most >> appreciated. >> >> Thanks Bethel. >>  >> >> > >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and >> the latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ Biosiggeneral >> mailing list Biosiggeneral@... >> https://lists.sourceforge.net/lists/listinfo/biosiggeneral > 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120818 05:22:35

Dear Alois, Thank you very much. Bethel ________________________________________ From: Alois Schloegl [alois.schloegl@...] Sent: 17 August 2012 23:18 To: Bethel Osuagwu Cc: biosiggeneral@... Subject: Re: [Biosiggeneral] The Time domain parameters On 20120816 18:59, Bethel Osuagwu wrote: > Dear Alois, > > Thank you very much for your reply. I will try to implement what you > described. But what I am having problem with is the line in tdp() > thus: > > filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; > //for example B = UC; A = [1, UC1]; and d=d0 is the pth > derivative > > The line with the filter is the line confusing me due to the division > because I do not know much about filters for now. But from your > description, the line is low pass filtering. So will I achieve what > this line is doing if I implement a simulink filter using only 'A' > and 'B' (i.e doing only filter(B,A,d.^2)) That should to it, except when your data contains missing values encoded as NaN's. or do I need to divide by an > output of another filter as in ./filter(B,A,double(~isnan(d0))) > ? This part is only needed when your data can contain missing values encoded as NaN's. In that case, then NaN's in d need to be replaced by 0 and the denominated need to account for the fact, that some samples have been ignored. Alois > > Thank you again for you time Bethel > > ________________________________________ From: Alois Schloegl > [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel > Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The Time > domain parameters > > Dear Bethel, > > > the rtsBCI simulink implements currently only the time domain > parameters of Hjorth and Barlow. Implementing tdp.m in simulink is > quite simple. you just need to connect 1st order difference blocks in > a sequential manner (output of pth difference block is the input of > the next differential block). Then connect the output of each block, > take the square, do a lowpass filter, and take the logarithm. > > I'll forward your request also Reinhold, the maintainer of rtsBCI. > > > I hope this helps, Alois > > > > > > > On 08/14/12 17:12, Bethel Osuagwu wrote: >> Dear Sir, >> >> I just realized that there's no simulink block in rtsBCI for >> calculating the Time Domain Parameter(TDP) Features implemented in >> Biosig. This TDP were used in 'demo2.m' of Biosig for >> demonstration. I tried reading the tdp() function so that I can >> implement the simulink block but I could not understand some part >> of the function when it takes multiple derivatives. Any help for >> implementing this TDP as a simulink block will be most >> appreciated. >> >> Thanks Bethel. >>  >> >> > >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and >> the latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ Biosiggeneral >> mailing list Biosiggeneral@... >> https://lists.sourceforge.net/lists/listinfo/biosiggeneral > 
From: Alois Schloegl <alois.schloegl@is...>  20120817 22:19:46

On 20120816 19:20, Bethel Osuagwu wrote: > Dear all, > > This is just to comment on what I have noticed on Biosig4octmat2.61 sload() function incase anybody might find it useful. > > I noticed that the following two lines have exactly the same effect (of NOT scalling the signal) in matlab R12 and R10 : > 1: [s,h]=sload(filename,...'UCAL',1); > 2: [s,h]=sload(filename...'UCAL',0); You need to use ON/OFF like this: 1: [s,h]=sload(filename,...'UCAL','ON'); 2: [s,h]=sload(filename...'UCAL','OFF'); I've clarified the help text of sload.m Alois > > while the following line has a different effect (of scalling the signal). > 3: [s,h]=sload(filename...); > > The line 1: probabily has an undesired effect? > > Thank you! > Bethel > > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Biosiggeneral mailing list > Biosiggeneral@... > https://lists.sourceforge.net/lists/listinfo/biosiggeneral 
From: Alois Schloegl <alois.schloegl@is...>  20120817 22:16:48

On 20120816 18:59, Bethel Osuagwu wrote: > Dear Alois, > > Thank you very much for your reply. I will try to implement what you > described. But what I am having problem with is the line in tdp() > thus: > > filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; > //for example B = UC; A = [1, UC1]; and d=d0 is the pth > derivative > > The line with the filter is the line confusing me due to the division > because I do not know much about filters for now. But from your > description, the line is low pass filtering. So will I achieve what > this line is doing if I implement a simulink filter using only 'A' > and 'B' (i.e doing only filter(B,A,d.^2)) That should to it, except when your data contains missing values encoded as NaN's. or do I need to divide by an > output of another filter as in ./filter(B,A,double(~isnan(d0))) > ? This part is only needed when your data can contain missing values encoded as NaN's. In that case, then NaN's in d need to be replaced by 0 and the denominated need to account for the fact, that some samples have been ignored. Alois > > Thank you again for you time Bethel > > ________________________________________ From: Alois Schloegl > [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel > Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The Time > domain parameters > > Dear Bethel, > > > the rtsBCI simulink implements currently only the time domain > parameters of Hjorth and Barlow. Implementing tdp.m in simulink is > quite simple. you just need to connect 1st order difference blocks in > a sequential manner (output of pth difference block is the input of > the next differential block). Then connect the output of each block, > take the square, do a lowpass filter, and take the logarithm. > > I'll forward your request also Reinhold, the maintainer of rtsBCI. > > > I hope this helps, Alois > > > > > > > On 08/14/12 17:12, Bethel Osuagwu wrote: >> Dear Sir, >> >> I just realized that there's no simulink block in rtsBCI for >> calculating the Time Domain Parameter(TDP) Features implemented in >> Biosig. This TDP were used in 'demo2.m' of Biosig for >> demonstration. I tried reading the tdp() function so that I can >> implement the simulink block but I could not understand some part >> of the function when it takes multiple derivatives. Any help for >> implementing this TDP as a simulink block will be most >> appreciated. >> >> Thanks Bethel. >>  >> >> > >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and >> the latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ Biosiggeneral >> mailing list Biosiggeneral@... >> https://lists.sourceforge.net/lists/listinfo/biosiggeneral > 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120816 17:20:27

Dear all, This is just to comment on what I have noticed on Biosig4octmat2.61 sload() function incase anybody might find it useful. I noticed that the following two lines have exactly the same effect (of NOT scalling the signal) in matlab R12 and R10 : 1: [s,h]=sload(filename,...'UCAL',1); 2: [s,h]=sload(filename...'UCAL',0); while the following line has a different effect (of scalling the signal). 3: [s,h]=sload(filename...); The line 1: probabily has an undesired effect? Thank you! Bethel 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120816 16:59:46

Dear Alois, Thank you very much for your reply. I will try to implement what you described. But what I am having problem with is the line in tdp() thus: filter(B,A,d.^2)./filter(B,A,double(~isnan(d0))) where UC =0.0085; //for example B = UC; A = [1, UC1]; and d=d0 is the pth derivative The line with the filter is the line confusing me due to the division because I do not know much about filters for now. But from your description, the line is low pass filtering. So will I achieve what this line is doing if I implement a simulink filter using only 'A' and 'B' (i.e doing only filter(B,A,d.^2))or do I need to divide by an output of another filter as in ./filter(B,A,double(~isnan(d0))) ? Thank you again for you time Bethel ________________________________________ From: Alois Schloegl [alois.schloegl@...] Sent: 16 August 2012 09:06 To: Bethel Osuagwu Cc: ; Reinhold Scherer Subject: Re: [Biosiggeneral] The Time domain parameters Dear Bethel, the rtsBCI simulink implements currently only the time domain parameters of Hjorth and Barlow. Implementing tdp.m in simulink is quite simple. you just need to connect 1st order difference blocks in a sequential manner (output of pth difference block is the input of the next differential block). Then connect the output of each block, take the square, do a lowpass filter, and take the logarithm. I'll forward your request also Reinhold, the maintainer of rtsBCI. I hope this helps, Alois On 08/14/12 17:12, Bethel Osuagwu wrote: > Dear Sir, > > I just realized that there's no simulink block in rtsBCI for > calculating the Time Domain Parameter(TDP) Features implemented in > Biosig. This TDP were used in 'demo2.m' of Biosig for demonstration. > I tried reading the tdp() function so that I can implement the > simulink block but I could not understand some part of the function > when it takes multiple derivatives. Any help for implementing this > TDP as a simulink block will be most appreciated. > > Thanks Bethel. >  > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ Biosiggeneral > mailing list Biosiggeneral@... > https://lists.sourceforge.net/lists/listinfo/biosiggeneral 
From: Alois Schloegl <alois.schloegl@is...>  20120816 08:07:09

Dear Bethel, the rtsBCI simulink implements currently only the time domain parameters of Hjorth and Barlow. Implementing tdp.m in simulink is quite simple. you just need to connect 1st order difference blocks in a sequential manner (output of pth difference block is the input of the next differential block). Then connect the output of each block, take the square, do a lowpass filter, and take the logarithm. I'll forward your request also Reinhold, the maintainer of rtsBCI. I hope this helps, Alois On 08/14/12 17:12, Bethel Osuagwu wrote: > Dear Sir, > > I just realized that there's no simulink block in rtsBCI for > calculating the Time Domain Parameter(TDP) Features implemented in > Biosig. This TDP were used in 'demo2.m' of Biosig for demonstration. > I tried reading the tdp() function so that I can implement the > simulink block but I could not understand some part of the function > when it takes multiple derivatives. Any help for implementing this > TDP as a simulink block will be most appreciated. > > Thanks Bethel. >  > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ Biosiggeneral > mailing list Biosiggeneral@... > https://lists.sourceforge.net/lists/listinfo/biosiggeneral 
From: Alois Schloegl <alois.schloegl@is...>  20120816 07:49:26

Dear Arlex, On 08/15/12 18:35, Arlex Oscar Marín García wrote: > Hello everyone, I've recently began to work with octave and the BIOSIG > library v2.3 mainly because I need to estimate an Multivariate > Autoregressive Model with it. > > The reason I work with this version is that I've tried to use the most > recent versions but with not much success, the library was using 64bit > versions and they were useless for me since I'm on a i686 platform. Also I > wanted to use the most stable version I could find, is my decision correct? > Should I use a more recent version of the library? Yes, its recommended to use the latest version. For estimating MVAR parameters, you can do without using mexfiles. (Which mexfiles are you trying to use ?) Its correct that the current release contains binaries only for mexw32, mexw64 and glxa64. In order to compile the mexfiles (mexSLOAD etc.) for your platform, download biosig4c++, see the REAMDE for prerequisites (aptget install libsuitesparsedev libzdev) and compile the binaries make mex4m Then, copy or move the binaries into some directory of your path (e.g. .../biosig/t200/ ) > > Reading the documentation included I can not understand fully how to use > this function "mvaar", using some dummy data and testing various parameters > didn't help that much either. > > What I want to do is calculate the parameter matrices for an arbitrary > model order p using a (up to) 88 channel, 512Hz sampled, 400s, EEG data. > The data is stored in matrix form (it has no headers, only the electrical > activity detected for each electrode 512 readings per second) and then > use this matrices to construct some other data. > MVAAR is for estimating "MultiVariate Adaptive AutoregRessive parameters", *adaptive* refers to "varying in time". Do you really want to do that ? More likely, you want to estimate "MultiVariate AutoRegressive" (MVAR) from a short segment assuming stationarity within that segment. In that case, you should use MVAR.M. In that case, see also for biosig/demo/demo7.m > Can BIOSIG do that? I mean, the data length might be too large, or the > number or channels...I really don't know. data length can never be too large, you should be only afraid if you have to little data. An issue might be the number of channels. 88 channels causes 88*88*p = 7744*p (p is the model order) coefficients to estimate. Possible issues are "curse of dimensionality", overfitting, matrices become singular (i.e. the condition number is bad causing excessive rounding errors). This could be also caused by the data acquisition, when there are some shortcuts between electrodes. Not all estimators might perform equally good under such conditions. I do not have that much experience with such large channel numbers, but it is certainly of interest to investigate it. Let me know about your experience. Alois > > Thanks in advance, Arlex Marín. > > > > *================================================* > * Arlex Oscar Marín García* > * Universidad Autónoma del Estado de Morelos  Facultad de Ciencias* > * Av. Universidad 1001, Col. Chamilpa* > * Cuernavaca Morelos, México * > * C.P. 62209 * > * Teléfono: (+52) 777 329 7020 ext. 3273 * > *================================================* > > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Biosiggeneral mailing list > Biosiggeneral@... > https://lists.sourceforge.net/lists/listinfo/biosiggeneral 
From: Arlex Oscar Marín García <mgao@ua...>  20120815 17:05:24

Hello everyone, I've recently began to work with octave and the BIOSIG library v2.3 mainly because I need to estimate an Multivariate Autoregressive Model with it. The reason I work with this version is that I've tried to use the most recent versions but with not much success, the library was using 64bit versions and they were useless for me since I'm on a i686 platform. Also I wanted to use the most stable version I could find, is my decision correct? Should I use a more recent version of the library? Reading the documentation included I can not understand fully how to use this function "mvaar", using some dummy data and testing various parameters didn't help that much either. What I want to do is calculate the parameter matrices for an arbitrary model order p using a (up to) 88 channel, 512Hz sampled, 400s, EEG data. The data is stored in matrix form (it has no headers, only the electrical activity detected for each electrode 512 readings per second) and then use this matrices to construct some other data. Can BIOSIG do that? I mean, the data length might be too large, or the number or channels...I really don't know. Thanks in advance, Arlex Marín. *================================================* * Arlex Oscar Marín García* * Universidad Autónoma del Estado de Morelos  Facultad de Ciencias* * Av. Universidad 1001, Col. Chamilpa* * Cuernavaca Morelos, México * * C.P. 62209 * * Teléfono: (+52) 777 329 7020 ext. 3273 * *================================================* 
From: Bethel Osuagwu <b.osuagwu.1@re...>  20120814 15:37:22

Dear Sir, I just realized that there's no simulink block in rtsBCI for calculating the Time Domain Parameter(TDP) Features implemented in Biosig. This TDP were used in 'demo2.m' of Biosig for demonstration. I tried reading the tdp() function so that I can implement the simulink block but I could not understand some part of the function when it takes multiple derivatives. Any help for implementing this TDP as a simulink block will be most appreciated. Thanks Bethel. 