Нет, т.к. в отчётах про подобные конфигурации (но без электроники) не замечал такой проблемы. Ну а вообще - установлен металлический воздушный фильтр "нулевик", который покрепче бумажного.
Разрежение останется без изменений. Система в этом смысле будет работать полностью как раньше, т.к. основная заслонка остаётся на том же месте, что и раньше.
Когда основная закрыта - открывается дополнительная и воздух начинает циркулировать по кругу компрессор-доп.заслонка. С выхода компрессора поступает на вход.
К счастью для пытливого читателя, в шапке упомянуто и отсутсвие первоначального опыта, и качество алгоритмов и цель статьи - рассмотрение подводных камней подобной разработки с позиции неопытного разработчика.
Комплекс обеспечивает всего-лишь управление байпасом в рамках глобальной задачи поставить наддув на атмосферный мотор.
Модельное управление двигателем - без сомнения, в заводском производстве или автоспорте берётся какой-нибудь, упомянутый выше, секу3 и полностью управляет всем.
У меня же гражданское авто и не ультимативное, а компромиссное решение. С точки зрения разработки - классическая подпорка.
Подпорка понимает, что нужно вдуть больше воздуха и вдувает. А дальше пусть там двигатель сам решает, что с этим воздухом делать.
Прочитал, что такое секу3. Интересно, но избыточно для моего случая. Полное перестроение системы управления двигателем. И если под свой ЭБУ я могу найти настройщика (буду не сам настраивать), то под этот - только самому учиться.
Но его плюсы - чуть-ли не рантайм настройка (и опенсорс), что здорово.
Возьму на вооружение. Само понятие пид-регулятора слышал, но думал, что оно просто термин, обозначающий регулятор. А тут даже конкретный алгоритм есть.
Вот окажется забавно, если физического канала нет, а возможность обнаружится. Образно говоря, при подаче сигнала определённой частоты на принимающий фотоэлемент произойдёт возбуждение (изменение сопротивления) отправляющего светодиода.
Делал веб-фронтенд для управления ботом Телеграма антибана. Показалось хорошей шуткой сделать интерфейс на голом html (под капотом - новейшие фронтенд решения, с учётом, что они еженедельно устаревают)
Почему offlineimap, а не getmail/fetchmail? Сейчас для себя выбираю обвязку для примерно похожего. Хотелось бы услышать мнение от более опытного в этом направлении.
Да, компаунд (лак) конечно применю. Виброизоляция + защита пайки от влажности. Опыт от электротранспорта есть.
Нет, т.к. в отчётах про подобные конфигурации (но без электроники) не замечал такой проблемы. Ну а вообще - установлен металлический воздушный фильтр "нулевик", который покрепче бумажного.
Разрежение останется без изменений. Система в этом смысле будет работать полностью как раньше, т.к. основная заслонка остаётся на том же месте, что и раньше.
В случай схемы с блоу-офф или перепускным клапаном - возникают вопросы к работе системы в атмосферном режиме, без наддува.
Эту возможность я хотел оставить.
То, что блоу-офф максимально прост и надёжен - это безусловно.
P.S. расчёт будет не объёмно-скоростной, а давление-температурный (не знаю, как правильно) с новым ЭБУ и программой под это.
Но ДМРВ останется. Так даже сохранится возможность работы поставить старый ЭБУ и вернуться полностью к старому режиму работы.
Когда основная закрыта - открывается дополнительная и воздух начинает циркулировать по кругу компрессор-доп.заслонка. С выхода компрессора поступает на вход.
Это уже во второй части статьи. Но вообще - подключал, через упоминаемые выше DC-DC на базе LM259. Пишут, что у многих проблем нет.
К счастью для пытливого читателя, в шапке упомянуто и отсутсвие первоначального опыта, и качество алгоритмов и цель статьи - рассмотрение подводных камней подобной разработки с позиции неопытного разработчика.
Отучиться в институте, чтобы установить компрессор в авто как хобби-проект. Ваша рекомендация - пока самая необычная в списке.
Комплекс обеспечивает всего-лишь управление байпасом в рамках глобальной задачи поставить наддув на атмосферный мотор.
Модельное управление двигателем - без сомнения, в заводском производстве или автоспорте берётся какой-нибудь, упомянутый выше, секу3 и полностью управляет всем.
У меня же гражданское авто и не ультимативное, а компромиссное решение. С точки зрения разработки - классическая подпорка.
Подпорка понимает, что нужно вдуть больше воздуха и вдувает. А дальше пусть там двигатель сам решает, что с этим воздухом делать.
Да, supercharger. Конкретно SC-14, для установки которого всё давно продумано сообществом.
Про то, почему перешли на турбины - есть другое мнение. Для удешевления.
Про коробку и другое - уже предусмотрено.
Прочитал, что такое секу3. Интересно, но избыточно для моего случая. Полное перестроение системы управления двигателем. И если под свой ЭБУ я могу найти настройщика (буду не сам настраивать), то под этот - только самому учиться.
Но его плюсы - чуть-ли не рантайм настройка (и опенсорс), что здорово.
Возьму на вооружение. Само понятие пид-регулятора слышал, но думал, что оно просто термин, обозначающий регулятор. А тут даже конкретный алгоритм есть.
Не пойму промежуточных тезисов вашего посыла автору:
Вы против того, чтобы лезли в системы, отвечающие за безопасность авто, те, у кого нет требуемого опыта?
Вы против бесовского ардуино?
Вы против советов на хабре от людей, не обладающих нужным опытом?
Вот окажется забавно, если физического канала нет, а возможность обнаружится. Образно говоря, при подаче сигнала определённой частоты на принимающий фотоэлемент произойдёт возбуждение (изменение сопротивления) отправляющего светодиода.
Делал веб-фронтенд для управления ботом Телеграма антибана. Показалось хорошей шуткой сделать интерфейс на голом html (под капотом - новейшие фронтенд решения, с учётом, что они еженедельно устаревают)
Вы пишите серьёзную статью, не не похоже, что она основана на полноценном опыте в каждом из направлений.
Для примера, типовой стек простого мониторинга (берём готовое ПО): prometheus, node_exporter, victoriametrics (3 микросервиса), grafana, БД grafana (распределённая, 3 микросервиса), prometheus alert manager, любая система реагирования на инциденты (1-2 микросервиса), шиппер логов, хранилище логов (эластик [3 микросервиса], loki).
Примерно 15 микросервисов в самом простом варианте и это я наверняка что-то забыл.
Тем не менее, задачу OLAP он полноценно закрывает (а иногда даже и не только OLAP).
Уже есть
https://github.com/gabrie30/ghorg
Почему offlineimap, а не getmail/fetchmail? Сейчас для себя выбираю обвязку для примерно похожего. Хотелось бы услышать мнение от более опытного в этом направлении.
https://github.com/google/ko