camshaft advance angle calculation: possible to implement?

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

camshaft advance angle calculation: possible to implement?

Post by Xtatic »

Hi

This question is mostly to Ken and James, but whoever is knowledgeble in this, please chime in too.

I have a system on my intake cam, which changes the cam's phase depending on rpm/load (variable intake timing) called VANOS (this is a BMW S50 US-spec engine)
Currently i have MS controlling the On/Off solenoid which actuates this system. I look at VE changes in the table to determine the optimal switching point of this solenoid.

Now to the question: I'd like to be able to know the relative intake cam angle (relative to the crank of course). I am pretty sure it's possible to calculate from the crank and cam sensors that my engine is equiped with.
You might wonder why i need to know this angle change if it's on/off anyway. Apparently, besides the on/off solenoid, the system uses oil pressure to move the phase of the cam, and the pressure changes with rpm. Therefore, i have a feeling that the cam advance angle is also a function of the oil pressure, which is a function of rpm i suppose.
This feature will also be invaluable to people with a later BMW engines which have an infinitely continuous VANOS, not just on/off but solenoid that uses PWM. From reading about similar systems, i learned that the stock ECU is using the cam sensor to provide feedback so the ECU knows whether to increase or decrease the PWM to achieve the needed cam position advance at any given time.

Please discuss and make your suggestions on how one would implement this.
I have a feeling it's possible just by modifying the firmware, as there already are both VR and Hall sensors on my v3 board, VR is currently used for crank and i am pretty sure that the cam sensor on my engine is Hall type.

Thanks
Alex
Jon k
Super MS/Extra'er
Posts: 1256
Joined: Fri Oct 14, 2005 10:28 am

Re: camshaft advance angle calculation: possible to implemen

Post by Jon k »

Alex,

The cam position sensor is a hall sensor on your particular model. However, I am not sure why this matters right now. From what I know from talking to people who know how the VANOS system works, the solenoid opens and closes and the oil pressure advances the camshaft said and done. The oil pressure doesn't seem to advance the camshaft variably with pressure/rpm, because if it did, there could be clearancing issues with valves based on oil pressure (what if your oil pressure goes way high, do your valves hit?).

I think that with an on/off type of variable valve timing, your cam position angle is measurable mechanically and that's the end of it. Once you get into the PWM dual VANOS vehicles, then it would be something we need to consider, though we don't have the ability to do that right now. I think its a valid question, but I don't think it really applies right now given the current restriction on inputs/outputs and the hardware in general
1992 BMW 525i M50 Non Vanos 24v Turbocharged
Stock COP Wasted Spark
MS2/E v3
rb26dett
Master MS/Extra'er
Posts: 497
Joined: Tue May 24, 2005 11:34 pm
Location: Auckland New Zealand

Post by rb26dett »

also, on virtually all engines oil pressure is capped and relieved by a valve above a certain level, so i doubt your oil pressure would be particularly linear, and also, oil pressure where? if it was right off the pump, then only rpm and that valve and viscosity would have any impact, if its after the filter, or above the head restrictor... you get the point.
ms2,v3,cop,innovate,mazda fe3/fe-dohc 2l 4cyl with stock 10:1 pistons,4 stock coils,4 stock ignitors,rx7 550cc injectors maxed@6600rpm&17psi,custom everything,holset he351cw turbo,44mm ext gate,nis gtr bovs,nis gtr intercooler,70mm lexus throttle,chinese fpr,10may v2 ms2e alpha code
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

rb26dett wrote:also, on virtually all engines oil pressure is capped and relieved by a valve above a certain level, so i doubt your oil pressure would be particularly linear, and also, oil pressure where? if it was right off the pump, then only rpm and that valve and viscosity would have any impact, if its after the filter, or above the head restrictor... you get the point.
well, you're right, that was just a crapshot about the oil pressure being a factor. That is why i'd like to devise some way to establish this as a fact and be able to datalog the intake camshaft phase change (advance angle).
It should be doable in theory - if i am not mistaken, it is already possible to decode the combination of crank and cam pos sensors for things like sequential spark/injection. Determining the phase shift of cam in relation to crank sounds like an easy exercise, at least in theory. Besides, as i said, this WILL be useful for people wanting to run newer BMW (or other modern with continuous variable cam timing) engines. One WILL need this phase change feedback to tune these engines properly.

oh, and before certain someone decides to speak on the community's behalf again, telling me what "we" want or don't want, here is a thread started with the similar need by a fellow squirter:
http://msefi.com/viewtopic.php?t=20701& ... ng&start=0


