Делаем дозиметр!

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

На ФОН - не работает, на ДОЗА - срабатывает Надпись "!ОПАСНОСТЬ!"  и пикает бузер.

Сейчас после срабатывания в ДОЗА "!ОПАСНОСТЬ!"  самопроизвольно выключается бузер на частицу только пикание, захожу в настройки он выключен.

При тревоге по ФОН и ДОЗА - надо слово Фон и Доза сдвинуть к левому краю до конца, сделать пробел между цифрами и мкР/ч и мкР/ч сдвинуть к правой стороне до конца  lФон:    301 мкР/чl     lФон:     4.31 мкЗ/чl

 

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Вроде что-то подправил и перезалил. Очень странно что на фон не сработало... Бузер тоже поправил.

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

Не думаю что менять мкЗ/ч на мкЗ хорошая идея, тк это уже по идее будут другие ед.измерения и могут некоторых вводить в заблуждение.

Все-таки мы же стремимся чтоб все было на русском)) А вообще лишние переключения шрифтов много памяти кушац)

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

ФОН - НЕ срабатывает надпись "!ОПАСНОСТЬ!" идет постоянный сигнал  и при нажатии прекращяется но при этом вырубает в настройке Щелчки: ВЫКЛ

ДОЗА - Срабатывает надпись "!ОПАСНОСТЬ!" идет постоянный сигнал  и при нажатии прекращяется но при этом вырубает в настройке Щелчки: ВЫКЛ

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Нашёл и справил! Архив перезалил.

На счет надписей среднего и макс погоричился, забыл что это картинка... Но все равно думаю не стоит менять, тк все на русском и тут пожалуйста..)) Если хочешь для себя то "dose_max_img" и "dose_mid_img".

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

При срабатывания порога идет длинный сигнал, после сброса прекращается и в последствии при пороге больше не включается. Щелчки работают. Передернешь питание все с начало... Если не нажимать кнопки при снижении порога  сигнал прекращается, если опять сработает порог опять сигналит.

В настройках Тревога Ф что вибра, что вибра+звук - срабатывает только звук.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Так можешь видос сделать что за звук? А при тревоге дозы вибра есть? если что вибрация должна быть только при 2-м пороге, при первом только звук.

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

 

Не понравилось Pav_13...
alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

Ну как тебе mad и max ?

Вот видео. При втором включается и адекватная тревога и вибратор.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Вообще выглядит прикольно)) Я там перезалил скетч, скорее всего должно решить проблему с постоянным писком.

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

Надо надпись "!ОПАСНОСТЬ!"  уменьшить с верху и с низу по пикселю чтоб не сливалось с остальным текстом.

Пиликает нормально, только если нажмешь кнопку больше не срабатывает первый порог на фоне.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Это хорошо что стал пиликать! Первый порог фона тоже починил, добавил твои картинки и подрезал "опасность" сверху и снизу. Архив перезалил.

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Все заработало как надо.... Если находишься в ФОН при срабатывания порога ДОЗА идет переключения на экран ДОЗА.

Еще один момент... Когда пиликает по порогу и ловит частицу идет заикание пиликания, Надо чтоб когда пиликает ОПАСНОСТЬ!, то частицы не пикали.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Так и должно быть, при первом пороге будет переключаться на то окно, из которого и идет тревога, чтоб понимать что "это не график зафонил"))

Да вообще они и не должны пикать...Тк идет прямой запрет...Буду разбираться...

UPD. Перезалил, должно стать нормально...

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Все заработало... Ну давай до завтра...

mambavamba14
Offline
Зарегистрирован: 25.12.2019

#ArDos_with_RADON_2.0.0 - Мелкие исправления, оптимизация(с версии 2.0.0 из библиотек будет требоваться только "EEPROMex.h").

Dark-Dante
Offline
Зарегистрирован: 09.01.2018

То хотите чтобы на русском было всё, то мид макс на инглише пишите потом)) Сильно жирные надписи, не смотрятся они там.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

Dark-Dante - Таке да, но эти помом более гармонично(симметрично) смотрятся, по сравнению с русскими надписями(те прям как то с показаниями сливались и казалось что что это что-то единое..), а там как говорится на вкус и цвет)) Если что их можно заменить на свои буквально в пару кликов))

Dark-Dante
Offline
Зарегистрирован: 09.01.2018

Не знаю, не видел как с русскими было, сказать ничего не могу)

mambavamba14
Offline
Зарегистрирован: 25.12.2019

