реклама на сайте
подробности

 
 
4 страниц V  < 1 2 3 4 >  
Reply to this topicStart new topic
> FFT stm32f407 лишние гармоники в выходном массиве
prig
сообщение Aug 25 2015, 09:00
Сообщение #31


Знающий
****

Группа: Свой
Сообщений: 786
Регистрация: 30-01-08
Из: СПб
Пользователь №: 34 595



Цитата(Krys @ Aug 25 2015, 10:28) *
...
Теперь вернёмся к конкретно нашим цифрам: на входе 1.15, на выходе 2.14. Даже если мы вход мысленно не сдвигали, то выход будет всё равно сдвинут функцией на 1 бит, при том вправо. Чтобы получить число в том же масштабе, что и входное, потребуется сдвинут результат на 1 бит влево.
Вот Вам и ответ. Т.е. вход сдвигать не надо вообще, а выход - на 1 бит влево.
...


Звиздец какое объяснение.
Я так понимаю, Вы пытаетесь донести вариант реализации умножения 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 это всего лишь вопрос значения этого нормировочного коэффициента. Результат этой функции никуда сдвигать не надо.
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 25 2015, 09:47
Сообщение #32


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



Цитата(prig @ Aug 25 2015, 16:00) *
Звиздец какое объяснение.
Осторожнее с эмоциями, здесь им не место )



Цитата(prig @ Aug 25 2015, 16:00) *
Я так понимаю, Вы пытаетесь донести вариант реализации умножения 1.15*1.15 -> 1.15 с использованием целочисленного умножителя.
Не обязательно умножения. К стати, с умножением всё сложнее. Я скорее пытался объяснить, что значит такой формат в виде двух чисел с точкой, и почему он всего лишь мысленный.


Цитата(prig @ Aug 25 2015, 16:00) *
Диапазон значений корня из суммы квадратов вещественной и мнимой части в формате 1.15 (диапазон каждой что-то около -0.99997...0.99997) будет выходить за границы диапазона -1...1. Т.е., в общем случае, для представления модуля комплексного числа в вышеуказанном формате 16-ти битным числом потребуется фомат 2.14 (примерно -1.99994...1.99994). С округлением, ессно. Как именно получается этот результат, вопрос десятый.
Я там выше подобный механизм расписывал для бабочки:
Цитата(Krys @ Aug 25 2015, 11:52) *
В рамках конкретной функции такие форматы можно объяснить: если каждую квадратуру выхода БПФ считать пронормированным к 1, то амплитуда в корень из 2 будет больше 1, поэтому при сохранении входного формата возникнет переполнение, следовательно положение точки нужно сдвинуть.
Но на самом деле этого не требуется конкретно для БПФ, т.к. заранее известно, что комплексные числа - это вращающиеся вектора, которые не могут выходить за единичную окружность, тогда и модуль не может превышать 1.



Цитата(prig @ Aug 25 2015, 16:00) *
С учётом того, что ТС собирается использовать нормировочный коэффициент (см. вопрос), использование формата 2.14 как 1.15 это всего лишь вопрос значения этого нормировочного коэффициента. Результат этой функции никуда сдвигать не надо.
А такое объяснение не понял теперь я )))




--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
prig
сообщение Aug 25 2015, 11:22
Сообщение #33


Знающий
****

Группа: Свой
Сообщений: 786
Регистрация: 30-01-08
Из: СПб
Пользователь №: 34 595



Цитата(Krys @ Aug 25 2015, 12:47) *
Осторожнее с эмоциями, здесь им не место )



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


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



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


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

С умножением всё достаточно просто.
Достаточно осознать, что из себя представляют диапазоны соответствующих форматов с фикс.точкой и диапазоны результатов операций.
Вот несколько наиболее показательных примеров:
Порядок диапазона для беззнаковых аргументов 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 - это фактически одно и то же. Различать их позволяет как раз нормировочный коэффициент.
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 26 2015, 03:50
Сообщение #34


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



Цитата(prig @ Aug 25 2015, 18:22) *
Осторожнее с изобретением объяснений типа "на пальцах".
Понятно: поперепирались по типу "ты дурак - сам дурак" )))
А как интересно Вы хотели, чтобы объяснялось? Просто 1:1 по учебнику? Дак ТС и сам его может прочитать. Ценность - в объяснении "своими словами".


Цитата(prig @ Aug 25 2015, 18:22) *
Осторожнее с изобретением объяснений типа "на пальцах". Можно попасть впросак.
А Вы этого сильно боитесь? Я не возражаю, если меня поправит более опытный коллега.


