ARDUINO Цветомузыка на MSGEQ7 и на фильтрах

ЦМУ на MSGEQ7. Также сюда добавляю второй проект ЦМУ на фильтрах.
ссылка на плату и схему https://oshwlab.com/technotrasher/colormusic
За год была проведена большая работа.
Итак ЦМУ на MSGEQ7.
1. Двухканальная схема. стерео.
2. Ручная регулировка шумов. предустановки шумов.
3. 7 режимов цму. в которых есть под-режимы.
4. 10 вариантов световых эффектов.
5. регулировки эффектов и режимов.
6. за "спектр" отвечают микросхемы MSGEQ7. достать рабочие сложно. (Купить более менее рабочие MSGEQ7 - по поиску на алиэкспресс "Модуль анализатора звука Aispark")
7. Аудио компрессор и система контроля клипинга взята тут - kompressor_SSM2167. прочтите обязательно, кто будет собирать.
8. описание режимов в начале скетча.
9. работа возможна с 300 светодиодами!
10. регулировка параметров с пульта и возможность сброса настроек "когда, что то нажал и все поломалось"
11. режим тишины с подсветкой (можно отключить), время срабатывания так же выставляется в скетче.
12 . Использованы статьи. тут для понимания работы MSGEQ7.
13. работа от микрофона. включается с пульта! на плате есть возможность отрегулировать чувствительность и время срабатывания микрофона.
14. режимы работы отображаются светодиодами на плате. на плате возможно механическое отсоединение сигнала с микрофона либо "байпас"
компрессора.
15. регулировка уровня входного сигнала линейным стерео потенциометром.
17. кнопки с платы убраны все, кроме переключения из ждущего режима. нужно для аварийного режима. если перестал работать пульт, а нужно включить хоть что то.
никаких энкодеров и т.д. скетч в первую очередь адаптировался под большую ленту. была битва за каждый байт и даже бит. и дорабатываться будет дальше.
18. Параметры сохраняются в память при отключении ЦМУ. в том числе режимы, шумы, настройки для режимов.
19. питание ленты обособлено от питания ардуино. вы не "сожжете" ардуино, забыв подключить внешний БП и программируя её через USB.
20.

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

Особая благодарность Евгению (Slenk) - он находил на меня пару минут на ответ и подсказку. я же подглядывал в его скетч и брал самое лучшее.
так же благодарность - Sergo_ST без его подсказок и терпеливых ответов на мои глупые вопросы скетч был бы намного "толще и тупее". и не факт, что работал бы.


Этап второй ЦМУ на фильтрах. проект делается совместно с poty
проект сложен для сборки.
что сделано - плата. бетта версия. постоянно вносятся изменения. часть отлажена и уже работает.
модуль сбора данных. частично отлажен. работа продолжается.
ЦМУ на фильтрах можно повторять. работает! плату можно заказывать. недавно были изменены некоторые номиналы конденсаторов в фильтрах.
плата доступна тут .
скетч colorMusic_v8_filter.rar
эффектов очень много. все описано вначале скетча. могу сказать, что есть эффекты от Лумазоид ЦМУ.

 

[arnisj]

@poty, куча ошибок и непонимания принципов работы))), но мне сидя на пляже лень объяснять в очередной раз))). В общем используйте что хотите/знаете, я то все что нужно было сделал за пару дней на ESP, перенести на ардуину тоже пару дней. А ссылаться на Гайвера и его несколько шаманские подходы к написанию кода - вообще о многом говорит , ведь у него во многих местах сделано странно, в других откровенно неправильно.

Где можно посмотреть на результат и, возможно скетч. ESP32 тоже больше по душе.

 

[kDn]

Где можно посмотреть на результат и, возможно скетч. ESP32 тоже больше по душе.

В проекте лампы, там и видео в теме и исходники в гите открыты и доступны всем желающим.
* Правда я проверял цветомузыку лишь для ESP8266, по идее на ESP32 тоже без проблем должно работать, но не тестировал.

 

[VictorArx]

