Gijom / TEAP

Hi, I'm wondering why it is necessary to divide a sample rate by 16 in the code:

Line 32 in b9f8d90

GSRsignal = Signal_filter1_low_mean(GSRsignal, round(sampRate/16));

I understand that round(sampRate/16) is passed as a windowSize argument for Signal_filter1_low_mean.m:

TEAP/src/signals/filters/Signal_filter1_low_mean.m

Line 36 in b9f8d90

filtAvgEls = ones(1, windowSize)/windowSize;

However, wouldn't this result in an empty signal (1×0 empty double row vector to be precise) if the sample rate of input is lower than 8Hz? This indeed is the result I get when I try to process data collected at 4Hz.

But first of all, why would sample rate / 16 equal a window size? I've looked at docstrings, but they didn't seem to help much either:
@brief Cleans a signal adding a low-pass mean filter to it. The window equals the sample rate, aka 1 sec.
@param windowSize: the window size (in samples)

Am I missing something here?

The idea here is to create an moving average filter with a window size of 1/16 of a second (i.e. sampling rate / 16). The goal of this filter is essentially to remove high frequency noise while preserving the shape of the signal. However, it is true that this does not make sense to apply this filter on signals with a lower sampling frequency than 32Hz. A workaround would be to first upsample your GSR signals to 32 Hz, or simply to remove this filter as it does not apply in your case.

Some workaround should nevertheless be implemented to deal with such signals. I leave this issue open.

Thanks for the clarification. I suppose one workaround could be to vary a filter size with a sampling rate, possibly with some heuristic, say 1/16 for signals sampled above 32Hz, 1/8 for signals in the interval [16Hz, 32Hz), 1/4 for signals in [8Hz, 16Hz), and so on. Following this logic, a window of size 1/2 of a second would suffice a signal sampled at 4Hz. Nonetheless, I suppose it wouldn't make sense to apply such a moving average filter for signals with a sampling frequency of less than 2Hz.

There might be a more sophisticated method for obtaining an appropriate filter size for signals of varying frequencies, but I'm not quite an expert on this issue. In my case, upsampling would also be a valid workaround you suggested, or simply not applying the filter altogether as the signal's sampling frequency is low enough.

This has been included in hotfix and will be merged in master hopefully soon.

The strategy is to make a warning if the sampling frequency is < 32 and not apply the filter. Further filtering can be applied by the user if needed.

Why divide sample rate by 16 when calculating a window size?