Обнаружение сигнала звонка с помощью фильтра нижних частот

Я создал 2 платы, которые общаются друг с другом, как система внутренней связи. На одном из них есть кнопка для отправки сигнала вызова другому. Сигнал вызова состоит из сигналов ШИМ, создаваемых микроконтроллером. Я хочу определить мелодию звонка MCU на стороне приемника.

Мой рингтон содержит 4 внешних импульса с периодом 300 мс:

внешний вид

200 мс этого сигнала содержат внутренние импульсы с периодом 1,25 мс:

введите описание изображения здесь

Итак, я хочу добавить схему фильтра на сторону приемника рингтона и преобразовать внешний сигнал в прямой ШИМ-сигнал. Ниже приведен пример вывода

введите описание изображения здесь:

До сих пор я пытался добавить фильтр нижних частот RC с обрезанием частоты внешнего сигнала (1/300 мс = 3,33 Гц ). Но я не мог даже приблизиться к выводу примера. Есть ли что-то, что я неправильно понимаю в концепции, поскольку я не очень разбираюсь в схемах?

Что касается моей схемы: я просто добавил к узлу последовательный резистор и параллельный конденсатор:

введите описание изображения здесь

Редактировать: я не хотел говорить о схеме, которая обрабатывает преобразование сигнала звуковой линии обратно в ШИМ, поскольку это не является предметом этого вопроса. Но я подозреваю, что мой RC-фильтр не работает должным образом из-за этой детали. Я попробовал решения в ответе, но они не сработали должным образом.

Ниже приведена схема моей стороны оптопары, линейный вход содержит аудиосигнал ШИМ. Аудиосигнал преобразуется обратно в ШИМ с помощью оптопары, после чего я получаю ШИМ-сигнал, который я дал на скриншотах выше. Но когда я добавляю RC-части к узлу OPTO_OUTPUT , сигнал ШИМ также изменяется в вольтах. Как вы думаете, я ошибся при добавлении частей RC?

введите описание изображения здесь

Вы подключаете входной сигнал к другому микроконтроллеру? Вас интересует программное решение, обладающее большей точностью и не требующее внешних компонентов?
@Damien Конечно, я хотел бы это услышать. Я пробую решения для ответов, но разные идеи тоже могут быть хорошими. К вашему сведению, я посылаю эти аудиосигналы линейным драйвером (TEA1062).

Ответы (4)

Если вы хотите, чтобы был получен сигнал 300 мс при фильтрации сигнала 1,25 мс, то вам нужно отфильтровать высокочастотный сигнал, а не другой. Это означает, что выбранная вами постоянная времени слишком велика и влияет на 300 мс. Высокочастотный сигнал имеет период 1,25 мс, поэтому выберите постоянную времени более чем в 10 раз больше, скажем, 25 мс, что также более чем в 10 раз меньше 300 мс. Вот быстрый тест в LTspice:

тест

V(a)показывает модулированный выход, V(b)показывает отфильтрованный выход с постоянной времени 22 мс и V(c)показывает восстановленный сигнал с небольшим гистерезисом 10 мВ для противодействия неидеальной фильтрации RC. Обратите внимание, что отфильтрованный сигнал имеет несколько более толстую трассу из-за остатка. Вы можете использовать фильтр Бесселя или Гаусса для получения лучших результатов, но это только усложнит задачу, и, кроме того, вам все равно потребуется восстановление сигнала, а это означает, что вы можете все упростить.


Если ваше Vccзначение равно 5 В, то сопротивление коллектора слишком велико, помните, что оптоизоляторы имеют сильную зависимость от Ic. Если это так, то попробуйте резистор 2 кОм, который будет использовать только Ic ~ 2,2 мА, и вы можете отказаться от дополнительного Rи разместить его Cнепосредственно на коллекторе (10 мкФ, адаптированное значение для постоянной времени). Тем не менее, это повысит Ic при Cразряде. В противном случае сделайте R=2k7и C=3u9(например). Не забывайте, что сигнал теперь инвертирован, поэтому я использовал инвертирующий компаратор с гистерезисом (триггер Шмитта). У меня нет TLPопто, поэтому я просто использовал все, что вы видите, адаптируйтесь к вашим потребностям. Меня сейчас нет дома, но вот попытка привести пример ( V(n004)это сигнал 300 мс):

бла

