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

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

#ArDos_with_RADON_2.0.0 - Реализован новый алгоритм счета фона, шкала на экране фон теперь показывает точность измерения(заполненность массива счета), если фон статичный(+-) то шкала заполняется до полного и остается таковой до момента скачка/спада импульсов в первых двух ячейках по отношению к предыдущим 7-ми ячейкам, если зафиксировали скачок/спад - то оставляем первые две ячейки, остальные затираем и считаем по алгоритму "домножения" до времени счета пропорционально заполнению буфера счета. Также, если текущий фон меньше 50-ти - то не реагируем на резкие изменения и ждем превышения этого предела.

Также есть настройки алгоритма:

#define GEIGER_COEF_MIN       0.10 //минимальный коэфициент начала спада фона(влияет на чувствительность к спаду)(0..0.50)
#define GEIGER_COEF_MAX       1.00 //максимальный коэфициент начала скачка фона(влияет на чувствительность к скачку)(0.50..5.00)
#define GEIGER_CYCLE          6 //количество циклов до начала обработки коэфициентов(влияет на скорость реакции к спаду/скачку)(4..10)
#define GEIGER_BACK           50 //уровень фона, при котором начинать ускоренный счет(30..100)(uR)

 

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

О, так уже намного лучше. Не идеал, но направление верное.

Далее алгоритм продлеваться будет? Если да - то, думаю, от ограничения в 50 мкР/ч можно будет отказаться. Либо порогово, 2/7/1.0 - 7/17/0.5 - 15/40/0.3, либо плавно до 10-15 секунд, на каждом шаге добавляя помалу количество ячеек сравнения и соотношение скачка.

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

UPD. Похоже, при набранном массиве не стоит брать отношение 2/7 и т.д., лучше брать к среднему по всему массиву за вычетом уже пройденного (т.е. при 2/7 среднее для сравнения считаем для ячеек 3-7, а не 1-7. При полностью набранном массиве среднее для всех элементов, кроме первых 2). Если смоделировать подход к источнику (т.е. не моментальное поднесение, а медленное) - алгоритм не отрабатывает, потому что в 7 ячейках уже завышенные значения. Если алгоритм отработал или прибор только включили, то по уже набранным ячейкам, но не менее тех же 2/7, 7/17 и т.д.

Видео надо?

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

tekagi - Конечно будем допиливать, это все-же первый набросок)) Не совсем понял про какое среднее имеешь ввиду "(т.е. при 2/7 среднее для сравнения считаем для ячеек 3-7, а не 1-7)", типо делаем так - (1-2яч. / 5-9яч.)? Или наоборот не учитывать 3-9яч. при полностью набранном массиве, а брать в расчет следующие?

Да видео можно))

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

Видео обновил. Из странного: при удалении КИ значения могут как резко упасть до нуля или ЕРФ (что нормально), так и до значений в два-четыре раза выше фона и потом медленно спадать до ЕРФ.

Смотри, у нас есть массив из 60 элементов, уже набран значениями без сильных отклонений от среднего, прогресс-бар заполнен. Пусть ячейка 1 - последняя заполненная, 2 - предпоследняя и т.д. Тогда берём среднее за ячейки 1 и 2 и сравниваем их с средним ячеек 3-60, проверяем больше ли, к примеру, двух-трёхкратного превышения. Если да - сброс и набираем сначала, если нет - среднее ячеек 1+2+3 и сверяем со средним по ячейкам 4-60, но пороговое соотношение уже должно быть меньше, к примеру 2,5. И так где-то до десятой-пятнадцатой ячейки (опять таки подбирать экспериментально, но больше вряд ли стоит) и отношения 0.3-0.5. Если был сброс - то сверку для каждого шага начинаем не ранее набора требуемого количества ячеек для сравнения, то есть n набранных к 3n или 4n среднего. Набрали после сброса девять ячеек - можно сравнить три последние с шестью более старыми и так далее. Учитываем, что несколько ячеек у нас осталось после сброса, так что какие-то данные уже имеются. Если сброс произошёл при соотношении 5 последних ко всему массиву - то у нас есть пять ячеек с данными,  которые можно использовать для формирования второго среднего. Поскольку минимальное соотношение у нас n к 3n, то есть хотя бы две набранные ячейки к шести - то через три секунды мы уже имеем данные для быстрого (хоть и грубого) анализа.

