common filters: pt1FilterGain must accept uint16_t (#5513)
* all places that call pt1FilterGain use lpfHz which is of type uint16_t. I have not confirmed yet but believe that when lpfHz were greater than 255 we would have seen data loss / overflow / wrap around. TBC
This commit is contained in:
parent
eca6fb3a0c
commit
a0add440f0
|
@ -42,7 +42,7 @@ FAST_CODE float nullFilterApply(filter_t *filter, float input)
|
|||
|
||||
// PT1 Low Pass filter
|
||||
|
||||
float pt1FilterGain(uint8_t f_cut, float dT)
|
||||
float pt1FilterGain(uint16_t f_cut, float dT)
|
||||
{
|
||||
float RC = 1 / ( 2 * M_PI_FLOAT * f_cut);
|
||||
return dT / (RC + dT);
|
||||
|
|
|
@ -129,7 +129,7 @@ float lmaSmoothingUpdate(laggedMovingAverage_t *filter, float input);
|
|||
// not exactly correct, but very very close and much much faster
|
||||
#define filterGetNotchQApprox(centerFreq, cutoff) ((float)(cutoff * centerFreq) / ((float)(centerFreq - cutoff) * (float)(centerFreq + cutoff)))
|
||||
|
||||
float pt1FilterGain(uint8_t f_cut, float dT);
|
||||
float pt1FilterGain(uint16_t f_cut, float dT);
|
||||
void pt1FilterInit(pt1Filter_t *filter, float k);
|
||||
float pt1FilterApply(pt1Filter_t *filter, float input);
|
||||
|
||||
|
|
Loading…
Reference in New Issue