Звиздец какое объяснение.
Я так понимаю, Вы пытаетесь донести вариант реализации умножения 1.15*1.15 -> 1.15 с использованием целочисленного умножителя.

Однако, к вопросу "И вот на выходе arm_cmplx_mag_q15() формат 2.14, как мне его преобразовать, чтобы получить значение амплитуды в отсчетах АЦП?" это имеет только косвенное отношение. И вот почему:

Диапазон значений корня из суммы квадратов вещественной и мнимой части в формате 1.15 (диапазон каждой что-то около -0.99997...0.99997) будет выходить за границы диапазона -1...1. Т.е., в общем случае, для представления модуля комплексного числа в вышеуказанном формате 16-ти битным числом потребуется фомат 2.14 (примерно -1.99994...1.99994). С округлением, ессно. Как именно получается этот результат, вопрос десятый.
С учётом того, что ТС собирается использовать нормировочный коэффициент (см. вопрос), использование формата 2.14 как 1.15 это всего лишь вопрос значения этого нормировочного коэффициента. Результат этой функции никуда сдвигать не надо.

Осторожнее с эмоциями, здесь им не место )



Не обязательно умножения. К стати, с умножением всё сложнее. Я скорее пытался объяснить, что значит такой формат в виде двух чисел с точкой, и почему он всего лишь мысленный.


Я там выше подобный механизм расписывал для бабочки:



А такое объяснение не понял теперь я )))

Осторожнее с изобретением объяснений типа "на пальцах". Можно попасть впросак.
Арифметика с фикс. точкой не так банальна, как это может показаться, это да.
Но все эти вопросы давно и очень хорошо изложены в соответствующей литературе.
Соответственно, доморощенные объяснения могут как прийти в противоречие с устоявшейся терминологией и практикой, так и привести к ошибкам.

С умножением всё достаточно просто.
Достаточно осознать, что из себя представляют диапазоны соответствующих форматов с фикс.точкой и диапазоны результатов операций.
Вот несколько наиболее показательных примеров:
Порядок диапазона для беззнаковых аргументов 16-бит и результата целочисленного умножения без знака (32 бита): 2^16 и 2^32. Как бы очивидно.
То же самое, но для аргументов со знаком: 2^16 и 2^31.
Теперь для 1.15.
Результат операции целочисленного умножения со знаком аргументов в формате 1.15 имеет тот же порядок диапазона - 2^31. Диапазон значений результата укладывается в -1...1.
Формат результата - 2.30. Порядок диапазона формата 2.30 - 2^32. Диапазон значений формата 2.30 укладывается в -2...2.
Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить.

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

1.15 и 2.14 - это фактически одно и то же. Различать их позволяет как раз нормировочный коэффициент.

Понятно: поперепирались по типу "ты дурак - сам дурак" )))
А как интересно Вы хотели, чтобы объяснялось? Просто 1:1 по учебнику? Дак ТС и сам его может прочитать. Ценность - в объяснении "своими словами".


А Вы этого сильно боитесь? Я не возражаю, если меня поправит более опытный коллега.


Тут теперь уже Ваши объяснения очень тяжело понять, так что даже дискутировать не могу. Единственно результат сдвигать надо вправо в последнем предложении, а округлить надо до сдвига.
К стати: вопрос на засыпку для разминки мозгов: почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд? )))


Давайте, учите меня писать БПФ ))) Я реализовал БПФ для сверхдлинных последовательностей )))


А я разве не про это же написал?



Зачем что-то запоминать, если заранее из теории БПФ известно, что бабочка делается 10 раз, и при каждой делается сдвиг на 1 разряд? Можно просто на выходе сделать обратный сдвиг на сразу известную константу.





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

что-то ТС пропал... у Вас всё заработало?

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

Вероятно, Вы пыталисьсь обобщить частный случай реализации целочисленного БПФ и сделали ошибку.




- Речь была о реализации функции умножения 1.15*1.15 -> 1.15 с помощью целочисленного умножения со знаком (ADI ещё используют описание типа 16.0*16.0 -> 32.0):

"Результат операции целочисленного умножения со знаком аргументов в формате 1.15 имеет тот же порядок диапазона - 2^31. Диапазон значений результата укладывается в -1...1.
Формат результата - 2.30. Порядок диапазона формата 2.30 - 2^32. Диапазон значений формата 2.30 укладывается в -2...2.
Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить."

А вот как говорят в ADI о реализации этой функции для одной из инструкций Блэкфина:
Signed fraction. Multiply 1.15 * 1.15 to produce 1.31 results after left-shift correction.
Round 1.31 format value at bit 16. (RND_MOD bit in the ASTAT register controls the rounding.)
Saturate the result to 1.15 precision in destination register half.
Result is between minimum -1 and maximum 1-2-15 (or, expressed in hex, between minimum 0x8000 and maximum 0x7FFF).

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

