Здравствуйте!

Не получается найти информацию по точности алгоритмов БПФ с фиксированной и плавающей запятой. В литературе встречаются фразы, что если нужна высокая точность, то лучше использовать плавающую точку.

Задача - 4096 точечное преобразование , входные данные 16-разрядные. Понятно, что разрешающая способность определяется к-вом точек. Но что подразумевается под точностью, точность амплитуды или точность по частоте?

Алгоритмы 1.15 и FP single выдадут идентичные результаты по частоте? (точность по амплитуде совершенно не критична)

От этого зависит выбор DSP.

Что-то у вас все "в одну кучу": и точность, и разрешающая способность.
ДПФ/БПФ - линейная операция и к ней применимы все методы анализа, что и для фильтров. Хотите лучше разрешать слабые сигналы на фоне сильных - увеличивайте динамический диапазон вычислителя и промежуточных результатов. Вот и весь сказ.

Вот модель, меняя параметр WIDTH можно сравнивать реализацию fixed point FFT и floating point single precision FFT.


Пример графика для вашего случая
Нажмите для просмотра прикрепленного файла

Для 15 бит, как видно из графика, ошибка fixed point реализации пренебрежима мала в сравнении с разрешающими способностями Фурье.

2-3 разряда - нормальное пренебрежение. угу.

С другой стороны, если разрядность ацп - 12-13 бит, то шум кварнтования на входе будет преобладать над шумом вычислителя в s1.15

Большое спасибо!

R2014b

Undefined function 'fi_radix2twiddles' for input arguments of type 'double'

У меня R2010b, возможно они поменяли с того времени набор функций из fi тулбокса. fi_radix2twiddles и fi_m_radix2fft_withscaling не входят в состав стандартных функций (на них даже хелпа нет), я их вытащил из примера. Вставил в свой скрипт, он их откуда-то из своих недр добыл. Собственно в примере есть их исходники.

А Вы уверены, что это действительно так?



Угу.

А точнее, для БПФ 4к, 16 бит, радикс-2 потребуется 1 защитный бит, и максимальный рост шума на 12-ти стадиях - в 12^0.5 раза.
Т.е., собственный шум 16 бит БПФ радикс-2 можно оценивать на уровне 13 бит. Для сигнала с эффективными 12-ю битами это действительно вполне адекватно.

Для радикс-4 потребуется 2 защитных бита. Потери на стадиях не изменятся (в 12^0.5 раза). Т.е., суммарная потеря на БПФ - около 4-х бит. С групповой плавающей точкой, ессно.
Для чистых 12-ти бит данных этого уже маловато.

И тут есть ещё один момент. Если для задачи ТС скорость критична, он должен учитывать заполнение кэша 1-го уровня данными и коэффициентами. Если оные в кэш не помещаются, производительность БПФ падает катастрофически.
Так что, при оценке потребной разрядности лучше добавлять какой-то резерв, так как переход на большую разрядность БПФ может оказаться неприемлем по скорости именно из-за заполнения кэша.
Кроме того, БПФ на перемножилках 1.15*1.15 потребует нормализации после каждой стадии(групповая плав. точка), что даёт проигрыш в производительности по сравнению с 32*32 того или иного вида при прочих равных.

Имха, с фикс. точкой на 16-ти битах стоит связываться только при большой серийности продукции и очень жёстких ограничениях на стоимость комплектации.
Для всего остального лучше сразу ориентироваться на 32*32 (фикс или плавающая - не принципиально). Только кэша 1-го уровня побольше, побольше, побольше...

В смысле что мне не нужна точность по амплитуде? Да, в спектре интерес к амплитуде +/- лапоть, интересует именно значение частоты. Т.к. задача определить значение частоты гармонического сигнала на фоне шума.



Да, скорость критична.




16 бит я указал с запасом, как максимально возможные. Вполне вероятно АЦП 12-разрядным будет.

Оно как бы да, 32 битный процессор вроде самое то, да и серийность низкая. Но дороже, больше потребление, выше порог вхождения

У вас какие полосы? Посмотрите stm32 M4, там есть FPU и уже готовые библиотеки с реализованными FFT на вкус и цвет. Дёшево и сердито. А с discovery достаточно одного дня, чтобы уже начать под него писать.

- Я к тому, что "точность по амплитуде" - это многофакторная величина, в том числе связанная с уровнем шума. А шум Вам всё равно придётся учитывать, особенно при регистрации "слабых" сигналов.

- Если рабочая полоса будет существенно ниже полосы оцифровки, ENOB может "неожиданно" увеличиться.
Да и вообще, 16*16 - это очень узенькие штанишки. Всегда есть риск растолстеть и не втиснуться.

- Доп. издержки для 32*32 могут с лихвой окупиться снижением затрат/времени на разработку софта, сопровождение, возможную модернизацию.
А если возможна унификация элементной базы и инструментария для нескольких типов приборов, выигрыш может и умножится.

(Помнится, около месяца гонял скверный редкопроявляющийся косяк. В результате нашлась одна собственная ошибка и одна незадекларированная аппаратная ошибка процессора. Аппаратная ошибка проявлялась только при определённом сочетании кода на ассемблере и некоторого специфичного набора данных. Хорошо, что пофиксилась. Но на фикс и тотальные проверки ушло ещё около месяца, так как проверялось на реальном железе с многосуточными прогонами.
А всё потому, что фирменные целчисленные библиотеки для 16*16 пришлось обрабатывать напильником. Для 32*32, особенно float, потребность в обработке напильником может снизиться почти до нуля.)

Для низкой серийности лучше ориентироваться на float. Софт будет проще и прозрачней, а затраты практически идентичны фикс. точке 32*32.
Доступность float для самого широкого круга задач - это уже свершившийся факт.
У того же TI, плав. точка фактически стала базовой для всех новых высокопроизводительных 32-битных сигнальников.
А ценники и возможные издержки могут приятно удивить.

Ну а если задача позволяет, STM-ы и прочие армо-мипсы могут удивить ещё больше. Так что, совет serjj может оказаться для Вас самым полезным.

Да вот собственно сейчас как раз и взвешиваются все за и против Cortex-M7 vs real DSP.
Анализируемый диапазон частот 1кГц...2МГц. Реалтайм не обязателен, накопили отсчеты, посчитали, накопили, посчитали (на низких частотах с перекрытием окон).

В кортексе смущает, что по бенчмаркам 1к FFT делается примерно на 2 - 3 мс, у DSP примерно за 20 - 50 мкс. Также напрягает в кортексах недетерминированное время выполнения команд.

А в DSP напрягает всё остальное))

Использую исключительно целочисленную математику. Дробную часть выделяю в конце после бабочек. Разницы с плавучкой никакой.

А что значит "вычисляю"? Если уже получилась только целая часть, то откуда из неё получится дробная?

Элементарно. При вычислениях я считаю, что целой части вообще нет нигде. Что исходные данные лишь дробная часть, что результат. То есть, если вход 16 бит, 32767 это почти 1, а -32768 это почти -1. И коэффициенты тоже в таком же духе. Только 18 бит со знаком родные для ПЛИС. Каждый раз округляю модуль до вхождения результата в 18 бит со знаком.

Прикинул я скорость на Cortex-M7 4096 FFT. Выходит в районе 1 мс в 32 бит целочисленной математике и 1,3 мс в плавучке. Эти 0,3 мс перевод из 16 бит со знаком в плавучку. Тормозно весьма, хотя все и в тсм посадил. ПЛИС в радикс 8 вышло порядка 8 мкс. Но требуется 64 умножителя и немеренно брам.