Возможно коэффициент сравнения при уровнях, близких естественному фону (ЕРФ) придётся увеличивать, обычно фон может гулять в большом диапазоне. От 7 до 35 мкР/ч колебания при 36секундном замере в порядке вещей (для выравнивания у нас есть длительный замер ака "среднее"). Разница при отклонениях от ЕРФ плюс-минус 15 микрорентген не критична, а это уже превышение в несколько раз от среднего. В то же время разница между 5миллирентген в час и 8 миллирентген в час меньше х2, но такой скачок нужно отловить в любом случае. Нужен дополнительный коэффициент-множитель, вот только от какого уровня его считать? От среднего по массиву или от среднего свеженабранных ячеек? Скорее всего второе.

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

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

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

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

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

#ArDos_with_RADON_2.0.0 - Переработан алгоритм. Изменены конфигурации алгоритма счета фона:

define GEIGER_RAD_MIN       50 //минимум диапазона квантования коэфичиентов(0..100)(uR)
define GEIGER_RAD_MAX       1000 //максимум диапазона квантования коэфичиентов(100..10000)(uR)
define GEIGER_BACK           50 //уровень фона, при котором начинать ускоренный счет(30..100)(uR)
define GEIGER_CYCLE          6 //минимум циклов до начала обработки коэфициентов(влияет на скорость реакции к спаду/скачку)(4..10)

static const float coef_mass[2][6] PROGMEM = { //массив коэфициентов для диапазона квантования фона
  0.00, 5.50, //0-й порог(естественный фон)
  0.10, 2.00, //1-й порог
  0.15, 1.75, //2-й порог
  0.20, 1.60, //3-й порог
  0.25, 1.50, //4-й порог
  0.30, 1.25  //5-й порог
};

 

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

Нужен ли

define GEIGER_BACK           50 //уровень фона, при котором начинать ускоренный счет(30..100)(uR)

Если не учитывать минимальный уровень, что изменится? Так теряем время на набор среднего значения до этих 50, тормозя весь алгоритм.

UPD: Пока слишком чувствительный, буду играться коэффициентами. При ЕРФ (у меня около 20 мкР/ч) не доходит до набора среднего. Первый коэффициент поправка на уровень текущего фона, второй кратность?

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

 tekagi - Упс, забыл удалить дефайн...он все равно ни на что не влияет...

В массиве: 1-й коэффициент для спада, 2-й коэффициент для скачка, все что между ними считается недостаточным для скачка/спада.

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

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

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

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

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

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

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

tekagi - Так по моей формуле при спаде коэффициент падает при скачке растет, поэтому и в массиве их по двое.

alexadresat - Да, нужно будет запрещать первый порог, если массив набран меньше чем на половину.

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

Брр, что-то я в трёх соснах путаюсь. Это оно?

        if (geiger_time_now >= GEIGER_CYCLE) {
          for (uint8_t i = 2; i < time_now; i++) temp += rad_buff[i + 1]; //запоняем
          float now = ((rad_buff[1] + rad_buff[2] + 1.00) / 2.00) / (((float)temp + 1.00)  / (time_now - 2));
          if (now < GEIGER_COEF_MIN || now > GEIGER_COEF_MAX) {
            for (uint8_t i = 2; i < GEIGER_TIME; i++) rad_buff[i + 1] = 0; //стираем
            geiger_time_now = 2;
            tmp_buff = rad_buff[1] + rad_buff[2];
            rad_mid_buff = 0;
            first_mid = 0;
            tmr_mid = 0;
          }
        }

То есть минимальный и максимальный коэффициенты у нас вполне могут относиться как n и 1/n? К примеру двухкратное изменение как 0,5 при падении и 2 при росте? Тогда, если нет особой необходимости задавать раздельно, их можно заменить одним.

1.00 какую роль в формуле играет?

Смена коэффициентов сейчас зависит только от текущего фона, а не от номера обрабатываемой ячейки массива?

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

tekagi - Да, это оно самое)) Да можно заменить 1-м, но так можно более точно настроить фронт роста/спада. 1.00 - значение минимума, тк делить ноль нету никакого смысла или того хуже делить на ноль...)) Коэффициенты сменяются в зависимости от текущего фона. А зачем их менять от текущей ячейки если все равно у нас +- среднее по набранным ячейкам, но не менее минимального порога??