Цитата(prig @ Aug 25 2015, 18:22) *
С умножением всё достаточно просто.
Достаточно осознать, что из себя представляют диапазоны соответствующих форматов с фикс.точкой и диапазоны результатов операций.
Вот несколько наиболее показательных примеров:
Порядок диапазона для беззнаковых аргументов 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 и потом округлить.
Тут теперь уже Ваши объяснения очень тяжело понять, так что даже дискутировать не могу. Единственно результат сдвигать надо вправо в последнем предложении, а округлить надо до сдвига.
К стати: вопрос на засыпку для разминки мозгов: почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд? )))


Цитата(prig @ Aug 25 2015, 18:22) *
С БПФ у Вас как раз незадача и вышла.
Давайте, учите меня писать БПФ ))) Я реализовал БПФ для сверхдлинных последовательностей )))


Цитата(prig @ Aug 25 2015, 18:22) *
Если использовать арифметику 1.15*1.15 -> 1.15 и 1.15+-1.15 -> 1.15 , возможность переполнения при вычислении БПФ гарантирована.
Именно из-за этого используется 1 или 2 "защитных" бита для радикса-2 или радикса-4 соответстенно.
А я разве не про это же написал?
Цитата(Krys @ Aug 24 2015, 11:00) *
Бабочка выполняет умножение входного числа (отсчёта синуса) на поворачивающий множитель. Поворачивающий множитель по определению не превышает 1, поэтому его формат тоже выбран 1.15 (хотя, это чуть-чуть некорректно, и в своей реализации я выбрал честный формат). После умножения бабочка делает сложение. Отсюда разрядность должна увеличиться на 1 бит. Разрядная сетка у нас фиксирована 16 битами, поэтому приходится отбросить младший бит дробной части, чтобы не словить переполнение. Отсюда получается результирующий формат на выходе бабочки 2.14. Бабочка выполняется над массивом данных 1024 сэмпла 10 раз, поэтому в результате точка съезжает аж на 10 разрядов вправо, про это говорят "гейн БПФ".



Цитата(prig @ Aug 25 2015, 18:22) *
Т.е. весь входной массив нормируется до необходимых значений. Нормировочный коэффициент запоминается.
Зачем что-то запоминать, если заранее из теории БПФ известно, что бабочка делается 10 раз, и при каждой делается сдвиг на 1 разряд? Можно просто на выходе сделать обратный сдвиг на сразу известную константу.


Цитата(prig @ Aug 25 2015, 18:22) *
Кроме того, на таком формате обычно используется групповая плавающая точка. Т.е., постадийная нормировка по-необходимости. Нормировочный к-т обновляется, ессно.
С промежуточной арифметикой 2.30+-2.30 -> 2.30 всё немного по-другому, но постадийная нормировка нормировка всё равно обычно используется.

Прикрепленное изображение


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


--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 27 2015, 07:55
Сообщение #35


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



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


--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
prig
сообщение Aug 27 2015, 10:59
Сообщение #36


Знающий
****

Группа: Свой
Сообщений: 786
Регистрация: 30-01-08
Из: СПб
Пользователь №: 34 595



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


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

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


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


- Речь была о реализации функции умножения 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), можно говорить о диапазоне значений результата или его порядке, а также о формате результата и диапазоне значений этого формата. И в этой части всё очевидно.


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


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

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



П.С. Судя по всему, Вы всё время пытаетесь интерпретировать единственный частный случай реализации целочисленного БПФ.
Это не есть правильно. Таки, лучше подучить матчасть для общего случая.
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 28 2015, 03:59
Сообщение #37


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



Цитата(prig @ Aug 27 2015, 17:59) *
Цитата(Krys @ Aug 25 2015, 11:52) *

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

- Подчёркнутое утверждение неверно. Вращающиеся вектора - неправильное объяснение.
И что же неправильно во вращающихся векторах?


Цитата(prig @ Aug 27 2015, 17:59) *
В зависимости от используемых целочисленных операций, сдвиг (нормализация) может осуществляться в процессе вычисления "бабочки" БПФ.
Приведите пожалуйста пример, где модуль выхода БПФ больше максимально возможного размаха его квадратур. Для векторов, вращающихся вокруг единичной окружности это невозможно.


Цитата(prig @ Aug 27 2015, 17:59) *
Вероятно, Вы пыталисьсь обобщить частный случай реализации целочисленного БПФ и сделали ошибку.
Я привёл условия типа "если каждую квадратуру выхода БПФ считать пронормированным к 1". Я согласен, что это для частного случая. Но для него я не сделал ошибку.


