АЦП. Разбор полётов

[pokk]

Вы подаете на вход функцию Дирака, а не реальный сигнал. В результате имеете не фильтрацию сигнала, а АЧХ..

Ну да так она и нужна была. =)

Та же бодяга с шумом.

а с шумом что не так ? белый до фильтра красный после.

[просто КОТ]

Исходники прилагаю. Файл adc8.c - обработка с размером буфера 8.

А я правильно понял -- он начинает считать с момента подачи питания ведь?!

[КРАМ]

Вы подаете на вход функцию Дирака, а не реальный сигнал. В результате имеете не фильтрацию сигнала, а АЧХ..

Ну да так она и нужна была. =)

Та же бодяга с шумом.

а с шумом что не так ? белый до фильтра красный после.

У меня смутное подозрение, что Вам просто не с кем поговорить...
Какое отношение измерение АЧХ фильтра имеет к самой фильтрации?
Вы спросили как фильтровать - я ответил.
Что то непонятно - перечитайте еще раз мой ответ. Если знаете что Вам нужно - зачем спрашивали?
К тому же Вы влезли в чужую тему со своим, как выясняется, ДРУГИМ вопросом....

[КРАМ]

Странные результаты получились, когда на входе строгий ноль.

Еще и не такие чудеса получите, когда будете мерять линейность АЦП...
Мало того, что Вы прицепили фильтр, который имеет выходное сопротивление выше допустимого для УВХ АЦП, так еще и поставили электролит с непредсказуемой и шумящей утечкой.
Даже и не берусь комментировать чудесатости такой схемотехники...

[pokk]

Какое отношение измерение АЧХ фильтра имеет к самой фильтрации?

У меня изначально было много вопросов не только как фильтровать.

Даже вот тут в самом начале, не как не могу понять каким образом буфер является фильтром. и как будет рассчитать его ачх и параметры

Теперь я всё выяснил благодарю за помощь.

[Барсик]

он начинает считать с момента подачи питания ведь?!

Да. АЦП молотит непрерывно. Запускается каждую миллисекунду. Где-то за 200 микросекунд рассчитывается среднее значение. Бедный контроллер - так долго торчит в прерывании... Т.е. каждую миллисекунду у Вас есть результат усреднения методом того самого скользящего среднего, которое так все любят. Но это усреднение по 8 значениям. 16 значений - уже непозволительная роскошь для ATtiny13 - компилятор начинает орать, что размер стека уменьшился до опасной величины.

Еще и не такие чудеса получите, когда будете мерять линейность АЦП...

Нельзя ли здесь подробнее. Я правильно Вас понял - линейность надо измерять вблизи нуля? Если да, то лучше это делать в каких пределах, если вся шкала АЦП это 1,1 вольта.

Даже и не берусь комментировать чудесатости такой схемотехники...

Да, кстати. Может, посоветуете правильную схемотехнику? А я её испытаю?

[bolek]

...Странные результаты получились...

У Вас в программе неверный алгоритм запуска АЦП, занесения результата в массив и вычисления среднего.
У Вас:

Код: Выделить всё

1.1 прерывание timer0_compa_isr(void) // каждую миллисекунду аппаратно запускается АЦП
1.2 дрыганье PORTB.3, PORTB.4
1.3 суммирование ВСЕХ элементов массива
1.4 вычисление среднего

Независимо от этого:

Код: Выделить всё

2.1.adc_isr(void)
2.2 дрыганье PORTB.1
2.3 запись результата АЦП в массив

Получается неопределенность в момент суммирования массива: суммирование нужно производить после того, как готов результат АЦП, чтобы процесс записи результата в массив (не одномоментный и прерывающий суммирование хз в какой стадии!) никак не влиял на суммирование.
В простейшем случае нужно добавить флажок (ResReady) готовности результата АЦП:
- в начале timer0_compa_isr добавить ResReady = 0;
- суммирование начинать по if (ResReady)
- в adc_isr добавить после ногодрыжества ResReady = 1;

