LC-1 - продолжение экспериментов.

Зачитавшись патентом Клауса http://www.google.com/patents/US6978655 я понял, что теория конечно хорошо но интересна и ее практическая реализация. Кроме того при работе с прибором постоянно возникают вопросы на которые необходимо знать ответы - например о калибровке на свободном воздухе?! Что будет, если например откалибровать контроллер на одном датчике а потом подключить другой? Можно ли определить остаточный ресурс датчика и предугадать время его смерти? Поэтому было решено произвести полный реверс инжиниринг П.О. LC-1 с восстановлением полной математической модели происходящего, включая все магические константы не указанные в патенте, и в итоге научится получать из этого прибора намного больше, чем просто смесь. 

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

Началось все со схемы. По сути в сети давно есть схема LC-1 в плохом качестве - за день она была расчищена и проверена на реальном контроллере на предмет совпадения с платой. 

С прошивкой тоже нет проблем. DLD файл - это прошивка Atmega64 в открытом виде если от нее отрезать 20h байтный хидер. Прошивку решено было взять самую первую v1.00 alpha - она вполне нормальная и по объему не большая. Однако позже было решено получить исходный текст и товарной прошивки v1.10 поскольку управление нагревателем ДК в этой прошивке несколько отличалось и в целом получаемые с нее показания были несколько стабильнее (менее зашумлены), однако v1.10 более склонна к "ошибке 8" на датчиках которые с v1.00 еще работают. Также был получен исходный текст от более позднего встраиваемого решения (OEM плата контроллера innovate из LM2 http://www.innovate-tech.com/products.html) - просто так за компанию, чтоб проверить нет ли там чего нового в области работы с лямбдами... 

В качестве дизассемблера для контроллеров я предпочитаю использовать ПО, которое дает код, по синтаксису соответствующий заводскому macro assembler либо полностью, либо наиболее близко (чтоб меньше надо было потом править руками и не было проблем с последующей сборкой). Для pic например таким заводским ассемблером является mpasm, а для AVR - avrasm2. В данном случае в качестве дизассемблера лучше всего подошел DasmAVR 1.28 от наших Китайских товарищей, увы унылая ida как всегда оказалась за бортом прогресса  - поскольку она как обычно, не отвечает именно указанным требованиям, и ее код просто сразу без танцев с бубном не собирался, да и вообще на ней вечно проблемы со всем, что не x86.

Получение компилирующейся прошивки с корректным указанием всех методов адресации данных и кода при таком размере, бинарного файла  - вопрос пары часов. Гораздо сложнее найти нужные библиотеки и определить названия их функций и методы вызовов. Причем если с целочисленной арифметикой было все ясно сразу же после первого взгляда, то с float функциями пришлось повозиться, поскольку очень велика вероятность ошибки в функциях того же сравнения - визуально по коду очень похожих либо вообще одинаковых. С помощью утилиты avrobjdump дизассемблировались все стандартные библиотеки float когда либо в каком то виде доступные для avr и код проверялся на совпадение с нашим.  В данном случае методом перебора всех подряд вариантов было определено, что предположительно прошивка собиралась winavr-20050214 или близкой к ней по дате версией, т.к. именно ее библиотеки имеют наибольшую степень корреляции с нашим кодом. 

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

В конце концов как только все функции float были распознаны и настало время создать математическую модель алгоритма. Для подобных устройств наиболее простой способ создать математическую модель - это воспользоваться программой excel.

В кратце, алгоритм работы контроллера LC-1 такой: Устройство подает на ячейку Pump некий положительный потенциал (+Ipump) и ждет переключения ячейки Sense - время между подачей этого потенциала и переключением мы назовем T1. Далее устройство подает отрицательный потенциал (-Ipump) и снова ждем переключения- это время T2. далее процесс циклически повторяется.

Измерение обоих времен между переключениями производится аппаратным 16 разрядным таймером с дискретом отсчета времени 0.5мкс. Программно таймер расширяется до 32 разрядов (счетчик в переполнении). Периодичность цикла (T1+T2) как показала практика лежит в пределах 3-8мс (значение можно увидеть осциллографом, на выводах PA0 PA2 контроллера atmega64). 

Итак мы получили Т1 и Т2 которые являются целыми 32-х разрядными числами, на основе этих чисел контроллером вычисляется Duty Cycle, которое мы далее для краткости будем называть DC, по формуле:

DC=(T1-T2)/(T1+T2)

Анализ этой формулы показывает нам, что значение DC лежит в диапазоне -1 +1 в случае же T1=T2 DC=0. 

Для того чтоб проделать это вычисление, полученные времена (а точнее их суммы и разности) переводят в формат float c 32-мя разрядами (IEEE754) таким образом далее все вычисления идут уже с float .

Теперь введем 2 определения DC:  DCexhaust - то что контроллер получает когда датчик находится в среде выхлопа и DCair - то что контроллер показывает на свободном воздухе (при калибровке сенсора на свободном воздухе).

Процесс калибровки достаточно простой. Контроллер проверяет находится ли датчик на свободном воздухе. (диапазон считываемых DC близок к свободному воздуху) а так же нажали ли кнопку или запустили процесс с logworks - lm programmer вставили новый датчик, включили прибор после сброса etc.. и если это так запускает процесс калибровки. Калибровка по сути это усреднение T1 и T2 на интервале 81.25ms*25=2cек (примерно). И дальнейшее запоминание полученных констант в памяти eeprom контроллера. Причем для хранения 32-х разрядных чисел используется простой способ их упаковки. Поскольку численные значения T1 и T2 не важны а важно только их соотношение - контроллер проверяет равны ли нулю старшие 16 разрядов у T1 и T2 и если не равны просто делит T1 и T2 на 2 до тех пор пока старшие разряды не вырождаются до 0. Полученные 16-ти разрядные константы сохраняются в eeprom контроллера и  затем будут использоваться для расчета DCair, пока процесс калибровки не будет запущен заново. 

В рабочем режиме лямбда вычисляется достаточно просто:

Для положительных значений DCexhaust:   lambda=DCair/(DCair-DCexhaust)

Для отрицательных значений DCexhaust:    lambda=(DCair/(DCair-DCexhaust))*0,71428+(1-0,71428)

Формула для вычисления % кислорода:    %O2=DCexhaust/DCair*20,9+0,08

Простейший анализ этой формулы дает нам ответы - что же такое калибровка у LC-1 и как она работает:

1) Калибровка - это наклон оси характеристики прибора относительно центра в точке DCexhaust=0 Lambda=1.