alexadresat - Тревогу поправил.

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

Ненене, так у нас будет дикая болтанка, какую я только что и наблюдал. Зависимость от фона - вторична. Первоочередное - зависимость от набранных данных. Если у нас уже набрано шесть ячеек - проверяем соотношение (i[1]+i[2])/2 к (i[3]+i[4]+i[5]+i[6])/4, коэффициент сравнения 5. Если семь - (i[1]+i[2]+i[3]/3 к (i[4]+i[5]+i[6]+i[7])/4, коэффициент сравнения 4.5, если восемь - (i[1]+i[2]+i[3]/3 к (i[4]+i[5]+i[6]+i[7]+i[8])/5, коэффициент 3. И так далее до десяти ячеек в правой половине формулы. Может отношение ячеек будет чуть иное (n к 3n), но принцип тот же. Если массив заполнен весь - каждую секунду пробегаем его целиком, проверяя на все условия, но по отношению к среднему по всему массиву минус ячейки, стоящие выше сверяемой. К примеру для текущей ячейки (i[1]+i[2]+i[3]+i[4]+i[5]/5  к  (i[6]+...+i[60])/55.

А зависимость от текущего фона: считаем грубо фон по правой половине формулы, по нему выбираем соответствие из дефайнов и умножаем на это значение коэффициент сравнения из первой формулы. Сверять с коэффициентом как >(5*Кфона) для роста и <(1/(5*Кфона) для спада. Где 5 - первый коэффициент сравнения, Кфона - поправка на текущий уровень фона.

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

mambavamba14 - А почему нет показаний mid vax? И на экране Доза тоже все по нолям. Текущий фон доходил до 52 мкР/ч, а так 36-24-18-14 мкР/ч.

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

#ArDos_with_RADON_2.0.0 - Переработан алгоритм. Изменены конфигурации алгоритма счета фона:

#define GEIGER_RAD_MIN       0 //минимум диапазона квантования коэффициентов поправки на текущий фон(0..100)(uR)
#define GEIGER_RAD_MAX       1000 //максимум диапазона квантования коэффициентов поправки на текущий фон(100..10000)(uR)
#define MASS_ALL             13 //всего данных в каждом массиве

static const uint8_t time_mass[MASS_ALL][2] { //массив выборки элементов из основного буффера для сравнения
  2, 4, //0-й порог
  3, 4, //1-й порог
  3, 5, //2-й порог
  4, 5, //3-й порог
  4, 6, //4-й порог
  5, 6, //5-й порог
  5, 7, //6-й порог
  6, 7, //7-й порог
  6, 8, //8-й порог
  7, 8, //9-й порог
  7, 9, //10-й порог
  8, 9, //11-й порог
  8, 10 //12-й порог
};

static const float coef_mass[MASS_ALL] { //массив коэффициентов сравнения для выявления скачков/спадов
  5.00, //0-й порог
  4.50, //1-й порог
  4.00, //2-й порог
  3.50, //3-й порог
  3.00, //4-й порог
  2.50, //5-й порог
  2.50, //6-й порог
  2.00, //7-й порог
  2.00, //8-й порог
  1.75, //9-й порог
  1.75, //10-й порог
  1.75, //11-й порог
  1.75 //12-й порог
};

static const float coef_back_mass[MASS_ALL] { //массив коэффициентов поправки на текущий фон
  1.50, //0-й порог
  1.40, //1-й порог
  1.30, //2-й порог
  1.20, //3-й порог
  1.10, //4-й порог
  1.00, //5-й порог
  0.90, //6-й порог
  0.80, //7-й порог
  0.70, //8-й порог
  0.60, //9-й порог
  0.50, //10-й порог
  0.40, //11-й порог
  0.30 //12-й порог
};

alexadresat - Очень странно..я это даже не трогал... И да, показания фона могут прыгать, пока не заполнен бар точность хотя-бы на половину(тк там считается примерно).

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

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

UPD: Максимум появился, до среднего дотикало не с первого раза, показания гуляют в значительных пределах. Придётся играться с коэффициентами.

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

GEIGER_RAD_MIN - Минимальный уровень фона для начала работы с коэффициентами коррекции фона(например 0 - начинаем смещать коэффициенты фона с 0 мкРч).

GEIGER_RAD_MAX - Максимальный уровень фона для окончания работы с коэффициентами коррекции фона(например 1000 - заканчиваем смещать коэффициенты фона с 1000 мкРч).

MASS_ALL - Количество элементов в каждом массиве(например 13 - в каждом массиве должно быть по 13 элементов).

Коэффициенты выставлены  на "абум", тк мне не на чем попросту их более точно выставить))

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

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

Теперь, похоже, дело за тестами. Жаль источник у меня максимум до полутора тысяч, видимо придётся эмулятор делать. Как раз на радиокоте недавно выложили.

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

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

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

tekagi - Да пусть остается, конфигурации все равно для тех кто разбирается в коде, да и для себя чтобы проще менять какие-либо параметры быстро. Для остальных основная вкладка "SETUP" есть))

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

