TRS-SOFTWARE

Хотел бы поинтересоваться у разработчиков проводились ли исследования чем ограничена скорость соединения есть ли резервы ее повышения, впринципе 10 пакетов вполне достаточно но думаю никому небыло бы плохо если бы стало например 15 тк ловить стационар в некоторых режимах было бы проще чем увеличилась бы скорость заполнения таблиц. Понимаю что Это уже из разряда "дое..аться" но все же интерестно.

Это именно из того самого разряда. Стационарность определяется не количеством пакетов а временем. Это как с той секретаршей, которая печатает 500 знаков в минуту... правда такая херня получается....

Довольно немногословно. Как насчет того что 2.23 проигрывает по пакетам и чо там соскоростью/таймингами. Насчет секретарши, Проводил эксперемент при количестве пакетов 7 и количестве пакетов 9-10 заполнение таблич намного быстрее при 10, думается что потому как на скорость заполнения влияет не только стационар или нет а еще и количество попаданий а на больших оборотах с этим проблемы тк ну не хотят они держаться ровно а имеют тенденцию либо расти либо падать. На вопрос о том что ограничивает скорость соединения хотелось бы тоже получить ответ - так для самообразования, если не сложно конечно оответить.

Я не согласен с Shtep'ом.
Текущий алгоритм настройки лично я считаю не оптимальным.
Как он работает...
Алгоритм следит за текущим потоком данных, если показатели не отвечают стационарности - запрет обучения. если отвечают, текущие значения считаются достоверными, и по ним строится поправка.

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

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

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

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

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

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

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

Для начала надо разобраться с терминологией, что такое стационарность. Потом что такое сходимость алгоритма. Потом почитать краткое описание иолта и подумать головой. Посе этого объясните мне, как связана скорость опроса, стационарность точки и алгоритм обработки? - вобщем то никак.
Стационарность определяется только одним параметром - временем неизменности параметра. Можно сделать 150 опросов за секунду, можно 10 за 2. При условии что и там и там данные не изменились - во втором случае стационарность будет вдвое выше чем в первом, при условии что у нас целевая функция не меняется чаще чем несколько раз в секунду. При этом весовой к-т будет выше у первого случая. Вопро - что даст более точную коррекцию?
Ну а по алгоритму - даже время тратить не буду. в ИОНе реализованы оба алгоритма. На данный момент - грубое регулирование, пошаговое, регулирование с аппроксимацией и со сглаживанием. Дополнительно есть статистическое регулирование в режиме накопления. При етом везде можно менять весовой к-т внешнего регулирования. что еще надо? Опять к кнопке "сделать зашибись" вернемся?

Кстати, говорить о "настройке высокой точности" по постобработке логов - можно только при условии катания примерно настроенного аппарата с ВЫКЛЮЧЕННЫМ внешним регулированием. Что впринципе малоприменимо для коммерческой настройки. Ибо надо сначала настроить, потом день-два катать с разными режимами и накоплением.
Ненастроенный и без коррекции - это бред.

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

ilkari, я то же хотел чтоб было всё в идеале с кнопкой "чтоб валило" , эксперементировал продолжительное время, и в итоге собрал нагрузочный стенд для мотора. На стенде можно хоть ИОНом, хоть ОЛТом, взял режимную точку, и удерживай сколько угодно. Выкатывается от и до! Если руки чешутся включаешь ОЛТ, газоанализатор и сидя в наушниках крутишь каждую режимную точку - ваще нормально получается, т.к. CO/CH в каждой точке можно в идеал накрутить. Рекомендую.

_________________
Семь футов под килем!

хвались самодельным стендом)))

Я обычно финально так и делаю накапливаю много данных а потом коректирую.

Хотелось бы экспертную оценку что такое случилось со скоростью соединения и таймингами. И у всех ли такое или это опять же единичный случай?

У меня на 2XX стабильно 10 пакетов бегает на 56к 40/40.