На заре моей юности после фильма Экипаж(первого фильма) делал цветомузыку на RC фильтрах и тиристорах. Почитал про цветомузыку на arduino.
Как в ней происходит разделение аудио сигнала на низкие, средние и высокие частоты?
ЗЫ. Уважаемые зубры этого форума, не опускайтесь до взаимных оскорблений друг друга.

 

[poty]

@VictorArx, ответ есть в описании проекта и в видео. Вкратце - оцифровка + математическое разложение на гармоники.

 

[VictorArx]

Почитал данный проект и захотелось сделать уже цветомузыку в ногу со временем на arduino. Когда посмотрел скетч , это двадцать лет учиться надо, чтобы забабахать такой код. Это какую надо иметь смекалку, чтобы это нарисовать. Респект.

 

[technotrasher]

Почитал данный проект и захотелось сделать уже цветомузыку в ногу со временем на arduino. Когда посмотрел скетч , это двадцать лет учиться надо, чтобы забабахать такой код. Это какую надо иметь смекалку, чтобы это нарисовать. Респект.

за два месяца нарисовать такое можно. а вот чтобы грамотно это написать - вот тут не один год учиться.

 

[kDn]

Всплыла эта тема, вспомнил о своих планах .

Беглое исследование возможностей AVR показало, что прескейлер можно менять в достаточно гибких диапазонах, при этом элементано перекрывая весь звуковой диапазон 20-20000, более того - вместо AnalogRead можно (если требуется) использовать неблокирующий варант - где сначала по отсечке времени стартуется конверсия, а затем периодически по ее окончанию (проверка флага) - производится чтение , либо можно на прерывание повесить - но это не сильно удобно будет, т.к. нужно выдерживать период опроса. Реальное ограничение одно - более 128 семплов в nano не влезет, если на ней же производить обсчет, т.к. 128*2*4 = 1024байт - половина имеющейся памяти, без учета накладных расходов. FFT требует значения кратные степени двойки, так что 128 предел.

В общем-то осталось теперь сесть и сделать , как только настроение будет - сделаю. Для полного звукового диапазона шаг гармоник будет 156,25Гц - что не сильно хорошо для НЧ, но для СЧ и ВЧ в общем-то пофиг. В принципе для НЧ можно будет дополнительное семплирование сделать, но это уже позже, если будет целесообразность и смысл.

Короче предварительные выводы - никаких преград и препятствий в реализации пока что не вижу, почему это не было сделано до сих пор? Ну... так получилось .
Магическая "частота" 9600Гц это дефолтный прескелейлер 128 ежеличего, а не проблемы микрофона или кода... но ведь крайне неправильно его использовать))). Нужно использовать 32, т.е. 36мкс или 38000 семплов в секунду, что позволит работать с частотами до 19кГц. Почему "частота" в кавычках для проектов от Гайвера и последователей? Да потому как там на самом деле меряют фигню, убирая постоянную составляющую, которая крайне необходима для корректного обсчета и этим "как бы" удваивают частоту (на самом деле просто дурят самих себя)

ARDUINO ADC Speeds (with 16MHz Clock) :

 Speed: PreScaler: Time: Freq: ActFrq: BitsRes:
 
 120KHz 128 116us 9.6ksps 9.6ksps 10b
 240KHz 64 60us 19ksps 19ksps 10b
 500KHz 32 36us 38ksps 38ksps 10b

Теорию можно здесь почитать и осознать: http://www.openmusiclabs.com/learning/digital/atmega-adc/

@poty, понятно написано выше? ^^^
Только потрудитесь задавать вопросы, если они появятся после прочтения ссылок. Вдумчивого прочтения ссылок, чтобы бы мне не приходилось уж совсем элементарные вещи объяснять. Ах да... На прескейлере 32 будет выше 9 эффективных бит АЦП, картинки найдете по ссылкам, с объяснениями. 9 бит это в общем-то 512 значений, как бы более чем достаточно.

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

 

[technotrasher]