Alex
Jon k
Super MS/Extra'er
Posts: 1256
Joined: Fri Oct 14, 2005 10:28 am

Post by Jon k »

Xtatic wrote:
oh, and before certain someone decides to speak on the community's behalf again, telling me what "we" want or don't want, here is a thread started with the similar need by a fellow squirter:
http://msefi.com/viewtopic.php?t=20701& ... ng&start=0


Alex
Alex, before you get an attitude like that perhaps you should re-read the thread. It is plainly legible in that thread that Al Grippo addressed it as needing the GPIO board with PWM outputs and some hardware. I don't know what you're trying to prove. We don't have the software and we're lacking outputs right now until the GPIO is working with the algorithm for MS2/E.
1992 BMW 525i M50 Non Vanos 24v Turbocharged
Stock COP Wasted Spark
MS2/E v3
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

Jon k wrote: Alex, before you get an attitude like that perhaps you should re-read the thread. It is plainly legible in that thread that Al Grippo addressed it as needing the GPIO board with PWM outputs and some hardware. I don't know what you're trying to prove. We don't have the software and we're lacking outputs right now until the GPIO is working with the algorithm for MS2/E.
You are wrong. I don't feel like disecting this thread i linked to, but i think it was Lance who suggested using the FIdle for PWM output - there is a solution to your "impossible" problem.
Besides, i never said i will need PWM capability, maybe you should re-read my original post, it is also plainly legible.

I've posted this thread for enthusiastic people to get together and possibly figure out a solution, not for people to come and tell me it's impossible (with nothing to support the claim) or what "we" do or don't need to do.
I would take this kind of response from Ken or James, but you are not them, so..

And by the way, thanks for the utterly insulting PM you've followed up with. I didn't know that bringing you to reality would bruise your ego so much. If i knew, i'd probably just have ignored your post.

Please don't turn this thread into one of your bf.c threads.

Thank you
Alex
MegaScott
MS/Extra Guru
Posts: 1280
Joined: Mon Jun 14, 2004 9:35 am
Location: Chiang Mai, Thailand

Post by MegaScott »

I would think that the on/off vanos system activation would not vary that much with oil pressure, this is an engine specific thing related to clearance wear and pump efficiency. I would also think when the ECU commands the solenoid to on, it expects the Vanos to be on as well. An engine in good condition should provide a fairly continuous amount of oil pressure, even at idle, but the oil pressure regulator should be open a little to provide pressure regulation, as the RPM's increase, the pressure regulator should still provide that same pressure, though the volume has increased, which means that it will just bypass more oil.

Of course I am saying this from an engine builders perspective, having not actually owned a VANOS equiped Bimmer myself, so I could be way off, The usual disclaimer applies, if I'm wrong just ignore my possibly ignorant post.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Post by muythaibxr »

As I understand it, the continulously variable setups have a sensor to detect cam position similar to a TPS, so they can pick a position, and then use PWM to match that position.

Usually the setups that have the on-off (again as I understand it, this is how toyota's VVT works, VVT-i is continuously variable) have the adjustable cam set up in such a way that no matter what the RPM, or oil pressure, it turns the same amount. It might not get there as quickly with the lower pressure, but it turns the same amount.

In order to actually map the positions in a table, we'd need to be able to tell cam position somehow. I don't think this can be done with the sensors that are used for ignition. (IF the position of the cam affected the position of those, you wouldn't be able to run the engine very easily).

We *could* use the fast idle output to PWM a solenoid, but we'd still need to use one of the spare ADCs to read back the position. Right now we're a little short on those.

We do intend to do that with MS3 (whenever we find out the for-sure details about it).

Ken
rb26dett
Master MS/Extra'er
Posts: 497
Joined: Tue May 24, 2005 11:34 pm
Location: Auckland New Zealand

Post by rb26dett »

correct, provided there is enough pressure to activate the system (one would assume that the requirement would be significantly below that of the rest of the engine by design) it would be just on, and only on. it would still be interesting to see where the cam is relatively though, esp if its not documented anywhere.

as for normal oil systems, i'd say most engines the relief valve is closed until a certain rpm when supply exceeds demand and the pressure rises above the threshold, on my skyline engine for example, this occurs at around 3k. obviously where it occurs will vary with wear and tolerances with age, but still, i'd say its unlikely that you'd find an engine that when warm shows full pressure at idle, and negligible increase with rpm.

fred.
ms2,v3,cop,innovate,mazda fe3/fe-dohc 2l 4cyl with stock 10:1 pistons,4 stock coils,4 stock ignitors,rx7 550cc injectors maxed@6600rpm&17psi,custom everything,holset he351cw turbo,44mm ext gate,nis gtr bovs,nis gtr intercooler,70mm lexus throttle,chinese fpr,10may v2 ms2e alpha code
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

Thanks for the feedback guys

I am still learning about engines, thus my hole in oil pressure knowledge.

Ken, there is no such TPS-like sensor to sense the advance angle on the cam on these engines (unless i am terribly wrong).

Here is my purely theoretical reasoning based on my limited knowledge on how this phase-shift could be calculated:

Here are my premises:
- Every tooth decoding of crank wheel means that MS "knows" the exact crank angle when a tooth passes the sensor.
- crank and cam decoders are implemented, giving (at least a theoretical) possibility of sequential spark/injection (i.e besides the crank angle, MS knows enough to distinguish the TDC before power-stroke and TDC before intake stroke, which is needed for sequential stuff)

suppose:
- we have a 1-tooth cam wheel (or at least an ability to recognize a constant single angle reference point on a cam wheel)

Now, i imagine the simple algorithm working as following:

when each fixed cam wheel reference point ( say start of tooth #1 ) is encountered, record the current position of the crank wheel (possibly extract this from the crank wheel decoder)
store this value in a datalog.
do this at every cam cycle iteration.

So, this datalog would give us the variable absolute position of crank in relation to the fixed reference point on the cam wheel. With a bit of subtracting, this gives us the variable absolute angle of the cam.


Please do correct me if my train of thought breaks somewhere.

Thanks
Alex
Jon k
Super MS/Extra'er
Posts: 1256
Joined: Fri Oct 14, 2005 10:28 am

Post by Jon k »

muythaibxr wrote: We *could* use the fast idle output to PWM a solenoid, but we'd still need to use one of the spare ADCs to read back the position. Right now we're a little short on those.

We do intend to do that with MS3 (whenever we find out the for-sure details about it).

Ken

That's the most important part right there Alex - From Ken, not me. I don't understand why it makes it any better having Ken tell you that ADC inputs are short versus me saying so, but there you have it. Although a noble idea and much underway in the plans, MS2 is severely short on IO right now.
1992 BMW 525i M50 Non Vanos 24v Turbocharged
Stock COP Wasted Spark
MS2/E v3
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

Jon k wrote:
muythaibxr wrote: We *could* use the fast idle output to PWM a solenoid, but we'd still need to use one of the spare ADCs to read back the position. Right now we're a little short on those.

We do intend to do that with MS3 (whenever we find out the for-sure details about it).

Ken

That's the most important part right there Alex - From Ken, not me. I don't understand why it makes it any better having Ken tell you that ADC inputs are short versus me saying so, but there you have it. Although a noble idea and much underway in the plans, MS2 is severely short on IO right now.
Thank you Jon for another unnecessary post. Ken said I'd need another ADC because he assumed that there is a cam advance sensor similar to TPS.
This is not however the case with single-vanos bmw engine as you probably know.
muythaibxr wrote: As I understand it, the continulously variable setups have a sensor to detect cam position similar to a TPS, so they can pick a position, and then use PWM to match that position.
Now, to answer your question on why i'd rather hear it from Ken, it is because Ken actually knows what he's talking about.

Alex
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Post by muythaibxr »

Alright guys, lets keep it civil please.

I was saying that for the continuously variable valve timing setups, they have a separate sensor that measures the cam position relative to the cam wheel.

I don't think you can measure cam angle using the cam teeth that are there for ignition, because if those moved relative to the crank wheel, you may have to renumber the crank wheel teeth on the fly (assuming it moves enough to change what teeth it falls between). If it moves but doesn't change which two crank teeth it's coming between, then you might be able to use it to figure out roughly how many degrees it moved.

Ken
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Post by muythaibxr »

after thinking some more and talking to James about it...

This could probably work by figuring out how much it changed by as long as it doesn't cross the missing tooth. It would only work if it was a missing tooth wheel with an extra cam tooth though.

Ken
jsmcortina
Site Admin
Posts: 39585
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Post by jsmcortina »

I was thinking about this setup this morning.

As the BMW uses a missing tooth crank wheel, the exact position of the cam tooth isn't critical provided it doesn't cross the missing tooth boundary.

So, what could be done as a proof of concept is to record the crank wheel tooth number and time since last tooth when the cam tooth event happens.
This data could be output to Megatune and logged.

Then activate the solenoid and see what happens.

From rpm and number of teeth these two numbers could be converted to an angle after the missing tooth.

If this data worked then the code could _possibly_ be adapted for closed loop control.

James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

Thank you James

I'd love to help in implementing this phase-shift readout for starters. I know it's not very useful in itself, but it's a start.
I have a single vanos on my engine, which is on/off, and either not advanced at all or advanced 12.5 degrees - no in-between. So while i cannot control it continuously, i'd be able to monitor the very effect of cam phase shifting in relation to crank. (i know, i know i am a geek :)
Later, dual-vanos, bmw engines are continuous in this adjustment and WILL require this feature in order to be tuned properly.
This hardware/software feature will of course complicate the tuning process somewhat, but at least it will give the opportunity to make use of it.

Just a "bystander's" opinion (please don't take it as a criticizm, as you guys are great to do this on your spare time):
I've spent good 5 hours today going through the ms2e code. I've made some sense of it, but would ultimately prefer to look at some kind of block diagram or description of the whole sequence in human form beforehand, as it is very easy for a novice to get lost in this code.
It is a spagetti type of code (not that anything is wrong with that), to which it should be very easy to draw a block/flow diagram, and highlight the important global vars/arrays.
Comments in the code are helpful at times and lacking at other times. Also i noticed that some flag values had been macro'ed and some just hardcoded hex with no description (which kinda sux :).

Anyway, i'll continue staring at the code, and try to come up with some "ingenious" way to implement this.

Cheers
Alex
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Post by muythaibxr »

again, I think most of the continuously variable ones (I would guess like your vanos) probably have a setup that lets them continuously monitor position as well, similar to a TPS in setup.

I know that at least some of them do it this way, not sure if everyone does though.

As far as your comments on the code, a lot of the decisions we make on how the code is organized favors function over form. We've tried to avoid using lots of function calls for example, because they involve needless overhead. We started using them more recently though because doing so allowed us to split code between various flash pages.

As far as the macros, I think I tried to use macros instead of just hex wherever possible, but with the two of us working on the code full-tilt, sometimes things like that slip through the cracks.

That said, the code shouldn't be too difficult to read and figure out.

Ken
Last edited by muythaibxr on Thu Sep 13, 2007 2:39 pm, edited 1 time in total.
rb26dett
Master MS/Extra'er
Posts: 497
Joined: Tue May 24, 2005 11:34 pm
Location: Auckland New Zealand

Post by rb26dett »

Xtatic wrote:It is a spagetti type of code (not that anything is wrong with that), to which it should be very easy to draw a block/flow diagram, and highlight the important global vars/arrays.
Comments in the code are helpful at times and lacking at other times. Also i noticed that some flag values had been macro'ed and some just hardcoded hex with no description (which kinda sux :).
that would be because its a complex piece of work stuffed into a tiny box ;-) embedded/hardware stuff tends to be a bit like that.

roll back over to msefi and have a look at the original single C file to have a more full appreciation for whats been done here.

the code is infinitely easier to read and follow than it was before.

full credit there.

fred.
ms2,v3,cop,innovate,mazda fe3/fe-dohc 2l 4cyl with stock 10:1 pistons,4 stock coils,4 stock ignitors,rx7 550cc injectors maxed@6600rpm&17psi,custom everything,holset he351cw turbo,44mm ext gate,nis gtr bovs,nis gtr intercooler,70mm lexus throttle,chinese fpr,10may v2 ms2e alpha code
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Post by muythaibxr »

Yeah, I have to say that the way this code looks is pretty typical of embedded code where it has to fit in a small amount of storage, and execute quickly on a slow CPU.

I don't know that we'll ever get around to doing a block diagram, at least not anytime soon. I'm not going to spend my limited spare time that I have for coding drawing boxes when I could be implementing new features or fixing bugs.

EDIT: Looking around, a lot of the hardcoded hex is only used when we're directly toggling something in the hardware...

Ken
Xtatic
Helpful MS/Extra'er
Posts: 108
Joined: Thu Oct 12, 2006 1:21 pm

Post by Xtatic »

muythaibxr wrote:Yeah, I have to say that the way this code looks is pretty typical of embedded code where it has to fit in a small amount of storage, and execute quickly on a slow CPU.
tell me about it. I write/maintain linux drivers for living

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)
muythaibxr wrote: I don't know that we'll ever get around to doing a block diagram, at least not anytime soon. I'm not going to spend my limited spare time that I have for coding drawing boxes when I could be implementing new features or fixing bugs.

Ken
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
Post Reply