setFont(TinyNumbersDown); //установка шрифта
invertText(true);
printNumF(now, 2, 28, 0, 46, 5, 32); //строка 1
invertText(false);

Добавить их можно во вкладку "таск бар" стр.2587

float now - нужно будет сделать глобальным, и удалить приставку "float" в таймере стр.532

Да чуть позже откомментирую алгоритм))

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

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

Пока крутится мысль сделать массив time_mass[MASS_ALL][2] на три столбца, а не на два, но это потом, а то вовсе запутаюсь. Может помочь более точном определении фона после скачка.

Основной рабочий массив у нас на 101 элемент с учётом выбрасываемой при сдвиге, то есть в массиве time_mass[MASS_ALL][2] сравнения сумма ячеек в одной строке может достигать 100, но не должна превышать это значение?

mambavamba14 пишет:
Да, нужно тестить отстраивать, вот кст эти строчки думаю помогут в отладке,

Эмм, а можешь обернуть в #ifdef? А то я может и сделаю, но это будет явно не с первой попытки))

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

tekagi - Да, основной массив 101 элемент, но это нужно для регулировки времени счета, те массив более чем на текущее время счета не заполняется, но можно и сделать чтоб двигался весь(типо история импульсов) и делать карты более большими. На данный момент time_mass не должен превышать текущего установленного времени счета.

Да могу, но уже завтра, а то уже голова кругом))

И да, архив обновил, добавил комментарии и подправил ошибку при сбросе по порогу, могло учитываться более 2-х ячеек.

UPD. Добавил смещение счета по всему массиву. Длинну массива можно задавать любую(36..255), все автоматически подстроится.

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

mambavamba14 - Ну и как теперь показания естественного фона подогнать?

Раньше замеры были 10-16 мкР/ч

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

alexadresat, а были какие?

Погоди подгонять, я с коэффициентами маленько пошаманю и конфиг файл скину. А то пока сильно разброс большой.

mambavamba14, похоже в строке

 float now = ((rad_buff[1] + rad_buff[2] + 1.00) / 2.00) / (((float)temp + 1.00)  / (time_now - 2));

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

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

UPD: alexadresat прав, с последним апдейтом началось завышение показаний. Первый набор - показания адекватные, как только набралась полная шкала прогресса - начинается рост, при норме у меня в 15-30 может дотикать до 54-75. Если обнулится по алгоритму ускорения - до набора шкалы опять более-менее адекватные, после набора - рост.

Конфиг ускорения пока вижу таким:

#define MASS_ALL             7 //всего данных в каждом массиве

static const uint8_t time_mass[MASS_ALL][2] { //массив выборки элементов из основного буффера для сравнения
  2, 6, //0-й порог
  3, 9, //1-й порог
  4, 12, //2-й порог
  5, 15, //3-й порог
  6, 18, //4-й порог
  7, 21, //5-й порог
  8, 24, //6-й порог
//  6, 7, //7-й порог
//  6, 8, //8-й порог
//  7, 8, //9-й порог
//  7, 9, //10-й порог
//  8, 9, //11-й порог
//  8, 10 //12-й порог
};