ну вот теперь что то инопланетное пошло. интересно цму таки разум обретет? ))) но если можно объяснить идею или дать ссылки на документацию. потому что уже для меня сложно. а то что у Алекса в проекте то реально мусор. я как практик, тестировщик говорю. но код для меня теперь дебри. простите.

 

[poty]

@kDn, я не уверен, что эта ветка подходит для теоретических изысканий. Что, собственно, @technotrasher, и подтвердил. Есть предложение создать для этого отдельную ветку. Впрочем, если @technotrasher будет не против, я готов объясняться и в этой ветке.

 

[technotrasher]

@kDn, я не уверен, что эта ветка подходит для теоретических изысканий. Что, собственно,
@technotrasher, и подтвердил. Есть предложение создать для этого отдельную ветку. Впрочем, если
@technotrasher будет не против, я готов объясняться и в этой ветке.

уже тут будем искать истину. чем больше тем - тем сложнее что то потом найти.

 

[VictorArx]

@technotrasher, Уже если для вас дебри, для меня воопче тёмный лес.

 

[technotrasher]

@technotrasher, Уже если для вас дебри, для меня воопче тёмный лес.

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

 

[VictorArx]

@technotrasher, В автоматике я понимаю, собирал много схем разных, вот с программированием напряг. Хочу собрать цму на arduino, если нарисуете скетч, то бишь код без мусора и более менее понятный и рабочий, буду весьма признателен. Бутылка чешского пива с меня.
PC. Много в инете скетчей для данного проекта, даже и не знаю, какой заливать.
PCC. Очень странно многие на Гайвера молятся, а другие компетентные программисты хают и говорят , что его коды мягко говоря туфта. Куды крестьянину податься.

 

[kDn]

@technotrasher, @VictorArx, в чем проблема? Выше @poty объяснений захотел, я ему их дал. Пусть изучает

А так-то для рядового пользователя все будет достаточно просто:

• сделать калибровку, по необходимости
• использовать результаты работы в своих целях, а именно - главную гармонику + массив гармоник или массив приведенный к нужному числу полос.

* Класс MICWORKER т.к. источником звука у меня в планах микрофон, я всеж-таки делаю под себя это , но это может быть и линейный вход - разницы в общем-то никакой.

Вон уже семплирование сделал, в логе можно наблюдать реакцию пина на палец , соберу все в кучу - тогда уже расскажу что конкретно делать.

 

[technotrasher]

@technotrasher, В автоматике я понимаю, собирал много схем разных, вот с программированием напряг. Хочу собрать цму на arduino, если нарисуете скетч, то бишь код без мусора и более менее понятный и рабочий, буду весьма признателен. Бутылка чешского пива с меня.
PC. Много в инете скетчей для данного проекта, даже и не знаю, какой заливать.
PCC. Очень странно многие на Гайвера молятся, а другие компетентные программисты хают и говорят , что его коды мягко говоря туфта. Куды крестьянину податься.

Скетч под MSGEQ7 я не встречал ещё. Гайвер - блогер. он идею кинул и все. его проекты не более чем просто интересные опыты с ардуино. но они хороши, тем, что развивают новичков. я например так и учился. наглядно и интересно. но в дальнейшем конечно нужно убирать из проектов его библиотеки. и искать другие решения. мой проект рабочий. но на сколько он "чистый"... не знаю. так как тест генератором частот - одно, а в реальности все по другому. вообще очень сильно все усложняют в ЦМУ. но и просто не получится. если не нужно стихийное мигание. Вот тут предлагают ещё интересные варианты. начиная от чистого кода и заканчивая фильтрами. оба варианта интересно проверить.

 

[Allkor]

Тема набирает обороты. Очень интересно! Мужики, только не тормозите! До Нового Года осталось совсем немного.

 

[VictorArx]

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

 

[arnisj]

Скетч под MSGEQ7 я не встречал ещё

Я так категорично бы не сказал
Msgeq7 Vu meter
Там же в описании Link to Code

 

[technotrasher]

Я так категорично бы не сказал
Msgeq7 Vu meter
Там же в описании Link to Code

