Jump to content

    

Усреднение вычислений АЦП

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

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

Share this post


Link to post
Share on other sites
T_average += (T_current - T_average) / 20.0.

 

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

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

Share this post


Link to post
Share on other sites
Так ведь, "усреднить помехи" по сути и означает отфильтровать их, т.е. - устранить.. Или нет?

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

Share this post


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

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

Share this post


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

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

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

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

 

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

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

Edited by 777777

Share this post


Link to post
Share on other sites
Получим, что результат никогда не достигнет входного значения. Но ведь и реальная, математическая экспонента никогда его не достигает! Вопрос лишь в необходимой точности.
Математическая экспанента хотя бы стремиться к нему. В Вашем же случае мы будем иметь постоянную ошибку. Результат этого - всё тот же - отбрасывание остатка при делении, который тем больше, чем больше делитель (это - ведь, наверное, и есть те тонкости, о которых Вы говорили выше). Тогда, уж лучше что-нибудь такое:

 

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

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

Share this post


Link to post
Share on other sites
...

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

T_average= (T_average_tmp + N/2) / N

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

Share this post


Link to post
Share on other sites
Математическая экспанента хотя бы стремиться к нему. В Вашем же случае мы будем иметь постоянную ошибку.

Что значит "постоянную ошибку"? Разумеется, экспонента будет отличаться от реальной из-за округлений, это неизбежно при цифровых вычислениях, вопрос лишь в необходимой точности. Даже если вы примените 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 - то не прибавляем, т.е. выполняем деление с округлением до целого. Тогда не будет ошибки с отбрасыванием, которой ты так боишься.

Share this post


Link to post
Share on other sites
Тогда уж лучше что-нибудь такое:

    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, то скорее всего там и фильтр нужен более высокого порядка.

Share this post


Link to post
Share on other sites

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

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
}

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

 

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

Edited by Флюктуация ваккума

Share this post


Link to post
Share on other sites

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

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 */

Share this post


Link to post
Share on other sites

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

 

Edited by Aldec

Share this post


Link to post
Share on other sites

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

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

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

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

Edited by lyric

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this