Далее. Вы пропустили очень полезный совет от Ser60: не вычислять каждый раз сумму всех элементов массива, а из предыдущей суммы вычесть заменяемый элемент массива и прибавить к ней новый viewtopic.php?p=1373681#p1373681
Это
1. даст вам независимость времени вычисления от количества элементов массива
2. существенно сократит время вычислений

В main помимо peripheralInit не хватает VariablesInit (инициализации переменных), в частности указателя массива и обнуления элементов массива.

Вообще, я бы
- отказался от прерывания adc_isr, заменив его ожиданием готовности результата АЦП в timer0_compa_isr
- по готовности результата АЦП выставил флажок ResReady
- вычисления среднего вынес в main, по появлению флажка ResReady.

Итого: одним прерыванием меньше, в прерывании timer0_compa_isr находимся только время АЦП.
Впрочем, дело Ваше

[Барсик]

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

Какой алгоритм КРАМ посоветовал, такой я туда и забил. А в чём, собственно, его неправильность? В том, что ногами дрыгаю в прерывании или что неправильно считаю среднее?

Независимо от этого:

Очень даже зависимо. В атмелах сделано так, что пока обрабатывается одно из прерываний, остальные запрещены. И если бы даже это было не так, то прерывания всё равно разнесены по времени. Вычисления в начале миллисекунлы, а считывание АЦП через 0,7 мс после этого. Не зря же я выводил отладочные импульсы - всё смотрел осциллографом.

Получается неопределенность в момент суммирования массива:

Никакой неопределённости нет. Я суммирую в другом прерывании, когда элементы массива измениться не могут, по причине, указанной выше.

Вы пропустили очень полезный совет от Ser60

Согласен. Но я сначала решил обкатать алгоритм от КРАМ-а

В main помимо peripheralInit не хватает VariablesInit (инициализации переменных), в частности указателя массива и обнуления элементов массива.

Инициализация некоторых переменных есть - она сделана при их объявлении. А инициализировать массив смысла нет, поскольку всё равно через 8 миллисекунд он будет переписан новыми значениями.

- отказался от прерывания adc_isr, заменив его ожиданием готовности результата АЦП в timer0_compa_isr

Как мне представляется, ожидать чего-либо внутри прерывания - весьма хреновая практика.

- вычисления среднего вынес в main, по появлению флажка ResReady.

Мне кажется, один хрен. Всё равно придётся запретить прерывания на время обработки...

Спасибо за замечания. Наконец-то я получил ответ по существу...

[КРАМ]

Может, посоветуете правильную схемотехнику? А я её испытаю?

А в чем тут вопросы? Если источник изначально низкоомный и требования по точности устраивают, то можно просто подать сигнал на вход. Или если нужно, обычный повторитель на ОУ для понижения сопротивления источника сигнала вполне подойдет. Можно применить и ОУ с ФНЧ низкого порядка для подавления зеркальной полосы пропускания цифрового фильтра и отчасти боковых лепестков основной. Но это по показаниям. Смотря какая полоса у входного сигнала, какая частота дискретизации, какие вычислительные ресурсы у МК...
Вопрос не конкретный. Нужна задача.

[КРАМ]

Различия в младших разрядах при фильтрации разными способами объясняются очень просто. Все зависит от параметров фильтра. Если нули АЧХ совпадут с частотой помехи, то подавление будет практически идеальным, но если частота попадет на центр бокового лепестка - эффективность фильтрации резко падает до уровня этого лепестка. Поэтому Ваши вопросы на эту тему бессмысленны без конкретных просчетов времен...
10 разрядный цифровой сигнал имеет шум квантования на уровне около -60 дБ к полной шкале. Уровни боковых лепестков при прямоугольном окне могут составлять и -20...-30 дБ.

[Барсик]