совершенно не то. хоть и похоже.

 

[Allkor]

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

Я тоже так думаю. Поэтому и делал с линейным входом.

 

[VictorArx]

Я тоже так думаю. Поэтому и делал с линейным входом.

Линейным выходом.
Делал через тройник, иначе куда подключить колонки?
У меня вообще появилась идея. Может нам скинуться в складчину, нанять грамотного програмёра( есть на примете такой, нужен особый подход) и он забабахает код к новому году и все деффки наши.

 

[poty]

Ответить за один раз вряд ли получится, поэтому в этом сообщении буду писать последовательно, не взыщите.
Предупреждаю, что учить теории никого не буду - её много в Интернете.
Как человек старой закалки, при анализе любого эксперимента, претендующего на научность, я обращаю внимание на условия тестирования и цели тестирования. Потому, пойду сразу этим путём.
Начну с простейшего: есть фундаментальное утверждение - теорема Котельникова (в ссылке выше - ограничена понятием частоты Найквиста). Из смысла этой теоремы есть одно важное следствие (точнее - это одно из условий в теореме): для воспроизведения сигнала из дискретных отсчётов необходимо, чтобы в сигнале отсутствовали частоты больше половины частоты дискретизации. В противном случае спектр "складывается" и появляются частоты, напоминающие интерференционные взаимодействия.
Если внимательно прочитать граничные условия теоремы Котельникова, то в ней речь идёт о спектральной мощности и её непрерывности. На практике часто подменяют мощность квадратом напряжения (предполагая, что импеданс нагрузки постоянен), а непрерывность - "достаточной продолжительностью" или "устоявшимся режимом". Как правило эти допущения дают адекватную точность.
Обратимся к эксперименту, приведённому по ссылке. Мои требования к эксперименту там не описаны, однако, имеется ссылка на более глубокое объяснение того, откуда взялись выводы, в частности, о битовом "разрешении" АЦП. Особенно прошу обратить внимание на применение Codec Shield, которая используется как anti-aliasing filter для эксперимента. Расшифровывая это понятие, мы увидим, что это ФНЧ, который используется для выполнения условия теоремы Котельникова: подачи на АЦП только тех частот, которые не превышают половины частоты дискретизации. Конкретно:

For our application, we used 3.8kHz as the total bandwidth, as the codec shield has a -60dB digital filter just past the Nyquist frequency, which explains the sharp cut-off in the plots.

(выделено мной)
Как видим, при всей "экстремальности" тестирования частот дискретизации, исследуемые частоты ограничены 3800Гц. Там же можно посмотреть, что оцифровываемая частота = 1кГц, амплитудой 2В, чистый синус. Необходимость всех этих примечаний/ограничений я позже поясню.
Типичное преобразование аналогового звука в цифровое представление состоит из 3 (а, по большей части, 4-х) этапов:
1. анти-алиасинг: применение фильтра, пропускающего только частоты до частоты Найквиста (с определённой точностью);
2. дискретизация: выделение временных интервалов, внутри которых изменение функции представляется одним значением;
3. квантование: аппроксимация аналогового значения амплитуды цифровым кодом с определённой точностью;
(4.) кодирование: сохранение цифрового кода в определённом формате, позволяющем восстановить последовательность отсчётов и временные интервалы между ними.
Для "нашего" случая все 3 этапа являются подготовительными для проведения спектрального анализа.

