RusEfi
- Автор темы andrey2
- Дата начала
(у меня сломалось цитирование)
почему половина прерываний лишняя? разве нас не радует иметь в два раза больше событий, т.е. в два раза больше точек точного углового положения?
если дело в физике именно индукционного датчика и плавающем втором фронте, то это частный случай именно индукционного датчика только - для холла всё-таки все прерывания одинаково полезны. А для индукционного значит да, нужно начать половину игнорировать.
почему половина прерываний лишняя? разве нас не радует иметь в два раза больше событий, т.е. в два раза больше точек точного углового положения?
если дело в физике именно индукционного датчика и плавающем втором фронте, то это частный случай именно индукционного датчика только - для холла всё-таки все прерывания одинаково полезны. А для индукционного значит да, нужно начать половину игнорировать.
andrey2, у меня вопрос
Как ты компенсируешь ошибку в УОЗ и во времени накопления при резком увеличении/уменьшении частоты вращения?
Ну и попутно расскажи как работает компенсация топливоподачи при увеличении/уменьшении воздушного потока в ДВС?
Хоть ты и выбрал тупиковый путь развития девайса, но для общего развития в итоге будет полезно :-D
Как ты компенсируешь ошибку в УОЗ и во времени накопления при резком увеличении/уменьшении частоты вращения?
Ну и попутно расскажи как работает компенсация топливоподачи при увеличении/уменьшении воздушного потока в ДВС?
Хоть ты и выбрал тупиковый путь развития девайса, но для общего развития в итоге будет полезно :-D
если вспомнить высшую математику то там есть такие два совместные понятия - условие необходимое и условие достаточное для (например) свершения какогото события.
избыточность только рождает лишние трудозатраты а порой и путаницу.
многим системам сам знаешь хватает и 6 зубов для точного поределения уоз( в частности) - а твоя работа классически укладывается в мартышкин труд - вместо того шоп дотачивать реально нужные функции устройства ты начинаешь его украшать бантиками - работа по твоему идет а по факту стоит на месте
избыточность только рождает лишние трудозатраты а порой и путаницу.
многим системам сам знаешь хватает и 6 зубов для точного поределения уоз( в частности) - а твоя работа классически укладывается в мартышкин труд - вместо того шоп дотачивать реально нужные функции устройства ты начинаешь его украшать бантиками - работа по твоему идет а по факту стоит на месте
в рамках оборота, внутри которого будет шум, активной реакции на шум сейчас нет, будет промахиваться. сейчас есть подсчёт скважности сигнала триггера, который идёт в лог (лампочка по промаху мимо ожидаемой скважности не зажигается сейчас). Кроме этого, если у нас за 10 оборотов 5 раз случается несовпадение количества событий с ожидаемым, то загорается код ошибки. Короче, будет проблема в этом месте - понятно как можно улучшить обработку и детекцию ошибок. Первоначальная детекция ошибки триггера уже есть.
при появлении главной щели триггер постоянно пере-синхронизируется - т.е. каждый оборот это пере-синхронизация.
при появлении главной щели триггер постоянно пере-синхронизируется - т.е. каждый оборот это пере-синхронизация.
Да не точные это отметки, вот в чем проблема - у них природа разная!
Если у тебя есть отметки с единой природой обраования (например разрыв магнитного потока) - то можно говорить о единой природе их погрешностей (т.е. точность становится лишь функцией знаний о природе погрешностей - и все их можно скомпенсировать).
Все динамические ошибки у шкива 60-2 устраняются. на эту тему у боша для кастомеров есть 40 страничный мануал с формулами - там все абсолютно расписано, зазоры-обороты-динамические ошибки-амплитуды и даже про чипы, что за датчиком стоят.
Если же у тебя 2 импульса разной природы - возникает куча вопросов. Какой из них точный и почему именно этот а не другой... По каким законам меняются погрешности - как они связаны с оборотами температурами? опять же для шкива 60-2 ширина зуба не стандартна и уж точно не 1/2 дыры никогда - т.е. тупо 2 мотора будут иметь хз какую разницу между импульсами.
Если у тебя есть отметки с единой природой обраования (например разрыв магнитного потока) - то можно говорить о единой природе их погрешностей (т.е. точность становится лишь функцией знаний о природе погрешностей - и все их можно скомпенсировать).
Все динамические ошибки у шкива 60-2 устраняются. на эту тему у боша для кастомеров есть 40 страничный мануал с формулами - там все абсолютно расписано, зазоры-обороты-динамические ошибки-амплитуды и даже про чипы, что за датчиком стоят.
Если же у тебя 2 импульса разной природы - возникает куча вопросов. Какой из них точный и почему именно этот а не другой... По каким законам меняются погрешности - как они связаны с оборотами температурами? опять же для шкива 60-2 ширина зуба не стандартна и уж точно не 1/2 дыры никогда - т.е. тупо 2 мотора будут иметь хз какую разницу между импульсами.
Прямо сейчас я никак не компенсирую резкое изменение оборотов - в рамках одного оборота скорость считается постоянной для целей рассчёта, но планирование УОЗ при этом опирается на прерывание ближайшего зуба. Т.е. если в начале запланировали отступить 1 градус от 15ого зуба, то после 15ого заба и отступим на 1 градус на основании скорости прошлого оборота двигателя. Я пока не вижу проблемы здесь, но вероятно скоро увижу - как только увижу вживую, сразу же займусь. Возможно, проблема проявляется менее серьёзно, чем в системах, которые не пере-рассчитывают цифры топливоподачи или УОЗ для каждого оборота? не знаю.
Ну или кто-то адекватный мне покажет конкретное место в моих или своих логах
Логи того динамо дня кстати лежат в https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2014_dec_20_dyno/
Ну или кто-то адекватный мне покажет конкретное место в моих или своих логах
Логи того динамо дня кстати лежат в https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2014_dec_20_dyno/итого есть пять причин, почему нужно уметь обрабатывать только один тип фронта - значит на этой неделе постараюсь сделать https://sourceforge.net/p/rusefi/tickets/99/
https://sourceforge.net/p/rusefi/tickets/99/
Прямо сейчас я никак не компенсирую резкое изменение оборотов - в рамках одного оборота скорость считается постоянной для целей рассчёта, но планирование УОЗ при этом опирается на прерывание ближайшего зуба. Т.е. если в начале запланировали отступить 1 градус от 15ого зуба, то после 15ого заба и отступим на 1 градус на основании скорости прошлого оборота двигателя. Я пока не вижу проблемы здесь, но вероятно скоро увижу - как только увижу вживую, сразу же займусь. Возможно, проблема проявляется менее серьёзно, чем в системах, которые не пере-рассчитывают цифры топливоподачи или УОЗ для каждого оборота? не знаю.
Ну или кто-то адекватный мне покажет конкретное место в моих или своих логах Логи того динамо дня кстати лежат в https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2014_dec_20_dyno/
Ну или кто-то адекватный мне покажет конкретное место в моих или своих логах
Логи того динамо дня кстати лежат в https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2014_dec_20_dyno/
Gremlin, твой вопрос за счёт его лаконичности сложнее точно понять. Вероятно тебя интересует момент искры больше чем момент начала накопления энергии в катушке?
В начале оборота я
1) рассчитываю скорость вращение на основании всего прошлого оборота
2) нахожу, между какими двумя зубьями у меня будет начало накопления энергии в катушке
3) нахожу, между какими двумя зубьями у меня будет искра
Когда случается один этих зубов, я рассчитываю сколько времени мне нужно подождать - событие будет где-то между зубами, не обязательно в обработчике одного из зубов. Ставлю будильник на основании скорости работы двигателя за прошлый оборот.
Мгновенная скорость кв на основании последних двух зубов не считается. С каким ускорением у нас кв может разкрутиться или замедлиться? У меня руки пока не дошли это посчитать - я сейчас исхожу из допущения, что скорость кв между двумя оборотами меняется не фатально. Значительная часть ошибки рассчётов с такими допущением компенсируется тем, что я привязываюсь к зубу - так что ошибка будет только в том, сколько именно ждать до вызова события после зуба. В таком маштабе я сомневаюсь, что ошибка получается значимой.
В начале оборота я
1) рассчитываю скорость вращение на основании всего прошлого оборота
2) нахожу, между какими двумя зубьями у меня будет начало накопления энергии в катушке
3) нахожу, между какими двумя зубьями у меня будет искра
Когда случается один этих зубов, я рассчитываю сколько времени мне нужно подождать - событие будет где-то между зубами, не обязательно в обработчике одного из зубов. Ставлю будильник на основании скорости работы двигателя за прошлый оборот.
Мгновенная скорость кв на основании последних двух зубов не считается. С каким ускорением у нас кв может разкрутиться или замедлиться? У меня руки пока не дошли это посчитать - я сейчас исхожу из допущения, что скорость кв между двумя оборотами меняется не фатально. Значительная часть ошибки рассчётов с такими допущением компенсируется тем, что я привязываюсь к зубу - так что ошибка будет только в том, сколько именно ждать до вызова события после зуба. В таком маштабе я сомневаюсь, что ошибка получается значимой.
С УОЗ как раз не является проблемой, так как это угловой параметр в пределах одного зуба. Даже если допустим, что текущая частота вращения КВ = частоте за предыдущий оборот погрешность будет в разумных пределах. Но с временем накопления пренебрежение изменением скорости вращения в текущем цикле вычислений может привести к уменьшению/увеличению времени накопления, что в итоге скажется на отклике в переходном режиме. Если планируешь блок применять на мотиках то предлагаю задуматься над этим вопросом