2) В точке Lambda=1 AFR=14.7 DCexhaust=0 калибровка не имеет никакого значения - т.к. показания прибора никак от нее не зависят в случае если состав смеси стехиометрический.

3) Чем дальше состав смеси от стехиометрического тем больше влияние калибровки на свободном воздухе.

4) Максимальное влияние калибровка оказывает собственно - на свободном воздухе. ;)

5) В основе калибровки сенсора лежит допущение о постоянстве содержания кислорода в воздухе = 20.9% при любых температурах и давлениях. Как показывает опыт в атмосферном воздухе, вне зависимости от  условий это действительно так и допущение справедливо.

Теперь когда мат-модель полностью восстановлена настало время проверить ее адекватность. Для этого необходимо получить исходные данные (T1 и T2) в какие то моменты времени и произвести параллельное вычисление результата с одновременным контролем результата получаемого от прибора при калибровке на свободном воздухе и при измерении "псевдо выхлопа", задатчиком смеси для которого как всегда является обычная пропан-бутановая зажигалка. 

Для получения T1-T2 пришлось дописать в исходник с десяток строк кода. Суть в том, чтоб контроллер на запросы с ПК полностью отдавал содержимое своего ОЗУ и таким образом любая переменная в контроллере могла быть введена в исходные данные мат модели в excel. Первые же опыты с запросами содержимого ОЗУ показали, что полученная модель абсолютно адекватна реальному контроллеру. 

Сразу же в 2-х разных контроллерах были откалиброваны 6 разных датчиков c последующим чтением значения DCair непосредственно из ОЗУ микроконтроллера, при этом было получено 12 констант, так или иначе все они лежали в диапазоне 0,61561-0,655099 

Таким образом для смеси: с приборным AFR=11 при DCair=0,61561 в случае если сенсор был ранее откалиброван с получением DCair=0,655509 а затем заменен, индицируемое AFR  составит 11,14 (отклонение 1.3%). т.е. ошибка измерения связанная с ошибкой выбора датчика в данном случае на критическом участке характеристики настройки не превышает 0.14 единиц AFR, что ни коим образом не влияет ни на саму настройку ни на дальнейшую работу двигателя (совокупная методическая ошибка speed density алгоритмов реальных современных ЭБУ применяемых при тюнинге - около 5%)!