Dark-Dante - По ссылке в посте с прошивкой есть фото всех экранов))

Pav_13
Offline
Зарегистрирован: 21.05.2020

Dark-Dante пишет:

То хотите чтобы на русском было всё, то мид макс на инглише пишите потом)) Сильно жирные надписи, не смотрятся они там.

+100500

Вы уж определитесь - "за красных вы, или за белых?" :)

А то название режима кириллицей, а подрежимы почему-то латиницей :(...

Или уже прицел на захват мировых рынков? :))

mambavamba14
Offline
Зарегистрирован: 25.12.2019

Хорошо, верну старые, а эти закоментирую, кто захочет поменяет.

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Привет! Че... заклевали за mid и mix? Ну и правильно сделал, что есть выбор, а так как я понял не угодишь не на кого... И вообще надо для себя делать и пусть другие подстраиваются.

Залил последнюю, нашел глюк, если заходишь в статистику, то выйти  по удержанию "ОК" невозможно, только по временному интервалу выходит в настройки. И еще надо переименовывать Статистика, это не статистика...

Pav_13 - Причем тут красные и белые... Не смотрятся русскими буквами. Ты вот даже ник почему-то латиницей написал... Тогда и название дозика надо по русски написать пусть по твоему Pav_13 - ApДОз

Pav_13
Offline
Зарегистрирован: 21.05.2020

alexadresat, есть такое выражение «О вкусах не спорят!», поэтому спорить и не буду, а вот на картинку в твоем сообщении 5457 без содрогания смотреть не могу! :) 

А ник у меня латиницей потому, что форумы кириллицу не принимают :(... Движки-то форумные буржуйские!

Вот поэтому и надо свой родной язык максимально продвигать! Там, где это в наших возможностях... Вот разработает mambavamba дозиметр, какого в мире нет... и все кириллицей на русском! И пусть буржуины потеют над переводом, приобщаясь к «великому и могучему»!

Насчет названия хорошая идея, толко правильнее будет «АрДоз»!

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

Мне помница кто-то был против инверсии верхнего бара...

Pav_13
Offline
Зарегистрирован: 21.05.2020

»Бывает и на старуху проруха!» (народное)... ;)

Pav_13
Offline
Зарегистрирован: 21.05.2020

Вот добрый я излишне!

Обещал же твои посты цитировать, что бы ты править не мог!

Учись с первого раза мыслю излагать, а то применю угрозу! :))

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

Pav_13 - Да давай цитируй. Утопия.... Сейчас модно санкции применять )))

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Исправил! А на что переименовать?? Мб "Об устройстве"?

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Незнаю... может Параметры

mambavamba14
Offline
Зарегистрирован: 25.12.2019

#ArDos_with_RADON_2.0.0 - Также теперь можно ограничить счет среднего фона до предела в мкР(все что ниже придела - учитывается, все что выше - не учитывается) параметр в "SETUP" - "MAX_BACK_MID", "статистика" переименована в "параметры".

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Привет! Что советчиков докуя, а проверить не кому...

#define PARAM_RETURN     1 //вернуть статистику устройства(требуется optiboot v8) (1 - статистика доступна из интерфеса | 0 - статистика не доступна из интерфейса) - забыл переименовать в Параметры.

Что-то с быстрым счетом я не понял. Раньше пальцем прикасался счет до 20 доходил, а сейчас прямо летит...

mambavamba14
Offline
Зарегистрирован: 25.12.2019

alexadresat - Привет. Да точно, забыл...поправил)

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

alexadresat
alexadresat аватар
Offline
Зарегистрирован: 22.02.2017

mambavamba14 - Махом счет набирает... и махом падает.

 

mambavamba14
Offline
Зарегистрирован: 25.12.2019

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

В общем говоря простым языком, раньше была реакция изменения значений при росте фона как у черепахи, сейчас как у кролика))

UPD. Добавлено ограничение счета среднего фона до предела в мкР(все что ниже придела - учитывается, все что выше - не учитывается) параметр в "SETUP" - "MAX_BACK_MID"

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

mambavamba14, пока ускорение неудачно, уходим в циклический сброс-набор. Плюс фактически не реагирует на резкое снижение уровня фона.  См. видео.

 

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Попробуй загрубить: "PULSES_BACK_MIN  0"  "PULSES_BACK_MAX   20"

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

Сейчас попробую.

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

mambavamba14
Offline
Зарегистрирован: 25.12.2019

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

