[aal 0]

Требуется сформировать 2 синуса (естественно в цифре). Можно пойти табличным методом - но для 8 бит и 1к хватит, а для 18 бит и метра может мало оказатся. Есть другой метод http://www.gaw.ru/html.cgi/txt/doc/...v/max2000_5.htm .

Но интересные эфекты: даже при инт64 вылазеют гармоники на уровне -70 дб + к этому и частота не точно заданная.

Попробывал так:

X(n)=k*X(n-1)-X(n-2), где k=2*cos(2*Pi*F/Fd);

для 0 градусов X(-1)=0, X(-2)=-A*sin(2*Pi*F/Fd);

для 90 градусов X(-1)=A, X(-2)=A*sin(pi/2+2*Pi*F/Fd)

90 гр. частота на сотые доли процентов выше и уползает вперёд по отношению к 0 гр.

Сейчас хочу через приблежённое вычеслени по Тейлору попробывать. Но явно по вычислениям более накладно будет.

Может ещё есть способ с минимум вычислений сгенерить синус?

(Всё должно в итоге оказатся в FPGA Спартан3).

[Andy_Mozzhevilov 0]

Требуется сформировать 2 синуса (естественно в цифре). Можно пойти табличным методом - но для 8 бит и 1к хватит, а для 18 бит и метра может мало оказатся. Есть другой метод http://www.gaw.ru/html.cgi/txt/doc/...v/max2000_5.htm .

[\quote]

 

Дайте точную ссылку на метод

Изменено 24 января, 2006 пользователем Andy Mozzhevilov

[Shamil 2]

Можно пойти табличным методом - но для 8 бит и 1к хватит, а для 18 бит и метра может мало оказатся.

 

Это смотря какие частоты дискретизации и с какой точностью нужно выдержать частоту сигнала.

Если нужно получить всего несколько фиксированных частот, и при этом есть возможность

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

 

Для примера: Нам требовалось иметь синусы 425 Гц, 2100 Гц, 2600 Гц на выходе

ИКМ кодека (8000 выборок/сек по 8 бит).

 

Сначала думали придеться ставить ПЗУ, но поигравшись с подбором

кратных частот нашли замены: 421,053 Гц (19 выборок), 2105,26 (19 выборок),

2600 (40 выборок).

 

Причем Synplify очень хорошо оптимизирует таблицы, и вышеприведенные синусы

заняли в ПЛИС Actel Ex256 не больше 10 %.

[aal 0]

http://www.gaw.ru/html.cgi/txt/doc/micros/...v/max2000_5.htm

 

Требуется генерить синусоиды с частотами от 300 Гц до 2,5 МГц с шагом 1 Гц.

Желательно с нелиненостями -90 дБ. Проект - селективный вольтметр, с полосами 30 и 100 Гц, желательно и со спектроанализатором.

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

Т.к. в спартане умножители 18 битные, то и синус желательно сформировать 18 битный. Частота опорного генератора 10 МГц.

[Andy_Mozzhevilov 0]

http://www.gaw.ru/html.cgi/txt/doc/micros/...v/max2000_5.htm

 

Требуется генерить синусоиды с частотами от 300 Гц до 2,5 МГц с шагом 1 Гц.

Желательно с нелиненостями -90 дБ. Проект - селективный вольтметр, с полосами 30 и 100 Гц, желательно и со спектроанализатором.

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

Т.к. в спартане умножители 18 битные, то и синус желательно сформировать 18 битный. Частота опорного генератора 10 МГц.

 

Что-то в постановке не то: -90дБ до 2.5МГц с шагом 1 Гц с тактовой 10МГц, это не описка?

Попробуйте посмотреть такой метод:

http://archive.chipcenter.com/dsp/DSP080201F1.html

и смежные статьи на том же сервере.

[iosifk 3]

Требуется сформировать 2 синуса (естественно в цифре). Можно пойти табличным методом - но для 8 бит и 1к хватит, а для 18 бит и метра может мало оказатся.

 

Может ещё есть способ с минимум вычислений сгенерить синус?

 

Когда-то от аналоговых времен помню, что пробовал генерить синусоиду при кусочно-линейной аппрокс. по методу треугольников.

