[Tanya 4]

Так ведь, "усреднить помехи" по сути и означает отфильтровать их, т.е. - устранить.. Или нет?

В данном случае, наверное, - нет. См 19 и 20 посты.

[Палыч 6]

T_average += (T_current - T_average) / 20.0.

 

То есть из считанного значения вычитаем текущее, делим на коэффициент и прибавляем к текущему. Плавающая точка здесь ни к чему, в целых числах тоже можно считать, правда там есть свои тонкости.

Вот, именно - тонкости! Представьте, что разность между считанным и текущим значениями - меньше двадцати. Что получим? По этой же причине у автора вопроса и прыгают значения: в первом топике он привёл код, якобы усредняющий из двадцати значений... Имхо, сумма подсчитывается из значений измерений делённых на 5 - так усреднять, мягко говоря, не корректно.

[777777 0]

Так ведь, "усреднить помехи" по сути и означает отфильтровать их, т.е. - устранить.. Или нет?

Да, но только устраняют их обычно на входе АЦП, в аналоговом виде, так чтобы АЦП выдавал устойчивый код, который не пришлось бы фильтровать. И не путем подключения RC-цепочки, а путем выяснения их природы и устранения того, что их вызывает. Например, распространенная ошибка - обратный ток от светодиодных индикаторов идет по той же земле, на которой висит АЦП. Падение тока на нем вызывает скачки на земле. Эти помехи вы не устраните усреднением, потому что все они "в одну сторону", так что даже усреднив их вы получите неправильный результат.

[blackfin 16]

Да, но только устраняют их обычно на входе АЦП, в аналоговом виде,...

Меня смутила формулировка.. ИМХО, есть разница между "устранение помех" и "устранение причин из-за которых эти помехи возникают на входе АЦП"..

[777777 0]

Вот, именно - тонкости! Представьте, что разность между считанным и текущим значениями - меньше двадцати. Что получим?

Получим, что результат никогда не достигнет входного значения. Но ведь и реальная, математическая экспонента никогда его не достигает! Вопрос лишь в необходимой точности. Если нужна большая - результат храним в long, а используем в качестве результата старшую половину - то есть как бы число с фиксированной точкой, в котором младшие 16 разрядов дробные.

По этой же причине у автора вопроса и прыгают значения: в первом топике он привёл код, якобы усредняющий из двадцати значений... Имхо, сумма подсчитывается из значений измерений делённых на 5 - так усреднять, мягко говоря, не корректно.

Почему? Просто результат будет в 4 раза больше.

 

По этой же причине у автора вопроса и прыгают значения: в первом топике он привёл код, якобы усредняющий из двадцати значений... Имхо, сумма подсчитывается из значений измерений делённых на 5 - так усреднять, мягко говоря, не корректно.

Пардон, не доглядел - конечно же надо сначала суммировать 20 значений, а результат делить на 5. А еще лучше - использовать степень двойки.

Изменено 13 февраля, 2009 пользователем 777777

[Палыч 6]

Получим, что результат никогда не достигнет входного значения. Но ведь и реальная, математическая экспонента никогда его не достигает! Вопрос лишь в необходимой точности.

Математическая экспанента хотя бы стремиться к нему. В Вашем же случае мы будем иметь постоянную ошибку. Результат этого - всё тот же - отбрасывание остатка при делении, который тем больше, чем больше делитель (это - ведь, наверное, и есть те тонкости, о которых Вы говорили выше). Тогда, уж лучше что-нибудь такое:

 

Инициализация переменной

T_average_tmp = T_current * N

...................

T_average_tmp += (T_current - T_average)

T_average= T_average_tmp / N

 

Последнюю строчку, может быть, записать даже так:

T_average= (T_average_tmp + N/2) / N

[xemul 0]

...

Последнюю строчку, может быть, записать даже так:

T_average= (T_average_tmp + N/2) / N

Последнюю строчку только так и нужно писать, чтобы погрешность от целочисленного деления осталась +-0.5LSB.

[777777 0]

Математическая экспанента хотя бы стремиться к нему. В Вашем же случае мы будем иметь постоянную ошибку.

Что значит "постоянную ошибку"? Разумеется, экспонента будет отличаться от реальной из-за округлений, это неизбежно при цифровых вычислениях, вопрос лишь в необходимой точности. Даже если вы примените float, все равно ошибка будет, так как float тоже дискретно. Но задача ведь не в том, чтобы имитировать экспоненту, а в том, чтобы сгладить сигнал. Для этого вычисления в целых вполне достаточно.

Результат этого - всё тот же - отбрасывание остатка при делении, который тем больше, чем больше делитель (это - ведь, наверное, и есть те тонкости, о которых Вы говорили выше). Тогда, уж лучше что-нибудь такое:

Инициализация переменной

T_average_tmp = T_current * N

...................

T_average_tmp += (T_current - T_average)

T_average= T_average_tmp / N

Тогда уж лучше что-нибудь такое:

    static long Adc0, AdcF;

    Adc0 = (long)ADC << 16;
    AdcF += (Adc0 - AdcF)>>3; // или разделить на нужное число, если оно не степень двойки
    int Result = AdcF >> 16;