Цитата(prig @ Aug 27 2015, 17:59) *
Т.е., два старших бита результата умножения 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).

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

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

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

"after left-shift correction" - мне непонятно, почему влево. Вот пример:
Есть переменная 8 битов с форматом 4.4, её нужно вместить с потерей дробной части в 4-битную переменную 4.0. Что мы делаем:
Код
исходная переменная, физическая разрядность (не так, которую мы
подразумеваем форматом 4.4):
                            7 6 5 4 3 2 1 0

Надо вместить в переменную:         3 2 1 0

Если просто скопировать биты 3..0 в биты 3..0 - сохранится младшая часть

Тогда исходную переменную надо сдвинуть вправо:

                            0 0 0 0 7 6 5 4
                            
А затем просто скопировать биты 3..0 в биты 3..0:
                            
Исходная переменная:        0 0 0 0 7 6 5 4
Копируем:                           | | | |
Конечная переменная:                7 6 5 4


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

Цитата(prig @ Aug 27 2015, 17:59) *
Аналогично, заданный Вами вопрос о разрядности тоже оказался не слишком корректен.
Ещё как корректен, просто это нужно прощупать "на своей шкуре".

Цитата(prig @ Aug 27 2015, 17:59) *
Для такой детерминированной функции, как целочисленное умножение со знаком (16.0*16.0 -> 32.0), можно говорить о диапазоне значений результата или его порядке, а также о формате результата и диапазоне значений этого формата. И в этой части всё очевидно.
Очевидно, но первое, что очевидно, оказывается неверным. Вопрос на засыпку был "почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд"? Очевидно это 31 разряд, а не 32. Потому что при умножении полезные данные сосредоточены в младших 15 битах операндов, следовательно 15 * 15 получаем 30 и 1 бит знака. 31 разряд в результате. Откуда 32?


Цитата(prig @ Aug 27 2015, 17:59) *
- Вероятно, Вы моделировали с табличным синусом или чем-то простеньким.
Согласен, тут я сделал свой вывод только для своего сигнала. Он был реальный, но с сильным преобладанием несущей, на фоне которой нужно было обнаружить отражения с допплером.


Цитата(prig @ Aug 27 2015, 17:59) *
П.С. Судя по всему, Вы всё время пытаетесь интерпретировать единственный частный случай реализации целочисленного БПФ.
Это не есть правильно. Таки, лучше подучить матчасть для общего случая.
А Вы уверены, что смогли охватить этот самый общий случай? Он бесконечен. Все случаи учесть невозможно. Так-то хорошо все утверждения парировать, что это не годится, в общем случае работать не обязано. Универсальный козырь.


--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 28 2015, 06:07
Сообщение #38


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



Цитата(Krys @ Aug 25 2015, 11:52) *
А надо-то вправо. БПФ усилил на гейн. Надо вернуть обратно.
Я извиняюсь, запутался. Действительно, здесь надо влево. БПФ усилил, но, чтобы влезть в разрядность сдвинул вправо с потерей младших битов. А чтобы получить число в его реальном масштабе, нужно обратно сдвинуть влево.


--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
prig
сообщение Aug 28 2015, 09:10
Сообщение #39


Знающий
****

Группа: Свой
Сообщений: 786
Регистрация: 30-01-08
Из: СПб
Пользователь №: 34 595



Цитата(Krys @ Aug 28 2015, 09:07) *
Я извиняюсь, запутался.
...


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

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

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


А вот если по сабжу, то возникает банальный вопрос. Зачем ТС морочится с 16-бит БПФ на F4?
Ну, разве что память экономит, но не факт, что это правильно в перспективе дальнейшего развития.
Go to the top of the page
 
+Quote Post
Krys
сообщение Aug 31 2015, 08:21
Сообщение #40


Гуру
******

Группа: Свой
Сообщений: 2 000
Регистрация: 17-01-06
Из: Томск, Россия
Пользователь №: 13 271



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


--------------------
Зная себе цену, нужно ещё и пользоваться спросом...
Go to the top of the page
 
+Quote Post
yanvasiij
сообщение Sep 1 2015, 08:44
Сообщение #41


Местный
***

Группа: Свой
Сообщений: 321
Регистрация: 23-12-11
Из: Уфа
Пользователь №: 69 041



Цитата(Krys @ Aug 31 2015, 13:21) *
куда делся ТС? Мы уже тут со скуки похоливарить успели, а его всё нет )))


Я сильно извиняюсь, за то, что пропал. Меня отправили в командировку, не могу сейчас ответить по существу. Как только вернусь покажу, что у меня получилось.
Go to the top of the page
 