Измеряю постоянное напряжение. С интервалом в 1 секунду. Выходное сопротивление источника примерно 3 кОм. Входное сопротивление АЦП от мегаома и выше. Я добавил ещё 10 кОм и конденсатор 47 мкф на вход АЦП, чтобы постоянная времени была где-то 0,5 секунды. И что такого "чудесатого" в этой схемотехнике?

Ваши вопросы на эту тему бессмысленны без конкретных просчетов времен...

Вот конкретные времена. Запуск АЦП осуществляется каждую миллисекунду. Результат считывается через 0,7 мс.

[КРАМ]

- отказался от прерывания adc_isr, заменив его ожиданием готовности результата АЦП в timer0_compa_isr

Как мне представляется, ожидать чего-либо внутри прерывания - весьма хреновая практика.

- вычисления среднего вынес в main, по появлению флажка ResReady.

Мне кажется, один хрен. Всё равно придётся запретить прерывания на время обработки...

Спасибо за замечания. Наконец-то я получил ответ по существу...

1. Вам правильно представляется. Ожидать готовности в прерывании бессмысленно, как и вообще устраивать прерывания по таймеру для решения этой задачи. Я уже Вам писАл - лучший способ - запуск АЦП АППАРАТНО по переполнению таймера и БЕЗ прерываний от этого таймера. Таким образом, семплирование сигнала будет определятся ТОЛЬКО АППАРАТНЫМИ интервалами и никакой латентности входа в прерывание не будет. Тогда АЧХ фильтра будет стабильной.
2. То же самое. Я писАл, что обработку лучше делать сразу после занесения очередного результата в массив, но при невысоких требованиях к фильтру - можно и в мэйн. Никакой особой проблемы с прерыванием расчета и изменением массива не будет. Совсем немного размоет АЧХ, много меньше, чем в первом пункте.
Самый лучший вариант - это применение МК с внутрицикловым ДМА. Например PIC24H или dsPIC33. У 33-их еще и сигнальное ядро есть, что позволит делать накопления в 40-разрядной сетке с минимумом времени на исполнение и особенно для непрямоугольных окон.
Способ расчета среднего непринципиален. Для прямоугольного окна можно и с вычитанием, как тут писАли, но полный пересчет более универсален, если вдруг придется перейти на иную форму окна.

[КРАМ]

Измеряю постоянное напряжение. С интервалом в 1 секунду. Выходное сопротивление источника примерно 3 кОм. Входное сопротивление АЦП от мегаома и выше. Я добавил ещё 10 кОм и конденсатор 47 мкф на вход АЦП, чтобы постоянная времени была где-то 0,5 секунды. И что такого "чудесатого" в этой схемотехнике?

Ваши вопросы на эту тему бессмысленны без конкретных просчетов времен...

Вот конкретные времена. Запуск АЦП осуществляется каждую миллисекунду. Результат считывается через 0,7 мс.

Входное сопротивление АЦП не имеет никакого значения. Все зависит от схемотехники УВХ. Основной момент - заряд семплирующего конденсатора. Если в АВР есть повторитель перед ним, то тогда входное сопротивление определится им, а если нет, то постоянной времени заряда емкости хранения УВХ.
Применять электролит в фильтре нельзя, особенно алюминиевый. Он очень шумит на утечках. Особенно при разогреве. Немного лучше тантал, но и его я бы не ставил.
Про просчет времен. Вы не о том. Вопрос был о просчете возможных нестабильностей семплирующих интервалов и соотнесении спетра помех к боковым лепесткам с учетом АЧХ внешних цепей.
ЗЫ. Кстати. 1мс интервала семплирования даст боковые лепестки уже через 1 кГц от частоты среза. Полагаю, что уровень помех там еще очень высок. Для эффективной цифровой фильтрации нужно иметь более высокую частоту семплирования.
Или ставить внешний фильтр...

[Барсик]

лучший способ - запуск АЦП АППАРАТНО по переполнению таймера и БЕЗ прерываний от этого таймера.

А оно так и есть. Таймер работает в режиме CTC. Этот режим от переполнения отличается только лишь тем, что таймер считает не до 255, а до значения, записанного в регистр OCR0A, после чего перезапускается сам (аппаратно!). И в этот момент запускается АЦП (опять же, аппаратно!). А строго через 13 тактов, результат преобразования готов. А прерывания от таймера к запуску АЦП не имеют отношения. В них я не спеша считаю среднее (и в это время никаких изменений в массиве быть не может!) и формирую импульсы для вывода результата на частотомер. Так что с латентностью и обработкой всё в порядке.

Самый лучший вариант - это применение МК с внутрицикловым ДМА.

Ну, тут Богом дан ATtiny13...

Все зависит от схемотехники УВХ.

Надо будет, конечно, ещё покурить даташит, но что-то мне кажется, что нет там (ATtiny13) никакого УВХ... Самый лучший УВХ - большой-пребольшой конденсатор

Всё. Мне необходим тайм аут. Меня мыть ведут...

[КРАМ]

АЦП последовательных приближений В ПРИНЦИПЕ не может работать без УВХ.
На входе АЦП всегда стоит ключ и конденсатор семплирования. Это аналоговая память на время преобразования. Именно поэтому не имеет никакого значения когда данные будут готовы. Важно лишь когда они были защелкнуты. А это как раз момент запуска преобразования.

[ChipKiller]

АЦП последовательных приближений В ПРИНЦИПЕ не может работать без УВХ.

.. может, но частота входного сигнала не должна превышать нескольких Герц ( вспоминается "дремучий" кр572пв1 )

[КРАМ]

Нет, не может. Его можно включить без УВХ, которого в нем нет, но это еще не означает, что результат будет удовлетворительный. Давайте не будем путать частоту входного сигнала и СПЕКТР входного сигнала. Если бы в НАШЕМ случае, который мы тут обсуждали, СПЕКТР входного сигнала был равен единицам герц, то и не было бы никаких проблем с фильтрацией...

[ChipKiller]

....Его можно включить без УВХ, которого в нем нет, но это еще не означает, что результат будет удовлетворительный.

... кр572пв1 может сносно работать при оцифровке сигнала термопары и чего-либо подобного без всяких УВХ, для остальных вещей без УВХ , конечно, не уедешь ....

[КРАМ]

... кр572пв1 может сносно работать при оцифровке сигнала термопары и чего-либо подобного без всяких УВХ, для остальных вещей без УВХ , конечно, не уедешь ....

Вы полагаете???
Это смотря с какой точностью эту термопару цифровать...
И смотря где эта термопара расположена и как далеко от АЦП она расположена...
На столе многое как то там работает, а как дело дойдет до натуры, все нужно делать заново...
Так не проще сразу делать ПРАВИЛЬНО, чтобы потом не искать себе геморрой?

[bolek]

...Как мне представляется, ожидать чего-либо внутри прерывания - весьма хреновая практика.

Согласен, не самое элегантное решение. Однако Ваше решение с прерыванием от АЦП вряд ли лучше:
1. посчитайте фактическое время входа/выхода из прерывания от АЦП с учетом того, что компилятор будет толкать и восстанавливать из стека. Думаю, ожидание флажка готовности АЦП в прерывании в течение времени преобразования ("...13 тактов...") займет меньше времени.
2. проведение достаточно длительных вычислений в прерывании тем более хреновая практика.
Реальная, не учебная, программа - как всегда, результат компромиссов.

Мне кажется, один хрен. Всё равно придётся запретить прерывания на время обработки...

Я не столь подкован в фильтрации как КРАМ, однако, если обработка данных не успевает за темпом их поступления, значит что-то спроектировано неправильно:
- неправильно выбрано железо/тактовая частота
- неправильно выбраны параметры фильтрации
- неоптимизирована программа
и т.д.