и какие недоргие датчики сейчас бывают в продаже под это дело?
Можно заходить на aliexpress, вводить номера бошевских датчиков (например, 0258007351) и выбирать там датчик за $30-40. Это недорогой, но и далеко не самый надёжный вариант. Или, вот, darxfame недавно нашёл более дешёвый аналог - 03C906262A.
и какие тут меры предосторожности соблюдать, чтоб не поломать их (в даташите к датчику, например, написано, не включать на свежем воздухе)
1) Не нагревать сильно лямбду до пуска двигателя. Иначе влага, накопившаяся в выпускной системе, при попадании внутрь, может уничтожить сенсор.
2) Не запускать двигатель с выключенным контроллером ШДК (это же касается и инновейта).
3) Не перегревать лямбду, т.е. не включать нагреватель на 100% длительное время и не ставить лямбду близко к ГБЦ.
В текущей реализации CJ125 в rusEFI уже есть эти защиты. Но нужно понимать, что код ещё как следует не протестирован, и мы не несём ответственности за какие-либо последствия его использования.
Если вкратце, то суть идеи в том, чтобы не реагировать на каждый фронт с триггеров, а анализировать, сколько времени проводит сигнал в 0 и в 1, и реагировать на приходящий сигнал только в том случае, если статистический анализ прошлых периодов показывает, что сигнал пришёл не слишком рано.
статистический анализ прошлых периодов - типа идет ли речь о разгоне/торможении (и соответствующем ожидаемом периоде?)
тут бы еще вспомнить кучу разных настроек в тюнер-студии (что означает у нас фронт/спад - по-моему там можно было по-разному настроить)
плюс еще такая штука: в LM1815 по-моему можно выдавать импульс произвольной длины, и он при любых RPM может оставаться таким. хотя сейчас подумал - вроде бы никаких противоречий с этим алгоритмом нет.
но вообще такая проблема стоит? (кроме как у Darxfame?)
если статистический анализ прошлых периодов показывает, что сигнал пришёл не слишком рано.
а почему не запись эталонного сигнала проанализировать бы на старте? или ты думаешь, что статистика реального сигнала точнее?
Подозреваю, что ты мог недопонять мои слова, и из-за этого я сейчас недопонимаю твой вопрос... Особенно твоё выражение "на старте" - речь идёт о старте двигателя? Или это синоним "для начала" ("for starters"), и ты хочешь сейчас поизучать работу алгоритма на эталонах? Поясни, пожалуйста, что ты имел в виду?
Я просто описывал новое поведение прошивки при работающем реальном двигателе, и под "статистическим анализом" подразумевал всего лишь сбор и накопление интервалов получаемого сигнала триггеров, для принятия решения о фильтрации. Насколько я понимаю, и на старте двигателя, и после старта, у нас в прошивке нет эталонных сигналов, которые мы могли бы анализировать, у нас есть только реальные сигналы от датчиков, которые мы и обрабатываем.
Мы можем вместо реального датчика подсунуть эталонный формирователь сигнала, но в нём не будет нужных помех, и не будет реалистичного рывкообразного повышения оборотов. Мы не увидим той картины, которая творится на реальном двигателе - это уже будет не старт, а просто абстрактная симуляция. Да, мы можем пробовать создавать искусственные "помехи" на условном ардуино, но это будет мало чем отличаться от уже написанных мной юнит-тестов.
Напомню, вот как выглядит типичная реальная помеха на пуске, пойманная анализатором:
noise_spike.PNG (3.99 KiB) Viewed 51744 times
Длительность такой единичной помехи меньше 2 мкс, но она успевает переключить фронт ICU и воспринимается как начало внеочередного зуба. И происходил сбой синхронизации. А сейчас такие помехи фильтруются как кусок пирога с пареной репой!
Главный трюк в том, что нам не важно, как именно натыканы эти помехи, и нам не важны длительности каждой помехи в отдельности. Помеха с этой картинки уменьшила время, в течение которого сигнал находится в "1", всего на несколько процентов!
И нам даже почти не важно, когда именно эти помехи появляются. Например, если бы эта помеха пришла чуть попозже, то мы бы приняли её за начало "правильного" фронта очередного зуба, потому что ко времени её прихода сигнал провёл в "1" уже достаточно времени (т.е. примерно столько же сколько и в прошлом зубе, плюс-минус допуск). Но это и хорошо, пускай так! Зато когда после этой помехи пришёл бы импульс уже от настоящего зуба, то мы бы его проигнорировали, потому что он появился слишком рано после помехи (которую мы уже приняли за зуб, и начали отсчёт следующего периода с неё) - и общее число "пойманных" зубов не поменялось бы!
Бывают, конечно, и более тяжёлые случаи (у darxfame):
noise_spike2.PNG (5.34 KiB) Viewed 51744 times
На этой 2-й картинке, на одном из зубов суммарная длительность пребывания сигнала в "1" уменьшилась чуть ли не на 30% (!) из-за помех. Но наш алгоритм фильтрации помех способен справляться и с подобными ситуациями (хотя, возможно, и не с данной конкретной, т.к. по факту 1/3 от длительности - это уже очень много, это сравнимо с допуском на резкое увеличение оборотов)...
статистический анализ прошлых периодов - типа идет ли речь о разгоне/торможении (и соответствующем ожидаемом периоде?)
Да, речь идёт о допущении, что ожидаемый период имеет незначительное отклонение от предыдущего. Именно такое допущение использует основной код декодера триггеров, а мы лишь меняем способ определения этого периода: мы не засекаем время между фронтами всех поступающих сигналов, а подсчитываем суммарное время, в течение которого сигнал "сидит" в 0 или в 1.
но вообще такая проблема стоит? (кроме как у Darxfame?)
У меня раньше тоже было немало ошибок триггера, да и сейчас иногда проскакивают единичные ошибки - в основном, на пуске, когда сигнал с дпкв слабее, а накопление больше...
P.S. Сорри за длинный и слишком подробный ответ...
Подозреваю, что ты мог недопонять мои слова, и из-за этого я сейчас недопонимаю твой вопрос... Особенно твоё выражение "на старте" - речь идёт о старте двигателя? Или это синоним "для начала" ("for starters"), и ты хочешь сейчас поизучать работу алгоритма на эталонах? Поясни, пожалуйста, что ты имел в виду?
Я имел ввиду на старте прошивки проанализировать эталонный сигнал. например как присваиваются значения в state->expectedTotalTime внутри findTriggerZeroEventIndex -ведь весь findTriggerZeroEventIndex работает через проигрывание формы сигнала и обработку этой эталонной формы обычным декодером триггера.
Я имел ввиду на старте прошивки проанализировать эталонный сигнал. например как присваиваются значения в state->expectedTotalTime внутри findTriggerZeroEventIndex
А что предполагается получить таким образом? Как это может повлиять на алгоритм фильтрации?
Текущий алгоритм фильтрации использует главное допущение, что все зубы шкива одинаковы, и не работает для других типов триггеров. Если предлагается расширить фильтрацию на все те страшные триггеры, у которых произвольная геометрия каждого зуба (определяемая анализом эталона?), и сравнивать периоды не только между собой, а и делать коррекцию по известным эталонным соотношениям?
Юзать
...То предложение, конечно, заманчивое, но несколько выходит за рамки моей компетенции...
Во-первых, я ничего толком не знаю про эти хитрые триггеры, и видел их только на картинках...
Во-вторых, я плохо знаю код декодера триггеров и симулятора (и эмулятора ). Например, я не понимаю эти страшные слова waveIndertionAngle(), pinStates (цитата "does this logic actually work? I think it does not!")... Плюс недостаток мотивации: нет насущного практического применения (больше никто пока не жалуется на помехи)
Этим летом я ещё раз проверил прошивку rusEFI и блок Prometheus в "боевых" условиях, в очередной поездке по Европе:
map-2018.jpg (290.77 KiB) Viewed 51389 times
Проехал по маршруту Украина-Польша-Германия-Франция-Испания-Италия-Словения-Венгрия-Украина около 6,5 тыс. км.
Т.е. до Барселоны и затем обратно по Ривьере (Лазурный берег).
В целом, ЭБУ и прошивка проявили себя с наилучшей стороны, как и в прошлую поездку!
Но на этот раз я ездил с коррекцией топлива:
fuel-corr.png (10.64 KiB) Viewed 51389 times
И с TPS-based таблицей УОЗ (т.е. зажигание в режиме Alpha-N, а впрыск по ДАД):
tps-based-advance.png (20.82 KiB) Viewed 51389 times
Таблицу постоянно менял в поездке, экспериментировал, так что на скриншоте просто образец...
В целом, и коррекция топлива, и УОЗ по TPS показали себя неплохо, расход по трассе 8-9 л (смотря как валить, в среднем я ехал 120-140 км/ч).
По приезду, после небольшого перерыва, я подготовил три PR:
Наверное всё же меньше, >80% из них - езда по трассе со скоростью 120-140 км/ч. В города мы редко въезжаем, останавливаемся где-то в пригородных кэмпингах или отелях на околицах, и оттуда уже на городском транспорте...
Я, основной водитель, плюс ещё один резервный водитель на подмену. Главное правило - стараться проезжать не больше 600 км в день, и делать остановки каждые 2-3 часа. Ну и, в общем-то, всё это удовольствие было растянуто на 20 дней, и каждые несколько дней обязательно должны быть вообще без машины, на месте...
Запчасти в багажнике были или поломок не было и не будет?
Немного запчастей в багажнике было, конечно. Например, ремень генератора, свечи запасные, катушки... Но а так, в целом, поломок не было, и запчасти, к счастью, не понадобились. За исключением датчика скорости, который под конец начал немного "моросить" (но его-то я как раз и не взял )...
Мысли вслух по использованию входов Прометея для будущего проекта Ion Sensing (вариант реализации):
1) Исходим из того, что у нас освобождается триггерный вход датчика фаз и аналоговый вход датчика детонации.
2) Два сигнала воспламенения C1 (1+3) и C2 (2+4) подаём на входы ЭБУ CAM+ и IN2 по такой схеме:
Cam = C1 (OR) C2
In2 = C1
3) Т.е. подаём на вход триггера CAM сигнал с обоих выходов, объединенный по логической схеме ИЛИ - тогда триггер сработает по любому сигналу (Есть вероятность, что сигналы C1 и C2 можно просто физически соединить друг с другом, если в модуле использованы выходные каскады по схеме open drain/collector).
4) А на обычный вход In2 (In1 у нас задействован под датчик скорости) подаём только сигнал C1 - так мы можем определить, какой из сигналов - источник воспламенения (предполагая, что одновременно оба сигнала C1 и С2 не будут активны одновременно) - просто опрашиваем состояние входа по прерыванию триггера cam.
5) Соответственно, нужно написать код распознавания фазы сигналы воспламенения на замену датчика фаз (и, впоследствии, для аварийных режимов).
6) По идее, вход In2 будет задействован только в начальный момент синхронизации (поиска фазы), а потом мы и так уже будем знать, в каком цилиндре сейчас могло быть воспламенение, и нам будет интересно только его наличие и точное время (по триггеру cam).
7) Сигнал детонации пускаем вместо входа датчика детонации (плюс напишем соответствующий код), тут всё просто.
Тут бы неплохо побольше разжевать. Я ничего не понял.
Вроде как идея заключалась в том, чтобы измерять ток в момент искрения (пусть преобразовательная часть ток-напряжение будет "черной коробочкой")
И если так, то я плохо себе представляю, как этот ion sensing работает с wasted spark (сигнал-то надо брать со свечи, которая не холостая, а с холстой - сигнал будет в лучшем случае неинформативным? если смешивать - интересны нюансы этого смешивания)
в природе существуют микросхемы коммутаторов аналогового сигнала, чуть ли не восьмиканальные, работающие по spi. но вот про скорость коммутации я не скажу. а задача стоит
И если так, то я плохо себе представляю, как этот ion sensing работает с wasted spark
Да, плохо работает с wasted spark, нужны индивидуальные катушки, фазированное зажигание. И, возможно, не всякие катушки подойдут (поэтому лучше начинать со специализированных, заточенных под это дело). Поскольку я и так давний фанат фазированного зажигания, то за этим дело не станет
Всё это были лишь мысли вслух, и не стоит воспринимать это как открытый призыв к действиям. Речь пока идёт просто о совместном эксперименте с Андреем @Russian...
Сначала попробуем с магическими катушками и магической коробочкой - к счастью они достаточно доступные. В мечтах можно потом коробочку заменить своей, но до этого ещё очень и очень далеко
- Блочок Ion Sensing Module SAAB 55352173 ("цифровой");
- 4 новых катушки 12787707 (китайские DMCOIL);
- проводка с разъёмами для катушек (б/у);
- коннектор для блочка и контакты к нему (аналог Tyco 1-965427-1).
Проводка нам досталась "покоцанная", с отрезанным коннектором ионного блочка:
ion2.jpg (141.86 KiB) Viewed 50866 times
Восстанавливаем коннектор, обжимая имеющиеся провода и добавляя новые. В неиспользуемые гнёзда вставляем три затычки:
ion3.jpg (142.29 KiB) Viewed 50866 times
Всё заматываем изолентой, сигналы воспламенения и детонации выводим в разъёмы проводки датчиков детонации и фазы, чтобы использовать старую проводку по максимуму без переделок (и оставить совместимость со старым вариантом):
ion4.jpg (170.03 KiB) Viewed 50866 times
ЭБУ тоже переделываем:
- убираем BIPы, поскольку новые катушки - "логические", управляются "плюсом" 5В;
- сигналы воспламенения подаём на входы In1 и In2 Прометея;
- добавляем подтяжку к +5В по входам (поставил 2.7кОм);
- сигнал датчика скорости перенаправляем в Cam+ вместо датчика фаз;
- переводим прошивку на режим попарного зажигания (холостая искра).
Собираем на столе простенький стенд для проверки:
ion5.jpg (218.9 KiB) Viewed 50866 times
Искра бегает, всё отлично, и анализатор не фиксирует сигналы воспламенения, как и должно быть.
Остальное проверим на машине. Просто накидываем катушки с проводкой "на весу":
ion6.jpg (145.63 KiB) Viewed 50866 times
Двигатель завёлся на удивление легко! Такое ощущение, что эти новые катушки дают более мощную искру, чем старые.
К ЭБУ подключаем анализатор и пишем сигналы воспламенения:
Анализатор ловит помехи, но, в принципе, картина ясна: после подачи управляющего импульса на катушку от блочка приходит один или несколько импульсов воспламенения. Причём, 1-й импульс как правило, очень короткий (~0.15 мс) и есть всегда, когда есть воспламенение, а за ним иногда идёт один или несколько (до 3-х?) импульсов подлиннее (до 5 мс).
Что он делает:
- подцепляет на внешние прерывания обработчик входов воспламенения (на базе кода джойстика);
- каждый такт собирает статистику по сигналам воспламенения (по двум каналам 1+3 и 2+4);
- добавляет новый режим отладки DBG_ION и выдаёт статистику в логи (debug*);
- ставит приоритет для внешних прерываний (STM32_EXT_EXTI*) на уровне ICU_PRIORITY;
Собирается следующая статистика:
- debugInt1 - счётчик числа тактов (чтобы можно было ориентироваться в логах, где какие данные);
- debugInt2, debugInt3 - количество изменений сигналов воспламенения (С1 и С2) с момента начала такта;
- debugFloat1,debugFloat2,debugFloat3 - время с момента начала такта до появления 1-го, 2-го и 3-го изменения сигнала воспламенения С1 (переход с 0->1 и наоборот);
- debugFloat4,debugFloat5,debugFloat6 - то же время, но для сигнала C2.
- debugFloat7 - общий счётчик срабатываний прерываний С1,С2.
Получаем два вот таких лога:
1) Пуск и ХХ на УОЗ=14 градусов, на 29-й секунде отключение 1-й форсунки (двигатель троит), затем на~32-й секунде отключение и 2-й форсунки (двигатель двоит).
Похоже, что с увеличением УОЗ время появления 1-го импульса воспламенение чуть-чуть уменьшилось (если сравнивать на одинаковых оборотах, что непросто с учётом изменения УОЗ). Впрочем, о влиянии УОЗ пока говорить рано...
Напомню, в обоих случаях - попарно-параллельный режим зажигания и впрыска, двигатель непрогретый.
К сожалению, наблюдаются "потери" части тактов, поскольку частота выдачи лога недостаточна для таких оборотов ХХ (надо смотреть на rpm<1000).
* * *
Теперь нужно поизучать логи и подумать, что можно с них вытащить, и какую ещё отладочную инфу записать...
На этом пока всё, всем спасибо за внимание!
крутая тут движуха!
а какую цель мы вообще преследуем, когда играем с этим ion sense? его настраивать проще/удобнее, чем традиционные датчики детонации?
про запчасти: блок продается на авите. катушки глянул в магазине типа экзиста - цены за штуку отличается от 1тр до 8тр - не слабый разброс!
про логи. я и в английской ветке догнать не могу, и тут тоже.
вроде бы где-то тут в вики писалось, что из блока идут два выходящих сигнала: один сигнализирует, в какой из катушек идет замер, а второй - указывает на наличие или отсутствие события детона (или я выдумал все это?)
на картинке из лог анализатора ign1 - это сигнал с эбу на блок зажигания? (туда он не инвертированный разве приходит?)
a с13 и с24?
интересная пила получилась у df1 и df4 в первом логе (уж очень друг на друга похоже - точно не одно и то же значение? и как это интерпретировать?), красный график на тех же логах отличается почему-то (а df3 и df6 и вовсе не показывает).
можно было бы предположить, что в норм условиях (без детона) должно быть только два графика (белый и красный), один над другим, которые бы указывали продолжительность горения? (или это мои очень наивные представления?).
начало пилы совпало с каким-то из отключений форсунок? кстати, они соответствуют разным каналам зажигания?
а когда будет код, который будет влиять на расчет впрыска/зажигания?
а какую цель мы вообще преследуем, когда играем с этим ion sense?
Например, вот три цели:
1) Диагностика пропусков воспламенения (и потенциально индикация необходимости замены свечей, поцилиндровое отключение впрыска/сушка и т.д. - надо изучать, что умеют делать крутые ЭБУ);
2) Обнаружение детонации (по идее, ионное обнаружение точнее акустического, во всяком случае на таких "шумных" цепных движках как у меня);
3) В идеале - автонастройка УОЗ (самая вкусная цель лично для меня).
вроде бы где-то тут в вики писалось, что из блока идут два выходящих сигнала
a с13 и с24?
Из блока в ЭБУ идут 3 сигнала:
1) с13 - сигнал воспламенения в 1+3 цилиндре
2) с24 - в 2+4 цилиндре.
3) сигнал детонации.
Суть в том, что два сигнала воспламенения 1+3 и 2+4 позволяют точно определить, в каком из цилиндров оно сейчас происходит. Исходим из того, что у нас схема работы цилиндров 1-3-4-2, т.е. ВМТ сейчас либо в 1+4, либо в 2+3 цилиндрах.
Т.е. мы получаем 4 возможных варианта:
1) ВМТ в 1+4 и сигнал С1+3 --> воспламенение в 1-м цилиндре;
2) ВМТ в 1+4 и сигнал С2+4 --> воспламенение в 4-м цилиндре;
3) ВМТ в 2+3 и сигнал С1+3 --> воспламенение в 3-м цилиндре;
4) ВМТ в 2+3 и сигнал С2+4 --> воспламенение в 2-м цилиндре;
И когда мы уже знаем, где именно воспламенение, то дополнительно смотрим и 3-й сигнал детонации.
на картинке из лог анализатора ign1 - это сигнал с эбу на блок зажигания? (туда он не инвертированный разве приходит?)
Да, это он. Он приходит не инвертированный (точнее, дважды инвертированный - один раз в растройках rusEFI, второй раз инвертируется в буфере 74HCT04). Я же писал выше, что катушка управляется плюсом, т.е. при подаче +5В начинается накопление, и при снятии напряжения идёт искра.
начало пилы совпало с каким-то из отключений форсунок? кстати, они соответствуют разным каналам зажигания?
Да, именно при отключениях та "пила" в конце и появилась. Но я не уверен, что она нам что-то может сообщить. В том смысле, что когда движок двоил, и смесь была неизвестно какая, и коленвал очень неравномерно вращается, из-за этого ошибки таймингов УОЗ, и пропуски в оставшихся 2-х цилиндрах и т.д. На таких данных вообще нереально что-либо понять.
Пока что главный источник информации для нас - это dint2 и dint3 - счётчики импульсов воспламенения.
На данный момент, я склонен полагать, что 1-й импульс, который приходит практически всегда, это помеха. Поэтому, если мы посчитали 2 или больше импульса в такте - то это и есть воспламенение, а если 1 или меньше - пропуск. Но если так, то пропусков что-то слишком много даже на "нормальном" с виду ХХ. Я очень хочу верить, что сам ионный блочок не "глотает" импульсы, и что это несовершенство моего обработчика в прошивке или входных цепей Прометея...
Такое происходит только на холодном движке, если хоть чуть-чуть прогреется (поработает минутку), то потом уже не глохнет после пуска. Надо будет что-то подправить в настройках...
А так, с самой машиной пока ничего не происходит. Зимняя спячка
Зато идёт активная подготовка к будущим проектам, и, в том числе, работа над новой платой Deucalion.
Вот пример тестовых настроек, проверенных на машине Артёма @darxfame:
timingPidSettings_example.PNG (28.53 KiB) Viewed 50283 times
P.S. Также обновил бутлоадер для Прометея, поскольку есть уже несколько плат Прометея на разных процессорах (469 и 405), плюс с учётом новой версии ChibiOS.
Был произведен первый запуск двигателя "Рыжика" на новом ЭБУ Deucalion:
В целом, плата оказалась рабочей, но по части обработки триггера нужно ещё постараться, пока что планка гистерезиса фиксированная, а нужно попробовать сделать адаптивную. Также нужно протестировать коммуникацию по CAN и LIN.
Конечно же, после того как двигатель снова заработал спустя полгода, я не удержался попробовать в деле то, ради чего, собственно, затевалось новое ЭБУ. Попробовать технологию ion sense. Но для того, чтобы как следует разобраться с ней и понять, как обрабатывать выдаваемые сигналы, нужно иметь больше информации о том, что происходит внутри цилиндра. Для этого нам понадобится датчик давления в цилиндре. К счастью, для этого не нужно покупать дорогой профессиональный набор: ещё несколько лет назад на этом форуме Макси предложил использовать дизельную свечу накала с датчиком давления! Я купил новую свечу от VW/Audi 03L905061F (врядли немецкий оригинал, скорее всего китайская копия):
pressure05.jpg (104.62 KiB) Viewed 48793 times
Правда, вставлять свечу накала непосредственно в ГБЦ мы не будем, неоправдано сверлить головку ради простого эксперимента. Лучше просто вывести наружу ГБЦ воздушный канал из камеры сгорания через свечное отверстие. Но свечу зажигания от ДВС при этом вынимать нельзя, нам ведь нужно мерять давление во время воспламенения, так что возможность поджига смеси обязательна! Переделать саму свечу - сложно, т.к. пришлось бы пробиваться через керамику и корёжить металл, герметизирующий свечу:
pressure07.jpg (83 KiB) Viewed 48793 times
Я посчитал, что проще изготовить для этого втулку-переходник, и вывести канал мимо свечи. А саму свечу взять диаметром поменьше, мотоциклетную. Но задачу изготовления втулки также осложняет форма свечного отверстия, где посадочное место утоплено на 7 мм вглубь ГБЦ:
pressure06.jpg (68.21 KiB) Viewed 48793 times
Внешний диаметр втулки, выходящей из ГБЦ, должен быть не более 20 мм, а сама резьба в свечном отверстии, напомню, М14х1.25. К тому же любая свеча, даже мотоциклетная, имеет расширение сразу после окончания резьбы. Поэтому пришлось выбрать свечу с удлинённой резьбой М10х1, длина 26.5 мм, код NGK 5946 (LMAR6A-9):
pressure08.jpg (83.56 KiB) Viewed 48793 times
Можно было бы взять ещё более тонкую свечу с резьбой М8 (например, NGK ER9EH-6N 1673 или NGK 5869, NGK 96652), но они все такие же короткие, как и обычные ВАЗовские свечи (19 мм). А проблема не в том, чтобы провести канал через резьбу свечного отверстия, а чтобы провести его в обход утолщения и керамического тела свечи. Поэтому бОльшая длина резьбы свечи нам важнее, чем диаметр резьбовой части. Вот вкручена свеча обычной толщины, но более длинная (25 мм), для прикидки:
pressure14.jpg (73.58 KiB) Viewed 48793 times
Ещё одна проблема - свеча накала с датчиком давления довольно длинная, и нужно подвести её максимально близко к гбц, чтобы сократить длину воздушного канала, по которому давление будет воздействовать на её шток. Чем короче канал, тем меньше будет лаг датчика, и нам будет проще ориентироваться в данных (хотя можно придумать, как определить величину лага и компенсировать его, об этом позже). Стало ясно, что свеча накала должна крепиться под определённым углом, чтобы всё поместилось:
pressure10.jpg (103.67 KiB) Viewed 48793 times
Какой же должна быть втулка? Похоже, что одной втулкой тут не обойтись, нужно две соединяющихся детали. После прикидки нескольких вариантов, остановился вот на таком (вид в разрезе):
pressure09.jpg (47.59 KiB) Viewed 48793 times
По чертежам токарь изготовил их из бронзы (точную марку не знаю, уж какая нашлась ), работы обошлись примерно по цене свечи накала:
pressure11.jpg (80.46 KiB) Viewed 48793 times
Одна втулка вкручивается в другую резьбой М5 и герметизируется конусной посадкой. Внутри - отверстие диаметром 1 мм выходит прямо к резьбе свечи:
pressure12.jpg (56.17 KiB) Viewed 48793 times
Чтобы укоротить вторую втулку и уменьшить длину воздушного канала, пришлось аккуратно срезать кончик свечи накала, ведь "накаливать" нам уже нечего:
pressure13.jpg (60.09 KiB) Viewed 48793 times
* * * Продолжение следует... * * *
Attachments
photo_2022-06-19_10-23-43.jpg (34.58 KiB) Viewed 32845 times
photo_2022-06-19_10-23-53.jpg (45.23 KiB) Viewed 32845 times
photo_2022-06-19_10-23-56.jpg (29.72 KiB) Viewed 32845 times
Также нужно уменьшить в диаметре "поясок" на мотоциклетной свече, чтобы дать немного больше места для канала внутри втулки. Для этого накручиваем свечу на втулку снаружи и стачиваем на точиле:
pressure15.jpg (81.86 KiB) Viewed 48791 times
Теперь можно попробовать собрать две втулки вместе:
pressure16.jpg (85.66 KiB) Viewed 48791 times
Не забываем про медную шайбу толщиной 1.5 мм, ведь у нашей самодельной втулки нет специальной уплотнительной шайбы, как у заводских свечей.
* * *
Осталось продлить канал вдоль резьбы, чтобы выйти в камеру сгорания. Для этого нужно пропилить канавку и во втулке, и в свече, прямо по резьбе. Чтобы правильно совместить канавки на свече и втулке, закручиваем и выкручиваем свечу несколько раз, чтобы уплотнительная шайба сжалась как следует и всё было герметично затянуто с нужным усилием. После этого при закрученной свече вставляем в отверстие втулки сверло 1 мм и аккуратно делаем "метку" на резьбе свечи в месте, где каналы будут соединяться:
pressure17.jpg (82.27 KiB) Viewed 48791 times
После чего выкручиваем свечу и видим на резьбе аккуратную отметину, вдоль которой и нужно сделать пропил вдоль резьбы:
pressure18.jpg (874.41 KiB) Viewed 48791 times
Также делаем пропил и внутри втулки (буравчиком дремеля), а заодно срезаем лыски с боков, чтобы было удобно закручивать и выкручивать втулку рожковым ключом:
pressure19.jpg (63.83 KiB) Viewed 48791 times
По длине втулка рассчитана так, чтобы совсем немного не доставать до края свечи, и фаска не даст прогореть легкоплавкому желтому металлу:
pressure20.jpg (49.72 KiB) Viewed 48791 times
* * *
Для подключения датчика свечи накала была использована проводка от аналогичных дизельных свечей Опеля, код 55577669:
pressure21.jpg (126.09 KiB) Viewed 48791 times
Они, как я и предполагал, отлично подходят и используют идентичные разъёмы. Распиновка такая:
1=светл-корич = +5В
2=бело-жёлт = сигнал
3=черн-бел = земля
4=толстый (не используется)
В итоге, всё в сборе выглядит вот так:
pressure22.jpg (153.45 KiB) Viewed 48791 times
Втулка со свечой накала вкручивается отдельно, после того как вкручена основная втулка со свечой зажигания. Так удобнее.
* * *
Что касается ion sense, то были использованы саабовские катушки зажигания, о которых я уже писал. Сигнальный 4-й выход катушки 3-го цилиндра, в который вкручена наша втулка, просто подключён на вход ion sense ЭБУ Deucalion. При этом сам саабовский модуль CDM не нужен, всё делает сама свеча и Дьюкелион!
Нам остаётся лишь подключить параллельно осциллограф и записать первые данные с датчика давления плюс ion sense на работающем двигателе!
Итак, чтобы двигаться дальше в изысканиях с ion sense, нужно продолжить работы над нашим новым ЭБУ на базе rusEFI, которое будет способно делать программный процессинг аналоговых сигналов в реальном времени. В этой ветке есть несколько фотографий плат: https://rusefi.com/forum/viewtopic.php?f=4&t=1682
Сборка плат довольно простая, нужно просто запаять коннекторы и платки-модули:
hellen-assembled-no-connector.jpg (562.87 KiB) Viewed 47132 times
И соединить всё вместе:
hellen-all-no-connector.jpg (511.44 KiB) Viewed 47132 times
Теперь нужно доработать прошивку и тщательно протестировать новые платы!
Считаю, что относительно успешная (по крайней мере, двигатель-то завёлся с первого же раза!). Но двигатель троил, т.к. возникли проблемы с качеством управления форсунками (об этом ниже).
2) Новый детектор триггера пока проявляет себя неплохо:
rpm_0_3365.PNG (15.71 KiB) Viewed 44783 times
Это фрагмент "экстремального" пуска двигателя с нажатой педалью газа, где движок раскручивается за менее чем 1.5 секунды с 0 до 3365 RPM - и без единой ошибки триггера!
* * *
По форсункам - в этой тестовой версии платы для управления форсунками использовались транзисторы VNN1NV04PTR. Это так называемые "умные" транзисторы с полным набором защит ("fully autoprotected Power MOSFET"). Но ведут они себя с форсунками очень странно:
* Если на затвор подать 5 вольт, они включают форсунку нормально и чётко, и не греются при этом. Но вот при отключении форсунки, когда на затвор проц подаёт "ноль", то затвор иногда почему-то "приподнимается" до напряжения 1-2В, и слабая ножка проца (4мА) не может опустить его в ноль. Хотя в даташите на транзистор сказано, что ток управления затвором не превышает 0.15 мА. И вот из-за того, что на затворе не полностью ноль, транзистор подвисает в полуоткрытом состоянии, выдавая на выходе половину напряжения, т.е. около 7В. И этого иногда бывает достаточно, чтобы форсунка тоже приоткрылась и начала пропускать бензин, а это уже опасно, как вы понимаете... Более того, из-за того что транзистор открыт только наполовину, он при этом начинает сильно греться...
* Без нагрузки я ни разу не мог воспроизвести такое странное поведение. Т.е. если с форсункой транзистор "чудит", то стоит мне отключить фишку форсунки, как тот же транзистор начинает вести себя без форсунки более-менее нормально, и затвор дёргается чётко, и сток управляет резистивной нагрузкой без проблем...
Причём, я не могу сказать, что транзисторы при этом сильно портятся или сгорают. Но! Их характеристики, измеряемые тестером, немного меняются по сравнению с такими же транзисторами, которые ещё не управляли форсункой. Например, если менять в режиме диод-тестера падение сток-исток. Т.е. "больные" транзисторы, которые уже управляли форсункой и "чудили", потом с виду вроде бы продолжают работать, открываются, закрываются, даже с форсункой - например, если вручную ими управлять, закорачивая затвор на +5В или ноль, то проблем никаких нет! А вот если управлять ими процом, да ещё и быстро клацать, в режиме миллисекундных таймингов форсунки, то что-то не то происходит. Но я не уверен на 100%, что здесь нет вины проца. Есть ощущение, что это как-то связано со слаботочностью ножки проца... Или как будто у транзистора нет нормального встроенного драйвера затвора, и приходится управлять большой ёмкостью затвора, и ножка не справляется...
* И я пробовал транзисторы с разных партий - как JLC-шные, так и из моих местных радио-магазинов. Причём, попадался мне транзистор "неубиваемый", который щелкал любой форсункой вообще без проблем, но были и такие, когда при первом же bench-test'е сразу форсунка начинает лить непрерывно, и всё уже ясно!..
* * *
В общем, решил я пока заменить эти транзисторы на BSP76E6433HUMA1, аналогичные, о чём расскажу уже в следующий раз...