Кстати не к месту вспомним про AEM  - у которого дискрет отображения 0.1 а точность любого прибора не может превышать 1 дискрет его отображения, получается что если иновейт вообще никогда в принципе не калибровать по воздуху - он с огромной вероятностью все равно точнее АЕМа...  ;)

Картинка ниже отражает зависимость Lambda от DCexhaus  при калибровочных значениях DCair=0,6 и DCair=0,7взятых как пример, расчет выполнен с использованием модели в еxcel.

О поддержке LSU-4.9

Как вы знаете LC-1, как и все остальные продукты innovate работает с датчиком BOSCH LSU-4.2 однако в прошивке v1.00 есть поддержка датчика NTK1H1 (полностью работоспособная) и LSU4.9 (заблокированная). Прошивка v1.10 работает только с LSU4.2 - все же остальные датчики там всегда блокированы. Так же для LC-1 существуют прошивки v1.20RC4 и V1.21- с ними пока не понятно...

В формуле вы могли заметили число - 0,71428 это константа заклона оси характеристики в области отрицательных (богатых) значений DCexhaus для датчиков LSU4.2 и NTK1H1, для датчика LSU4.9 во всех прошивках LC-1 она равна 0,6431. Однако же в прошивке для контролеров LM2 и LC2 для датчика LSU4.9 уже используется та же самая константа 0,71428 что скорее всего более верно, поскольку Клаус неоднократно писал, что константы одинаковые... Таким образом неправильная константа - еще один уровень блокировки. Ну и последний (надеюсь) уровень - собственно подпрограммы выбора типа и переключения типа сенсора в которые явным образом специально были внесены ошибки.

Датчики LSU отличаются только сопротивлением нагревателя но и размером ячейки а так же предельно допустимыми токами Ipump. LSU4.9 быстрее греется, но несколько медленнее (не существенно, как показала практика) реагирует на изменения состава, предельно допустимый ток Ipump у нее меньше. Медленность скорее всего обусловлена еще и тем, что контроллер подает Ipump одинаковый для датчиков этих типов, в то время как целевое Rpump значительно отличается - и в результате даже на меньшей ячейке динамика накачки у LSU 4.9 страдает... Т.е. сейчас с точки зрения системы LSU4.9 - ничем не лучше, видимо этим и обусловлено отсутствие поддержки которая просто не была нужна. Но времена меняются и я решил разблокировать поддержку в ПО и провести опыт подключения датчика LSU4.9 к контроллеру LC-1 с параллельным подключением LSU4.2 к другому контроллеру для определения точного значения корректирующей константы заклона оси. Собственно проблема состоит в том, что LSU4.2 на новых автомобилях очень давно не используется и с производства снят. Раньше он шел как запчасть от VW с номерами Bosсh и VW на корпусе. Потом VW номер с корпуса пропал. Уже сейчас в новых комплектах innovate идет китайский датчик LSU4.2 у которого вообще нет никакой маркировки и странным образом выглядит изолирующая оплетка кабеля - в общем Bosch 7057 уже "не торт", и стоит немного поволноваться на этот счет. LSU4.9 же пока  стоит на новых машинах, следовательно не стоит ожидать проблем хотя бы с качеством наличием и ценой.. 

NTK1H1 - редкий датчик который впервые использовали на серийной Хонде 1500 в середине 90-х, стоит как чугунный мост, по некоторым сведениям - медленнее, и в данный момент не вызывает особого интереса. Хотя так же по словам - датчик значительно более надежный.

Прогрев и контроль нагревателя.

Некоторые данные для управления прогревом из прошивки LC1 v1.10F:

Параметр/Датчик. NTK LSU4.2 LSU4.9
Минимальное допустимое напряжение питания контроллера (В) 11,08 7,6 5,029
Минимальное сопротивление нагревателя (Ом) 2 1,8 1,6
Максимальное сопротивление нагревателя (Ом) 30 30 30
Целевое сопротивление нагревателя для прогретого сенсора (Ом) 9.1 6 7.5
Целевое R nernst  для контроля момента прогрева датчика (Ом) - 80 200
Целевое R pump для управления нагревателем (Ом) Определяется в процессе калибровки
Порог R pump cell cirquit shorted (Ом)   17 17
Порог R pump cell cirquit open (Oм)   600 600
Порог R nernst cell cirquit shorted (Ом)   2 2
Порог R nernst cell cirquit open (Oм)   501 501

