Тоновый набор

                           Пpивет, Alexander!

*** 26 Feb 04 22:21, Alexander Martynenko wrote to All:

 AM> Подскажите, где можно глянуть алгоритм или исходник программы
 AM> определения кода тонового набора (DTMF) если не ошибаюсь.

 AM>  Короче, однокристалкой нужно расшифровать цифру, набранную с
 AM> телефона тоновым набором.

 AM> URL?

http://smsn.chat.ru /

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

                                      с уважением Владислав

    Hello, Vladislav!

Пят Фев 27 2004, Vladislav Baliasov писал к Alexander Martynenko по   поводу
"Тоновый набор."
 AM>> URL?

 VB> http://smsn.chat.ru /

 VB>   Hо в сравнении с готовым декодером стоимостью в один бакс - хлам.
 VB> Проблема не в распознавании собственно цифры, хуже всего надежно
 VB> детектировать паузы в условиях реального сигнала. Хочешь устойчивой
 VB> работы - ставь аппаратный декодер. Проверено.
Hе стоит так категорично. Программные просто зачастую имеют грубые ошибки в
алгоритмической реализаци.
 VB>                                       с уважением Владислав
  WBR!  Maxim Polyanskiy.

                           Пpивет, Maxim!

*** 27 Feb 04 23:57, Maxim Polyanskiy wrote to Vladislav Baliasov:

 VB>> хлам. Проблема не в распознавании собственно цифры, хуже всего
 VB>> надежно детектировать паузы в условиях реального сигнала. Хочешь
 VB>> устойчивой работы - ставь аппаратный декодер. Проверено.

 MP> Hе стоит так категорично. Программные просто зачастую имеют грубые
 MP> ошибки в алгоритмической реализаци.

Я просто сделал коррелятор и посмотрел, что у него на выходе. Мне _очень_ не
понравилось. Т.е. когда наличествует сигнал - все вполне пристойно, но с
паузами разбираться сложнее. Так что если делать - то нормальный фильтровый.
Или применять готовый аппаратный.

                                      с уважением Владислав

Hемедленно нажми на RESET, Vladislav Baliasov!



 MP>> Hе стоит так категорично. Программные просто зачастую имеют грубые
 MP>> ошибки в алгоритмической реализаци.
 VB> Я просто сделал коррелятор и посмотрел, что у него на выходе. Мне _очень_
 VB> не
 VB> понравилось. Т.е. когда наличествует сигнал - все вполне пристойно, но с

  Смотрите в сети SPRA096.PDF: Application Report: DTMF Tone Generation and
Detection, An Implementation Using the TMS320c54, SPRA096 1997 (C) Texas
Instruments.

  Вкратце: используется алгоритм Герцеля (Goertzel), в сущности тоже
самое, что и ДПФ, но для реализации на микроконтроллере сложно --
рекурсивный алгоритм, и нужна достаточная точность вычислений (зато
умножений в ~2 раза меньше, но все float)...

complex goertzel(short *what,  int howmuch, double theta)
{
double v0, v1, v2;
complex w;
double t, f;
int x;
    w=cos(theta)-sin(theta)*I;
    f=2*creal(w);
    v0=v1=v2=0;
    for (x=0; x<howmuch; x++) {
        v0=v1; v1=v2;
        v2=f*v1-v0+what[x];
    }
    return v2-w*v1;
}

  Для подавления всяческих помех учитывается, что в сигнале DTMF второй

гармоники не должно быть, а в речи, например, запросто. Больше никаких

хитростей там нет.


 VB> паузами разбираться сложнее. Так что если делать - то нормальный
 VB> фильтровый.
 VB> Или применять готовый аппаратный.

  Что значит "нормальный фильтровый" ?

                           Пpивет, Kirill!

*** 01 Mar 04 03:08, Kirill Frolov wrote to Vladislav Baliasov:

 KF>   Смотрите в сети SPRA096.PDF: Application Report: DTMF Tone
 KF> Generation and Detection, An Implementation Using the TMS320c54,
 KF> SPRA096 1997 (C) Texas Instruments.

 KF>   Вкратце: используется алгоритм Герцеля (Goertzel), в сущности тоже
 KF> самое, что и ДПФ, но для реализации на микроконтроллере сложно --
 KF> рекурсивный алгоритм, и нужна достаточная точность вычислений (зато
 KF> умножений в ~2 раза меньше, но все float)...

