Регулируемый Иип На Базе Атх С Цифровым Модулем

[tar]

импульсник не корректно работает

Если ты не понимаешь о чем речь, зачем говоришь? (это риторический вопрос на него ненужно отвечать) да еще и в утвердительной манере

[Starichok51]

tar, ну, так я же уже написал, что уйдет ОУ для усиления сигнала с шунта и падение на шунте можно снизить до 250 мВ.

в самых первых прошивках у меня суммировалось 10 измерений без усреднения. что давало, якобы, 10,000А. но "игра" на разнице соседних измерений должного эффекта не дала, поэтому я отказался от такого "умножения".
чтобы такое умножение давало эффект, нужно на вход АЦП подмешивать шум.
и даже сумма теперешних 250 измерений без подмешивания шума не оправдывает себя в должной мере.
можно хоть сейчас сумму 250 измерений делить на 25, а не на 250, но последний разряд будет скакать...

а если применить ЦАП 12-битный, то "цена деления" будет примерно 10,000 / 4096 = 0,00244. на индикацию можно выводить в тысячных (мА), но будут неравномерные скачки между соседними значениями, где на 2, а где на 3 тысячных.

Добавлено after 3 minutes 37 seconds:
BEST-83154, после последней модернизации прошивки работает корректно во всем диапазоне от 0,1А до 10А, с отклонением по мультиметру не выше 0,01А.

[tar]

Помоему вы что то неправильно понимаете.

Я говорю об фактическом отображении тока потребления нагрузкой а не то что было выставленно вами. Просто потому что точность этого ацп позволяет измерять даже 10.000А с определенной точностью, без всяких скачков, с погрешностью ~+-4мА. Фактически я уже пробовал замерять с шунта 0.1 и диапазоном ацп, погрешность во всем диапазоне 0.000 - 4.999 около +-5мА даже если суммарная погрешность на все 10А будет 10мА это будет фигня, и это реально стоит того что бы отображать последний знак.

Для точного нескачущего числа мне достаточно 32 выборки. Притом я не просто набираю 250 значений и делю, это не совсем правильно. Нужно делать буфер.

для простого понимания

Код: Выделить всё

#define ADC_SIMPLES (32) // Количество семплов

int16_t adc_array[ADC_SIMPLES]; //буфер семплов

uint8_t i = 0;
while (i<ADC_SIMPLES){
  adc_array[i] = 0;
i++;
}	

 while (1)
 {
//Базовый цикл программы
      adc_array[ADC_INCREMENT] = ads1115_read(&mainAdc);

		i = 0;
		result = 0;
		while (i<ADC_SIMPLES){
			result += adc_array[i];
			i++;
		}
       //теперь переменная result содержит истинное усредненное значение

	ADC_INCREMENT++;
	if (ADC_INCREMENT >= ADC_SIMPLES)
	{
		ADC_INCREMENT = 0;
	}
}

Идею думаю понять можно. В таком исполнении я получаю вышеприведенную точность сверенную по профессиональному мультиметру (не из головы цифры та епта).

С такой точностью можно спокойно отображать 0.000 - 10.000
По вольтметру, я использовал верный делитель на 100, примерно с такой же точностью можно отображать напряжение от 0.000 до 100.00В. Но вот напряжение на миливольтах подводит чуть больше, и тут сказывается еще делитель.

Если интересует я могу подготовить конкретные цифры с замерами на нормальном мультиметре.

Добавлено after 5 minutes 31 second:
Ах тыж, забыл, в конце result Нужно поделить на количество семплов. Но я думаю суть и так понятна

[Starichok51]

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

всё я правильно понимаю. но нужно смотреть шире и учитывать не только измерение, но и дискретность задания.
допустим, измерения будут идеальные, без всяких +-4 мА. и тут мы упираемся в дискретность задания, которая значительно грубее дискретности этого АЦП...

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

[tar]

но нужно смотреть шире и учитывать не только измерение, но и дискретность задания.

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

По замерам.

Взял сопротивление 0.1 Ом обычная китайская керамика 5W.

Усиление 1.024V в аккурат должно быть для 10А. 32 семпла считаются по идее которую я выложил выше.

Я не вводил никаких дополнительных коэффициентов, только подбил программно сопротивление шунта.

Замер делал в дифференциальном режиме.

ads1115 сравнение.png

(10.97 КБ) 739 скачиваний

Ну незнаю я что вам там кажется такое не реальное. Первые замеры до 1А я делал на Б5-44А так вот у него есть встроенные (как по мне очень не плохой) миллиамперметр, так вот показания у меня получаются ровнехонько как на этом амерметре, прям один в один. Не так все хорошо конечно на диапазоне 0-10мА ну оно и понятно. Но после 10мА точность как видно до 1мА что очень даже достойно. Причем нет никаких скачков, все плавно и четко.

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

Добавлено after 2 minutes 56 seconds:
Хотя скорее всего надо еще корректить сопротивление шунта, это можно сказать так, на скорую руку я делал. В любом случае видно что этого АЦП с лихвой хватить для нормального показомера

[BEST-83154]

tar - так я не отвечал на НЕ заданный вопрос
а просто констатировал факт

вы говорите от таких низких токах - а кто то подумал что это импульсник и там по любому будут скачки!
как бы вы там не усредняли и не глушили и тд
идеального не существует!

Starichok51 - это хорошо что (с отклонением по мультиметру не выше 0,01А.)
но при 10а это вполне норма,но не стоит забывать,что у тестера так же может быть своя погрешность
в общем это все относительные измерения

tar - у тебя студия нормально воспринимает эти сокращения uint8_t ???
мне пришлось уйти от этого,т,к студия тупит из за них
оно вроде как и работает и в то же время (ну тут дальше маты)

[zanny]

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

[tar]

как это математически выглядит?

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

[Starichok51]

обычная китайская керамика 5W

для наших целей имеет недопустимо большой ТКС. потому к 5 Амперам у тебя набежало уже 15 мА.
да я в ads1115 даже не сомневаюсь, что его хватит для показометра. тут мне ничего не надо доказывать.

суммирование без усреднения это что?

просто сложили, например, 10 раз, но на 10 потом не поделили.

сделал я сейчас тестовую прошивку, где сумму из 250 измерений поделил на 25.
таким образом, напряжение получил по 0,01В, а ток получил по 0,001А (по 1 мА).

напряжение стоит довольно хорошо, но есть редкие колебания на +-0,01В.
у напряжения получается "растяжка" в 3 раза - 1000 дискрет АЦП превращаются в 3000 дискрет индикации. думается, что для диапазона 60 Вольт ("растяжка" в 6 раз) стабильность показаний будет хуже.

а для тока миллиамперы постоянно дрыгаются ("растяжка" в 10 раз). получается, что простое суммирование большого числа семплов себя не оправдывает, о чем я и говорил.

tar, некорректно сравнивать 10-битный АЦП с 15-битным.
в моем случае, с 10-битным АЦП, даже не помогает суммирование 250 семплов.

[zanny]

если сложить 10 раз по 1 получим 10, а не 1.

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

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

[tar]

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

В моем же варианте, следующее полученное значение не может в значительной степени повлиять на результат, максимальное значение которое оно может внести 1/32.

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

некорректно сравнивать 10-битный АЦП с 15-битным.

Да я и не пытался, я вобще изначально говорил не про 10 битный ацп а про ADS1115

Понятно что с 10 битным ацп особо ничего не получишь.

[mr_kot]

[uquote="zanny",url="/forum/viewtopic.php?p=3103069#p3103069"]если сложить 10 раз по 1 получим 10, а не 1.[/uquote]
Перенести запятую на индикаторе не большая проблема. И делить результат сложения для этого совершенно необязательно. Значащие цифры при этом ведь не изменятся?

[Starichok51]

следующее полученное значение не может в значительной степени повлиять на результат, максимальное значение которое оно может внести 1/32.