static const float coef_mass[MASS_ALL] { //массив коэффициентов сравнения для выявления скачков/спадов
  5.00, //0-й порог
  4.00, //1-й порог
  3.00, //2-й порог
  2.50, //3-й порог
  2.00, //4-й порог
  1.70, //5-й порог
  1.50, //6-й порог
//  2.00, //7-й порог
//  2.00, //8-й порог
//  1.75, //9-й порог
//  1.75, //10-й порог
//  1.75, //11-й порог
//  1.75 //12-й порог
};

static const float coef_back_mass[MASS_ALL] { //массив коэффициентов поправки на текущий фон
  1.70, //0-й порог
  1.40, //1-й порог
  1.30, //2-й порог
  1.20, //3-й порог
  1.10, //4-й порог
  1.00, //5-й порог
  0.90, //6-й порог
//  0.80, //7-й порог
//  0.70, //8-й порог
//  0.60, //9-й порог
//  0.50, //10-й порог
//  0.40, //11-й порог
//  0.30 //12-й порог
};

alexadresat, в помещении фон обычно сильно отличается от внешнего. Если уличный замерял в пределах 5-13 вдали от строений, то дома при 36 секундах в среднем 15-37. Стены фонят, шлаконабивные. В высотках гранит с плит влияет, плюс ДПР радона везде встречается. Но в данном случае таки баг счёта.

 

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

Среднее показание постоянно пропадает.

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

alexadresat - Уупс...шальным тыком время счета контузило до всего буфера)) Поправил.

tekagi - Единицы убрал, проверку на ноль сделал, конфиг залил. Архив обновил.

Да надо бы на гит уже ползти, но пока лень шото))

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

alexadresat пишет:
Среднее показание постоянно пропадает.

Это нормально, сброс идёт. Пока не отладим алгоритм ускорения, чтобы напрасно не дёргал - так и будет.

mambavamba14 пишет:
Да надо бы на гит уже ползти, но пока лень шото))

Можно ленивой версией. Регайся на гите, создавай пустой проект, импортируй папку с файлами АрДоса. На комп поставь Gitahead, подключи в нём свой репозитарий (там, правда, заморочка с ключом, но она разовая). Когда подхватил - у тебя на компе локальная копия репозитария. Сделал изменения в скетче - в gitahead: Stage all, commit. Можно комментарий добавить, что и зачем менял. Оно синхронизирует с сервером. В ём ещё и compare встроенный, тыкая по версиям видишь подсвеченным, что изменено по отношению к предыдущей. Notepad++ плюс gitahead, как по мне мастхэв. Хотя пора на студию переползать, ой пора...

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

Десять минут работы, вот такие результаты.

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

alexadresat - Полоска до максимума не доходит??

tekagi - Как то пробовал однажды атмел студио...шото не зашло))

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

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

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

Атмел и мне не понравился. Зато теперь регулярно на мыло микрочип спам шлёт, дескать у нас новые дев-киты по вкусным ценам. Ага, вкусные цены у китайцев)) А вот Visual Studio Code потыкать стоит. Ардуино поддерживает (не помню, плагином или из коробки), но заодно поддерживает такую прорву языков и функционал, что ой. Но да, надо разбираться и осваивать новое, что всегда нелегко :( Пока пользую Notepad++ с ардуино-плагином, по сравнению с АрдуиноИДЕ - как чоппер по сравнению с велосипедом "Зайка-3".

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

Похоже, map'ить коэффициент, зависящий от уровня фона не стоит, там нелинейная зависимость. Нужно будет три-четыре, ориентировочно для диапазонов 0-50, 50-300, 300-1500, 1500 - 144000.

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

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

tekagi - Над будет как нибудь попробовать)) Шош там блокнотике такого, шо иде даже рядом не стоит)) И да, архив перезалил, сделал более правильную проверку ну нули в массивах.

Да можно думаю что нибудь придумать по интереснее мапа, это пока для проверки так сказать))

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

Сейчас среднее вообще по нолям, ни разу за 40 минут...

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

alexadresat - А попробуй с первыми коэффициентами, также будет??

Перезелил архив, добавил ступенчатый перебор коэффициентов поправки по фону. Теперь конфиги выглядят так:

#define MASS_TIME             7 //всего данных в массиве коэффициентов времени
#define MASS_BACK             7 //всего данных в массиве коэффициентов фона
 
