DTMF декодер на цифровом интерфейсе, UART, I2C ... Опции

[semen_992]

Доброго времени...
Никак не могу найти ответ на свой вопрос сам
Есть ли декодеры дтмф на цифровых интерфейсах?
Например на UART RS-232 I2C и т.д.
Спасибо

[Dima_G]

В тему самостоятельной разработки DTMF декодера - мнение моего бывшего начальника
http://www.microchip.su/showpost.php?p=425...mp;postcount=41

Небольшое отступление
Однажды, на конференции DSPA, разговорились с инженером компании, работающей в "смежном" направлении (разрабатывающей телефонные станции, средства мониторинга и архивации), и речь коснулась DTMF детектора. Я с удивлением узнал, что они делали DTMF три месяца. Меня это развеселило, ибо незадолго перед этим я как раз сделал DTMF детектор за две-три недели. Притом, что у меня уже был большой опыт по разработке детекторов частотных сигнализаций R.1/R.2/R1.5 + АОН. Это была "неофициальная" работа, мне захотелось расширить функциональность модуля на будущее, может кому пригодится. Услышав про эти три недели мужики только хитро щурились и ухмылялись в усы.

Теперь, спустя 5 лет, моя очередь хитро щуриться и ухмылятся в отрощеные усы , слыша ваши мнения о "детекторе за месяц".

Дело в том, что разница между "работающим" детектором (даже отвечающим требованиям ITU-T, ETSI, отечественным отраслевым РД и т.п. стандартам/рекомендациям), и "хорошим" детектором, который не задумываясь можно применять в любом проекте - столь существенна, что сложность и, соответственно, время разработки возрастают на порядок.

В реальной жизни, сумма человеческих ресурсов, потраченных на исследования, моделирование, разработку, оптимизацию, создание тестового инструментария, собственно тестирование, анализы причин отказов и т.д. - у нас получилась приблизительно около 6 человеко/месяцев.
Некоторых частей проведенной работы можно было избежать, от других отказаться жертвуя функционалом, третьи просто не проводить, жертвуя производительностью. Но и в таком формате общая сложность разработки "хорошего" детектора не будет менее 3 человеко/месяцев.

Если вы работаете в области, где применимый в реальной жизни результат не так уж и важен (например "грантоедство"), то детектор за 1 месяц достаточно. Однако в коммерческом секторе реальный заказчик вам за такой продукт денег не заплатит, и с этим придется считаться. И разработчик может сколько угодно бить себя в грудь, взывать к авторитетам ITU-T, ANSI, ETSI, размахивать стопкой сертификатов соответствия - увы, на решение заказчика это мало повлияет, денег вы не увидите. В лучшем случае, можно договорится "по русски", т.е. "сейчас поставим, потом доделаем".

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


При разработке "правильного" DTMF детектора возникаем множество проблем. Вот примерный список (НЕсортированный по приоритету и сложности, и неполный)

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

2. Детекция сигнала DTMF (принятие решения)
Далеко не все возможные проблемы отражены в рекомендациях. Да и в самих документах есть широкий простор для неоднозначных толкований (см. May be valid). Некоторые вещи там даны на откуп разработчику и прямо не требуются (например детекция безъинтервального сигнала). К сожалению так и не дошли руки до применения нейронной сети для контроля всех параметров сигнала, а она там просто напрашивается. Принятие решения осложняется приведенным выше пунктом 1, из-за невозможности (либо сложности) корректно определить алгоритмом Герцеля длительность сигнала, энергию, точную частоту и т.п.


Вот эти первые два пункта часто и считают "детектором DTMF". Все проблемы здесь решаемы, они очевидны, либо проявляются при первых тестах. На грамотную реализацию этих пунктов вы как раз потратите 1-3 месяца в зависимости от опыта, предварительных заделов (например моделей алгоритмов), наличия хорошей тестовой платформы, применяемого языка и платформы.
Но, мы ведь не забыли, прибавить время разработки пакетных тестов к времени разработки самого детектора, правда? А время тестировщика (или своё собственное, если это одно лицо)? Есть вообще категория людей и стиль ведения проектов, когда делается за месяц, а потом три месяца тестируется.
Так что, боюсь, сюда еще требуется добавить около 1 человеко/месяца "тестового ресурса". Исполнители, т.е. инженеры-разработчики, стремясь подчеркнуть свой уровень, обычно оперируют только месяцем разработки, абсолютно не учитывая затрат на тестирование. Для этого, над ними поставлен руководитель, который всё это считать обязан.