temp = map(constrain(rad_buff[1], PULSES_BACK_MIN, PULSES_BACK_MAX), PULSES_BACK_MIN, PULSES_BACK_MAX, GEIGER_TIME, 1);

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

rad_back = tmp_buff * ((float)GEIGER_TIME / temp);

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

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

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

То есть сравнение ведётся среднего по массиву с количеством импульсов за одну последнюю секунду? Немудрено, что разброс такой большой. Привязываться к количеству импульсов в единицу времени тоже не лучшая идея, здесь скорее отношение за малый период к среднему за большой, причем чем выше фон - тем меньше отношение. Для уровней, близких к ЕРФ - в 3...5 раз, для 200-500 мкР/ч в 2 раза, 500-3000 в 1,5-1.7 раза, для уровней выше можно непрерывно считать за несколько секунд.

tekagi пишет:
Я вообще больше склоняюсь к трём пороговым значениям времени, 1 сек., 5 сек., 20 сек. Сравнивать как с пороговым значением имп/с для определения, за какой интервал вести подсчёт (если фон несколько миллирентген, то там 36 секунд точно ждать не надо, но хоть и считаем по части, массив продолжаем заполнять, чтобы среднее видеть), так и кратность к среднему за весь массив, что позволит увидеть динамику изменения и не учитывать среднее за весь массив, тормозящее изменение отображаемых показаний.

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

1я - не учитываем,

средне за 1ю и 2ю - 7х,

среднее за 1-2-3ю - 5х

и т.д.

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

Сейчас при падении фона опять начинаем с малых значений и максимального времени счёта, то есть при фоне в 20 мкР/ч секунд 10-15 показывает фон ниже 15. Хотя после скачка и до первого полного набора массива логичнее считать не среднее за 36 секунд, а среднее за прошедшее с момента сброса время при пересчёте на 36 секунд.

Видео реакции обновил. Сейчас сниму скорость и стабильность показаний старой и новой версии.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Хорошая мысль считать от текущего фона, переделал и перезалил, попробуй.

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

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

Сейчас сниму видео сравнения алгоритма счёта твоей версии и модифицированного скетча Бодрого. Обрати внимание на скорость выравнивания показаний и стабильность при неизменном уровне фона. Из минусов - такое поведение только при первом наборе массива, прикрутить автосброс по скачку фона у меня руки так и не дошли, поэтому после первого набора полного массива (250 ячеек, ЕМНИП), реакция на скачки фона ооочень снижается. Планировал прикрутить описаный выше детект скачка и по нему обнулять массив далее точки сравнения, это как раз дало бы требуемый эффект. Чуть позже попробую детально расписать алгоритм, как я его вижу (если разберусь в своей же писанине годичной давности, мне на это тоже немало времени надо))).

Видео обновил. Значения в пресетах не менял, как скачал - так и залил.