static const uint8_t time_mass[MASS_TIME][2] { //массив выборки элементов из основного буффера для сравнения
  2, 6, //0-й порог
  3, 9, //1-й порог
  4, 12, //2-й порог
  5, 15, //3-й порог
  6, 18, //4-й порог
  7, 21, //5-й порог
  8, 24, //6-й порог
//  6, 7, //7-й порог
//  6, 8, //8-й порог
//  7, 8, //9-й порог
//  7, 9, //10-й порог
//  8, 9, //11-й порог
//  8, 10 //12-й порог
};
 
static const float coef_time_mass[MASS_TIME] { //массив коэффициентов сравнения для выявления скачков/спадов
  5.00, //0-й порог
  4.00, //1-й порог
  3.00, //2-й порог
  2.50, //3-й порог
  2.00, //4-й порог
  1.70, //5-й порог
  1.50, //6-й порог
//  2.00, //7-й порог
//  2.00, //8-й порог
//  1.75, //9-й порог
//  1.75, //10-й порог
//  1.75, //11-й порог
//  1.75 //12-й порог
};

static const uint16_t back_mass[MASS_BACK][2] { //массив квантования коэффициентов поправки на текущий фон
  0, 50, //0-й порог
  50, 300, //1-й порог
  300, 1500, //2-й порог
  1500, 14400, //3-й порог
  14400, 20500, //4-й порог
  20500, 35200, //5-й порог
  35200, 65500, //6-й порог
//  6, 7, //7-й порог
//  6, 8, //8-й порог
//  7, 8, //9-й порог
//  7, 9, //10-й порог
//  8, 9, //11-й порог
//  8, 10 //12-й порог
};

static const float coef_back_mass[MASS_BACK] { //массив коэффициентов поправки на текущий фон
  1.70, //0-й порог
  1.40, //1-й порог
  1.30, //2-й порог
  1.20, //3-й порог
  1.10, //4-й порог
  1.00, //5-й порог
  0.90, //6-й порог
//  0.80, //7-й порог
//  0.70, //8-й порог
//  0.60, //9-й порог
//  0.50, //10-й порог
//  0.40, //11-й порог
//  0.30 //12-й порог
};

 

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

mambavamba14, попробуй. Сам блокнот, ардуино плагин. В плагине есть инструкция по установке, если всё верно - в меню "языки" внизу появится Arduino. Есть ещё весьма полезный compare плагин, но не найду исходного архива. Если поиском не найдёшь - напомни, выдерну из установленного. Единственный минус, по сравнению с ИДЕ - не подхватывает все связанные файлы из рабочей директории, приходится отрывать вручную (а может я просто не нашёл в опциях). Зато сохраняет состояние вкладок (открытых файлов) при выходе и обновляет их содержимое при открытии.

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

Сейчас получше ..., но вот максимально 54 мкР/ч, в работе 10 минут.

10 мкР/ч

mid: 13 мкР/ч

max: 54 мкР/ч

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

Видимо максимум, как и тревогу, следует брать из не менее n набранных ячеек.

Пока пользую так:

#define MASS_TIME             5 //всего данных в массиве коэффициентов времени
#define MASS_BACK             7 //всего данных в массиве коэффициентов фона
 
static const uint8_t time_mass[MASS_TIME][2] { //массив выборки элементов из основного буффера для сравнения
//  2, 6, //0-й порог
//  3, 9, //1-й порог
  4, 12, //2-й порог
  5, 15, //3-й порог
  6, 18, //4-й порог
  7, 21, //5-й порог
  8, 24, //6-й порог
//  6, 7, //7-й порог
//  6, 8, //8-й порог
//  7, 8, //9-й порог
//  7, 9, //10-й порог
//  8, 9, //11-й порог
//  8, 10 //12-й порог
};
 
static const float coef_time_mass[MASS_TIME] { //массив коэффициентов сравнения для выявления скачков/спадов
  5.00, //0-й порог
  4.00, //1-й порог
  3.00, //2-й порог
  2.50, //3-й порог
  2.00, //4-й порог
//  1.70, //5-й порог
//  1.50, //6-й порог
//  2.00, //7-й порог
//  2.00, //8-й порог
//  1.75, //9-й порог
//  1.75, //10-й порог
//  1.75, //11-й порог
//  1.75 //12-й порог
};

 

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