А вот следующие пункты уже не столь очевидны. Однако отжирают приблизительно такое-же количество ресурсов.


3. Устойчивость к речи и (SIC!) к музыке
Наиболее сложная задача, практически не отражена в рекомендациях. Грамотно спроектированный детектор, даже без дополнительных блоков защиты, успешно проходит тесты на устойчивость к речи, хотя и без запаса прочности. Однако в современной станции требуется также и устойчивость к музыке, здесь задача еще более усложняется. Да и уровень "стандартной защиты" заказчика может не устроить.

Кстати, хочу отметить, что распространённый критерий устойчивости к речи, приводимый во всех статьях про детектор DTMF "для студентов" - анализ второй гармоники сигнальной частоты - на самом деле ОЧЕНЬ слабый, и в "серьёзном" алгоритме присутствует лишь "для галочки", т.к. перекрывается другими более надёжными и достоверными критериями.
Более того, "студенческий" алгоритм использующий ТОЛЬКО этот критерий - не пройдет даже Белл-овские тесты на устойчивость речи, не говоря уже о хоть скольнибудь серьёзной защиты от музыки.

4. Не соответствие стандартам
Увы, рекомендации и стандарты это очень нужные вещи, но в "хорошем" детекторе нужно считаться и с реальной жизнью. А конкретно:
- несоответствие линий связи и станционного оборудования по затуханию, взаимопроникновению каналов и (главное) по шумам
- несоответствие передатчиков DTMF сигнала по девиации, отношению уровней энергий сигнальных частот и т.п., связанные с низким качеством дешевого (обычно китайского) абонентского оборудования
- присутствие дополнительных сигналов в линии связи, не предусмотренных в DTMF рекомендациях, даже более того - прямо запрещенных. Пример - сигналы систем тарификации, сигналы сформированные системами с частотным разделением каналов, которые после "некачественной" фильтрации могут пролезть в наш участок спектра из-за аляйсинг эффекта.

И сигналы необходимо детектировать невзирая на эти "проблемы" реального мира, "плохого" оборудования заказчика и линий связи, еще помнящих голоса Троцкого и Бухарина. Но при этом другие параметры детектора (например устойчивость к речи) страдать не должны. А что существует "допустимое НЕсрабатывание на тоне", я, извините, даже и не слышал, для детектора даже единичное такое несрабатывание - незачёт.


В итоге, у нас, все проблемы были успешно разрешены. Попутно сделаны несколько дополнительных модулей, например "предварительный детектор", который с высокой вероятностью вычисляет появление DTMF сигнала по 5-7мс интервалам, для систем где необходимо блокировать голосовой тракт при передаче DTMF, а также для систем VoIP, NGN, GSM, где (как обсуждалось выше) информация от детектора передается в цифровом виде, а генерацию DTMF сигнала приемная сторона осуществляет самостоятельно.
Детектор отличается очень низким потреблением производительности, которое при подключении предварительного детектора "в тандеме" становится еще меньше. Это важный для нас показатель, т.к. сильно влияет на цену, а значит и конкурентноспособность (возможно, и с запасом, обрабатывать до тысячи каналов на DSP класса C64).
Самое главное достоинство - практически непробиваемость человеческой речью и очень высокая устойчивость к музыке. Голосовые тесты (популярные, открытые и коммерческие) детектор проходит с перекрытием допустимого минимума ошибочных детекций на порядки. Каких-то "официальных" тестов для музыки мне не встречалось, однако и там устойчивось, на мой взгляд, замечательная, по крайней мере она "достаточна".

Разработанный детектор применяется на нескольких DSP платформах. Сертифицирован в составе станционного оборудования в 10-ти странах мира и обслуживает, на данный момент, более 5 миллионов абонентов, в составе различных проектов на различном оборудовании.

С уважением,
МАШИН Андрей Павлович
Руководитель отдела разработки №4
Embedded software sector

P.S.
Если мне сейчас дать задание создать то-же самое с нуля, я потрачу примерно полтора-два месяца, и это с учетом того, что весь этот путь уже был пройден. И если человек без опыта берется делать нечто подобное за 1 месяц, оценив сложность работы лишь на основе "постановки задачи" то он, по моему мнению, либо гений (тогда мы были бы о нём наслышаны), либо глупец (тогда врятли мы о нём еще, что либо, услышим), либо просто не имеет опыта (что наиболее вероятно). В последнем случае - всё еще впереди, с опытом придет и умеренность в суждениях.