Возможно, если удастся подобрать что-то в этом духе, ( делал я это для реализации в альтере лет 8 назад и деталей уже не помню ) то из таблицы надо будет брать не сам сигнал, а только поправку. Следовательно объем таблицы значительно уменьшится.

Удачи!

[KPAH 0]

Есть такая штука как резонантный фильтр, подробности по ссылке

http://www.research.scea.com/research/pdfs...rmath_GDC02.pdf

[Stanislav 0]

Требуется сформировать 2 синуса (естественно в цифре)

 

..................................

Может ещё есть способ с минимум вычислений сгенерить синус?

(Всё должно в итоге оказатся в FPGA Спартан3).

 

Стандартный способ вычисления значения функции заключается в полиномиальном приближении ее на отрезке и отображении любого значения функции на этот отрезок. Например, для косинуса и синуса:

1 Разбиваем один период косинуса на четыре части, учитывая, что cos(-x)=cos(x); cos(2*pi*n+x)=cos(x); cos(pi+x)= -cos(x); sin(x)= -cos(pi/2+x). Пользуясь этими соотношениями, значение аргумента приводится к отрезку [0; pi/2].

2.Участок функции с аргументом [0; pi/2] аппроксимируем полиномом: sin(x) ~ A0+A1*x+A2*x^2+...An*x^n, где А0...Аn - коэффициенты полинома. Для наилучшего приближения (в смысле наименьших средних квадратов), если склероз не изменяет, это к-ты полинома Лежандра, и ни в коем случае не Тейлора! Для Ваших требований хватит n=5-6. О вычислении к-тов нужно посмотреть в справочнике по математике. Значение функции вычисляется рекуррентно, на Спартане должно реализоваваться в пол-пинка...

Можно попробовать аппроксимировать косинус и на отрезке [-pi/2; pi/2], если это будет удобнее для реализации на ПЛИС. Тогда останутся только четные степени раздожения, но вычислений будет несколько больше.

 

Вообще-то такую штуку можно реализовать и на недорогом DSP...

[SSerge 4]

Можно попробовать аппроксимировать косинус и на отрезке -pi/2; pi/2, если это будет удобнее для реализации на ПЛИС. Тогда останутся только четные степени раздожения, но вычислений будет несколько больше.

 

Я в своих изысканиях пришёл к выводу что лучше всего получается если сводить всё к отрезку [-pi/4;+pi/4] и считать либо синус либо косинус как разложение в ряд в окрестности нуля. На таком интервале они быстрее сходятся.

В данной конкретной задаче придётся считать в любом случае обе функции, и синус и косинус.

 

Ещё одно интересное разбиение - на четыре (на самом деле получается три) разных полинома:

sin(x) и cos(x) при x=[-pi/8;+pi/8] - как обычно - в окрестности нуля, а на интервале

x=[+pi/8;+3pi/8] считать разложением в окрестности pi/4, коэффициенты для sin и cos получаются одинаковыми с точностью до знака.

Изменено 24 января, 2006 пользователем SSerge

[KPAH 0]

Чем ряды считать, лучше уж по фомуле sin(a+b) - быстрее будет это точно ( это в принципе и есть резонантный фильтр, я просто настаиваю на том, чтобы вы ознакомились с предложенным мной документом ). Особый шик - при некоторых частотах умножений для вычисления синусов/косинусов вообще не потребуется.

Изменено 24 января, 2006 пользователем KPAH

[aal 0]

Спасибо Всем откликнувшимся!

Изучаю Вашу инфу. Проведу эксперименты - обязательно отчетаюсь.

[Stanislav 0]

Я в своих изысканиях пришёл к выводу что лучше всего получается если сводить всё к отрезку [-pi/4;+pi/4] и считать либо синус либо косинус как разложение в ряд в окрестности нуля. На таком интервале они быстрее сходятся.

В данной конкретной задаче придётся считать в любом случае обе функции, и синус и косинус.

Ещё одно интересное разбиение - на четыре (на самом деле получается три) разных полинома:

sin(x) и cos(x) при x=[-pi/8;+pi/8] - как обычно - в окрестности нуля, а на интервале

