Сделал всё сам с нуля по объяснениям vdimas (кстати, кому лень — код Шахтёра замечательно работает). Всю целочисленную арифметику выкинул.
Единственная проблема с которой столкнулся это слишком большая избирательность по частоте. То есть даже скажем 703 вместо 697 уже не распознавалось. Поигрался с НЧ фильтром, вроде помогло, но с другой стороны теперь разрыв на 10мс, формально разрывом не являющийся, надо обрабатывать программно. Учитывая, что последовательные нажатия одной и той же цифры надо рассматривать как одно (то есть постобработка всё равно имеется) это не проблема. Думаю в конечном итоге неплохо будет сделать функцию автонастройки под телефон, чтобы все коэффициенты были на грани срабатывания.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Шахтер, Вы писали:
V>Пара комментариев:
Ш>>Иными словами, данная составляющая сигнала есть линейнаю комбинация двух сигналов sin(2*Pi*(F1/Fd)*k) и cos(2*Pi*(F1/Fd)*k).
V>Линейная комбинация — это суть векторная сумма. Зря ты убрал из формул sin(phy1) и cos(phy1) — стало непонятно слушателям.
Линейной комбинацией двух векторов a и b называют вектор x*a+y*b, где x и y скаляры.
Ш>>Т.е. фактически, нам нужно просто спроектировать полученный сигнал на две ортогональные плоскости плоскости и вычислить энергию проекций.
V>Роме: проекция вычисляется путем свертки с единичным сигналом.
Не понял этой фразы. Причем здесь свертка?
Ш>>Что собственно мы и делаем. Дальше проверяем, что мощность на одной из пар стандартных частот превосходит порог.
V>Угу, у меня примерно тоже самое http://www.rsdn.ru/Forum/Message.aspx?mid=1563751&only=1
Насколько я понял, ты используешь меандр вместо синуса. Так раньше делали на старых дохлых процах, на которых умножение было слишком дорогим удовольствием. Сейчас экономить на этом не имеет смысла.
Использовать меандр можно, предварительно отфильтровав сигнал, чтобы убрать высшие гармоники от искомых частот.
Тут возникает одна проблемка -- по-хорошему, энергию срезанной части тоже надо учитыват при рассчетах.
V>(правда, я вычисления синусов/косинусов не буферировал, т.к. в оригинальном варианте у меня вообще умножение на прямоугольные сигналы сдвинутые на 90 градусов).
V>Отличие от твоего варианта в том, что твой вариант реально требует довольно-таки длинной последовательности, иначе подобный детектор будет реагировать на входные частоты с большим отклонением, чем 3% в стандарте.
Это всё регулируется выбором порога срабатывания.
V>К тому же, буфер каждый раз пересчитывается по кругу.
Не понял, что ты имеешь ввиду?
V>В общем, предлагаю вместо этого использовать "бесконечный" сумматор, выполненный в виде фильтра НЧ с частотой среза, обратной скорости реакции. Сама характеристика фильтра НЧ уже является некоей оконной ф-ией, где последние отсчеты будут больше влиять на результат, чем дальние. А в твоем варианте с кольцевым буфером "давние" отсчеты так же влияют на результат, как и самые последние. (Хотя, надо погонять оба варианта... Подход у них абсолютно одинаковый...)
Ну так мы обсчитываем кусок сигнала -- с чего это старые отсчеты должны отличаться от новых?
Здравствуйте, Шахтер, Вы писали:
V>>Линейная комбинация — это суть векторная сумма. Зря ты убрал из формул sin(phy1) и cos(phy1) — стало непонятно слушателям.
Ш>Линейной комбинацией двух векторов a и b называют вектор x*a+y*b, где x и y скаляры.
ok, ключевое слово было "векторная" (сумма векторная)
Ш>>>Т.е. фактически, нам нужно просто спроектировать полученный сигнал на две ортогональные плоскости плоскости и вычислить энергию проекций.
V>>Роме: проекция вычисляется путем свертки с единичным сигналом.
Ш>Не понял этой фразы. Причем здесь свертка?
Математически то, как ты ищешь проекции — это оно и есть. Свертка с некоей образцовой частотой.
Ш>Насколько я понял, ты используешь меандр вместо синуса.
Нет, там в коде у меня именно 2 синусоиды, это я устно делаю замечания, что для DTMF даже прямоугольного образцового сигнала достаточно.
Ш>Так раньше делали на старых дохлых процах, на которых умножение было слишком дорогим удовольствием. Сейчас экономить на этом не имеет смысла.
Согласен, речь шла не столько об умножении, сколько о вычислении sin и cos, которые не требовались в случае меандра, хотя, это тоже не проблема.
Ш>Использовать меандр можно, предварительно отфильтровав сигнал, чтобы убрать высшие гармоники от искомых частот. Ш>Тут возникает одна проблемка -- по-хорошему, энергию срезанной части тоже надо учитыват при рассчетах.
Ты абсолютно прав. При сравнении нашего порога с общей энергией сигнала, последняя вычисляется от сигнала ДО фильтрации.
V>>Отличие от твоего варианта в том, что твой вариант реально требует довольно-таки длинной последовательности, иначе подобный детектор будет реагировать на входные частоты с большим отклонением, чем 3% в стандарте.
Ш>Это всё регулируется выбором порога срабатывания.
V>>К тому же, буфер каждый раз пересчитывается по кругу.
Ш>Не понял, что ты имеешь ввиду?
Ну, у тебя вроде "окно" движется (буфер), и ты каждый раз производишь вычисления над всем буфером. В моем варианте я произвожу вычисления только над текущим сэмплом.
V>>В общем, предлагаю вместо этого использовать "бесконечный" сумматор, выполненный в виде фильтра НЧ с частотой среза, обратной скорости реакции. Сама характеристика фильтра НЧ уже является некоей оконной ф-ией, где последние отсчеты будут больше влиять на результат, чем дальние. А в твоем варианте с кольцевым буфером "давние" отсчеты так же влияют на результат, как и самые последние. (Хотя, надо погонять оба варианта... Подход у них абсолютно одинаковый...)
Ш>Ну так мы обсчитываем кусок сигнала -- с чего это старые отсчеты должны отличаться от новых?
Тут речь о помехоустойчивости. Кратковременные мощные помехи на частотах близких к обнаруживаемым искажают "картинку" все время, пока они находятся в твоем окне (отсчеты помехи находятся в буфере), и даже возможны ложные срабатывания. Это действительно так — поэкспериментируй. В моем варианте ситуация сглаживается фильтром НЧ, и подобные по характеру помехи не приводят к срабатыванию детектора.
Здравствуйте, adontz, Вы писали:
A>Отчитываюсь:
A>Сделал всё сам с нуля по объяснениям vdimas (кстати, кому лень — код Шахтёра замечательно работает). Всю целочисленную арифметику выкинул. A>Единственная проблема с которой столкнулся это слишком большая избирательность по частоте. То есть даже скажем 703 вместо 697 уже не распознавалось.
Хм, мене 1%.. понятно... У меня использовался прямоугольный образцовый сигнал, избирательность была похуже, как раз по стандарту.
A>Поигрался с НЧ фильтром, вроде помогло, но с другой стороны теперь разрыв на 10мс, формально разрывом не являющийся, надо обрабатывать программно.
Не надо ничего обрабатывать программно. У тебя фильтры НЧ стоят на вычислении повернутых на 90 градусов проекций. Да, действительно, этот фильтр НЧ в таком случае надо сделать более быстрым. Но ведь ты можешь пропустить через допольнительный 20мс фильтр НЧ саму энергию, т.е. значения sqrt(f1*f1 + f1'*f1').
Тут важный момент в том, что весьма желательно, чтобы АЧХ фильтра, выявляющая общую энергию сигнала, была близка к АЧХ фильтра детектора конкретной частоты.
A>Учитывая, что последовательные нажатия одной и той же цифры надо рассматривать как одно (то есть постобработка всё равно имеется) это не проблема. Думаю в конечном итоге неплохо будет сделать функцию автонастройки под телефон, чтобы все коэффициенты были на грани срабатывания.
ИМХО, лучше все-таки привести систему в соответствии стандарту, и при этом добиться работоспособности даже при большом уровне шумов (например, громко говорить в трубку и при этом давить на клавиши — система должна срабатывать)
Чем ниже частота среза фильтра НЧ в этой системе, т.е. чем выше избирательность, тем выше помехоустойчивость. Надо вообще-то поискать, может быть последние стандарты более жесткие. Потому как мне трудно представить себе современную трубку, у которой погрешность излучения DTMF была бы 3%, реально у них погрешности — доли процента.
Здравствуйте, vdimas, Вы писали:
V>Хм, мене 1%.. понятно... У меня использовался прямоугольный образцовый сигнал, избирательность была похуже, как раз по стандарту.
Да мне просто ленб таблицу держать, я коэффициенты масштабирования запоминаю, а sin/cos считаю функциями.
V>Не надо ничего обрабатывать программно. У тебя фильтры НЧ стоят на вычислении повернутых на 90 градусов проекций. Да, действительно, этот фильтр НЧ в таком случае надо сделать более быстрым. Но ведь ты можешь пропустить через допольнительный 20мс фильтр НЧ саму энергию, т.е. значения sqrt(f1*f1 + f1'*f1').
То есть иметь два фильтра? Надо попробовать...
V>ИМХО, лучше все-таки привести систему в соответствии стандарту
Не факт что телефон будет очень соответствовать стандарту.
V>и при этом добиться работоспособности даже при большом уровне шумов (например, громко говорить в трубку и при этом давить на клавиши — система должна срабатывать)
С этим проблем нет. Я подавал на вход фильтра сигнал у которого уровень шума был даже выше уровня сигнала всё равпознаётся. В качестве генератора шума использовалcя генератор псевдослучайных чисел. Думаю шум получился вполне себе белый
V>Чем ниже частота среза фильтра НЧ в этой системе, т.е. чем выше избирательность, тем выше помехоустойчивость. Надо вообще-то поискать, может быть последние стандарты более жесткие. Потому как мне трудно представить себе современную трубку, у которой погрешность излучения DTMF была бы 3%, реально у них погрешности — доли процента.
Да на моём телефона всё как раз зашибись, но хотелось бы попробовать на всех.
Здравствуйте, vdimas, Вы писали:
V>Задача стоит — обнаружить факт наличия. Корреляция с эталоном — это самый простой и самый надежный способ. Прекрасно работает даже в условиях, когда шум сильно перекрывает основной сигнал.
Именно так! Когда я на синклере АОН делал то к этому же и пришел.
Здравствуйте, adontz, Вы писали:
V>>Чем ниже частота среза фильтра НЧ в этой системе, т.е. чем выше избирательность, тем выше помехоустойчивость. Надо вообще-то поискать, может быть последние стандарты более жесткие. Потому как мне трудно представить себе современную трубку, у которой погрешность излучения DTMF была бы 3%, реально у них погрешности — доли процента.
A>Да на моём телефона всё как раз зашибись, но хотелось бы попробовать на всех.
Здравствуйте, vdimas, Вы писали:
V>вот поискал http://www.gaw.ru/html.cgi/txt/app/micros/msp430/slaae16.htm V>там требуемая погрешность по частоте 1.8% указана... V>Это я к чему... тут такие законы, что повысив избирательность вдвое, ты примерно вчетверо улучшаешь предельное отношение сигнал/шум.
На самом деле мне проще попросить в Users Guide всех закнуться, чем объяснять почему на некоторых телефонах не срабатывает
Здравствуйте, vdimas, Вы писали:
Ш>>Не понял этой фразы. Причем здесь свертка?
V>Математически то, как ты ищешь проекции — это оно и есть. Свертка с некоей образцовой частотой.
У нас похоже терминологические непонятки. Я вычисляю скалярное произведение, свертка сигналов -- это нечто иное.
V>>>К тому же, буфер каждый раз пересчитывается по кругу.
Ш>>Не понял, что ты имеешь ввиду?
V>Ну, у тебя вроде "окно" движется (буфер), и ты каждый раз производишь вычисления над всем буфером. В моем варианте я произвожу вычисления только над текущим сэмплом.
Нет, посмотри внимательно приведённый код. При поступлении очередного отсчета пересчитываются скалярные произведения, при этом нет нужды пересчитывать весь буфер -- мы учитываем только пришедший отсчет и ушедший. В сумме получается несколько операций умножения и сложения.
V>>>В общем, предлагаю вместо этого использовать "бесконечный" сумматор, выполненный в виде фильтра НЧ с частотой среза, обратной скорости реакции. Сама характеристика фильтра НЧ уже является некоей оконной ф-ией, где последние отсчеты будут больше влиять на результат, чем дальние. А в твоем варианте с кольцевым буфером "давние" отсчеты так же влияют на результат, как и самые последние. (Хотя, надо погонять оба варианта... Подход у них абсолютно одинаковый...)
Ш>>Ну так мы обсчитываем кусок сигнала -- с чего это старые отсчеты должны отличаться от новых?
V>Тут речь о помехоустойчивости. Кратковременные мощные помехи на частотах близких к обнаруживаемым искажают "картинку" все время, пока они находятся в твоем окне (отсчеты помехи находятся в буфере), и даже возможны ложные срабатывания. Это действительно так — поэкспериментируй. В моем варианте ситуация сглаживается фильтром НЧ, и подобные по характеру помехи не приводят к срабатыванию детектора.
Опять я чего-то не понял. Если у тебя идет такая помеха, что она задавила сигнал и сама из себя представляет DTMF тон, то сделать тут ты ничего не сможешь. Детектор должен на это дело реагировать. Но это случай исключительный. Обычно, мы находимя в ситуации, когда мощность помех значительно (хотя бы в несколько раз) меньше мощности полезного сигнала.