Возможно, Вы пытались поведать о чём-то другом, подразумевая ваше понимание какого-то частного случая.
Аналогично, заданный Вами вопрос о разрядности тоже оказался не слишком корректен.
Для такой детерминированной функции, как целочисленное умножение со знаком (16.0*16.0 -> 32.0), можно говорить о диапазоне значений результата или его порядке, а также о формате результата и диапазоне значений этого формата. И в этой части всё очевидно.




- Вероятно, Вы моделировали с табличным синусом или чем-то простеньким. Попробуйте на реальном сигнале типа OFDM. Фиксированная постадийная нормализация (может осуществляется в процессе вычисления бабочки) приведёт к потере гейна и, соответственно, к увеличению шума самого преобразования. И в отдельных случаях потери будут чувствительные (например, для 16-бит 8К БПФ на сигнале DVB-T это уже хорошо заметно, проверялось на реальном же железе, а о 16-ти битах для 32К DVB-T2 даже говорить нечего).

Так что, ваше обобщение касается только частных случаев. В общем случае оно неверно.



П.С. Судя по всему, Вы всё время пытаетесь интерпретировать единственный частный случай реализации целочисленного БПФ.
Это не есть правильно. Таки, лучше подучить матчасть для общего случая.

И что же неправильно во вращающихся векторах?


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


Я привёл условия типа "если каждую квадратуру выхода БПФ считать пронормированным к 1". Я согласен, что это для частного случая. Но для него я не сделал ошибку.


Согласен, если рассматривать иностранную цитату непогрешимой, то моё утверждение неверно. Но если считать, что цитата не является неоспоримой аксиомой, то ошибся не я, а цитата и Вы вместе с ней. Жирным с подчёркиванием я выделил места под вопросом.

"Всегда" - ошибка. Именно про это был мой "вопрос на засыпку", и засыпка произошла.

"Saturate the result to 1.15" - в рамках предыдущего "всегда" сатурация не требуется, там просто нечего сатурировать.

"after left-shift correction" - мне непонятно, почему влево. Вот пример:
Есть переменная 8 битов с форматом 4.4, её нужно вместить с потерей дробной части в 4-битную переменную 4.0. Что мы делаем:


Сдвиг-то вправо.

Ещё как корректен, просто это нужно прощупать "на своей шкуре".

Очевидно, но первое, что очевидно, оказывается неверным. Вопрос на засыпку был "почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд"? Очевидно это 31 разряд, а не 32. Потому что при умножении полезные данные сосредоточены в младших 15 битах операндов, следовательно 15 * 15 получаем 30 и 1 бит знака. 31 разряд в результате. Откуда 32?


Согласен, тут я сделал свой вывод только для своего сигнала. Он был реальный, но с сильным преобладанием несущей, на фоне которой нужно было обнаружить отражения с допплером.


А Вы уверены, что смогли охватить этот самый общий случай? Он бесконечен. Все случаи учесть невозможно. Так-то хорошо все утверждения парировать, что это не годится, в общем случае работать не обязано. Универсальный козырь.

Я извиняюсь, запутался. Действительно, здесь надо влево. БПФ усилил, но, чтобы влезть в разрядность сдвинул вправо с потерей младших битов. А чтобы получить число в его реальном масштабе, нужно обратно сдвинуть влево.

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

Мне в своё время пришлось довольно долго объяснять заказчику, почему для их задачи лучше использовать радикс-2, а не 4, а ещё лучше соскочить с 16-бит АДи на 32-бит ТИ и избавиться от нескольких неудачных решений. Уговорил. Но с терминологией и мелочами пришлось разбираться серьёзно и, опять же, доносить до заказчика. При том, что заказчик с ЦОС не по-наслышке знаком, и вообще весьма крут и хорошо известен в узких кругах.

Ну, да ладно. Базар мы слегка не по-делу устроили, но кому-то он может оказаться полезным.
Объясняльщики мы оба никакие, но суть возможных неприятностей с целочисленными БПФ наверное донесли. И то ладно.


А вот если по сабжу, то возникает банальный вопрос. Зачем ТС морочится с 16-бит БПФ на F4?
Ну, разве что память экономит, но не факт, что это правильно в перспективе дальнейшего развития.

куда делся ТС? Мы уже тут со скуки похоливарить успели, а его всё нет )))

Я сильно извиняюсь, за то, что пропал. Меня отправили в командировку, не могу сейчас ответить по существу. Как только вернусь покажу, что у меня получилось.

Расскажите чем все закончилось. Куда, что и когда надо сдвигать чтоб в итоге получить правильные значения амплитуды гармоник?

У меня все красиво заработало. Спасибо всем кто помогал и принимал участие! Ниже привожу пример на базе все той же dsp библиотеки. Делаю следующее сначала генерирую сигнал, потом загоняю его в FFT:



Если нужно я могу конечно выложить весь проект, но там сделано на базе STMCube, так что очень много всего лишнего и весит при этом такой проект невменяемо много.

Очень хотелось бы увидеть более полную картину, где уже используется АЦП. Если не затруднит выложите пожалуйста.

Выложу в понедельник - пример у меня на работе