Здравствуйте, форумчане!

Подскажите пожалуйста, как отфильтровать резкие изменения амплитуды.
Частота: 100кГц
Напряжение амплитуды, примерно: 2В
Сложность в том, что присутствует плавное изменение амплитуды.

В приложении форма сигнала и то чего я добиваюсь.
Дальнейшая обработка будет в МК, нужно поймать горбушку для вызова прерывания.

Побывал АМ демодулятор на диоде и ОУ, но в сигнале все равно присутствует пила и как отфильтровать, я уже всю голову сломал.
Хотя бы направьте в каком направлении копать!

Сообщение отредактировал Vasily_ - Oct 30 2017, 09:30

Куда такие частоты лупите - уж после детектора явно будет частота поменьше. Понятно? Т.е. после детектора частота будет поменьше, как я уже сказал и АЦП уже будет реально ее прихватить.

Plain - молодец! И все-то у него получается.
А если синхронный детектор сделать?

Обнаруживает спад в одной полуволне.

От делителя R16 R17 зависит.

Решение с пиковыми детекторами изящное и работоспособно при правильном выборе элементов в широком диапазоне частот и температур.
Совсем неясна любовь к использованию МК там, где 3 корпуса мелкосхем и сборка транзисторов решают задачу быстро, "дешево" и эффективно. Вот оно Использование МК ради использования МК!

Что именно неясно? Вам неясно почему решение вообще без каких либо мелкосхем и транзисторов лучше, чем их наличие? Я думал - это должно быть очевидно.
Неясно почему 1 чип (МК), лучше чем огород из 5 (МК+3логики+сборка)?

Везде есть свои плюсы и минусы, и каждый человек к ним имеет свой собственный набор весовых коэффициентов

Возможно вам проще реализовать программно, но вы алгоритм еще не выложили, а Plain по-быстрому собрал и выложил готовую схему. Кому-то проще схему сделать, потому что время жмет, а программист не очень высокой квалификации и долго будет реализовывать, а кому-то надо 100к шт. выпустить - ему выгоднее привлечь стороннего.
С другой стороны, всё-равно надо плату/комплектацию заказывать-монтировать-проверять и что 1 корпус, что 10 - не будет играть большой роли(тем более у ТС на плате уже не 1 корпус). Вот когда будет приличная серия - тогда да, можно и переделать на программную реализацию. И т.д. и т.п.

Все просто,
1 - цена. Эта "рассыпуха" стоит сущие копейки.
2 - надежность. Понятие зависание программы для "рассыпухи" отсутствует.
3 - не нужно монструозного МК, который тупо будет гонять данные с АЦП.

Готовая - это ещё не говорит о том, что она будет работать так, как надо ТС. И даже не факт, что если сейчас, испытанная на каком-то сигнале эта схема будет работать достаточно удовлетворительно, то завтра, когда что-то немного изменится, оно так же будет работать.
А один из главных плюсов программной реализации - гибкость. Алгоритм в будущем нетрудно переделать, доработать под новые исходные данные. А вот схему...
Да и программная реализация там должна быть несложная.
И раздел здесь - "для начинающих", а это значит для людей развивающихся, а развиваться можно только пытаясь разобраться в чём-то новом, а не тупо повторяя чужое готовое решение.

Хороший алгоритм нахождения максимума (пусть даже у нас чистая синусоида) по десятку отсчетов на период можете предложить? Чтобы еще за период справлялся...

Сразу - нет. Надо сперва в Матлабе пробовать.
Но я бы сначала попробовал выпрямить сигнал и прогнать его через простой ФНЧ с децимацией (может даже предварительной, чтобы уменьшить загрузку CPU).
Как видно - у автора длительность искомых событий примерно равна 4 периодам, так что можно сделать децимацию как минимум в 4 раза.
DSP уровня TI-шного C55xx с такой задачей справится без вопросов. А на Cortex-M надо будет писать очень оптимально и наверное на асме (обработчик сэмплов).

Я тоже размышляю на тему перехода в МК, уж больно меня пугает такое количество аналоговой рассыпухи.
Сейчас пробую реализацию на стареньком ARM7TDMI. Прерывания с ADC для уменьшения количества циклов выношу в RAM. Частота известна и стабильна, нужно только при инициализации поймать верх горбушки, а далее измерять с заданной частотой и вносить корректировки.
Предложенная Plain’ом схема мне очень нравится, если с МК прогорит, то вернусь к ней.
* Жалко всего две руки и одна голова, а так бы и схему собирал и кодил одновременно

Афтору надо 16 каналов завести в проц - это только дсп и то не всякий справится , а с ним сложностей в изучении вагон. Если был бы один-два канала да, намного проще копеечным STM32F030 обойтись, который дешевле выбранной атмеги, имеет шустрое ацп и достаточно ресурсов для данной задачи без всяких асмов.

Компаратором (внешним или внутренним) находить переходы сигнала через 0. По срабатыванию запускать таймер или АЦП. Таймером или временем выборки подобрать, чтобы АЦП срабатывал на вершинах синусоид. По некоему количеству выборок находить скользящее среднее. Количество выборок должно быть таким, чтобы отслеживать плавные изменения сигнала. По среднему вычислять порог, насколько ниже ловить. Сравнивая выборку с порогом, принимать решение. Гуляем!

Если хотите, чтобы получилось, то имхо - процессор надо всё-таки помощнее - хотя бы Cortex-M с частотой явно больше 100МГц.
И писать надо оптимально. А это уж явно не вытягивать сэмплы программно из АЦП - тут у вас всё быстродействие CPU только на это и уйдёт.
Явно нужно DMA+ADC и подумать над оптимальным расположением кода/данных в памяти.


А где автор говорит про 16 каналов? Вроде в исходном задании только 1 канал....


Ну да - и по малейшему шуму, вся работа идёт лесом.

PS: Да - и начинать надо не с АЦП и программирования, а с создания модели в Матлабе. Чтобы хоть примерно оценить требуемые для решения задачи ресурсы.