Я понимаю, что ваш ответ должен работать очень хорошо, но я еще не мог заставить его работать. Я предполагаю, что проблема может быть связана со схемой между MCU и линейным входом. Не могли бы вы посмотреть на мою правку?
@abdullahcinar Я обновил свой ответ, посмотрите, отвечает ли он вашему редактированию. Забыл добавить, но входное сопротивление ( R1) может быть слишком низким для ваших нужд, так как оно потребляет ~ 20 мА, но я сделал это только для того, чтобы коллектор не пропускал импульсы. Как я уже сказал, не стесняйтесь приспосабливаться к вашим потребностям.
Большое спасибо за подробный ответ, вы очень любезны! Я пытаюсь проверить это на своей установке, но мне немного сложно это сделать, когда у меня нет этой схемы на моей печатной плате. Но, как вы сказали, я думаю, что мне просто нужно будет пересчитать резисторы в соответствии с моим опто (может быть, и не нужно), и это должно работать. Добавлю результаты.
Это работает очень хорошо!
Использование фильтра нижних частот вводит задержку, которой не должно быть, и создает медленные нарастающие/спадающие фронты, для которых требуются триггеры Шмитта или компараторы для создания быстрых фронтов для цифровой логики. Не то чтобы что-то из вышеперечисленного должно быть проблемой (похоже, это не для ОП), но это может быть для кого-то, кто пытается применить эту идею к аналогичной ситуации.
@DmitryGrigoryev Правда, именно поэтому я сказал, что в этом случае, использует ли он простой RC или Бесселя/Гаусса/и т. д., ему все равно нужно обработать сигнал (comp/Schmitt/etc). RC можно было бы затянуть для меньшей задержки за счет большего гистерезиса.

В зависимости от того, насколько точно вы хотите обнаружить сигнал звонка, вам может потребоваться полосовая фильтрация принятого сигнала (при F = 800 Гц), а затем обнаружение его огибающей. В качестве альтернативы (и это может быть предпочтительнее) вы можете использовать перезапускаемую моностабильную схему, которая будет давать постоянный высокий выходной сигнал при активации «внутреннего сигнала». Учитывая ваш профиль звонка, этот сигнал будет исчезать примерно на 100 мс каждые 300 мс. Это определяет «огибающую» вашего сигнала вызова. Затем вам потребуется некоторая логика, чтобы определить, что форма конверта была приблизительно правильной.

Есть и другие вещи, которые нужно искать. На ум приходят микросхемы тонового декодера - LM567 много раз использовался в подобных приложениях. Или вы можете изменить свой основной сигнал 800 Гц, включив два тона, и использовать чип декодера DTMF.

Я бы использовал детектор конвертов:

введите описание изображения здесь

Если вы выберете постоянную времени RC где-то между несущей частотой и частотой сигнала, вы получите следующий результат:

введите описание изображения здесь

Вы можете добиться этого непосредственно с помощью микроконтроллера.

Это имеет некоторые преимущества:

  • Нет необходимости во внешних компонентах.
  • Нет времени отклика / задержки, вызванной фильтрацией.
  • Более высокая точность.

В принципе, я понимаю, что вы хотите знать рабочий цикл ШИМ-сигнала.

Сделать это с помощью микроконтроллера довольно просто, учитывая, что ваша частота относительно низкая, для UC это не должно быть проблемой.

Вам нужен только таймер и прерывание.

  • Подключите сигнал непосредственно к входу UC.
  • Настройте управляемое контактом прерывание как по нижнему, так и по верхнему фронту.
  • Установите таймер с известным периодом времени.

При вызове прерывания сначала считывается значение таймера, затем считывается состояние вывода (низкий или высокий).

При следующем прерывании сделайте то же самое, тогда вы узнаете, как долго контакт был высоким или низким, сделайте то же самое для другого фронта.

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

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


Соображения:

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

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

Мы также рассматриваем обнаружение сигнала с помощью программного обеспечения, но мы начнем с аппаратного решения. То, что вы сказали, является хорошим способом, я рассмотрю возможность использования этого подхода. Но это будет зависеть от того, насколько сложным будет наше программное обеспечение. Мы не хотим, чтобы он прерывал наши другие важные процедуры каждые 1,25 мс. Но, как я уже сказал, это хороший подход, который я рассмотрю, если мы решим использовать программную процедуру для обнаружения кольца. Спасибо!
@abdullahcinar Честно говоря, я бы этого избегал, если только в вашей системе уже нет быстрых прерываний. Вы не сможете отключить прерывания более чем на 1,25 мс, не рискуя получить ложные результаты от алгоритма обнаружения, и вам придется быть более осторожным при написании любого критичного ко времени кода.