Так вот, анти-алиасинг практически всегда проводится на аналоговом сигнале, поскольку после преобразования наложенные спектры разделить практически невозможно, для этого нет параметров. Имеющиеся "цифровые способы" либо предварительно "добывают" эти параметры, либо по сути своей представляют собой варианты оверсемплинга в предварительной стадии. Также имеются методы однобитового квантования, которые используют другие подходы к преобразованиям, но частоты там, увы, не подпадают под возможности микропроцессоров. Вывод из этой фразы: для получения адекватного входного сигнала для оцифровки необходима предварительная аналоговая часть. Как можно понять, она отсутствует как у Гайвера, так и в проектируемом варианте у @kDn.
Анти-алиасинг серьёзно меняет картину того, что можно получить в экспериментах. В частности, по ссылке, приведённой выше, имеется график разрешения в битах в зависимости от применяемой частоты дискретизации. Для выбранной @kDn частоты 38 киловыборок в секунду утверждается, что эффективное битовое разрешение составляет около 9,4 бит. Вспоминаем частоту анти-алиасинга (3,8кГц), читаем здесь, понимаем, что разрешение напрямую зависит от полосы, которую оцифровываем ( Eq. 10, чтобы долго не искать). На полосе 19кГц это битовое разрешение будет уже 8,2 эффективных бита. С анти-алиасингом, надеюсь, всё. Если хотите немного больше почитать о дополнительных условиях (которые в эксперименте были проигнорированы, и которые скорректируют результаты теоретической формулы для практических применений) - добро пожаловать в раздел "CORRELATION BETWEEN QUANTIZATION NOISE AND INPUT SIGNAL YIELDS MISLEADING RESULTS" того же документа. Я потом буду ещё говорить о том, что тестирование на синусоидальных сигналах не даёт адекватной картины оцифровки реального сигнала, этот раздел - добавка к моим рассуждениям далее.

Теперь попытаюсь пояснить применение сигнала амплитудой 2В, а не 2,5В и как сделали "удачную аппроксимацию" результатов на эталонные измерения, которые проводились как раз на 2,5В сигнале. Смотрим в п. 32.8 datasheet на ATMega 328p, который и используется в Arduino Nano. На частоте 200кГц абсолютная ошибка преобразования (5 основных источников ошибок) составляет 2 LSB, на частоте 1МГц - 4 LSB. Думаю, на частоте 500кГц, которая выбрана для оцифровки с частотой 38кГц, эту ошибку можно считать 3 LSB, что при Vref=4V составляет в районе 31мВ. Т.е., за счёт 0,5В запаса из расчётов просто убрали нелинейный и шумящий участок преобразования, заменив его рассуждениями, что раз на 2В будут такие результаты, то уж full-scale будут в 5/4 раз лучше по отношению сигнал/шум. Как видно, это не совсем так, хоть и, признаю, для этой стадии преобразования и назначения данная цифра имеет лишь научное значение. Однако, запомним, что теоретический предел динамического диапазона для 500кГц - это 20*log₁₀(2^(10-3))=42дБ по напряжению.

Перейду к свойствам самого сигнала. Я уже упоминал "пик-фактор" музыкального сигнала (используйте поиск, можете почитать довольно удачное изложение на русском языке здесь). Возвращаясь к спектральному анализу: гармоника "отображает" именно мощность сигнала, которая определяется значением RMS. Для синусоидального сигнала соотношение простое: амплитуда = RMS * корень(2). Т.е., максимальное "эффективное разрешение", которое можно получить с помощью тестового синусоидального сигнала примерно в 1,4 раза меньше теоретического. Для музыкального сигнала всё гораздо сложнее. В зависимости от жанра пик-фактор может изменяться от 2 до 15 и более. Это важно потому, что амплитуда сигнала, подаваемого на АЦП не должна превышать максимального входного значения для конкретного устройства (в нашем случае, допустим, 5В), в то же время FFT будет давать гармоники, суммарная мощность которых соответствует RMS, то есть в 2-15 раз меньше. Возьмём хотя бы значение 5 в качестве пик фактора, это снизит наш динамический диапазон 42дБ на 14дБ (до 28дБ)! Мы можем игнорировать перегрузку по входу, но это будет давать широкий шлейф шумовых гармоник довольно большого уровня. В каком-то смысле, учитывая, что мы делаем не прецизионный инструмент, этот факт можно игнорировать до определённого предела, но рок и классика будут визуализироваться с серьёзными ошибками. @technotrasher уже нашёл один из способов держать пик-фактор в узде - применение компрессоров, но это, как ни крути - снова аналоговая предобработка. С эффективными компрессорами пик-фактор можно снизить до 5-7дБ, т.о., динамический диапазон можно сохранить на уровне 35дБ.
Продолжаю описывать разницу в тестировании на "чистом синусе" и музыкальном сигнале. Синус можно сделать таким, чтобы его амплитуда симметрично умещалась между 0 и максимальным входным напряжением АЦП. А если взять 2 синуса с разной частотой? Тогда мощность придётся перераспределять между ними. А если подать музыкальный сигнал, который имеет практически непрерывное заполнение спектра гармониками? Тогда можно потерять гармоники либо в полосе, которая имеет небольшой вес в общем музыкальном спектре (см. спектральную плотность музыкального сигнала, например, здесь), либо в низкой части динамического диапазона (любое исследование по динамическому диапазону музыкальных произведений). Да, есть возможность включить АРУ, можно сделать это аналоговым способом или с помощью управления референсом (в ограниченном масштабе, так как по datasheet минимальное значение референса для 328p, при котором сохраняется глубина по битам - 1В). В принципе, вариант низкой амплитуды гармоник можно лечить цифровым способом, но, судя по Вашим упоминаниям о достаточности двух-трёх отсчётов - как это делать Вы не знаете. И это приводит нас к последнему: ограниченность ресурсов для цифровой обработки. Т.е. полученный результат будет, в общем-то, в основном амплитудным демодулятором, полосовое декодирование будет осуществляться только на бумаге.

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

 