Прогрев сенсора обеспечивается по сложной номограмме - критерием окончания прогрева является достижение целевого сопротивления нагревателя для прогретого сенсора. Фактически показания warming up % на приборе это оставшийся процент до достижения сенсором прогретого состояния. При этом сопротивление холодного сенсора (для LSU 4.2) будет принято за 0% а 6 Ом за 100%. После достижения целевого сопротивления нагревателя контроллер продолжает прогрев для достижения сенсором целевого сопротивления уже в измерительной ячейке (Nernst). Как только целевое R Nernst будет достигнуто - сенсор считается прогретым. Судя по константам, используется характеристика и температурный режим рекомендованный BOSCH для сенсоров LSU в начале 2000-х годов (более горячий режим, чем Rn 100, 300 который рекомендуется для современных сенсоров LSU 4.2 и LSU 4.9).

Прогретый сенсор контролируется путем измерения R pump. Которое в процессе калибровки определяется в конкретной комбинации сенсор-контроллер и запоминается для достигнутого целевого значения R nernst после калибровки.

Модификация прошивки LC-1.

Одной из задач изменения кода прошивки собственно была открытие и проверка поддержки LSU4.9, вторая задача возникла спонтанно.. Высокоскоростной протокол реализованный в J5LS позволяет вести съем данных системы управления с программируемым интервалом в 20-30мс. Обычный протокол Января имеет программируемый интервал запроса 50-200мс. LC-1 измеряет состав за 2-5мс (как мы выяснили выше) но  выдает результат в виде среднего арифметического с интервалом 82мс. т.е. LC-1 делает минимум 10-40 измерений, чтоб выдать результат в то время (как писал сам Клаус) достаточно всего трех. В итоге в прошивку LC-1 был добавлен новый протокол связи, причем переключение на этот протокол производится на лету, таким образом, чтоб устройство, для всех программ от Innovate, выглядело как обычная LC-1, но посылка "волшебных байт", переключала бы ее в режим, когда на интерфейс c высокой скоростью выдавалось каждое произведенное измерение и состояние всех необходимых переменных для воспроизведения этого измерения на ПК. При этом скорость передачи увеличивалась до 115200. Прошивки получили литеру F в конце номера версии. 

Для реализации был выбран HDLC протокол. Обладая небольшой избыточностью (не многим больше, чем сейчас у LC1) этот протокол позволяет пересылать пакеты произвольной длинны с контролем целостности в виде CRC16 контрольной суммы не загружая процессор. В HDLC пакет включается обычные для LC1 статус и lambda, исходные времена T1-T2 и напряжение питания контроллера (оно позволяет контролировать питание на 37 выводе ЭБУ куда собственно и подключен контроллер,  что как показывает практика, совсем не лишнее при настройке). Раз в 2c передается пакет с калибровочными T1-T2, типом ДК и периодом PWM его нагревателя.

Параллельно в прошивке при переключении на высокую скорость полностью блокируется вывод информации о составе в ЦАП. Так же блокируется 0-й канал USART который служит для соединения приборов innovate в цепь и в реальности мной никогда не использовался а так же другие лишние участки кода не влияющие на измерения. Cам же код связанный с измерением немого пересмотрен и из него убраны некоторые узкие места...

Эксперименты с прошивкой показали, что при переключении на высокую скорость обмена и росте потока данных общая стабильность показаний прибора упала и в режиме свободного воздуха появился заметный шум в младшем разряде %O2. Выяснилось, что причиной была помеха от ADM202 на аналоговые цепи лямбды. ADM202 содержит внутри встроенный генератор отрицательных и положительных напряжений для работы интерфейса RS232 на переключаемых конденсаторах и каждый передаваемый в этот интерфейс байт значительно увеличивает потребление МС и генерирует широкий спектр помех. Разработчики знали об этом и поставили в цепи питания микросхемы дроссель с конденсатором.  В итоге было принято решение ADM202 с платы выпаять и соединить процессор с USB-COM адаптером исключительно по TTL уровням, причем питание для адаптера брать с USB. Помехи тут же пропали и стабильность показаний вернулась к "норме" для LC-1. Основным же источником помех в системе остается схема контроля нагревателя ДК. Однако прошивка имеет механизмы фильтрации этих помех.