Тогда бы уж отправил к SLAAE16 (Generation and Recognition of DTMF Signals with
the Microcontroller MSP430) - это практически на любой платформе реализуемо.
Вот еще бы кто ликбез провел, как считаются эти коэффициенты - увы, вот в ЦОС я
дуб-дубом...

 KF>   Что значит "нормальный фильтровый" ?

Hу, я имел в виду программную реализацию натурального полосового активного
фильтра, а не коррелятора с накоплением результата перемножений.

                                      с уважением Владислав

Hемедленно нажми на RESET, Vladislav Baliasov!


 KF>>   Смотрите в сети SPRA096.PDF: Application Report: DTMF Tone
 KF>> Generation and Detection, An Implementation Using the TMS320c54,
 KF>> SPRA096 1997 (C) Texas Instruments.
 KF>>   Вкратце: используется алгоритм Герцеля (Goertzel), в сущности тоже
 KF>> самое, что и ДПФ, но для реализации на микроконтроллере сложно --
 KF>> рекурсивный алгоритм, и нужна достаточная точность вычислений (зато
 KF>> умножений в ~2 раза меньше, но все float)...
 VB> Тогда бы уж отправил к SLAAE16 (Generation and Recognition of DTMF Signals
 VB> with
 VB> the Microcontroller MSP430) - это практически на любой платформе
 VB> реализуемо.
 VB> Вот еще бы кто ликбез провел, как считаются эти коэффициенты - увы, вот в
 VB> ЦОС я
 VB> дуб-дубом...
  
  Так там же написано: это косинус угла, приходящегося на один
дискретный отсчёт, для обнаруживаемой частоты. Мнимую часть, вместе с
синусом, выкинули, ибо нужна только амплитуда. То есть коэффициент
считается как 2*cos(2*M_PI*P/NS), P -- полное число периодов
обнаруживаемой частоты, нужно целое число, NS -- число дискретных
отсчётов, за полный цикл. Проще, P/NS -- это отношению обнаруживаемой
частоты, и частоты дискретизации.

 KF>>   Что значит "нормальный фильтровый" ?
 VB> Hу, я имел в виду программную реализацию натурального полосового активного
 VB> фильтра, а не коррелятора с накоплением результата перемножений.

  AFAIK это и есть сильнодобротный фильтр для частного случая.

   Vladislav, ты ещё здесь сидишь?


Вторник Март 02 2004 00:10, Vladislav Baliasov wrote to Kirill Frolov:

 KF>> Что значит "нормальный фильтровый" ?
 VB> Hу, я имел в виду программную реализацию натурального полосового
 VB> активного фильтра, а не коррелятора с накоплением результата
 VB> перемножений.

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

 Hужно будет хранить отдельно результаты для "синусной" и "косинусной"
составляющих, по каждому из "коротких окон" (и так для каждой из
анализируемых частот). При завершении накопления в очередном "коротком окне"
рассчитать результат по всем "коротким окнам" (получится текущее значение
данной спектральной составляющей сигнала), обнулить результат для следующего
"короткого окна" и начать накопление в нём. Опускаю нюансы, связанные
с использованием промежуточных значений, позволяющие "размазать" расчёты
на всё время накопления следующего "короткого окна".

 В результате получится "скачущее" с нужной точностью "окно анализа"
заданой длительности.



 К примеру, если использовать 16-ти битные промежуточные результаты,
4 "коротких окна" и 8 анализируемых частот, потребуется 2*2*4*812%8 байт
оперативной памяти. По-моему, вполне терпимо...



                                                   Георгий

Hемедленно нажми на RESET, George Shepelev!


 KF>>> Что значит "нормальный фильтровый" ?
 VB>> Hу, я имел в виду программную реализацию натурального полосового
 VB>> активного фильтра, а не коррелятора с накоплением результата
 VB>> перемножений.
 GS>  А чем коррелятор не угодил? Его реализовать всё-же проще, чем цифровой
 GS> фильтр (умножения не нужны - для контроллеров без аппаратного умножения
 GS> это довольно критично). А чтобы убрать жёсткую зависимость от момента
 GS> начала накопления, можно использовать набор накопленных на "коротких
 GS> окнах"
 GS> результатов.

   Вопрос: почему нельзя взять ну если не бесконечно малое окно, то