[VictorArx]

@poty, Буду изучать, что это всё значит.
Если я правильно понял изложенный материал, нужно сначала аудио сигнал разложить на частоты с помощью операционных усилителей и лишь затем подавать на arduino? Типа анализатора спектра.

 

[kDn]

@poty, похвально, то что вы наконец-то решили почитать сначала теорию, реально похвально, т.к. подавляющее большинство "товарищей" тут (не в данной конкретной теме, а на форуме в целом, тут - собирательное) доказывают что-то вообще не врубаясь в суть дела, что кроме раздражения не вызывает ровным счетом ничего. Теперь хоть на одном языке можно говорить.

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

1. Кроме частоты семплирования и того самого отзеркаливания ВЧ которое имеет место быть, есть еще такая штука как АЧХ. Так вот имеем АЧХ микрофона, АЧХ устройства воспроизведения и лишь после двух этих преобразований сигнал придет на вход АЦП и будут иметь влияния алиасинга , по факту же получается так, что УЖЕ на 16-18кГц те пару MAX9814 что у меня используются имеют значительный "завал", ну и сами колонки у меня "заваливают" в районе 18кГц. Следствие - алиасинг каких частот вы ожидаете увидеть на спектре гармоник после FFT?

* Но тут вы верно поняли первую граблю на которую наступил Гайвер - он данное явление совершенно не брал в расчет и получал забавные эффекты на ленте, которых быть не должно было . Ессно это можно решить входным фильтром, если сознательно ограничить диапазон ЗЧ к примеру до 300...4000Гц - оставив только голосовой диапазон. Допустим есть желание передавать голос и как можно сильнее пожать его. Но здесь ведь задача не передачи голоса и ориентируемся на полный звуковой диапазон, не так ли??? )))
** Ну и если здравый смысл должен вам подсказать, что помех в районе ультразвука, у вас с микрофона не будет, врядли они будут и с линейного - но для успокоения, можете конечно ограничить ВЧ по 18-20кГц фильтром, хуже от этого не будет. Один фильтр это не грядка полосовых, которые воткнуты хз зачем для контроллера (повторюсь, я понимаю смысл для аналоговой схемотехники, но для цифровой - оно не надо).

Для выбранной @kDn частоты 38 киловыборок в секунду утверждается, что эффективное битовое разрешение составляет около 9,4 бит. Вспоминаем частоту анти-алиасинга (3,8кГц)

