Самый низкий тон имеет частоту 697 Hz, самый высокий - 1633 Hz. Как видим, все вполне вписывается в полосу пропускания телефонного канала. Однако кажущаяся простота DTMF несколько обманчива. Давайте пройдем по тракту от момента нажатия на кнопку на передатчике до декодированного сигнала в приемнике.

Как следует из названия и размерности матрицы, каждый символ (будем в дальнеейшем называть его 'код' , если придется) описывается уникальной комбинацией 2 частот. Для полноты информации приведем эти частоты здесь: Строки: 697, 770, 852, 941 Hz. Столбцы: 1209, 1336, 1477, 1633 Hz. Первый же взгляд на эту сетку приводит нас к первому открытию: частоты не кратны! Значит, ни одна из частот нижней группы не будет ошибочно декодирована как частота верхней группы в случае если звуковой тракт передачи нелинеен и генерирует гармоники. Посмотрим еще раз на сетку частот- мда, цифры какие кривые, и разнос небольшой. Генерировать такую лабуду аналоговыми методами наверное неинтересно. Цифровыми методами проще. Что и делается с помощью либо цифровых генераторов читающих прошитую заранее таблицу, либо синтезатором частоты. Но цифра цифре рознь и даже цифра имеет право на допуск- питание там, температура, магнитные поля, искажения в тракте и прочее, типа made in China. Веселые ребята из ITU (International Telecommunication Union) посовещались и решили что всякое в жизни бывает и что отклонение частоты тона (Frequency tolerance) в 1.5% в каждую сторону от центра обязано быть декодировано как valid tone в приемнике. А отклонение больше чем 3.5% обязано быть им отвергнуто. В промежутке между этими процентами точность декодера оставляется на мастерство разработчика и не регламентируется.

Поехали дальше. Видимо, поскольку назначение речевого тракта изначально было все же передача речи, а не музыкальных тонов, его АЧХ и оптимизирована под речь. Также эта АЧХ имеет спад в сторону высоких частот. И тогда те же ребята из ITU сказали разработчикам- мужики, а вы кодируйте амплитуду тонов нижней группы на 1...2 децибел ниже чем верхней, тогда за счет завала верхних частот в тракте уровни примерно выровняются. И назовем это не 'Лезгинка', а 'Twist'.

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

Когда сигнал достигает приемника, проходит как и любой аудио сигнал через звуковой тракт (декодирование осуществляется на звуковой частоте, не на ПЧ скажем). Поскольку каждый производитель придает звуковому тракту такую АЧХ какую он считает нужным (за исключением может отдельных промышленных жестких стандартов), ITU сказал: "ну вы , блин, даете.." Неравномерность в тракте такая что об 1..2 Db twist-a уже не приходится и говорить. "Ну да ладно", -сказали уже не очень веселые ребята из ITU,- "если уж все так любят кривые АЧХ, вот вам наши рекомендации для декодеров- нижний тон не должен быть меньше чем на 4 Db ниже чем верхний. И будем продолжать называть такой перекос 'Twist'. А если верхний слабее нижнего, то (черт с вами) лимит увеличиваем до 8 Db, и будем такой перекос именовать 'Reverse Twist' " (cм. приаттаченную картинку). В этих пределах декодер обязан распознавать DTMF коды. А чтоб вам жизнь медом не казалась, вот вам другие ограничения:

• распознавать код как valid только если оба тона начинаются не позже чем 5ms друг от друга;
• распознавать код как valid только если его длительность превышает 40ms;
• будучи распознанным, прерывания кода в 10ms не должны приводить к повторному распознаванию;
• будучи распознанным, прерывания кода в 40ms обязаны приводить к повторному распознаванию;
• будучи распознанным и после разбитым прерываниями на куски длительностью менее 23ms, распознать как конец кода.

Почесали репу мужики разработчики декодеров и стали думать об алгоритмах, как выполнить эти условия да еще при этом частотный анализ провести. Пошли на поклон к Батьке Фурье как обычно. Батька Фурье (см. портрет) сказал, что алгоритма ему не жалко, только ленивый его не применяет через N лет после его, Батькой, изобретения. Но как они собираются выполнять противоречивые требования к количеству сэмплов, если временнЫе ограничения требуют уменьшения количества сэмплов в его, Батькином, окне, а частотные ограничения требуют их увеличения? Поскольку в чистом виде алгоритм на подходил, вышел один мужик и сказал - "А я каждый фильтр буду квантовать отдельно, то есть сделаю 8 фильров и буду подгонять параметры для каждого фильтра в зависимости от требуемой полосы. И название возьму готовое - Goertzel algorithm". Вышел второй мужик и сказал: "А я буду квантовать нелинейно, то бишь изменять временнОй период между сэмплами. Таким образом я убью 8 зайцев (то бишь тонов) сразу одним циклом. И назову это 'Modified Goertzel algorithm'".
Третий послушал и сказал "Хороши 2 идеи, но вы забыли про гармоники и шумы. Я же применю обе ваши идеи и проанализирую как полезный сигнал, так и шумы. А как назвать пока не знаю". Четвертый мужик сказал - "Нет, Батьке конечно спасибо, но мы пойдем другим путем, без накопления отсчетов. Будем FIR (Finite Impulse Response) фильтр строить. Спасибо русскому мужику с чисто русской фамилией Ремез, он знает как построить нужный фильтр с минимальной стоимостью машинного времени." Потом были еще и пятый и шестой и N-ные мужики, но голос их потонул в громком споре первых четырех отстаивающих свои идеи. Наконец все разошлись и прибежали уже знакомые ребята из ITU злорадно крича вдогонку: "Мужики, мы забыли вам сказать: декодер обязан работать до минус 25Db, и выдерживать соотношение сигнал\шум минимум в 12Db"...

Не многим из когорты повезло. Как черт из табакерки стали выскакивать ложные срабатывания декодеров во время речевого сигнала. С шумом оказалось бороться проще, потому как спектр его размазан и мощность составляющих мала. Средняя же речь оказалась наполнена соловьиным свистом, отвечающим даже наложенным ITU временнЫм ограничениям. Простецкая задачка вычисления спектральных составляющих постепенно обрастала алгоритмами принятия решения, среди которых Батька Фурье вообще оказался задвинут на задний план. В учет пошли соотношения энергии выборки (окна) и энергии DTMF тонов, энергии тонов относительно друг друга, куча сравнений с пороговыми уровнями, попытки определения пауза\сигнал, и даже (прости Господи) Евклидова метрика. Кому-то надоело наконец подгонять бесконечные итерации под дядек из ITU, и начихав на них и решив - да и пусть не будет декодер ITU compliant, зато кошмары по ночам сниться не будут, - сузили полосы фильтров, ослабили допуск на шумы, уменьшили Frequency Tolerance и Twist, пристроили юзер интерфейс для любителей поэкспериментировать, и стали искать кому бы сосватать свой декодер.

Так в некоторых интернет приложениях появилась DTMF фича.

Иногда слышимый 'пилот сигнал' - это, видимо, CTCSS tone, который выполняет другую функцию. О нем мы споем песню в следующий раз..

Появление одного тона на фоне другого, даже если оба попадают в нижнюю и верхнюю DTMF группы, не должно опознаваться декодером, т.к. настоящие оба тона толжны появляться одновременно с интервалом не более 5ms друг от друга. Иначе это должно расцениваться как помеха. Однако присутствие СTCSS тона не должно влиять на распознавание. По идее он должен режектироваться до подачи сигнала на DTMF декодер, как к примеру, режектируют dial tone в телефонах.