[zltigo 1]

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

Простите :) А чем DSP по Вашему отличается от решений "аппаратых декодеров" масса которых сделано с лохматых 70x годах? Ну а DSP, уж поверьте мне старому телефонисту, именно и работают в самых, что ни на есть профессиональных условиях на стороне телефонной станции. В старые времена групповые DTMF приемники стояли, причем на самых, что ни наесть допотопных DSP (уже забыл, как назывался тот TMS, который клонировали в 80x в Союзе под именем "Рената", и который, не для DTMF, правда, а для "импульсного челнока" я в те времена и прикручивал вместо жутких гибридных аналоговых фильтов ). Те TMS ныне большинство восьмибитовиков банально счет счет мегагерцев за пояс заткнут. Ну а ныне со всем DTMF этим справляются походя, между всем прочим и индивидуальные DSP-шки в SLIC-ах. И никаких "для себя" на коленке - для наколенного творчества это как раз все эти "аппаратные декодеры". Ну а "динамический диапазон" он в цифровой телефонии это 8bit, правда после компрессора. Но поскольку уровни передачи DTMF c телефона вполне сравним 0dB (-3...6dB), то на стороне ATC это более, чем приличный уровень, даже на длиииинной аналоговой линии. Ну а на цифровых линиях о затуханиях вообще говорить не приходится.

[CADiLO 12]

Отличие простое - В аппаратном декодере набор из "железных" фильтров плюс хорошее АРУ. В DSP считаем програмно.

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

Если все так прекрасно, почему в мини АТС Samsung (1200 номеров) 2008 года выпуска (модель могу заехать посмотреть у знакомых) стоят платы с коммутируемыми MT8870? 2 платы по 16 декодеров и место еще под две. Хотя сама станция управляется промышленным PC + мотороловский DSP.

MFC ( если не ошибаюсь там R2) сделали на DSP, а на DTMF поставили аппаратные декодеры. Не знаете почему ?

[zltigo 1]

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

Спасибо, я за 25 лет в телефонии никогда не слышал слов "сертификация" и "методика". Теперь услышал :).

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

Знаю - Cамсунг делает бытовку, как умеет, даже если он лезет в офисную телефонию. Кроме того, аналоговые станции вымерли уже давно, даже если Cамсунг и выпускает это барахло для офисных нужд. Я не занимаюсь аналоговыми коммутаторами и соответственно приемниками с аналоговыми входами с 1988 года. Аналог, если он есть, кончается

на абонетском комплекте. Я (про Siemes, Alkatel, Nokia и прочих умолчу, дабы избежать обвинений в мании величия ) что-то делаю не так?

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

Господи, ну что такое "железные" фильтры? Если поискать, то могу найти Вам фото "железных" - натуральные гибридки в "железных" корпусах - море операционников с точной обвеской. Все Ваши одночиповые DTMF приемники это уже цифровая обработка, причем зачастую более, чем скромная ввиду ограниченных ресурсов.

[CADiLO 12]

>>> Спасибо, я за 25 лет в телефонии никогда не слышал слов "сертификация" и "методика". Теперь услышал

 

Даже не буду воспринимать как юмор. Эксплуатационщики может и не слышали, а мы разрабатывали коммутацию. И для системы "Алтай", и выносы 200 - 3000 номеров, и стыки E1/T1 с разными станциями. Сдать в эксплуатацию оборудование не пройдя испытания и сертификацию - нереально. Методика всех испытаний это нескоько толстых папок.

 

>>> Все Ваши одночиповые DTMF приемники это уже цифровая обработка

 

Например какие???? Тот же народный 8870 - аналоговый, современные Zarlink, тоже DSP внутри не наблюдается.....

[blackfin 22]

Отличие простое - В аппаратном декодере набор из "железных" фильтров плюс хорошее АРУ. В DSP считаем програмно.

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

Если все так прекрасно, почему в мини АТС Samsung (1200 номеров) 2008 года выпуска (модель могу заехать посмотреть у знакомых) стоят платы с коммутируемыми MT8870? 2 платы по 16 декодеров и место еще под две. Хотя сама станция управляется промышленным PC + мотороловский DSP.

MFC ( если не ошибаюсь там R2) сделали на DSP, а на DTMF поставили аппаратные декодеры. Не знаете почему ?

Да, действительно, почему? Среднестатистический DSP для декодирования DTMF требует всего 0.891 MIPS (Average), т.е. DSP ценою в 7.2$ в связке с набором дешевых АЦП заменяет ~300 аппаратных декодеров 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.

[Aner 4]

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

[blackfin 22]

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

А в пересчете на "2 платы по 16 декодеров"?

[zltigo 1]

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

Зря улыбку в цитате обрезали. Это именно юмор человека все эти годы занимающегося цифровыми системами связи. И естественно почти все знающего о стандартах их соблюдении и особенно измерении -

многие годы именно разработка тестового оборудования была моей работой.

Привет многолетним дотягивателям древней аналоговой радиосистемы "Алтай" до сколь-нибудь рабочего рабочего состояния!

 

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

В цифровых станциях и набор дешевых АЦП не нужен, ввиду отсутствия аналогового сигнала после абонетского комплекта. А в мелкокоробочно-штучном варианте, АЦП, как грязи на борту практически любого микроконтроллера. MIPS-ов нынешними микроконтроллерам тоже хватает. Что собственно и было сразу сказано. Имеющий уши, да услышит.

[Harbinger 10]

Если предположить, что устройство, содержащее декодер, находится не на одной плате с МК (и вообще заранее неизвестно, куда оно будет подключено), то декодер с последовательным интерфейсом смотрится вполне логично - линии экономятся, а требования к разводке SPI или I2C несколько проще, чем для аудио. Аппаратный в этом случае выигрывает перед программным на "мелком" микроконтроллере - исключается работа программиста (пусть и простая) и технологическая операция программирования МК.

[zltigo 1]

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

Всяких "если", может быть вагон и маленькая тележка и "работа программиста" нельзя сказать, что любой справится, речь просто идет о том, что по нынешними временам в качестве базового варианта, с которого надо начинать рассматривать и к чему стремиться, это вариант размещения DTMF приемников "в уголке" основного контроллера. Дальше конечно можно всяких если (если я только PIC14 знаю а другого и знать не хочу, если я год писал только пересылку двух байта в UART, если.... ) добавлять сколько угодно.

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

[Harbinger 10]

GSM ещё цветочки :)... через CDMA вообще не гонится. Обычно проходит кусочек, миллисекунд 10-20.

[alx125 0]

И при всем что здесь было сказано, остается открытым вопрос - почему ни один производитель не реализовал в своих GSM приемниках встроенный DTMF-декодер? Наверное для этого существуют важные причины!

В частности, на форуме Nokia (forum.nokia.com) этот вопрос тоже постоянно обсуждается для Symbian.

:rolleyes:

[DimaG 0]

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

[sobr 0]

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

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

Что касается цитаты МАШИНА Андрея Павловича привенной выше, я не могу не согласиться, НО господа, "народный 8870" никак не соответствует понятию "хороший детектор".

Года два назад я делал "декодер за месяц" на dsPIC. Он работал стабильней, чем "народный 8870". Теперь в этом нет необходимости.

Но... тема то совсем о другом.

[alx125 0]

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

 

Мне известно это. Но их так мало, что я посчитал правильным об этом даже не упоминать в постановке вопроса!