camshaft advance angle calculation: possible to implement?

[muythaibxr]

tell me about it. I write/maintain linux drivers for living

I used to write FreeBSD kernel code, and now I do a little of everything, including linux driver work at my day job.

btw, i fully understand the overhead of multiple function calls. Is there a reason why you guys don't use them with "inline" specifier? You get the benefit of modularity in the source, and the speed of completely inline code (no overhead as the compiler just concatenates them together automatically). But i guess you guys also worry about how much space the binary occupies too, so i guess it's GOTO and ASM time. (we all really need some updated hardware)

inline also doesn't seem to work with this port of gcc. I inlined a few of the functions for controlling the ignition outputs, and the asm looked the same before and after I did it. Even if inline did work though, it does cause us to use more space like you say. Kernel coding is a bit different from this kind of coding though, as even with kernel coding, you don't have to be incredibly careful about the speed unless you're writing an interrupt handler. Most of the time the CPUs you are writing for in the linux kernel are WAY faster than the processor on the ms2.

I don't mind working on the slower hardware. It's fun to actually have to care how fast the code executes. We've been able to be a little less careful about execution speed in the main-loop than we were with ms1, and gain a LOT more accuracy in comparison, so I still think we have some life left in this chip. We do need a faster chip to do some of the more complicated stuff that we're interested in.

I'd be glad to help with this kind of diagram/description, but unfortunatelly i don't have the same understanding of the code as you two do, and won't have for a while (if ever).

Alex

The code isn't really all that complicated to tell the truth. I'm going to clean up some of the style for it sometime before 2.0 is released, but code-flow and all that is not that difficult to understand in this code.

I mean it's mainly:

1) start at the top of the main loop, and go to the bottom.
2) look at each ISR and see what each one does.
3) then the hardest part: see how the IC ISR and RTC ISR interact with variables that are set in the main loop.

For number 3, the main things to consider are that the spark scheduler is in the main loop, and the ISR just reads the calculated values from there, and uses them to set the ignition outputs. The fuel calcs are also in the main loop, and used in the IC ISR to set the fuel pulse-width.

There are also some other things, like the boost control and idle speed control algorithms are in the main loop, but the RTC takes the % calculated in the main loop, and turns it the appropriate output on and off to get the desired PWM behavior.

But really, if you just go through the main loop, you'll get a good idea of how it all works, then it's just a matter of figuring out where specific main-loop calculated variables are used in the interrupts. It's pretty obvious which ones are used outside the main loop, as I've tried to surround those in a DISABLE_INTERRUPTS...ENABLE_INTERRUPTS block.

Anyway, hope that helps.

Ken

[Xtatic]

Just thought of another cool use for implementation of this feature

Getting stock Ignition advance table by snooping on the stock ECU, something i wanted to try long time ago. I understand most of hardcore squirters frown at the idea of basing the tuning off of stock tune, but for beginners like myself, it would be a great starting point. After all, one has to respect the millions invested in R&D by the manufacturer to figure out what the engine likes/dislikes in terms of ignition especially.
In particular, my engine was modern enough to be equipped with a proper ECU and direct ignition, so it's not like i'm trying to duplicate a dizzy ignition map (which would be silly). Besides, gen after gen, stock ECU's get more and more powerful/complex getting the tune closer to the optimal edge (not necessary for pure power purposes though), but i still consider it useful to have someting tried and true as a base/reference map to use as a starting point and not blow something up.

Now to the point: If I (or someone else) will ever come up with an implementation to the original problem in the beginning of this thread, one could easily adapt this implementation to this ignition map snooping problem.

Here is how: in an idea of an algorithm i described above, one would need to figure out the angle of the crank wheel, when the particular angle (particular unique tooth) is encountered on the cam wheel. Knowing this one would be able to determine the phase-shift between the two wheels.

Now, imagine that you have the cam sensor input attached to an inductive pickup on one of the spark plugs / coils instead (the pickup could be taken and retrofitted from a cheap timing light), providing some sort of circuit facilitating signal similarity in between.
So the impulse from the inductive pickup from a sparkplug wire would act like a unique tooth on an imaginary wheel, and so using the same implementation i described earlier, one could easily calculate the spark advance.

i'd appreciate it if there is someone interested in helping me out with this. I do believe this would be a useful feature for people with modern engines.

Alex

[Jon k]

Alex did you see on bf.c that Antonch has extracted the DME maps in actual degrees and converted l/min MAF flow to kpa load?

[Xtatic]

Alex did you see on bf.c that Antonch has extracted the DME maps in actual degrees and converted l/min MAF flow to kpa load?

no i haven't, thanks for heads-up. I've seen a bunch of maps posted by people with tec3's and such on similar to ours engines.

EDIT: just read the thread about this. Antonch is right about warning people just taking and using his maps, MAP based systems are much more sensitive to say how free flowing one's exhaust is. That's why the actual measurement of the final physical advance on a particular car is the safest way to go IMO.

this could be useful for people with engines, for which the stock maps had no been published, as well as to figure out functions/correlations of more complex engine features with respect to igntion values. For example, on engines with dual-vanos (independent continuous advance of intake or exhaust cams) - how does one know how the advance tables change in relation to the cam positions? I mean with on/off vanos it's easy - just two discreet points of reference - not the case with continuous/dual vanos. One could probably just linearly interpolate between the highest and lower cam advance tables with ok results, but this may not be a linear relationship.
Therefore i think that as engines and stock management get more and more complex, the usefulness of knowing stock tunes through thorough datalogging is increased.
Take the dual-vanos example: you datalog stock ignition advance values at variety of rpm, map, cam phase-shift values, then you run the datalog through a number crunching machine and estimate how cam phase-shift affects an advance table as we know it (just rpm and map based), then come up with some kind of transfer function (also represented as a table), then integrate all this in MS2 firmware

btw, did you know that vanos functions not only to increase the VE at low/midrange, but to also to implement the "internal EGR"? and with dual-vanos, ecu can actually control how much EGR is going on? (i.e, if we could tune it, we could actually set it to do NO EGR and always get a "fresh" mixture for max power, or lot's of EGR to pass emissions )