+Quote Post
alex2103
сообщение Feb 9 2016, 12:35
Сообщение #42


Частый гость
**

Группа: Свой
Сообщений: 115
Регистрация: 7-03-07
Из: г. Запорожье
Пользователь №: 25 945



Цитата(yanvasiij @ Sep 1 2015, 11:44) *
Я сильно извиняюсь, за то, что пропал. Меня отправили в командировку, не могу сейчас ответить по существу. Как только вернусь покажу, что у меня получилось.

Расскажите чем все закончилось. Куда, что и когда надо сдвигать чтоб в итоге получить правильные значения амплитуды гармоник?
Go to the top of the page
 
+Quote Post
yanvasiij
сообщение Feb 15 2016, 04:22
Сообщение #43


Местный
***

Группа: Свой
Сообщений: 321
Регистрация: 23-12-11
Из: Уфа
Пользователь №: 69 041



Цитата(alex2103 @ Feb 9 2016, 17:35) *
Расскажите чем все закончилось. Куда, что и когда надо сдвигать чтоб в итоге получить правильные значения амплитуды гармоник?


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

CODE

#define FFT_LEN 1024
#define TEST_FREQUENCY 31.969f
#define TEST_AMPL 600.0f

#define TEST_AMPL3 500.0f
#define TEST_FREQUENCY3 64

#define TEST_AMPL4 400.0f
#define TEST_FREQUENCY4 72

#define TEST_AMPL5 300.0f
#define TEST_FREQUENCY5 96

#define TEST_AMPL6 200.0f
#define TEST_FREQUENCY6 128

#define TEST_AMPL2 100.0f
#define TEST_FREQUENCY2 160

...
for (u32 i = 0; i < FFT_LEN; i++)
{
float tmp;
tmp = TEST_AMPL * sin( (TEST_FREQUENCY*2*PI/(FFT_LEN-1)) * i);
tmp += TEST_AMPL2 * sin( (TEST_FREQUENCY2*2*PI/(FFT_LEN-1)) * i);
tmp += TEST_AMPL3 * sin( (TEST_FREQUENCY3*2*PI/(FFT_LEN-1)) * i);
tmp += TEST_AMPL4 * sin( (TEST_FREQUENCY4*2*PI/(FFT_LEN-1)) * i);
tmp += TEST_AMPL5 * sin( (TEST_FREQUENCY5*2*PI/(FFT_LEN-1)) * i);
tmp += TEST_AMPL6 * sin( (TEST_FREQUENCY6*2*PI/(FFT_LEN-1)) * i);
tmp += 600;
int tmpInt;
tmpInt = tmp;
fInput[inputShift] = tmp;
fInput[inputShift+1] = 0;
input[inputShift++] = tmpInt;
input[inputShift++] = 0;
}
for (u32 i = 0; i < FFT_LEN*2; i++)
input[i] = fInput[i];

arm_cfft_f32(&arm_cfft_sR_f32_len1024, fInput, 0, 1);
arm_cmplx_mag_f32 (fInput, fOutput, FFT_LEN);
fOutput[0] = (fOutput[0]*NORMIRATION_COEF)/2;
output[0] = fOutput[0];
for (u32 k=1; k<FFT_LEN; k++)
{
fOutput[k] = fOutput[k]*NORMIRATION_COEF;
output[k] = fOutput[k];
}
...


Если нужно я могу конечно выложить весь проект, но там сделано на базе STMCube, так что очень много всего лишнего и весит при этом такой проект невменяемо много.
Go to the top of the page
 
+Quote Post
Apparatchik
сообщение Apr 21 2017, 06:39
Сообщение #44





Группа: Участник
Сообщений: 8
Регистрация: 4-08-12
Пользователь №: 73 014



Цитата(yanvasiij @ Feb 15 2016, 06:22) *
Если нужно я могу конечно выложить весь проект, но там сделано на базе STMCube, так что очень много всего лишнего и весит при этом такой проект невменяемо много.

Очень хотелось бы увидеть более полную картину, где уже используется АЦП. Если не затруднит выложите пожалуйста.
Go to the top of the page
 
+Quote Post
yanvasiij
сообщение Apr 23 2017, 06:34
Сообщение #45


Местный
***

Группа: Свой
Сообщений: 321
Регистрация: 23-12-11
Из: Уфа
Пользователь №: 69 041



Выложу в понедельник - пример у меня на работе
Go to the top of the page
 
+Quote Post

4 страниц V  < 1 2 3 4 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd November 2017 - 22:15
Рейтинг@Mail.ru


Страница сгенерированна за 0.01445 секунд с 7
ELECTRONIX ©2004-2016