Crank+Cam based input pattern support requests thread

For discussing and developing different RPM/Position decoders using our superior modular architecture! One thread per pattern, please.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Crank+Cam based input pattern support requests thread

Post by Fred »

Hi,

Because development resources are scarce and we intend to do everything, and I mean everything properly down the finest detail, the number of input styles supported will initially be low.

To start with I intend to write code to support 36-1 with or without a cam sync pulse. I have one tester who has this setup, and it is by far the most common type. It is also what I intend to use FreeEMS for when I get back to NZ.

What comes next on the list will depend entirely on what that trigger type supports (at the very least wasted spark/semi sequential) or doesn't and whether or not someone is going to actively alpha test that code in the short term future.

Two main types of post are welcomed,
A I have this and I want to alpha test it with you
B I would one day like to see this present as an option

Posts in this thread of the A type should include sufficiently detailed public domain information about or teeth etc, which edges are reliable, whether they are VR, Hall, or something else, etc. i.e. enough detail to implement the functionality in the code.

Posts in this thread of the A type should also state what your personal intentions are. i.e. :
  • Whether you have a running vehicle with this type of trigger on it
  • Whether you have an xdp512 and support circuits at you disposal or are planning to order soon
  • What level your electronic skills are at (testing at this stage will involve building or adapting boards either on strip board or designing and printing your own)
  • What level your DIY EMS skills are at (anyone with good MS experience should be fine in this regard)
  • How much time you think you can throw at testing (being alpha there is every chance that stuff wont work and will need multiple testing sessions)
  • What level your C code skills are at (the ability to diagnose things and retest them youself with changes is a bonus for sure)
Additionally, if you think there should be more on my list of "required information" or changes to it, please post here too.

And, of course, discussion/banter about the things mentioned which is on topic is also welcome :-)

EDIT : Have a look at the wheel analysis ods file in the docs directory of one of the later releases to see what has been thought about so far.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Crank+Cam based input pattern support requests thread

Post by ababkin »

Well you know a bit about my intentions, so i'll be brief

my wheel is a german popular 60-2 kind. With half-moon cam wheel (1 tooth)
the cam phase however moves about 18-20deg due to the vanos mechanism on modern BMWs. There are a lot of enthusiasts all around world with these single-vanos engines (produc year span was 93-99 or so)

i can of course test this on my car.

Alex
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Crank+Cam based input pattern support requests thread

Post by Fred »

With respect to the crank, does the phase of the signal move, or just the lobe angle?

Single vanos is an on off type isn't it? It should be possible to either code such that the signal (rising, falling, or both) must fall inside a certain range of angles, or indeed to adjust the expected angle based on whether or not its been switched. Or both. Most likely though, because cam readings aren't very accurate anyway, it should be possible to just treat it as a flag of which cycle we are in.

And, because I know you will ask this, it should be possible to log the angle that it falls on, and potentially do something with that information ;-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Crank+Cam based input pattern support requests thread

Post by ababkin »

yes, the wheel moves with the cam and therefore the cam phase moves too (in respect to the crank).

yes, single vanos is on off, but i plan to experiment with feeding PWM to it and setting the cam advance continuously while monitoring the cam phase through the cam trigger, just like what's done on dual-vanos but only for intake cam in my case. (hopefully the solenoid i have won't complain about PWM operation)

why aren't cam readings not accurate? the fall-rise/rise/fall edge is defined quite clearly, feed this to hardware interrupt and compare to the interrupt time of crank teeth and you'll have it pretty accurate i think.
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Crank+Cam based input pattern support requests thread

Post by Fred »

OK, interesting. I'm sure it can be handled anyway :-)
ababkin wrote:why aren't cam readings not accurate? the fall-rise/rise/fall edge is defined quite clearly, feed this to hardware interrupt and compare to the interrupt time of crank teeth and you'll have it pretty accurate i think.
Quite simply because of slack between cam and sensor, slack in drive from crank to cam, back and forward lash from the valve train (particularly at high revs and even more so with large cams).

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Crank+Cam based input pattern support requests thread