у меня следующее полученное значение вносит 1/250. что-то мне кажется, что это гораздо лучше, чем 1/32.

Перенести запятую на индикаторе не большая проблема. И делить результат сложения для этого совершенно необязательно.

вот именно.
допустим, было число 120, на индикатор вывели 12,0.
а теперь сложим 10 раз по 120 и получим 1200. на индикаторе перенесем запятую и увидим 12,00.

[zanny]

в самых первых прошивках у меня суммировалось 10 измерений без усреднения.

теперь понятно. но в случае сложения 10 измерений и смещения запятой это и есть деление на 10, т.е. среднее.

[BEST-83154]

разве что то мешает выводить так сказать плавающую запятую в вашем семблере?
я вот не пойму вы,что с целыми числами работаете?

[mr_kot]

[uquote="Starichok51",url="/forum/viewtopic.php?p=3103178#p3103178"]у меня следующее полученное значение вносит 1/250. что-то мне кажется, что это гораздо лучше, чем 1/32.[/uquote]
Рискну вмешаться.
Старичок, ты наверное не совсем правильно понял. Ты складываешь 250 сэмплов, делишь их на 25 и выводишь результат. Дальше - следующие 250 сэмплов.
А tar собирает в буфер 32 сэмпла, суммирует, делит на 32 и выводит результат. Но дальше у него из буфера удаляется самый старый сэмпл, остальные сэмплы сдвигаются и на свободное место вносится новый. Ну как-то так.

[Goodefine]

[uquote="tar",url="/forum/viewtopic.php?p=3103073#p3103073"]Вся идея заключается в том, что бы сохранять историю полученых семплов, и на основе этой истории формировать результат.[/uquote]
Да, такой подход как бы "обрезинивает" результат. Для тахометра когда-то среднее считал так:

Код: Выделить всё

//--------Функция подсчета среднего значения----------------//
void stat_value(ulong8* stat_buff, ulong8* next_value, ulong8* st_val)
{
 ulong8 stat_val=0;
		
	for(uchar8 j=0;j<STAT_BUFF_SIZE-1;j++) stat_buff[j]=stat_buff[j+1];
    stat_buff[STAT_BUFF_SIZE-1]=*next_value;
    for(uchar8 j=0;j<STAT_BUFF_SIZE;j++) stat_val+=stat_buff[j];
	
    stat_val>>=3;  //делим на STAT_BUFF_SIZE ( stat_val/=STAT_BUFF_SIZE;)
    *st_val=stat_val;
}
//=======================//

По результату будет как и Ваш вариант, похоже

[Starichok51]

mr_kot, я знаю, что такое скользящее среднее, мне это объяснять не надо.
но мне хочется получить стабильный результат без скольжения.
к тому же, у меня за секунду обновятся все 250 значений, и от "истории" семплов ничего не останется.
скользящее среднее выгодно там, где оно скользит гораздо медленнее, чем производится вывод на экран.
делать по несколько раз за секунду вывод на экран - тебя это мелькание будет раздражать.
растягивать скольжение на энное число секунд - при смене задания тебя это тоже будет раздражать в ожидании, пока среднее устаканится.
поэтому в данном проекте применение скользящего среднего совершенно бессмысленно.

вы,что с целыми числами работаете?

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

но в случае сложения 10 измерений и смещения запятой это и есть деление на 10, т.е. среднее.

ну да, и причем, без всяких затрат времени на применение математической обработки.

[tar]

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

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

Такой подход хорош тем что вы набираете данные не в какой то конкретный момент времени и его выводите, а набираете его как бы линейно с почти равными интервалами времени.

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

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

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

Да растягивать та зачем, зачем вобще об этом думать. У вас буфер сам обновляется и всегда имеет актуальные данные.

поэтому в данном проекте применение скользящего среднего совершенно бессмысленно.

При использовании ADS1115 в качестве АЦП очень даже имеет смысл. НО я вас ни в чем не убеждаю, дело ваше.

[Starichok51]

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

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