равное по времени одному дискретному входному отсчёту?  Ведь как
вычисления упростятся!  Собственно это и ответ.

   Kirill, ты ещё здесь сидишь?


Четверг Март 04 2004 01:49, Kirill Frolov wrote to George Shepelev:

 GS>> А чем коррелятор не угодил? Его реализовать всё-же проще, чем
 GS>> цифровой фильтр (умножения не нужны - для контроллеров без
 GS>> аппаратного умножения это довольно критично). А чтобы убрать
 GS>> жёсткую зависимость от момента начала накопления, можно
 GS>> использовать набор накопленных на "коротких окнах" результатов.
 KF>    Вопрос: почему нельзя взять ну если не бесконечно малое окно, то
 KF> равное по времени одному дискретному входному отсчёту?

 Смысл? В большинстве случаев нет необходимости в таком разрешении по времени.
Представь частотные анализаторы сигнала в виде высокодобротных фильтров и
определи характер реакции на появление пакета с заданной частотой...


 KF> Ведь как вычисления упростятся!

 Усложнятся, а не упростятся. Число отсчётов в результирующем окне - величина
постоянная. Идея заключалась в том, чтобы оперировать не с отдельными
отсчётами, а с предварительно обработанными группами отсчётов...



                                                   Георгий

Hемедленно нажми на RESET, George Shepelev!


 GS>>> использовать набор накопленных на "коротких окнах" результатов.
 KF>>    Вопрос: почему нельзя взять ну если не бесконечно малое окно, то
 KF>> равное по времени одному дискретному входному отсчёту?
 GS>  Смысл? В большинстве случаев нет необходимости в таком разрешении по
 GS>  времени.

  Смысл в том, что ширина полосы зависит от количества точек над
которыми производится преобразование. При 1 точке получается ()().
Поэтому тезис об использовании набора коротких окон несостоятелен.

 KF>> Ведь как вычисления упростятся!
 GS>  Усложнятся, а не упростятся. Число отсчётов в результирующем окне -
 GS>  величина
 GS> постоянная. Идея заключалась в том, чтобы оперировать не с отдельными
 GS> отсчётами, а с предварительно обработанными группами отсчётов...

   Что-то я не понимаю. :-/

   Kirill, ты ещё здесь сидишь?


Пятница Март 05 2004 20:07, Kirill Frolov wrote to George Shepelev:

 GS>>>> использовать набор накопленных на "коротких окнах" результатов.
 KF>>> Вопрос: почему нельзя взять ну если не бесконечно малое окно,
 KF>>> то равное по времени одному дискретному входному отсчёту?
 GS>> Смысл? В большинстве случаев нет необходимости в таком
 GS>> разрешении по времени.
 KF>   Смысл в том, что ширина полосы зависит от количества точек над
 KF> которыми производится преобразование. При 1 точке получается ()().

 В том-то и дело, что "количество точек над которыми производится
преобразование" не меняется. Оно определяется:

a) длительностью "окна" (задаётся разрешением по частоте)

б) частотой сэмплирования (задаётся шириной спектра анализируемого сигнала)

 KF> Поэтому тезис об использовании набора коротких окон несостоятелен.

 "Hеубедительно" (c)

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


 KF>>> Ведь как вычисления упростятся!
 GS>> Усложнятся, а не упростятся. Число отсчётов в результирующем
 GS>> окне - величина постоянная. Идея заключалась в том, чтобы
 GS>> оперировать не с отдельными отсчётами, а с предварительно
 GS>> обработанными группами отсчётов...
 KF>    Что-то я не понимаю. :-/

 Подумай о ситуации, когда длительность пакета обнаруживаемого сигнала
(или паузы сигнала) соизмерима с длиной окна анализа. Уменьшить окно
нельзя - упадёт разрешение по частоте. Каждый раз пересчитывать по
всем точкам - чрезмерно увеличивается объём вычислений...



                                                   Георгий

Hемедленно нажми на RESET, George Shepelev!


 GS>>>>> использовать набор накопленных на "коротких окнах" результатов.
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 KF>>   Смысл в том, что ширина полосы зависит от количества точек над
 KF>> которыми производится преобразование. При 1 точке получается ()().
 GS>  В том-то и дело, что "количество точек над которыми производится
 GS> преобразование" не меняется. Оно определяется:
 GS> a) длительностью "окна" (задаётся разрешением по частоте)
 GS> б) частотой сэмплирования (задаётся шириной спектра анализируемого
 GS> сигнала)

   Сам себе противоречишь. То-есть длительность окна не меняется.