В "Матрице" было реализовано авто переключение контроллера в высокую скорость и прием HDLC пакетов - для этого тип контроллера выбирается как "Innovate-LC1 fast". Для нормальной работы пришлось установить повышенные приоритеты для процесса и потоков отвечающих за получение информации с ШДК, для корректной обработки информации так же пришлось повысить точность системного таймера Windows с 15мс (штатно в XP) до 1мс.  Первые же опыты с новой прошивкой дали потрясающие результаты - на один стандартный запрос диагностического пакета по KWP удалось получить от 40 до 90 измерений Лямбды с средним периодом (для уже старенького датчика) 2-4 миллисекунды на измерение. Вот файл потока полученный с LC1 c новой прошивкой "в тесте с зажигалкой", в левой части время windows от запуска программы в миллисекундных тиках, L-состав смеси, S-статус (0-lambda 1-%O2), T1 период 1 в тиках таймера, T2 - период 2 в тиках таймера. P-период полного измерения в мс (t1+t2). T1_FA - период 1 при калибровке на свободном воздухе. T2_FA период 2 при калибровке на свободном воздухе. UACC- напряжение питания контроллера HTR_DC - скважность управляющего сигнала на нагреватель ДК (0-255=0-100%)

При составе = 8.36 цикл измерения прерывается - это видно по исчезновению информации о результатах измерения. Возобновляется он примерно через 5 секунд при продувке камеры ШДК до состава 8.34. 

Проверка поддержки LSU4.9.

Для тестирования к одной LC-1 был подключен датчик LSU4.9 BOSCH 0 258 017 010 в котором разъем был заменен на разъем вышедшего из строя 057 датчика, к 2-й обычный LSU4.2 (057) штатно входящий в комплект, в первом контроллере при этом был активирован датчик LSU4.9 (c ПАК Матрица - поскольку lmconfig не позволяет это делать), оба датчика были закручены в единую камеру продуваемую пропаном из баллона от походных плиток. 

Первый же тест показал, что контроллер корректно управляет нагревателем LSU4.9, а так же то, что верным является использование одинаковой константы заклона (0,71428) для всех типов ШДК (как собственно реализовано в LM-2)! 

Немного об LC-2.

LC-2 - новый контроллер innovate выпущенный в конце августа 2013 года. Фактически контроллер тот же. Датчик тот же. Методика работы та же. Но в нем все же есть некоторые изменения: 

-Изменен формат хранения настроек и способ их программирования. Программы изменяющие настройки на прямую могут не работать - следует использовать lmprogrammer. 

-Калибровку измерителя по свободному воздуху невозможно запустить ни с последовательного интерфейса ни с кнопки (как раньше). Единственный способ - калибровка одновременно с нагревателем после включения прибора с отключенным разъемом лямбды или сброса калибровок нагревателя в lmprogrammer.

-Применен другой ЦАП (с прежним были проблемы с надежностью из за низкой нагрузочной способности). 

-Светодиод индикации состояния встроен в корпус. 

-Более грамотное управление нагревателем (соответствует прошивке 1.21 в LC-1) однако большая склонность к перегреву зонда возможно не лучшим образом скажется на его ресурсе.

-LSU4.9 по прежнему не поддерживается (для поддержки нужна другая прошивка). (впрочем после написания этой статьи, примерно через 3 месяца вышла такая прошивка - это версия ПО 1.02, и LSU-4.9 теперь в LC-2 так же поддерживается официально, и даже как вариант можно купить LC-2 с LSU-4.9 в комплекте)

В общем и целом алгоритм остался тем же, но есть небольшие изменения - часть вычислений перенесли в float, но все формулы те же. 

P.S.

В конце стоит заметить, что в сети обнаружился еще один "цифровой контроллер" ШДК работающий по принципу похожему на Innovate. Автор этого произведения - из Канады. Называется оно sigma lambda controller, сайт http://www.14point7.com/ недавно автор открыл исходный код http://www.14point7.com/products/slc-free однако после беглого анализа схемы и кода стало ясно что автор все же использует классический метод IP базированного измерения - т.е по факту это ближе к АЕМ.

 продолжение

(c) Maxi(РПД) 2013-2016 Копирование материалов ресурса без разрешения автора запрещено.