А математически вычислить никак? )) По крайней мере не для живого сигнала и для кратных частот. Я думаю, с этого надо начать.
А для живого сигнала, конечно, уже, как написано тут:

Правильно ли я понимаю что речь идет просто о вычислении амплитуды комплексного числа?

Но ведь именно это и делает arm_cmplx_mag_q15(). После ДПФ input[] уже содержит в себе действительную и мнимую составляющие, из них можно вычислить и амплитуду и фазу. Я вычислил амплитуды и построил по ним график, но результат мне не понятен. Или я что-то путаю?

А какую частоту синусоиды взяли? Можете файл прикрепить с отсчётами? Фактически интересует, сколько сэмплов период повторения. Но файл лучше )



А в чём Ваша ошибка была? Вы вообще неправильно данные на вход подали? Да, для вещественного синуса комплексная часть равна нулю.



Почитайте на вики про бабочку в операциях БПФ, тогда все вопросы исчезнут. В 2х словах: формат 1.15 означает 16-битное представление, 1 бит под целую часть (он же знак, поэтому под целую часть нет ничего, и число должно быть меньше 1), а 15 битов - под дробную часть. Грубо говоря, в таком формате все числа пронормированы к 1.
Бабочка выполняет умножение входного числа (отсчёта синуса) на поворачивающий множитель. Поворачивающий множитель по определению не превышает 1, поэтому его формат тоже выбран 1.15 (хотя, это чуть-чуть некорректно, и в своей реализации я выбрал честный формат). После умножения бабочка делает сложение. Отсюда разрядность должна увеличиться на 1 бит. Разрядная сетка у нас фиксирована 16 битами, поэтому приходится отбросить младший бит дробной части, чтобы не словить переполнение. Отсюда получается результирующий формат на выходе бабочки 2.14. Бабочка выполняется над массивом данных 1024 сэмпла 10 раз, поэтому в результате точка съезжает аж на 10 разрядов вправо, про это говорят "гейн БПФ".



Чтобы получить правильную амплитуду, нужно результат поделить на вышеупомянутый гейн. Можно и не делить физически, а "держать в уме" наличие усиленного результата. Так что делить или не делить - от этого качественно картинка меняться не должна, кривая спектра всё равно будет выглядеть одинаково внешне, и палки частот всё равно должны быть в нужных местах. Вы сначала добейтесь правильного положения палок, а затем уже думайте о правильном измерении абсолютного уровня амплитуды палки.

Чуть позже смогу выложить файл с синусоидой. Ошибка была в том, что я ложил данные во входной массив "подряд", а нужно было писать ноль в ячейки с комплексными значениями.
Я добился того, что "палки" находятся "на своих местах". Про бабочку почитаю подробно, пока только и знаю что весь принцип БПФ основан на бабочках (они могут быть по основанию 2,4,8, теоретически возможно и более, но практически слабо реализуемо). А что касается гейна БПФ - ведь я и сместил на 10 разрядов (или если хотите разделил на 2^10), но и после этого на выходе значения даже не близкие к реальным значениям амплитуд гармоник. Выход тоже пронормирован к 1 верно? Значит, чтобы получить амплитуды реальные амплитуды гармоник, то мне нужно сделать так: output[i]/2^15 * 2^12 (мой АЦП 12 бит)?

Я уже сам запутался, кому и что надо )) Вы напишите ещё раз, что хотите рассчитать и что не срастается?



А вообще, Вам бы книжку почитать по БПФ. Мне нравится пример на стр. 151 в книжке Лайонс_-_ЦОС_2е_издание_русский_перевод_2006 (можно скачать в местных закромах). Там хотя бы понятно, как образуются амплитуды и отсчёты, откуда берутся такие числа. Хорошо всё разжёвано. У Вас должно получиться также, как в примере. Да и вообще в этой книжке хорошо даётся материал касаемо данного вопроса.

