Arduino.ru

#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)

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

Далее алгоритм продлеваться будет? Если да - то, думаю, от ограничения в 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 и т.д.

Видео надо?

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

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

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

Смотри, у нас есть массив из 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, но такой скачок нужно отловить в любом случае. Нужен дополнительный коэффициент-множитель, вот только от какого уровня его считать? От среднего по массиву или от среднего свеженабранных ячеек? Скорее всего второе.

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

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

#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-й порог
};

Нужен ли

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

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

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

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

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

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

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

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

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

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

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

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

        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 какую роль в формуле играет?

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

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

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

Ненене, так у нас будет дикая болтанка, какую я только что и наблюдал. Зависимость от фона - вторична. Первоочередное - зависимость от набранных данных. Если у нас уже набрано шесть ячеек - проверяем соотношение (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 - первый коэффициент сравнения, Кфона - поправка на текущий уровень фона.

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

#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 - Очень странно..я это даже не трогал... И да, показания фона могут прыгать, пока не заполнен бар точность хотя-бы на половину(тк там считается примерно).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 - Уупс...шальным тыком время счета контузило до всего буфера)) Поправил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-й порог
};

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

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

10 мкР/ч

mid: 13 мкР/ч

max: 54 мкР/ч

Видимо максимум, как и тревогу, следует брать из не менее 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-й порог
};

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пришлось сходить в мастерскую, впаять джампер на преобразователь. С подсветкой 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

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

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

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

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

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

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

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

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

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