Post by ababkin »

Admin wrote:
Quite simply because of slack between cam and sensor, slack in drive from crank to cam, back and forward lash from the valve train (particularly at high revs and even more so with large cams).

Admin.
Very good insight!

I hope smart averaging can take care of that. In addition, i think that this slack is only (or predominantly anyway) function of the cam position/phase (and not random) and as such, slack amount can be factored in.
Even if i am wrong on the above, it is a fact that BMW is able to measure this phase-shift with sufficient accuracy on their dual-vanos valvetrains, since they are able to adjust the phase continuously with pretty good repeatability of the final torque/hp curve.
I'll just have to do some reverse engineering.
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Crank+Cam based input pattern support requests thread

Post by AbeFM »

Where is the sensor? On the miata, the cam tooth you read is ON the cam, well, on the cam gear, and it's dead accurate. It can "bounce" relative to the crank for sure, but that's a software filtering thing to be sure. But you're really reading the effective position of the cam, rotation by rotation, without a doubt.

Put me in a B+/A- category. I'm still on the fence but imagine I will pick up a board soon as I'm quite interested. A certain amount of programming skill (enough to read code and tweak it, especially if commented) I posses. My car uses Hall Effect sensors ('00 miata), with 4 unevenly spaced crank triggers and two cam "marks", one a single tooth, the other a tight doublette. They are not quite at TDC, but do tell you if you are on an even or odd cycle.

All 2001 and up miatas have variable intake timing, and watch these pulses to know where they are at. If my head ever gives up the ghost I may get one of those - but I hope it never happens since there's a lot of work into my head already.

Definately if I do this I'll be able to do a lot of testing and have access to a reasonable amount of test equipment (oscopes, perhaps logic analyzers, etc)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Crank+Cam based input pattern support requests thread

Post by Fred »

Don't me wrong, the cam sensors are definitely accurate enough to read the angle from, reason being that you can just average it over a few successive cycles without issue. But to base all engine timing from only the cam... not so good.

BTW, 60-2 should be covered with the same code exactly as 30-1. Assuming I can figure out how to write it :-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: RPM/engine position signal interpretation and implementation

Post by AbeFM »

Stolen:
And here is the the data for the M2 (NB) Miata, 1999-2005.

The numbers are crank degrees relative to the #1 TDCC (negative being before and positive after)

Crank signal edges in one engine cycle ( engine cycle = 720 crank degrees), 16 edges total:

falling edge at -80 ( == 640 )
raising edge at -77 ( == 643 )
falling edge at -10 ( == 710)
raising edge at -7 ( == 713 )
falling edge at 100
raising edge at 103
falling edge at 170
raising edge at 173
falling edge at 280
raising edge at 283
falling edge at 350
raising edge at 353
falling edge at 460
raising edge at 463
falling edge at 530
raising edge at 533

Cam sync signal edges in one engine cycle, 6 edges total:

falling edge at 37
raising edge at 57
falling edge at 377
raising edge at 397
falling edge at 421
raising edge at 441

Jim
________________
The new JimStim chips, with two white dots, reflect this pattern.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Crank+Cam based input pattern support requests thread

Post by Fred »

ababkin wrote:why aren't cam readings not accurate? the fall-rise/rise/fall edge is defined quite clearly, feed this to hardware interrupt and compare to the interrupt time of crank teeth and you'll have it pretty accurate i think.
I should also add that because of the other things I mentioned, the tooth count in them is usually small, and thus the gaps between the teeth get larger, and consequently the ability for the engine to accelerate and change rpm between the EMS's only way of knowing about it is much greater.

If you put fine teeth in so that that accuracy is there, then the jitter and play etc cause even more pronounced effects.

So, it's not that you can't mount the teeth there, and its not that there is jitter, its that you cant have both.

The denso dizzy uses 24 teeth on the cam for example, thats 12 per crank revolution. Enough, but not brilliant. I don't know of any with higher counts than that, where as 36 or 60 on the crank is commonplace.

I hope that serves to clarify what I said earlier.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply