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

Вы ищите м/с DTMF receiver обязательно с последовательным интерфейсом? Чем параллельный не угодил?

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

Если со стороны передачи это делается командой - то

Схема с центральным коммутатором по их словам давно устарела и оператором используется только в малых населенных пунктах.

Ну а с просто DTMF почти любой микроконтроллер способен справиться.

по этому и внешний ставят.

Да и у контроллера ресурс отымать не стоит.

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

Проще...

то даже DSP по динамическому диапазону не прокатит - только аппаратные декодеры.

Достаточно обратиться в любую контору проводящую сертификацию и попросить методику.

Не знаете почему ?

В аппаратном декодере набор из "железных" фильтров

Отличие простое - В аппаратном декодере набор из "железных" фильтров плюс хорошее АРУ. В DSP считаем програмно.
Кстати к челноку меньше требования предъявляются чем к DTMF. Достаточно обратиться в любую контору проводящую сертификацию и попросить методику.
Если все так прекрасно, почему в мини АТС Samsung (1200 номеров) 2008 года выпуска (модель могу заехать посмотреть у знакомых) стоят платы с коммутируемыми MT8870? 2 платы по 16 декодеров и место еще под две. Хотя сама станция управляется промышленным PC + мотороловский DSP.
MFC ( если не ошибаюсь там R2) сделали на DSP, а на DTMF поставили аппаратные декодеры. Не знаете почему ?

Compliance Testing : Compliant with Bellcore GR-506-CORE, Bellcore TR-TSY-000181, ETSI 300-001, ETSI 201-235, ITU Q.24, Table A-1, AT&T, ITU Q.24, Table A-1, NTT specifications.

вот-вот, например 8870 меньше бакса.

Даже не буду воспринимать как юмор.

набором дешевых АЦП заменяет

Если предположитью..

Небольшое отступление
Однажды, на конференции 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 месяц, оценив сложность работы лишь на основе "постановки задачи" то он, по моему мнению, либо гений (тогда мы были бы о нём наслышаны), либо глупец (тогда врятли мы о нём еще, что либо, услышим), либо просто не имеет опыта (что наиболее вероятно). В последнем случае - всё еще впереди, с опытом придет и умеренность в суждениях.

остается открытым вопрос - почему ни один производитель не реализовал в своих GSM приемниках встроенный DTMF-декодер?

Вопрос поставлен не верно... Правильная постановка: Почему Вы не знаете о GSM модулях способных детектировать DTMF? А они есть... Например WMP100. DTMF - одна из причин по которой я использую этот модуль.

Тогда и о PIC18 еще не слышали, не то что о 24-х

Ну или если есть время и деньги - .... читайте написаное выше. Все зависит только от задачи.

А этого реликта хватает для 90% задач.

>>>Это совершенно не имеет значения.
Правда? Ну тогда сделайте мне распознавалку например на PIC16F76.

1. Не отправлять DTMF в аудиоканал - тогда точно будет Ваша "проблема GSM кодека " - называйте как хотите.

только не на модуль работает...

Смысл простой - при обнаружении DTMF кода на абонентской аналоговой линии

, или просто - при необхомости передать "рапознаваемый" DTMF, в сеть должны быть отправлены заранее подготовленные пакеты голосового кодека

НЕ с мобильника на "охранку" позвонить, а, например, с обычного проводного, да путь и с ISDN, телефона...

Еще один "прекрасный совет" - не использовать GSM вообще . Я все правильно понял?

Можно спорить до бесконечности, но програмный DTMF декодер не достигнет качества аппаратного за те же деньги.

Далее - если я позвоню с обычного телефона на сотовый - то мой DTMF от обычного телефона распознает коммутатор сотового оператора и точно так же даст команду последней соте сгенерить сигнал. Или Вы с таким не сталкивались?

и вообще не вижу проблемы, только что позвонил. и через динамик телефона в микрофон прослушки все прекрасно схавал 88L70

Я и спорить продолжать не буду, просто скажу в последний раз, что это полный бред. Как минимум матаппарат для синтеза ЛЮБЫХ фильтов один и тот-же, а ресурсов в цифре несравненно больше. Но тем, кто не смог синтезировать приемник на DSP и забубенил "Пришлось конвертнуть цифру в аналог и поставить декодеры.", это объяснять, как я вижу, уже бесполезно .

ИМХО единственное преимущество аппаратных декодером наличее АРУ. Если большой динамический диапазон не нужен, а в абсолютном большинстве случаев он не нужен, то преимущество за программным детектированием. Во всяком случае задача детектирования DTMF прошедшего через аудиотракт на 8870 не решаема абсолютно, программно еще можно как-то побороться. А эта задача намного актуальней(актуальная задача это задача за решение которой готовы платить деньги ) чем прием DTMF пришедшего фиг знает откуда.

Так почему же она (задача) еще не решена даже для таких брендов как Nokia и т.п.? У них то ресурсов (денег, мозгов и т.п. хватает). Ведь это было бы их небольшое но конкурентное преимущество.

Например, цифрового эквивалента аналогового фильтра на переключающихся конденсаторах я не знаю.

Потому, что сама эта задача абсурдна с точки зрения идеологии GSM.

Но почему-то 99% всех GSM модулей имеют только команды для генерации DTMF, но не декодирования!

Так почему же она (задача) еще не решена даже для таких брендов как Nokia и т.п.? У них то ресурсов (денег, мозгов и т.п. хватает). Ведь это было бы их небольшое но конкурентное преимущество.

Но почему-то 99% всех GSM модулей имеют только команды для генерации DTMF, но не декодирования!
Скорее всего не возможно обеспечить 100% работоспособность этого DTMF-декодера во всем спектре применений и условий эксплуатации GSM-модулей. А это уже не их (больших фирм) подход...

Потому, что сама эта задача абсурдна с точки зрения идеологии GSM.

Ведь, что такое GSM? Это передача АНАЛОГОВОЙ информации в ЦИФРОВОМ виде. А что такое DTMF? Это передача ЦИФРОВОЙ информации в АНАЛОГОВОМ виде. В итоге, получаем довольно абсурдную схему передачи с использованием DTMF:

ЦИФРА->DTMF->АНАЛОГ->GSM(кодер)->ЦИФРА->ЦИФРОВОЙ_КАНАЛ_ПЕРЕДАЧИ->ЦИФРА->GSM(декодер)->АНАЛОГ->DTMF->ЦИФРА.

Сравните со схемой передачи без использования DTMF:

ЦИФРА->GSM(модем)->ЦИФРА->ЦИФРОВОЙ_КАНАЛ_ПЕРЕДАЧИ->ЦИФРА->GSM(модем)->ЦИФРА.