RLC Meter, аналоговая часть

[DIVON2]

Проект Coocox 1.77 / GCC 4.8 2014q3

Это что, портированные проект с питона на си?

[pixar]

это исходники автора, собранные в проект в coocox.

[balmer]

буфер на выходе ЦАП лучше отключить.

А как без буфера? У DAC без буфера выходное сопротивление порядка 1 МОм. А мы его нагружаем на достаточно низкоомную нагрузку в десяток килоом....

[pixar]

У DAC без буфера выходное сопротивление порядка 1 МОм.

откуда такая цифра? в даташите упоминается выходной импеданс 15 кОм (с буфером) - я думаю , это как раз импеданс без буфера, а в даташите - ошибка.
Внутренний буфер немного кривоват и дает большой переходной процесс даже на малых шагах , с которым ты потом борешся подключамым конденсатором.
У меня в приведенной схеме на синусе 25 кГц из 128 шагов амплитуда одинаковая с буфером и без буфера. Даже больше - без буфера выходной сигнал в полном диапазоне питания , а с буфер недотягивает ~0.15-0.2 вольт до +/- питания (м/c STM32F303CB).

dac_output.jpg

(68.81 КБ) 778 скачиваний

[balmer]

в даташите упоминается выходной импеданс 15 кОм (с буфером) - я думаю , это как раз импеданс без буфера, а в даташите - ошибка.

Однако ты прав.
Погуглил, нашел такой документ. См. 1.1 DAC equivalent circuit. и "As an example, the STM32F407 defines the impedance output with buffer off at a maximum
value of 15 kΩ. "

Так, что действительно выключение буфера видимо будет в плюс. Надо будет только RC цепочку пересчитать чутка, чтобы резистор был на 30-60 КОм.

[alexf58]

A что за хитрая кодировка в коментариях С файлов? Ни под Линуксом, ни под Виндами так и не подобрал ничего.

[balmer]

utf-8 там кодировка русских комментариев.

[alexf58]

UTF-8 я пробовал. Файл RLCMeter в корне прекрасно читается. А коментарии - нет. Чем его открыть?

P.S.
HEX editor и правда показывает честные UTF-8 буквы. Разберусь как нибуть.

P.P.S. В оригинальных файлах, как оказалось, все честно - UTF-8.
А я начас смотреть из архива для кокоса. Вот там с комментариями полный бардак...

Заодно нашел очень удобную программу для чтения *любых* кодировок: BabelPad.

[balmer]

Раз уж всплыла эта тема - вот такой мне недавно придумался вариант упрощения (потому как в другой железке подобный узел стал проектировать). Теоретически параметры ухудшиться не должны.

Оригинальный вариант виртуальной земли для MCP6S21


Выкинули лишний ОУ (заодно избавились от проблемм с нелинейностью, из за которых snubber network вставляли)


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


Итого - экономим пару дешевых ОУ, кучу рассыпухи и место на плате

[alexf58]

Eще вопрос. А зачем использовать чип с 100 ногами? Почему, скажем, не STM32F303CC? Вроде есть и USB, и SPI, те же ADC/DAC, до 256K flash.

[balmer]

Это был чип, который было проще всего купить. В российских магазинах в то время (не знаю как сейчас) были только 100 ногие.

[alexf58]

Как я понял, пришлось добавлять С7 с ключем для фильтрации на низкой частоте. Из-за того, что выборки реже. Возникает вопрос: а надо ли уменьшать частоту DAC? Понятно, что если в таблице 2000 точек, то 1 КГц получится на 2 МГц, а для получения 100 Гц надо снизить до 200 КГц. А надо ли? Ведь можно сделать маленький буффер, скажем на 256 точек. По прерыванию от DMA подгружать следующую порцию, либо первую половину, либо вторую. Например на 1 MHz.

[balmer]

Пробовал в свое время увеличивать размер буфера для DAC и соответственно увеличивать точность аппроксимации. Измеримых улучшений заметить не смог.

Кстати причины того, что у меня качество сигнала от DAC не очень хорошая на частотах ниже 200 Гц - так и не понял. Но вот кстати недавно делал радиоприемник и выводил сигнал через DAC от STM32. И там было "гудение". Причем источник довольно интересный этого гудения. Оказывается когда процессор активно обрабатывает float инструкции он что-то делает чуть по другому, чем когда обрабатывает целочисленые. Этого оказалось достаточно, чтобы на выходе DAC была помеха с частототой обработки FFT