Правда, gnu-тый компилятор не очень эффективно кодирует сдвиги (не знаю, может IAR поумнее), поэтому этот участок лучше написать на ассемблере.

Смысл в том, что в старших 16 битах AdcF хранится фильтрованное значение, а в младших - его дробная часть, т.е. оно представляет собой число с фиксированной точкой. При кодировании на ассемблере можно даже подойти к делению (сдвигу) более творчески: если в отбрасываемых битах старший 1, то к оставшимся прибавляем 1, а если 0 - то не прибавляем, т.е. выполняем деление с округлением до целого. Тогда не будет ошибки с отбрасыванием, которой ты так боишься.

[ReAl 0]

Тогда уж лучше что-нибудь такое:

    static long Adc0, AdcF;

    Adc0 = (long)ADC << 16;
    AdcF += (Adc0 - AdcF)>>3; // или разделить на нужное число, если оно не степень двойки
    int Result = AdcF >> 16;

...

Смысл в том, что в старших 16 битах AdcF хранится фильтрованное значение, а в младших - его дробная часть, т.е. оно представляет собой число с фиксированной точкой.

+1

Давно делаю похожим образом, часто запас разрядов в аккумуляторе делаю равным числу сдвигов для деления на коффициент фильтра (он степень двойки). Т.е. для беззнаковых 10-битных отсчётов и "рециркуляции" 7/8, т.е. весе очередного отсчёта 1/8 будет так:

    uint16_t acc;
void update(uint16_t val) {
   acc = acc - ((acc + 4) >> 3) + val;
}

uint16_t get_result() {
   return  (acc + 4) >> 3;
}

Собственно, с не-степенью двойки будет аналогично, просто

(acc+4)>>3

езде заменится на

(acc+DIVIDER/2)/DIVIDER

, но я не вижу в этом особого смысла. Если задача так чувствительна к тому, что новый отсчёт будет входить не с 1/8 или 1/16, а имено с 1/10 или 1/13, то скорее всего там и фильтр нужен более высокого порядка.

[Wantcan 0]

Пожалуйста,помогите переделать найденный на этом форуме программный ФНЧ под мои условия,сам не могу разобраться.

int nStepFilter( int val)
{
#define  shift  (4)   // n = 2^shift 
#define  lsb    ((1 << (shift)) >> 1)

    static int x = 0;
    int av = (x + lsb) >> shift;

    x += val - av;

    return av;
#undef lsb
#undef shift
}

[Wantcan 0]

Остановился на таком варианте

 ta++; if(ta==20){ta=0;temp=tempADC/100;}
   if(ta==0)tempADC=0;   
   tempADC+=read_adc(0);

[FluktuacyaVaccuma 0]

Нужно создать в оперативной памяти закольцованный FIFO-буфер с двумя указателями (PTR_first и PTR_last).

 

И регистр суммы. Разрядность его должна быть достаточной для хранения суммы 20-ти значний без округления.

 

Как только приходит очередное значение от АЦП Вы его записываете в ячейку, на которую указывает PTR_last, добавляете его к сумме и вычитаете из суммы значение, на которое указывает PTR_first.

 

После чего двигаете PTR_first и PTR_last на следующие ячейки в кольце.

 

Таким образом у Вас всегда в регистре cуммы будет акутульное значение среднего, умноженное на 20.

 

Чтобы получить среднее достаточно будет поделить значение, находящееся в данный момент в регистре суммы на 20.

Изменено 15 августа, 2015 пользователем Флюктуация ваккума

[PicUni 0]

Такой вариант не подойдет?

for(i=0;i<20;i++) // усредняем 20 выборки

{

ADC_cur = ADС;

if (i == 0)

{

ADC_old = ADC_cur; // первое значение отправляем в сумму

ADC_sum = ADC_old;

}

else

{

ADC_old += ADC_cur; // сложили текущее значение со старым

ADC_old /= 2; // поделили на 2

ADCsum += ADC_old; // просуммировали

}

}

ADC_cur = ADC_sum/20; // cумму поделили на 20 */

[Aldec 0]

Для индикатора достаточно суммы 5-10 значений. 

 

Изменено 17 апреля, 2019 пользователем Aldec

[lyric 0]

Здравствуйте.

Вопрос не про фильтрацию, но про АЦП:

контроллер AVR. Напряжение на входе НЕ меняется, но при этом измеренное значение АЦП со временем (полчаса-час, сутки-трое суток) меняется, - уползает вверх, или вниз, когда как... Отчего это может быть? В программе значение АЦП аппроксимировано в диапазон 0-6000. Так вот в таком виде (0-6000) значение уезжает вплоть до 40 единиц, - например установилось значение 3500, и плавно уменьшается, и через час оно уже 3478, хотя измеряемый сигнал никак не менялся.

Ещё вторая проблема с АЦП, - если программа выдаёт сигнал включения какого-либо вывода в состояние 0, то значение АЦП искажается, - может разово возрасти, а может разово уменьшится примерно на 10 единиц. Подскажите пожалуйста почему и что с этим делать? 

Изменено 18 апреля, 2019 пользователем lyric