x=[+pi/8;+3pi/8] считать разложением в окрестности pi/4, коэффициенты для sin и cos получаются одинаковыми с точностью до знака.

 

Все-таки, попробуйте использовать для разложения многочлены Лежандра - будете немало удивлены. Дело в том, что Тэйлор наилучшим образом приближает ф-цию только в бесконечно малой (дельта-) окрестности конкретной _точки_, а пол-м Лежандра - на _отрезке_.

[SSerge 4]

Все-таки, попробуйте использовать для разложения многочлены Лежандра - будете немало удивлены. Дело в том, что Тэйлор наилучшим образом приближает ф-цию только в бесконечно малой (дельта-) окрестности конкретной _точки_, а пол-м Лежандра - на _отрезке_.

 

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

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

 

Вопрос таким образом сводится к выбору наилучшего сочетания: объём таблицы - степень интерполяционного полинома.

 

Сейчас посмотрел в исходники IAR-овского sin() - там над вопросами эффективности не особо задумывались, считают Тейлором суммируя до 9-й степени для float и аж до 17-й для double.

То ли дело фортрановские библиотеки для PDP - когда-то они были для меня источником алгоритмов (интернет тогда уже был, только до нас ещё не добрался, а гугл ещё не выдумали - за каждой фигнёй приходилось тащится в библиотеку, за N километров!, по морозу! не то что нынешняя молодёжь! :) )

[Stanislav 0]

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

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

 

Вопрос таким образом сводится к выбору наилучшего сочетания: объём таблицы - степень интерполяционного полинома.

 

Сейчас посмотрел в исходники IAR-овского sin() - там над вопросами эффективности не особо задумывались, считают Тейлором суммируя до 9-й степени для float и аж до 17-й для double...

 

Нет-нет, табличным способом задаются только коэффициенты при степенях аппроксимирующего полинома, которые находятся аналитически, а узловые значения функции задавать вовсе не нужно. Точно так же, как в тейлоре, но, в отличие от него, эти к-ты будут зависеть от степени полинома. Наверное, и в ИАРе используется не тейлоровское разложение, здесь может сбить с толку абсолютно идентичный способ вычисления значения полинома. Кстати, представление лежандром оптимально только в смысле наименьших средних квадратов на отрезке, поэтому я и предложил его для генератора - будет давать минимум гармоник. Можно задаться другим критерием, напр., минимизацией масимальной ошибки на отрезке, тогда к-ты поинома будут слегка другими. Если мне опять склероз не изменяет, приближение по Лежандру дает для синуса на отрезке [0;pi/2] по 3 верных двоичных разряда за итерацию, что хорошо сочетается с цифрами, приведенными Вами. Тейлор же такой точности (24р за 9 итераций) не даст. Если выложите исходный текст ИАРовского синуса, постараюсь выяснить это - самомУ стало интересно.

[SSerge 4]

Нет-нет, табличным способом задаются только коэффициенты при степенях аппроксимирующего полинома, которые находятся аналитически, а узловые значения функции задавать вовсе не нужно. Точно так же, как в тейлоре, но, в отличие от него, эти к-ты будут зависеть от степени полинома. Наверное, и в ИАРе используется не тейлоровское разложение, здесь может сбить с толку абсолютно идентичный способ вычисления значения полинома. Кстати, представление лежандром оптимально только в смысле наименьших средних квадратов на отрезке, поэтому я и предложил его для генератора - будет давать минимум гармоник. Можно задаться другим критерием, напр., минимизацией масимальной ошибки на отрезке, тогда к-ты поинома будут слегка другими. Если мне опять склероз не изменяет, приближение по Лежандру дает для синуса на отрезке [0;pi/2] по 3 верных двоичных разряда за итерацию, что хорошо сочетается с цифрами, приведенными Вами. Тейлор же такой точности (24р за 9 итераций) не даст. Если выложите исходный текст ИАРовского синуса, постараюсь выяснить это - самомУ стало интересно.

Точно, от к-тов Тейлора немного отличаются в младших разрядах, наверняка какой-нибудь полином.

Уступив настоятельной просьбе :) ознакомился с предложенным KPAH документом, вставляет.

Исходник синуса прилагается.

#define __TWOOPI 0.63661977236758134308

sinus.c.txt