PS: Кстати да. Есть еще такой вопрос - почему сделал два канала усиления, когда можно было сделать один канал и переключать I V каналы.
Причина - хотелось низкую входную емкость и минимальные наводки между каналами. Приведенная ко входу емкость получилась порядка 2 pF, что довольно неплохой результат. Наводки между каналами так-же получились очень низкими. На частотах до 10 КГц ниже уровня шума.

[alexf58]

Я не про точность, а про sample rate. Если я правильно понял, на маленьких частотах она снижается. Вплоть до использования прескейлера на таймер. Для DAC снижение частоты уменьшает и частоту помех, и их надо отфильтровывать дополнительным конденсатором. Если же на 100 Гц выборки делать с частотой 1 МГц, то фильтр с частотой среза скажем 150-200 КГц вполне справится. Или я что то не понял?

[balmer]

Смотри. Сейчас там размер буфера SINUS_BUFFER_SIZE = 2000 сэмплов. Это значит, что на частоте 100 Гц получается 200 000 SPS у DAC. Если бы это как-то влияло на качество сигнала, то уменьшение/увеличение размера буфера в два раза можно было-бы измерить/заметить. Ничего измерить не смог и забил.

Кстати да - философское отступление: Каждый результат должен быть измеряемым
Нет измеряемого результата - нет возможности понять "А сделал ли ты вообще чего либо?"

[alexf58]

Как человек занимавшийся аналоговым звуком, я очень верю в измеряемость результатов и не верю в изотерику.
Так вот, я перечитал всю эту ветку, и заметил что тебе пришлось вставить переключаемый конденсатор чтобы фильтровать высокочастотный шум на низкой частоте. Могу сам померять, дело не хитрое. Если ты увеличивал размер буффера, а тем самым и SPS с включенным С7 и это не дало результата, то нельзя сделать вывод что увеличение SPS до 1 млн не избавит от необходимости вообще переключать фильтр.
Другое дело, что возможно на низкой частоте есть другой источник искажений, к частоте дискретизации вообще не относящийся. Скажем взаимодействие с 50 Гц наводками.

[balmer]

К сожалению с низкими частотами не до конца разобрался. Форма синуса после DAC на частотах ниже 200 Гц остается идеальной. Но почему-то фаза между I V каналами начинает все больше и больше различаться при уменьшении частоты. На частоте 10 Гц (мерял и на такой) различие фаз достигает аж 2 процента. Да помогает калибровка. Но причину эффекта так и не понял.

[alexf58]

Действирельно странно. Каналы идентичны кроме IV конветрора. Паразитные емкости наоборот должны проявляться на высоких частотах. Разве что на самом деле переходные конденсаторы не равны? (С10, С14)

[alexf58]

Проект Coocox 1.77 / GCC 4.8 2014q3

Я прошу прощения за нескромный вопрос. А кто то проверил, что это работает? С авторским makefile все прекрасно собирается и запускается, а вот кокосовский вариант делает вид, что собрался, но там нет startup_stm32fxxx. Соответственно в бинарнике нет в начале векторов.

В файле "RLC_Balmer3_coocox.coproj" тоже ссылок на startup не видно. Что я не так понимаю?

[pixar]

Спасибо за нескромный вопрос. Я остановился на том, что кокос перестал выдавать ошибки и warnings . В железку залить не пытался, тк проект использовал для "чиста пасмотреть". А так же в связи с запаром на работе пришлось всё отложить. Если интересует - могу попробовать довести все в кокосе до ума и на макетке запустить.
Что мне не очень понравилось : Автор организовал работу DAC-ADC на принципе real time - одновременно забивать один буфер и обрабатывать другой. Для задачи измерения подход, думаю, не совсем верный :

когда процессор активно обрабатывает float инструкции он что-то делает чуть по другому, чем когда обрабатывает целочисленые. Этого оказалось достаточно, чтобы на выходе DAC была помеха с частототой обработки FFT .

У меня есть другой вариант : - DAC & ADC12 работают от одного триггера TIM4 , ADC12 собирает пачку uint32_t, потом ждёт завершения обработки. Начало сбора пачки привязано к началу периода DAC. Перед обработкой - выборка uint32_t разбивается на два канала, длинная выборка uint16_t сжимается в один период int32_t суммированием и удалением постоянной составляющей. Обработка одного периода делается float.
Общался с Никитой по этому вопросу, он порекомендовал длинную выборку паковать в буфер из множества периодов и на него, перед обработкой , накладывать оконную функцию.

Если же на 100 Гц выборки делать с частотой 1 МГц, то фильтр с частотой среза скажем 150-200 КГц вполне справится. Или я что то не понял?

DMA работает только с инкрементом адреса , поэтому потребуется буфер на полный период. С буфером на четверть периода потребуется работа процессора для формирования синуса. Других ограничений нет.