- Что хочу получить: амплитуды гармоник в отсчетах АЦП.

- И да, пожалуй, пойду перечитаю про БПФ. Спасибо за источник!

Я не программист, поэтому в Ваши исходники копаться не полезу, спрашиваю так: вход с АЦП у Вас как переменная описан с плавающей точкой или с фиксированной? Каким конкретно типом, какой разрядности? И что значит "сместил на 10 разрядов", какой операцией? Сместил вход или выход БПФ?

Покажите, пожалуйста, полный получившийся спектр. Вы приводили выше картинку, но она похоже неполная, там нет отрицательной частоты. И вот Вы пишете, что "значения даже не близкие". Напишите прямо: подал столько-то, поэтому по расчётам (как рассчитывал?) ожидаю получить столько-то, но по рисунку спектра видно столько-то.

А Вы на вход подавали просто 12-битные отсчёты АЦП? Тогда если результат поделить на 1024, то должна получиться половинная амплитуда входной синусоиды в попугаях входного 12-битного сигнала.

Вход АЦП - целочисленная перменная (12 бит), которая хранится в uint16. Эти значения накапливаются в массиве input[] (он имеет тип q15_t, который по сути просто переопределение int16) без каких бы то нибыл изменений (просто взял АЦП и переложил в этот массив) в таком порядке: input[n] - действительная часть, input[n+1] - комплексная (n=0,2,4,6,8...) - в таком виде их нужно там располагать, если я правильно понял документацию на DSP библиотеку. Вот в действительную часть я положил значения АЦП. Этот массив отправляется в функцию arm_cfft_radix2_q15(), которая вообщем то и делает комплексное быстрое преобразование Фурье по основанию 2. Результат в комплексном виде кладет во все тот же массив input[]. Далее, чтобы вычислить амплитуду комплексного числа, в библиотеке DSP есть функция arm_cmplx_mag_q15(), которая в выходном массиве для каждого комплексного числа (в мое случае пары членов input[n] и input[n+1]) находит значение амплитуды (корень квадратный из суммы действительного и мнимого компонента). Однако, чтобы эту функция правильно посчитала, нужно, как я понял, во входном массиве input[] каждый член сдвинуть влево на 10 бит: for (u32 i=0; i<2048; i++) input[i] = input[i]<<10 и только потом передавать функции arm_cmplx_mag_q15() в качестве параметра. В результате я рассчитывал получить массив амплитуд гармоник, составляющий мой сигнал. Вообщем-то массив и получился, с "палкой" в том месте, где я и рассчитывал получить его (output[0] и output[50] - ведь я подал смещенную синусоиду с частотой 50 Гц). Если Вы спрашивали значения этого выходного массива, то вот они в десятичной системе счисления. Подал синусоиду 500 милливольт, при разрядности АЦП 12 бит я рассчитывал увидеть число 610 в десятичной системе (или 262h хексе), а получил 17438 в десятичной (или 441E в хексе). В полном виде на картинке он выглядит вот так:

Спасибо, теперь всё гораздо понятнее.
А входной сигнал выложите, пожалуйста.

И Вы пишете, что подали 500мВ, а какое напряжение полной шкалы? АЦП двухполярный? Т.е. 1 бит под знак, а значения в доп.коде на выходе? И вообще, лучше давайте продолжать работать не с живыми данными АЦП. Сначала надо отладить всё на идеальной модели входного сигнала, где всё точно.

С какой разрядностью на входе и выходе работает функция arm_cmplx_mag_q15()?

И ещё Вы пишете:
Если не будет выхода за предела разрядной сетки, сдвиг можно сделать хоть до, хоть после функции. Но Вы ещё не назвали разрядность, поэтому как будет известно - будем думать.

И сдвиг вправо, а не влево. Это ошибка в Ваших расчётах или просто опечатка? Если ошибка, то прошу все вышеприведённые цифры повторить заново после исправления.