Может разберёшься в моих набросках из 1.08.2. Просто для понимания, как оно работает до полного набора массива. Мне всё же такой алгоритм нравится больше:

		if (timer_seconds != count_and_dose_seconds) 
			{
				count_and_dose_seconds = timer_seconds;
					for (int i = 0; i < 254; i++)  //сдвигаем
					{
						mass_poisk[i] = mass_poisk[i + 1];
					}
				mass_poisk[254] = shet;
				if ((zam_poisk_counter < 254) && (zam_poisk_counter < geiger_counter_seconds))  //первый набор массива
					{
						fon_vr_poisk = fon_vr_poisk + shet;  						
						zam_poisk_counter++;
						fon = fon_vr_poisk*((float(geiger_counter_seconds))/(float(zam_poisk_counter))); 
//						fon_254 = fon;
						fon_254 = 0;
					}
				else if ((zam_poisk_counter < 254) && (zam_poisk_counter == geiger_counter_seconds))  //
					{		
						zam_poisk_counter++;
						fon_vr_poisk = fon_vr_poisk + shet; 
						fon = fon_vr_poisk*((float(geiger_counter_seconds))/(float(zam_poisk_counter)));
						fon_254 = fon;		
						fon_vr254 = fon_vr_poisk;
					}
				else if ((zam_poisk_counter < 254) && (zam_poisk_counter > geiger_counter_seconds))  //
					{
						fon_vr_poisk = 0;
						fon_vr254 = 0;
						for (int i = zam_poisk_counter; i > 0; i--) 
							{
								fon_vr254 = fon_vr254 + mass_poisk[254-i];
							}
						for (int j = 254 - geiger_counter_seconds; j < 255; j++) 
							{	
								fon_vr_poisk = fon_vr_poisk + mass_poisk[j];
							}
						fon = fon_vr_poisk;
//						fon_254 = (float(fon_vr254))*((float(geiger_counter_seconds))/(float(zam_poisk_counter)));
						fon_254 = (float)fon_vr254*((float)geiger_counter_seconds/(float)zam_poisk_counter); 
						fon_vr254 = 0;
						zam_poisk_counter++;
					}	
				else if (zam_poisk_counter >= 254)  //набор массива
					{
						fon_vr_poisk = 0;
						fon_vr254 = 0;
						byte geiger_counter_seconds_reverse = 254 - geiger_counter_seconds;
						for (int i = 254; i > 0; i--) 
							{
								fon_vr254 = fon_vr254 + mass_poisk[i];
								if (i > geiger_counter_seconds_reverse)
									{
										fon_vr_poisk = fon_vr_poisk + mass_poisk[i];
									}
							}
						fon = fon_vr_poisk;
						fon_254 = (float(fon_vr254))*((float(geiger_counter_seconds))/254.0);
					}
				shet = 0;
				doz_v = doz_v + fon / 100.0 / 36.0;
				time_doza = time_doza + 1;
				if (doz_v - doza_vr >= save_DOZ)  //а не пора ли сохранить дозу ?
					{
						eeprom_wrD ();
						doza_vr = doz_v;
					}
//Serial.print(" zam_poisk_counter=");
//Serial.println(zam_poisk_counter);						
			}

Планировалось:

Первая секунда после старта/ручного сброса. Массив обнулён, Текущий номер ячейки 0. Считаем по алгоритму из кода выше, проверок на среднее нет.

Набираем массив, считая среднее. Если после третьей - пятой секунды количество импульсов больше, к примеру, 20 - начинаем усреднение и сравнение. То есть на данном этапе у нас пять ячеек с данными более одного импульса.

Шестая секунда. Берём среднее ячеек 1 и 2 (последняя и предпоследняя секунда) и сравниваем со средним за все шесть ячеек. Если отношение ((i1+i2) /2 ) / ((i1+i2...i5+i6) /6 ) больше 10 - автосброс, то есть вытираем всё после второй и до конца массива. если нет - идём дальше.

Седьмая секунда. Берём среднее ячеек 1, 2 и 3 и сравниваем со средним уже за семь ячеек, пороговое отношение берём, к примеру, 9. Больше - автосброс с сохранением ячеек 1-2-3, меньше - далее.

Так где-то до 15й-20й секунды, в диапазоне 10-20 ячейки можно брать отношение где-то 0.5 - 0.3, и проверку на отношение раз в 3 ячейки, а не каждую.

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

Когда набрали весь массив - сравнение проводим либо со средним за 30-40 секунд, либо за весь массив, тут уж нужны эксперименты. Как и с коэффициентами отношений, ибо пока это всё наброски.

 

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Хмм...надо думать...тонкая грань получается между скоростью и стабильностью показаний... В этом видео была прошивка уже с зависимостью от дозы??

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

RADON залит с момента этого поста:

mambavamba14 пишет:
Хорошая мысль считать от текущего фона, переделал и перезалил, попробуй.

ArDos 1.08.2 ЕМНИП.

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

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Понял, буду пока думать - обдумывать)) Пока особо каких-то идей нет(кроме которой что сейчас реализована). В мыслях пока, что нужно что-то компактное, точное и быстрое, нужно думать как это реализовать...

UPD. Пока вернул старый алгоритм счета фона.

mambavamba14
Offline
Зарегистрирован: 25.12.2019

#ArDos_with_RADON_2.0.0 . Немного допилил свой алгоритм, попробовать что из этого выйдет.

Из нового: 1 - Теперь при превышении порога(установлен 50 мкР) начинается ускоренный счет, начальная счета половина от текущего времени счета и время счета будет падать с ростом фона. 2 - Добавлено 2-х замерное усреднение(предыдущее и текущее), если скачек(или снижение) фона меньше коэфициента(10 * (время.счета / текущее.время.счета)), то усредняем, если больше то пропускаем усреднение и выводим значение. 3 - Максимальный порог сдвинут до 100 мрЧ, чтобы более плавно убавлять время счета.

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