Меняется интервал между ними. Почему они тогда короткие?

 KF>> Поэтому тезис об использовании набора коротких окон несостоятелен.
 GS>  "Hеубедительно" (c)
 GS>  Предложенный метод позволяет производить более точное "позиционирование"

   Hу да, для мелких контроллеров это неплохое решение.

   Vladislav, ты ещё здесь сидишь?


Воскресенье Февраль 29 2004 12:30, Vladislav Baliasov wrote to Maxim
Polyanskiy:

 VB>>> хлам. Проблема не в распознавании собственно цифры, хуже всего
 VB>>> надежно детектировать паузы в условиях реального сигнала. Хочешь
 VB>>> устойчивой работы - ставь аппаратный декодер. Проверено.
 MP>> Hе стоит так категорично. Программные просто зачастую имеют
 MP>> грубые ошибки в алгоритмической реализаци.
 VB> Я просто сделал коррелятор и посмотрел, что у него на выходе. Мне
 VB> _очень_ не понравилось. Т.е. когда наличествует сигнал - все вполне
 VB> пристойно, но с паузами разбираться сложнее.

 А ты попробуй программный порог срабатывания разумный установить,
сигналы в паузе _существенно ниже_, чем когда DTMF присутствует...

 VB> Так что если делать - то нормальный фильтровый.

 Hу а чем тебя цифровая фильтрация не устраивает? ;-)

 VB> Или применять готовый аппаратный.

 Это, конечно, проще, для того их и выдумали...



                                                   Георгий

    Hello, Kirill!

Сpд Маp 03 2004, Kirill Frolov писал к Maxim Polyanskiy по поводу "Re: Тоновый
набор."
 MP>> Дествительно гоню - герцы с мсеками путаю. 20мс конечно ;)
 KF>    Всё равно гонишь. За это время экран даже полностью не заполнить,
 KF> хоть одними нулями.
push hl - 11 тактов. ставим в ряд.. экран 6912/234%56*1138%016 тактов на
очистку. 20мс35%00*2070%000 тактов. Как говорица если умеючи - то можно и 2
раза нулями заполнить ;)
 KF> -+- [ZX]
  WBR!  Maxim Polyanskiy.

Hi!

In a message of 03 Mar 04 Maxim Polyanskiy wrote to Kirill Frolov:

 KF>>    Всё равно гонишь. За это время экран даже полностью не заполнить,
 KF>> хоть одними нулями.
 MP> push hl - 11 тактов. ставим в ряд.. экран 6912/234%56*1138%016 тактов
 MP> на очистку. 20мс35%00*2070%000 тактов. Как говорица если умеючи - то
 MP> можно и 2 раза нулями заполнить ;)

Вот только непонятно, зачем нулями заполнять атрибуты. Hу да ладно, простим
тебе :-)


Bye...

   Alexander, ты ещё здесь сидишь?


Четверг Февраль 26 2004 22:21, Alexander Martynenko wrote to All:

 AM> Подскажите, где можно глянуть алгоритм или исходник программы
 AM> определения кода тонового набора (DTMF) если не ошибаюсь. Короче,
 AM> однокристалкой нужно расшифровать цифру, набранную с телефона тоновым
 AM> набором.

 Копать в сторону БПФ.


                                                   Георгий

Hello George!

27 Feb 04 17:40, you wrote to Alexander Martynenko:

 AM>> определения кода тонового набора (DTMF) если не ошибаюсь. Короче,
 GS>  Копать в сторону БПФ.

Обломись. Частоты DTMF не лезут ни в Цаhаль ни в Красную Армию, в отличие от
кратных 100 гц частот АОHов, а делать БПФ на большинстве однокристалок - это
удовольствие для последователей Леопольда фон Захер-Мазоха.

Anatoly

БПФ eto ia ta k ponimaiu FFT (Fast Fourier Transform)? Izvinite, no ia eto
vse prohodil na angliiskom.

Tak MSP430, kstati, mozhet delat'. U nego i vstroennii "multiplier" est'.
A voobche, esli FFT delat', to luche vsego prosten'kii DSP postavit'.
Ne smotrel v storounu DSPic, no vozmozhno eto to chto vam podoidet.

Rudolf