Функция arm_cmplx_mag_q15() принимает на вход массив, состоящий 16 битных знаковых значений. В описании к функции написано следующее:



Я еще так и до конца и не разобрался, что значит форматы 1.15 и 2.14. Но из описания следует, что на вход подаем в формате 1.15, а на выходе имеем 2.14. Более того, входные значения у этой функции в комплексной форме, как я уже и писал - input[n] - действительная часть, input[n+1] - комплексная (n=0,2,4,6,8...). В эту функцию я отправляю массив только после БПФ, предварительно сдвинув каждый член на 10 бит ВЛЕВО, ошибки тут нет:



Сделал все сначала на сгенерированном массиве. По-порядку, что я сделал:

1) Сгенерировал 1024 точки синуса с частотой 50 Гц и амплитудой 600. Сигнал двуполярный один бит знак, остальное в дополнительном коде. Вот по такой схеме (с матлабом связываться не стал, проще было прям внутри моей программы его генерировать):



Получилась вот такая картинка:



2) Далее полученные массив отправил на обработку в DSP либу, получилась вот такая характеритика:

Мы говорим про функцию, которая рассчитывает амплитуду частотных составляющих по их мнимой и действительной частям?


Ну я Вам про форматы пытался выше объяснить. Если что - спрашивайте конкретные вопросы, поясню более детально.
В рамках конкретной функции такие форматы можно объяснить: если каждую квадратуру выхода БПФ считать пронормированным к 1, то амплитуда в корень из 2 будет больше 1, поэтому при сохранении входного формата возникнет переполнение, следовательно положение точки нужно сдвинуть.
Но на самом деле этого не требуется конкретно для БПФ, т.к. заранее известно, что комплексные числа - это вращающиеся вектора, которые не могут выходить за единичную окружность, тогда и модуль не может превышать 1.


А надо-то вправо. БПФ усилил на гейн. Надо вернуть обратно.


А частота дискретизации тогда какая?


По этим картинкам видно, что частота сигнала у Вас не кратна частоте дискретизации. Подайте кратную частоту, так гораздо удобнее сначала разбираться, почему БПФ не дал ожидаемую амплитуду.

Да, arm_cmplx_mag_q15() рассчитывает амплитуду по мнимой и комплексной части.

По поводу форматов конкретный вопрос собственно такой: У меня есть знаковое целочисленное число - отсчеты моего АЦП. Нужно ли его преобразовать, чтобы получить формат 1.15 ибо именно в таком формате мне нужно подавать данные на вход FFT? И вот на выходе arm_cmplx_mag_q15() формат 2.14, как мне его преобразовать, чтобы получить значение амплитуды в отсчетах АЦП?

По поводу гейна и сдвига. В том-то и дело, если сдвигать ВПРАВО, то в выходном массиве после вызова arm_cmplx_mag_q15() одни нули. Если не сдвигать, то картинка характеристики "обрезается", нет "нижних" маленьких "тычков" (гармоники с малой амплитудой).

Частота дискретизации 1024 Гц. Повторил эксперимент для частоты сгенерированного математически сигнала 32 Гц (т.е. 1024 кратно 32), амплитуда 600. Картинка исходного сигнала вот:



На выходе вот такая картинка:

Положение точки в числах с фиксированной точкой - понятие чисто условное, которое существует только в головах разработчиков, чтобы понимать, какое реальное число представлено в коде из скажем 8 битов.
Например, дана переменная 8 битов со значением битов 48. Сказано, что эта переменная имеет формат s3.5. Какое же реальное число закодировано в этих 8 битах? Закодировано 1,5. А если это s4.4 - закодировано 3.
Внутри вычислителя положение точки никак не фигурирует, для него это всегда полностью целые числа, без дробной части. Но разработчик, зная, что входной 8-битный знаковый поток он представил в уме, скажем, как нормализованный к 1 (т.е. s1.7 - это реальные числа сдвинутые влево на 7 битов), понимает, что результат ему надо задвинуть обратно на те же 7 битов, чтобы получить правильный результат в его реальных числах, которые он представлял в уме.
Т.е. у нас есть инструмент, который оперирует только целыми числами. И у нас есть реальные числа, которые никак не укладываются в диапазон этого инструмента. Нам надо сначала в уме растянуть наши числа на полную шкалу инструмента, а затем результат (он опять в целых числах) обратно сжать на столько же битов. Для 8-битных чисел, например, инструмент понимает числа до 127, а реальные числа у нас не больше 1. Поэтому все наши реальные числа надо умножить на 127, чтобы влезть в полную шкалу инструмента.
Возвращаясь к ответу на исходный вопрос:
На входе предполагается (в уме) формат 1.15, а на выходе 2.14. Как это понять?
Отвлечённый пример: пусть на входе формат 1.15 и на выходе формат 1.15. Это означает, что положение точки в одном и том же месте. Если на входе мы свои числа растянули на полную шкалу, сдвинув влево на 15 разрядов, то на выходе нужно сдвинуть вправо. А если мы на входе ничего не сдвигали (это всё равно мысленная операция в конце концов), то и на выходе ничего сдвигать не надо.
Теперь вернёмся к конкретно нашим цифрам: на входе 1.15, на выходе 2.14. Даже если мы вход мысленно не сдвигали, то выход будет всё равно сдвинут функцией на 1 бит, при том вправо. Чтобы получить число в том же масштабе, что и входное, потребуется сдвинут результат на 1 бит влево.
Вот Вам и ответ. Т.е. вход сдвигать не надо вообще, а выход - на 1 бит влево.


Понятно, Вы методом научного тыка решили, что сдвигать всё же надо )))
Я придерживаюсь мнения, что сдвигать вообще не надо никуда, функция БПФ и так всё сделала за Вас, оно и логично по-идее с точки зрения разработки юзер-френдли интерфейса, чтобы пользователь не парил голову, сколько стадий бабочки прошло, ему нужен только готовый результат.
Однако вот тут мне непонятно:
Откуда у Вас после сдвига влево спектр приобретает "нижние маленькие тычки", если без сдвига их нет? До сдвига эта информация должна быть уже заложена в несдвинутый сигнал. А если она заложена, то как она обрезается отсутствием каких-либо действий (случай без сдвига)? Не должно такого быть. Подумайте, может, где-то ошибка.


Другое дело. Вот с этого сразу и надо было начинать.
К стати, по картинке спектра: левая и правая палки имеют разный уровень. Этого быть не должно. Уж не знаю, откуда взялось. Может, функция кривая, может, мнимая часть где-то пролезла (хотя почти не реально). Может, другие участники форума подскажут, откуда берётся этот эффект. Если не найдётся причина - предлагаю входные числа затолкать в матлаб один к одному, и над ними проделать fft(). Там должно быть одинаково.

Спасибо большое, за объяснения форматов! Наконец-то стало понятно.

А по-поводу сдвига. Я же сдвигаю ПЕРЕД тем как ложить в функцию arm_cmplx_mag_q15(), а в ВЫХОДНОМ массиве уже смотрю есть тычки или нет. Если не сдвигать вообще ВХОДНЫЕ ДАННЫЕ, то и в выходном массиве ничего кроме нулей нет, если сдвигать недостаточно сильно, то в выходном массиве "срезается" нижняя часть характеристики.

Пожалуйста!

А во входном массиве (т.е. на выходе БПФ) есть что-то кроме нулей в тех точках, где нет палок? Можете показать вещественный спектр и мнимый спектр до сдвига и до выделения амплитуды?
Даже если Вы сдвинули вход, чтобы повысить разрешение, то после этого нужно сдвинуть обратно, чтобы сохранить правильный масштаб чисел. И тогда всё равно получите нули ))