Стало чуть быстрее, но всё равно не то. Фон 20мкР/ч, выход на "полку" около миллирентгена 18 секунд, возврат к ЕРФ 21 секунда. Много, и видна линейность нарастания/спада показаний. "Болтанка" ушла.

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

Зачем нужен периодически заполняющаяся шкала прогресса, если считаем среднее за последние n секунд? Она должна заполняться только при первом наборе или после скачка показаний, чтобы пользователь видел, что отображаемые данные пока не достигли требуемой точности. Если массив набран показаниями без радикальных отклонений шкала должна быть полностью заполнена и статична. При ускоренном счёте можно показывать только часть шкалы, пропорционально уменьшению времени счёта. Хотя по логике вещей шкала скорее должна отображать погрешность, а при высоких уровнях фона и пропорциональном уменьшении времени счёта погрешность меняться не должна.

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

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Мб уменьшить GEIGER_BACK_MAX например до 10000 или вообще до 1000, должна вырасти скорость, но боюсь может появится та самая "Болтанка"(но это не точно). Предыдущие значения и так затираются, которые не участвуют в счете.

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

Хмм..А что если после скачка частиц мы как обычно уменьшаем время счета, но ка только начинают стабилизироваться импульсы по немногу возвращаем время счета на место, тем самым скачок фона будет виден сразу, а со временем (36 сек.) начнет возрастать точность из-за увеличения времени счета и шкала как раз будет это отображать?? Также и набор точности при первом включении/сбросе?

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

Не хочешь попробовать алгоритм, что я выше описывал?

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

mambavamba14 пишет:
Хмм..А что если после скачка частиц мы как обычно уменьшаем время счета, но ка только начинают стабилизироваться импульсы по немногу возвращаем время счета на место, тем самым скачок фона будет виден сразу, а со временем (36 сек.) начнет возрастать точность из-за увеличения времени счета и шкала как раз будет это отображать?? Также и набор точности при первом включении/сбросе?

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

Чую, при оптимизации алгоритма могут возникнуть проблемы с набором дозы, но я пока не смотрел реализацию. Сначала счёт, остальное потом.

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

mambavamba14
Offline
Зарегистрирован: 25.12.2019

tekagi - Я пока думаю, собираю информацию, уже кое-какая есть картина в голове как сделать... Просто попутно пару мыслей пришло по поводу этого алгоритма, решил попробовать что из этого выйдет))

Для среднего замера используется текущей фон и прибавляется он в общий массив каждую секунду. Понял, прибавлять старое среднее плохая затея))

Да я понял что к чему, будем двигаться в этом направлении)) Нет, с дозой никаких проблем, она никак не зависит от других расчетов, это практически полностью автономный блок(в принципе как и остальные).

Да, начнем с реакции на рост/спад, так будет логичнее))

tekagi
tekagi аватар
Offline
Зарегистрирован: 07.10.2016

Средний реализовать можно двумя схожими способами. Нам нужен усреднённый фон за последние где-то 5-7 минут. В старой версии был просто массив на 250 ячеек, по последним 36 считался текущий фон, по всему массиву средний. Но лучше пользовать один массив секунд на 60 для обычного замера, когда маркер времени полностью пробегает 60 секунд, то есть массив заполнился - считаем его сумму и закидываем во второй массив, где-то на 10-20 ячеек. Кидаем в первую ячейку, а весь массив сдвигаем, чтобы последняя вылетела. Ждём до следующего полного прохождения первого массива, повторяем суммирование и внесение в первую ячейку со сдвигом. Получаем данные за последние 10-20 минут, суммируем, пересчитываем по коэффициенту счёта счётчика - и у нас среднее за эти последние 10-20 минут (лучше время задавать в настройках, в диапазоне 3-20 минут). Но тут нужен тот же принцип детекта скачка среднего. Сам смысл длительного замера - замер фона в одном месте или одного образца. Если видим резкий перепад - перестаём показывать среднее и ждём, пока массив заполнится данными без резких отклонений от среднего значения. Иначе данные у нас попросту недействительные.

Максимальное значение мне, к примеру, мало интересно. Раньше я использовал максимум за последние 84 секунды только для масштабирования графика обычным map. В этом случае его вывод оправдан, позволяет визуально сопоставить отображаемые графиком данные. То есть высота столбика на графике могла быть и 30 мкР/ч, если фон плавает вблизи ЕРФ, и миллирентгены. Но тут уж дело вкуса, кому-то и такие данные интересны.