Цитата(yanvasiij @ Aug 25 2015, 13:42)

По поводу форматов конкретный вопрос собственно такой: У меня есть знаковое целочисленное число - отсчеты моего АЦП. Нужно ли его преобразовать, чтобы получить формат 1.15 ибо именно в таком формате мне нужно подавать данные на вход FFT? И вот на выходе arm_cmplx_mag_q15() формат 2.14, как мне его преобразовать, чтобы получить значение амплитуды в отсчетах АЦП?
Положение точки в числах с фиксированной точкой - понятие чисто условное, которое существует только в головах разработчиков, чтобы понимать, какое реальное число представлено в коде из скажем 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 бит влево.
Цитата(yanvasiij @ Aug 25 2015, 13:42)

По поводу гейна и сдвига. В том-то и дело, если сдвигать ВПРАВО, то в выходном массиве после вызова arm_cmplx_mag_q15() одни нули. Если не сдвигать, то картинка характеристики "обрезается", нет "нижних" маленьких "тычков" (гармоники с малой амплитудой).
Понятно, Вы методом научного тыка решили, что сдвигать всё же надо )))
Я придерживаюсь мнения, что сдвигать вообще не надо никуда, функция БПФ и так всё сделала за Вас, оно и логично по-идее с точки зрения разработки юзер-френдли интерфейса, чтобы пользователь не парил голову, сколько стадий бабочки прошло, ему нужен только готовый результат.
Однако вот тут мне непонятно:
Цитата(yanvasiij @ Aug 25 2015, 13:42)

Если не сдвигать, то картинка характеристики "обрезается", нет "нижних" маленьких "тычков" (гармоники с малой амплитудой).
Откуда у Вас после сдвига влево спектр приобретает "нижние маленькие тычки", если без сдвига их нет? До сдвига эта информация должна быть уже заложена в несдвинутый сигнал. А если она заложена, то как она обрезается отсутствием каких-либо действий (случай без сдвига)? Не должно такого быть. Подумайте, может, где-то ошибка.
Цитата(yanvasiij @ Aug 25 2015, 13:42)

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