jonhub/filters

A realtime digital signal processing (DSP) library for Arduino

filters's Issues

Filters are unsuitable for fixed-rate sampling

These filters assume the sampling rate is the rate of the user program calling their input() methods. This is fine if the user just calls filter.input(analogRead(PIN)) in his loop. However, if he manages to have a fixed sampling rate (maybe by using external hardware) and his calls to input() are not quite periodic, then the filters will assume wrong timings. I have witnessed one user being bitten by this issue.

A related issue is the poor performance. I have benchmarked FilterOnePole::input(float) at about 245 µs average time per sample on a 16 MHz AVR-based Arduino. I suspect a significant fraction of this time is spent in computing ampFactor as

ampFactor = exp( -1.0 / TauSamps );

given that both the floating-point division and the exponential are very CPU-intensive on 8-bit FPU-less micros.

Computing this for every sample is reasonable if the sampling rate is not constant. However, when using a fixed sampling rate, this computation only needs to be performed once, at initialization. I implemented a constant-rate low pass filter similar to FilterOnePole in LOWPASS mode and it takes only 27.8 µs per sample, i.e. it is 8.8 times faster than FilterOnePole.

I suggest putting a note somewhere, maybe in a README file, warning the users that this library is only suited for cases where the sampling rate cannot be kept constant, and that dealing with this uneven sampling comes at a high cost in terms of processing time.

compilation error

Arduino\libraries\Filters-master\FilterTwoPole.cpp: In member function 'void FilterTwoPole::test()':

C:\Users\Shubh\Documents\Arduino\libraries\Filters-master\FilterTwoPole.cpp:198:33: error: 'analogWrite' was not declared in this scope

 analogWrite(10,osc.output() ); // hardcoded the dial pin

                             ^

exit status 1

The default view is running

I want the display to run without having to write 4V, 1000V then the final display. I want a final view that is legible

// wire i2c
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27,16,2);

#include <Filters.h>

float testFrequency = 50; // signal frequency (Hz)
float windowLength = 40.0/testFrequency; // how long to average the signal, for statistist

int Sensor = 0;                 

float intercept = -0.04; // adjust untuk kalibrasi
float slope = 0.0964; // adjust untuk kalibrasi
float current_Volts;

unsigned long previousMillis1 = 0;
const long interval1 = 1000;

void setup() {
  Wire.begin();
  Serial.begin(9600);
  
  lcd.init();
  lcd.backlight();
}

void loop() {
  RunningStatistics inputStats;               
  inputStats.setWindowSecs( windowLength );
   
  while( true ) {   
    Sensor = analogRead(A0); // read the analog in value:
    inputStats.input(Sensor); // log to Stats function
        
   if(millis() - previousMillis1 >= interval1) {
      previousMillis1 = millis();
        current_Volts = inputStats.sigma()* slope + intercept; //Calibartions for offset and amplitude
        current_Volts = current_Volts*(49.3231); //Further calibrations for the amplitude     
          lcd.clear();
          lcd.setCursor(0,0);
          lcd.print("VOLTAGE");
          lcd.setCursor(0,1);
          lcd.print(current_Volts);
          lcd.print("V");
    }
    break;
  }
}

Undefined behavior on timer rollover

The method FilterOnePole::input(float) starts with these statements:

long time = micros();
ElapsedUS = float(time - LastUS);   // cast to float here, for math

When micros() reaches 2³¹, which happens roughly 35.8 minutes after the program starts, time becomes a large negative number, and the subtraction time - LastUS overflows.

In C and C++, arithmetic overflow of signed integral types is undefined behavior. This means the program is incorrect, and anything can happen, including (but not limited to) the subtraction giving the expected result. Just for illustration, here is a recent example of the kind of surprises you can get with integer overflows.

The same bug is present in FilterTwoPole.cpp and in FilterDerivative.cpp.

The fix is very simple: all variables holding timestamps (LastUS, LastTimeUS, thisUS, time and now) should be declared unsigned long. This is the type returned by micros(), and it is not a coincidence that it is the right type for timing calculations. Unlike signed integers, the arithmetics on unsigned integers are specified by the C and C++ standards to be done modulo MAX(type)+1. This guarantees that the subtraction will yield the correct result even across a micros() rollover.

Filters - output

I'm not sure if I am setting it up correctly but if I set a low pass filter frequency at 100 (Hz). The 100 Hz should be the cutoff frequency correct? Now if I use the output function of my filter and print the value... should I be seeing a value of zero if my input frequency is over 100 Hz?

Library for C language

Hello,

I know this is targeted for Arduino users, however, if using esp-idf then C language is required. Is it possible to convert to C language for your library?

Thank you.