#ArDos_with_RADON_2.0.0 - Средний и максимальный фон начинают отображаться только после минимального набора точности, добавлена авария при отсутствии импульсов от счетчика, настроить интервал проверки можно в "config" параметр "IMP_ERROR_TIME", добавлена возможно вывода коэффициента на экран для отладки, параметр в "config" - "COEF_DEBUG", добавлен новый подпункт "ФОН1" в пункт настроек "Щелчки", он позволяет включать треск щелчков по превышению порога "Ф1".

UPD. Добавлен предел отключения режима сна устройства при больших уровнях фона для более корректной работы устройства, параметр в "config" - "RAD_PWR_MANAGER".

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

"Помедленнее, пжалста, я зап-писываю" (с) Шурик. А то перезаливать не успеваю))

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

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

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

У тебя с дуинки выпаяны светодиоды и преобразователь? Просто интересно сколько сейчас потребление во сне)) Есть небольшая мысля, тк в PowerDown находится постоянно не целесообразно(из-за пропуска 100 тактов) но зато в нем самое низкое потребление(до 10мкА камень жрет), то что если включать его только когда у-во прям именно спит(выключен дисплей) и например при ЕРФ до 50мкр...

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

Преобразовашка не выпаяна, так что точно не скажу. Надо дуинку отпаивать. А так разницы сон-работа почти не видно, около 8 миллиампер, может на полмиллиампера падает. Кстати, в пункте "ЩЕЛЧКИ" тоже просится "КР.СНА". Коль уж уснул - так не храпи.

Может вечером выпаяю, проверю.

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

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

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

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

Так и должно быть, подразумевалось что выход из сна/включение подсветки будет происходить только по нажатию, а на удержание не реагировать))

Вот поэтому PowerDown и не использовал...Только сейчас вот дошло что можно на низком фоне включать, а при повышении использовать более легкие режимы сна))

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

Ну тогда нормально. Фича))

Ага, похоже стабилизатор питания либо снят, либо вообще никакого воздействия не оказывает. Загнал в программное выключение из быстрого меню - около микроампера.

Кнопки малёхо тупят. Сброс делал.

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

tekagi - Тогда очень странно что 8мА кушает...А сам преобразователь сколько не замерить? И ещё, 8мА с подсветкой или без?

Разбил счет фона на несколько этапов, должно стать нормально.

UPD. Перезалил, забыл нули из переменных выкинуть...

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

Пришлось сходить в мастерскую, впаять джампер на преобразователь. С подсветкой 11мА, без подсветки 8мА. При уходе в сон почти не меняется, может на 100-200мкА меньше (плавает). На преобразователь 900мкА.

Чтой-то у меня не выходит вывести в дебаг (coef * coef_back), постоянно нули выдаёт. Разместил над надписью мкр/ч, если вывожу только coef всё работает, а перемноженый не хочет показываться. Забираю его в глобальную debug_coef после

for (uint8_t i = time_1; i < (time_1 + time_2); i++) temp += rad_buff[i + 1]; //запоняем буффер вторго плеча
debug_coef = coef*coef_back;

Вывожу в блоке COEF_DEBUG:

      invertText(false);	  
	  printNumF(debug_coef, 2, 54, 8/*, 46, 5, 32*/); //строка 1

Вроде ж ни один из коэффициентов нулю не равен...

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

tekagi - Прошивка последняя которую в посте выше обновил?? Возможно потому что coef уже перемножен с coef_back тут:

coef = coef_time_mass[mass_switch] * coef_back; //получаем коэффициент из массива для сравнения на скачок/спад

 

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

Да не похоже, дальше ж идёт 

if (now < (1.00 / (coef * coef_back)) || now > (coef * coef_back)) { //если видим скачок или спад

Ладно, сейчас стяну новую.

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

tekagi - Ох это ещё со вчерашней... Сегодня я оптимизировал это дело... Как то со сном очень странно..не должен столько камень кушац в standby...

UPD. - Архив перезалил, сейчас заметил что неправильно считывал массив коэффициентов фона после оптимизации...

 

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

mambavamba14 - Просто идет постоянный набор за 2 минуты уже 1300 мкР/ч набрало. Кнопки отзываютя нормально.