New fully sequential mode
Turbo Mini Forums

With the new planned fully sequential mode I was wondering if the code should double the req fuel value when going from the dual pulse mode to the single pulse mode.

This would mean that the third VE table for the single pulse mode wouldn't have to have values that are equivalent to the sum of the VE for the 2 cylinders but rather the average of the VE values. That would also make the table look more like a VE table and would have values closer to the other 2 tables.

I guess Paul is the one to answer this question but opinions are welcome.

Jean

http://www.jbperf.com/

Yes.

Saul Bellow - "A great deal of intelligence can be invested in ignorance when the need for illusion is deep."
Stephen Hawking - "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."

i thought i knew quite a bit about cars and then i read your topics! is it just me that reads this stuff about MS and sits there thinking "am i really that thick"?

i've got omex ignition only and would love a full self learning injection system, sorry i cant be any help and i can imagine this being another topic with just you and Paul but keep up the good work

I would like the option of having a single VE table for the whole lot, but would be quite happy to have three tables basically the same.

Saul Bellow - "A great deal of intelligence can be invested in ignorance when the need for illusion is deep."
Stephen Hawking - "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."

Jean,

have you had a chance to look at the strange way the current two pulses merge (shoprt/long/short/long etc..)

Personally I would prefer to understand that before making a comment on a third table....

I intend to keep well away from the need for a third table but I would really like to know what was happening with those merged pulses.

Rod.

Schrödinger's cat - so which one am I ???

Rod,

Not yet but I will soon (today or tomorrow, hopefully).

Not that I want to minimize this but if you run your injection pulses close enough to merge them you'll run into other problems before. So this situation should never happen and care should be taken to make sure it doesn't.

Jean

http://www.jbperf.com/

Jean,

I agree about never letting it happen - and Paul has now shown that large injectors at idle don't have to an issue..... so we can avoid it.

I would still like to know why though... just the way I'm made !!!

Schrödinger's cat - so which one am I ???

I totally agree about knowing why it's doing that. If there's a bug it needs to be corrected simply due to the fact that it shouldn't be there and there might be other unexpected side effects.

Jean

http://www.jbperf.com/

I agree Jean that operating at conditions that cause the pulses to merge should be avoided.

However, I am mindfull that it would only take a malfunction of the boost control, for whatever reason, and the engine would go into melt down.

I'm sure that you will soon identify the reason now you know it is there.

Saul Bellow - "A great deal of intelligence can be invested in ignorance when the need for illusion is deep."
Stephen Hawking - "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."

There was indeed a bug which affected not only the siamese mode but the non-siamese mode as well.

The issue was that the pulse following a pulse collision was not being scheduled. And since it was not scheduled, there was no collision in the following engine cycle so there was this sequence with a cycle with one short pulse (missing pulse) and the long pulse (2 merged pulses).

Now when there is a collision the 2 pulses merge as intended and as I described before. But that still means that if there is something that causes a major overlap, the resulting merged pulse will be shorter than the sum of the 2 pulses.

Jean

http://www.jbperf.com/

Jean,

In one respect I'm really glad you have seen it and have an explanation - sometimes when I mess about with a scope (the very old one or the newer USB one) I do wonder if I'm looking at what I think I'm looking at.....

Although we all agree the overlap should be avoided at basic design (ie, like injector sizing), is there a simple fix to the collision that would allow resultant merges to be equal ???

I guess this has never come up before as it's only on your siamese code that you run a single injector channel on a 0,0,25,25 % duty cycle ???

Rod.

Schrödinger's cat - so which one am I ???

The problem is the same as why I want to use 3 tables for the transition from the dual pulse to the single pulse. How do you handle the extra opening time and the timing of the merged pulse? There are solutions but they won't be correct for all situations.

So what needs to be done is to avoid unintended merging by carefully setting the injection timing. And don't forget that you will have some margin for error because as the pulses merge, you will get the equivalent of the opening time where the injector will be open and providing additional fuel.

The problem will be before the pulses merge where you will actually get less fuel due to the injector non-linearity at these small intervals between pulses. And for those, the code can't do much because it doesn't even know about this. One way to avoid this is to do what Gerald proposed and use end-of-pulse timing for the inners and start-of-pulse timing for the outers. That way you always have a known interval (in degrees but you can convert that to time easily).

Jean

http://www.jbperf.com/

Jean,

I fully understand that a merged pair of pulses is going to be innacurate for the reasons you state above, particularly you can't add the extra openning time and the non-linearity of close/open disappears in the middle. To some extent those two cancel each other out I would have thought, BUT, these inaccuracies are of far less severity than the lack of scheduling causing alternate half length (merged) pulses.

I'm struggling to put it into words but, although I will do everything possible to avoid overlapping pulses, if we unintentionally approach that area, is there anyway to stop a merge from not scheduling the next event ???

Gerald's proposal would obviously allow you to totally avoid merges but, as far as I can see at present we only have the choice of start or mid or end applied equally to both pulses.

Even if we could apply end to the first and start to the second, it would limit the flexibility for getting AFRs correct during the experimentation/tuning phase.

Rod.

Schrödinger's cat - so which one am I ???

This is the strategy that I would adopt.



Just make sure that the two pulses do not get too close before going into single pulse mode.

I have sufficient data from previous trials to set up the tables to give a good starting point.

Edited by Paul S on 22nd May, 2009.

Saul Bellow - "A great deal of intelligence can be invested in ignorance when the need for illusion is deep."
Stephen Hawking - "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."

Paul, are you planning on going up to 12000rpm? Kidding aside, that's an interesting looking graph. But I would have thought you'd be making the transition at a lower rpm. And does that involve staging at some point?

Rod, as Paul mentions you will be able to change from dual mode to single mode to absolutely avoid any unwanted merging. And if you want to stay with the dual mode, you could build a table that sets the timing to a very wide gap for the highest load and set this outside your intended load range. So if you have something weird happen and boost goes higher than intended, you just have a wider gap that will prevent any overlap.

And the end-of-pulse/start-of-pulse option will make it into the next release with the hybrid mode. I should have that new release in a few days.

Jean

http://www.jbperf.com/

Edited by Paul S on 22nd May, 2009.

Saul Bellow - "A great deal of intelligence can be invested in ignorance when the need for illusion is deep."
Stephen Hawking - "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."

I hadn't noticed the MAP part in the scale but that makes sense. So the 12000 would represent anything such as 12000rpm at 1Bar and 6000rpm at 2Bar or any other combination. This assumes that you'd be using the same AFR with the same VE but it's probably a good enough estimation.

And I agree that if you can avoid staging then you should. That way you avoid the transition and the tuning of it.

Jean

http://www.jbperf.com/