Так. А вот тут вы снова начинаете писать странное. Во-первых я особо ничего не утверждал, а лишь привел данные сторонних исследований и данные оттуда. Тут следует отметить, что вне зависимости от настроек прескейлера вы будете все равно получать те же 10 бит, только вот "доверять" можно будет все более и более узкому диапазону бит. При этом старших бит, младшие будут сильно шуметь и терять в информации. Про вспоминаем частоту анти-алиасинга (3,8кГц) - ??? Куда-что вспоминаем? Вспоминаем то, что то откуда вы вычитали информацию имеет строчку - 3.8kHz as the total bandwidth . Я как бы уже сказал, что диапазон в моем случае будет 38500/2=19250кГц. Рекомендую еще раз обдумать написанное и исправить ошибки.

понимаем, что разрешение напрямую зависит от полосы, которую оцифровываем ( Eq. 10, чтобы долго не искать). На полосе 19кГц это битовое разрешение будет уже 8,2 эффективных бита.

Я прочитал документ, поглядел формулы имею вопрос - как вы посчитали 8.2? Приведите расчет тут. Поскольку в ссылке на пример что вы дали - есть расчет SNR и Signal Gain, т.е. мне действительно интересно из каких соображений вы пришли именно к такому результату.

Для музыкального сигнала всё гораздо сложнее. В зависимости от жанра пик-фактор может изменяться от 2 до 15 и более.

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

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

Блин... вы серьезно решили загонять хрен знает какой сигнал в ардуину? Можно так вообще постоянный сигнал подать и затем рассуждать, что ничего не работает. Еще раз говорю - нужно включать здравый смысл, либо отстроить микрофон на средний, нормальный уровень сигнала, либо использовать АРУ. Все. Впрочем это вообще никакого отношения к FFT и ADC не имеет и от них не зависит. На счет визуализации вопрос вообще отдельный. Дело в том, что даже если вам дать частоту главной гармоники, ее приведенную в относительные попугаи амплитуду, а также массив гармоник с таким же попугайным приведением по амплитудам гармоник - то это визуализацию не напишет))). Я лишь низкоуровневую часть делаю, все остальные украшалки это уже не ко мне, т.к. мне и лампы хватает, а данной задачей занимаюсь исключительно чтобы использовать AVR как со-процессор и расширитель портов.

* А так, пишите, конечно. То что я пишу - игнорируют или не понимают, может ваше изложение будет понятнее для среднестатистического обитателя форума.
** Вообще я в раздумьях на счет того, чтобы ограничить ADC 8 битами, просто для того, чтобы сэкономить память. Т.е. в коде уже написал два варианта - 10 бит и 8 бит с переключалкой, но по большей мере на этап тестирования и отладки - дальше зафиксирую на 8 битах.

Как можно понять, она отсутствует как у Гайвера, так и в проектируемом варианте у @kDn.

На всяк случай для понимания - у меня будет на АЦП сигнал идти с микрофона MAX9814, хотя может и для MAX4466 сделаю. Что это за модули и что они имеют - прочитайте, если вдруг не в курсе. Естественно сигнал с них не будет превышать значений AREF, т.е. вписываться в то, что ожидает ADC. По поводу доп. фильтра я выше уже объяснял, в той реализации, что я делаю он как бы не обязателен.

 

[poty]

@kDn, это - моя специальность, изученная ещё в 80-ые, так что не стоит ёрничать по этому поводу.
Про алиасинг Вы несколько подменяете понятия. Если у Вас уже имеется завал к 16-18кГц, то стоит понимать, что крутизна этого среза должна быть достаточно высокой, явно не соответствующей АЧХ микрофона, допустим. Если завал в принципе большой (по амплитуде, а не по крутизне спада), то с учётом уровня высоких частот в -15дБ на штатной верхней частоте MSGEQ7 и ограниченного количества семплов для расчёта вместо реальной картины Вы будете получать состояние луны на день рождения еврея в 1918 году.
Про пик-фактор, динамический диапазон Вы так ничего и не поняли. Видно, не дано. И даже ссылки, которые Вы сами приводите, не помогают, вот беда.
Расчёт приводить не буду - сразу написал, что считать и понимать формулы не учу, за этим - в школу.