естественно я если выкладываю на интервале ЭБУ - ОНО СГЛАЖЕНО! а как еще то ведь на один ответ из ЭБУ из лямбды их будет не менее 10-ти. А что, можно как то еще записать в лог 10 ответов если ячейка одна?
Ну вот смотри почему я считаю что это не всегда есть хорошо.
Обычно же как делают это сглаживание чтобы экономить ресурсы и особо не потерять в производительности, правильно, как ты любишь говорить - погроминг вульгарис. Самый первый метод который всегда и всем приходит на ум это - накапливаем сумму значений лямбды между диагностическими запросами от эбу и счетчик количества полученных значений от шдк.
Пусть у нас заданный состав смеси =12.7 AFR
Пусть у нас 10 значений прилетело (то есть счетчик=10), и для простоты понимания пусть они (давай в значениях AFR) будут такими 12.4, 13.0, ... 12.4, 13.0
Давай их просуммируем и получим (12.4+13.0)*5=25.4*5=127, что по итогу даст нам сглаженное среднее значение "по больнице" =127/10=12.7 ... Ну, красиво, валидно, стильно, модно, молодежно - бери значение да используй в своем автотюне ... тем более что расхождения между заданным составом смеси и составом смеси по ШДК нет, значит коэффициент коррекции =1
И это всё круто если у нас вдруг не окажется китайская "вялая глючная лямбда", либо у нас не полезет какие-то другие артефакты, а может и проблемы по пропускам ...
Вот смотри пусть у нас в нашей замечательной цепочке вдруг где-то добавится ещё одно значение от лямбды, то есть между запросами эбу прилетит 11 значений от лямбды и в той же цепочке где-то рандомно окажется это лишнее значением=22.04 AFR
Значит мы получим сглаженное значение с лямбды равное (127+22.04)/11=149.04/11=13.549090909090909091 ..окай, пусть 13.549 AFR ... Выглядит как валидное для автотюна? - выглядит. Надо ли его использовать как отклонение от целевого состава смеси для коррекции? - получается надо, ведь у нас отклонение на 13.549-12.7=0.849 AFR, то есть получается надо корректировать и тянуть смесь из бедной к целевой. Но это же не правильно, у нас 10 значений более валидных которые говорят - не трогай, всё более-менее норм.
Окай. Давай отсеивать такие всплески. Ну к примеру будем не суммировать значения а тупо ими наполнять какой-то массив между запросами эбу, и еще (опять же один из популярных методов работы с такими данными) откидывать самое маленькое и самое большое значение из этой цепочки. Тогда у нас отлетит одно значение 12.4 (как минимальное) и отлетит наш "всплеск" 22.04 и мы получим "среднее по больнице" =(149.04-22.04-12.4)/(11-1-1)=114.6/9=12.733333333333333333 ... Окай, пусть 12.73 ... Лучше чем прошлый метод? - Лучше. Но опять же, а если "всплесков" будет больше одного в выборке, то получим вариант не лучше первого, опять получим какое-то псевдовалидное значение, от которого опять будем корректировать автотюном ... Да и опять же, массив, поиск экстремумов, тратим память (да и хуй с ней) и расчетные ресурсы (это уже важно) ...
То есть при обоих верхних методах мы можем получить ошибку расчета, где она нам не нужна, когда будем использовать некоторое псевдовалидное значение, вместо того чтобы
как у меня - игнорировать такое значение в расчете и автотюне, ибо не валидно, так как в цепочки "выбивается из строя", и говорит только о том, что надо проверить почему оно вылезло (может пропуск искры был, а может просто лямбда вялая и китайская) ... Но тянуть автотюном в этот момент ничего никуда не надо. И если отдельные всплески есть, то просто обратить на это внимание (вдруг это предтеча каких-то проблем), а вот если прям посыпались эти значения потоком, то тут должна появится огромная красная надпись на экране, которая гласит - "вырубай нахуй, страшно ..." и включить аварийный режим до выяснения обстоятельств.
