kday

My stock CAS setup is working fine but I want more accuracy and plan on going full sequential at some point, most likely with custom hardware and software. I decided to try making a 60-2 wheel out of the crank trigger wheel that came with my 1996 engine. I haven't tested it yet (the engine is still half-assembled) but I think it will work.





The tooth edge to tooth edge accuracy is not as great as I would like, but I don't think it will be a problem, since the error will be constant (i.e. it just affects the scalar tuning parameters).

I made this on a low end benchtop mill with a (really low end) rotary table with dividing plates.

Cutting the outer tooth diameter:

After 60 iterations:

I spent more time making the parts to mount the wheel to the table for machining and measurement than I did actually cutting the teeth.




(Actual machinists will laugh of course -- I am a complete amateur at this.)

The teeth are too shallow for the stock sensor mount, so a new mount is the next piece to be done. The outer tooth diameter is just slightly above the height of the belt on the pulley.


The whole setup while measuring VR sensor amplitude with the unmodified trigger wheel:




I haven't cut the missing teeth yet. I'm thinking I will put them at 90 degrees after #1 TDC for ease of remembering. The only constraint on this that I can think of is that you don't want the missing teeth to be in an area where you need the most precise timing, which would be roughly the 45 degrees before #1 TDC and #1 TDC + 180. Am I overlooking anything here?

Matt Cramer

Nice fab work, and yes, 90 degrees BTDC is a perfectly good spot for the missing teeth.

Joe Perez

iTrader: (8)

Wow, this whole process seems eerily familiar, including the spinning of the wheel on the same machine you made it with to test the sensor. Very nice looking work so far.

I've often though about doing exactly this- taking a stock '96+ wheel and modifying it into an even-tooth format. Every time, I've then realized how much work it would take to do it right and very quickly banished the thought from my head. Nice to see someone actually go all the way.

kday

Thanks. It wasn't actually that much work and was enjoyable. Thinking about doing the step and repeat 60 times by hand is much worse than actually doing it. I think a 60-2 wheel is probably easier than e.g. a 36-1 since 1/120 of the circumference is very close to 5/32" (the tool size I used) and each tooth only required one left-right motion. (I suppose you could do the same with 36 teeth but you would have to remove a lot more material.) The only thing I would do differently is not buy the cheapest possible rotary table. This one kind of sucks.

Before I make the sensor mount I'm going to prototype an adaptive VR amplifier circuit and determine the maximum sensor to tooth gap I can get away which will trigger reliably at cranking speeds.

Incidentally, combining small sensor gaps and high wheel speeds is a good way to blow the input stage on your oscilloscope...

Joe Perez

iTrader: (8)

Yeah, when I was testing mine by spinning it on the lathe, I was surprised by how much voltage that sensor was able to put out at higher speeds.

That sensor you are using looks rather unconventional, from a packaging standpoint at least. Is that what the stock '96-'97 sensors look like? (I've never seen one.)

kday

That is the '96 sensor with the original bracket still attached. It is a little odd looking. I have a few miscellaneous Bosch VR sensors around that I might try, but this one is nice since it has a bolt hole for mounting rather than being a friction fit.

AbeFM

iTrader: (3)

Interesting it's a different sensor.

Hopefully your error isn't as bad as you think. Because if it is, you're going to have worse timing than you would with 4 teeth!

On the bright side, with 60 teeth, you can really only be off by maybe 2 degrees no matter how badly you messed up (and you look to be much better than that). But to play devil's advocate here:

6 degrees tooth to tooth spacing. If you were off by 1 degree, the motor would think it was running 16% faster/slower than I thought.

On a four tooth, such as the stock one, if I'm off by an entire tooth width (I think they are 3*) my engine RPM won't report too far off, though my absolute position might be.
But I should be within 3%.

So what ends up happening? You end up doing so much averaging in software you almost lose what you were hoping to gain in the first place - plus the CPU spends a not insignificant percentage of its time dealing with "Oh, there's a tooth! Average it in, figure out how fast we're going, is there anything we need to do? No? Ok, back to what we were doing then" that your fuel and timing targets will be off because you'll be very accurately hitting the timing calculated for two rotations ago.*

Of course, I don't think your wheel is as far off as you make it out to be, only suggesting that adding more teeth means a smaller error is important.

Is the OEM sensor a true VR one? Mine is (OEM '99) a VR based but outputs open collector. Go get one of those? :-) I guess for the scope a small series resistor should help you out I would think.



*7500 rpm / 60 sec/min * 60 teeth/rotation means (even if you're ignoring falling edges) gives you 133 microseconds per interrupt. That's 1000 clock cycles per tooth. This is a rough estimate, but figure it's about 100 cycles JUST to deal with the interrupt (so says the old programmers here). It, at minimum, has to add one to the tooth counter, and check to see if it's a tooth that it thinks matters, and you've quickly used up 15-20% of the available CPU time counting teeth.

When the computer has to do something like update the "when do I spark" or "am I accelerating, should I add more fuel", it makes these estimates whenever it's not busy dealing with teeth. So, you might be shooting yourself in terms of accuracy.

Anyway, looks like a fun project. I'm sure it'll work great and be a good upgrade. Certainly better than when I just punched a hole in the middle of an OEM toothed wheel and welded it onto the mazda wheel. :-P

kday

I don't think you're right about the error, Abe. Fundamentally the ECU doesn't care about the instantaneous engine speed for the fuel and spark timing. It cares about the engine position, and any tooth placement error will be consistent from revolution to revolution. So maybe I say 15 degrees BTDC in megatune and it is actually 14 degrees. It will be 14 degrees every time. That's OK.

The above assumes that the event scheduling resolution is equal to the edge count (2x tooth count). So with a 60 tooth wheel I could set timing with 3 degrees of resolution without caring about instantaneous engine speed. To get better resolution, the ECU needs to predict how many clock cycles will elapse between the two tooth edges surrouding the desired trigger point, based on how many clock cycles elapsed between some number of previous tooth edges, and use that prediction to schedule events with the CPU clock. Error in the tooth width will have an effect here -- some teeth will be "longer" than others -- but again, it is constant from rev to rev.

The 96 sensor is a passive differential VR sensor.

Joe Perez

iTrader: (8)

Yeah, I knew that the '96-'97 cars had a shielded 2-wire raw VR sensor, I'd just never seen one before. Their wheel is different as well. On the NB wheels, the four teeth have both leading and trailing edges which are square and symmetrical. If you look at pic #3 here, you can see that on his wheel, the leading edge is sharp and square, but the trailing edge ramps down gradually. I wonder what that signal looks like on a scope?

Oh, c'mon. Even my slow-*** MS1 has no trouble keeping up with a 36-1 wheel.

My understanding of the MS2's tooth routine is that, like the MS1, it only does the RPM calculation once per cycle. So even though it has to count 60 teeth per rev, it does not do the RPM computation on every single tooth. The only difference vs. MS1 is that it will pick-and-choose which tooth it starts the dwell countdown on to maximize accuracy, rather than always starting the timer on the reference tooth. Of course, I could be totally wrong. This is all based upon reading written descriptions of the routine, not the source. That damn C stuff is just incomprehensible compared to real code.


So, kday, when can I send you my wheel for modification?

kday

I have some traces of the unmodified wheel I can post when I'm back in the garage. I'm not sure why the wheel is the shape it is. No obvious advantage was evident in the traces.

I will probably write my own trigger wheel code on an external microcontroller when I go sequential + COP. I think the code can be simpler and possibly more accurate by trading off the flexibility the MS2 algorithm has. Plus I will need to build a board with 4 injector drivers anyway, might as well plop down a micro and a VR conditioner and send just the fuel and spark parameters over CAN.

I might be willing to do another wheel in trade for something, assuming the wheel you have fits my jigs. No promises on tooth to tooth tolerances though...

AbeFM

iTrader: (3)

Heh, I like the idea of doing the interpreter yourself. And I would like to see the trace as well. VR sensors look for edges, so it'd almost be like they are trying to hide the edge they are not using? Or maybe they roughed it out and more carefully put in the edge they cared about? Seems off either way.

“”Oh, c'mon. Even my slow-*** MS1 has no trouble keeping up with a 36-1 wheel. “”

That's just what I'm getting at – it's well known (to me at least) that the MS 'back shelfs' calculations which are less important than the critical ones. It doesn't make sense not to. So the more you give it to do, the more engine cycles will be completed before other calculations are done. Which get preference, I don't know. I certainly wasn't suggesting that the rpm are calculated every time a tooth goes by, then you really WOULD get skipping at high revs. :-P I'm saying that you are loading the CPU a significant percentage of its capabilities to have so many teeth. It's a bit better on the MS-II, and will be totally ok on the MS-III HC12 based systems. A 80 MHz clock won't have the issues of a 5MHz one, especially with two processors.

If the MS-I is using a “reference tooth” then you're not getting any more accuracy at all, are you? You'd literally be better off with a single tooth!

As to the error in the teeth, that's the biggest point. You don't tell it JUST when to fire. There's some interpolation there... I'm trying to think of how to put this. Say it wants to fire just on one side of the tooth sometimes, and just on the other at others. The gap, if it waits for the tooth, would be much bigger since it'll be hopping sides of the tooth (i.e. 19.5 degrees would fire at 13.5 because one tooth is moved over. But 14.0, which would happen after the tooth which might be a degree off would happen at 15.0, meaning a 0.1 degree change do to a SLIGHT difference in MAP or AIT would translate to a 1.5 degree error.


Of course, from looking at the wheel, I don't think your mechanical error is that big. I am much more concerned with processor load. You could measure the gaps in the teeth and I bet you'll find out you're withing a 10th of a degree anyway.

kday

1/10th of a degree on a 5.8" wheel is 5 thousandths of an inch. That would be non-trivial to achieve for a skilled machinist with good equipment and I'm an amateur with cheap tools. I already measured my error, and it is more than 1 degree.

But I still don't think it's an issue. You haven't explained how the error varies from revolution to revolution.

kday

Here is the output of the unmodified 1996 trigger wheel:

AbeFM

iTrader: (3)

I think it all comes down to how the code runs. If, as in my scenario, it fires right on the tooth edge, you could get a large variance.

Let's say there's a tooth who's trigger edge is supposed to be at 14 degrees, but it's actually at 15 degrees.

You set up your map to fire at an indicated 13.8 degrees (i.e. your map says 13.8 degrees). As you said, this won't effect anything, under those exact conditions, you'll always fire at 13.8*, This assumes the previous tooth (the one at 8 degrees) is where it belongs. So the computer knows RPM, and it knows where 8 degrees is, and an appropriate number of MS later, it fires the sparkplug. Your car makes good power and is consistent, allowing you to run really tight timing as well.

Now, let's say your intercooler heat soaks some small amount, your manifold gets hot, or you drive through a local hotspot on your favorite road. The MS-II thinks, Oh, intake temps are up. Let's retard the timing 0.4 degrees. So it wants to fire at 14.2 degrees. It knows a tooth is coming at 14 degres, so it says "I'll wait until .2 degrees after the tooth, then fire". Sound logic with a good wheel.

So, it waits till 13.8, no tooth. where it expects 14. No tooth. 14.2, no tooth. This carries on until 15 degrees, where the tooth is. Now, it knows to wait a short time (0.2 degrees) and fires the plug.

So what's the big deal? The big deal is the map was set up for 13.8 degrees. A small change of less than a degree, if it crosses the boundry of an illplaced tooth, can have a much bigger effect. The attempt on the MS's part to fire the plug 0.4 degrees later turned out to be 1.4 degrees later, giving you worse timing than a well made 4 tooth wheel. The teeth on the OEM wheel are set up to give you a useful timing mark close enough to give a good reference but far enough away not to interfere with the ignition event.

Of course, the code could ignore those extra teeth, as Joe said, the MS-I (I guess) uses the missing tooth and bases everything on that. Or any tooth where it never changes the one to fire from. A given time past a particular tooth, the issue would go away as you suggested. But if you put lots of teeth and they are wrong, well... That's like having pull fire alarms all the time. :-)

Not trying to insult you here, you are doing some amazing work. But I'd suggest either doing the code yourself to account for things like this, acquiring a wheel that you 100% trust, or triple checking the code that is already written to ensure that it does this correctly.

But I submit that if the computer is using a single reference tooth to fire from, that all the other teeth buy you no accuracy, they only take computation time away from the CPU for handling other tasks. Thankfully, most of those other tasks matter more at idle than at full tilt, and there you have a lot of spare time. But full sequential spark and fuel starts to be demanding of the processor.

That's my quick stab at it. I could easily be wrong. :-)

kday

Maybe I am assuming too much about how the MS code works. I am assuming it works the way I would design it

AbeFM

iTrader: (3)

Huh, yeah, interesting. It's asymmetric. But certainly not 'hiding the edge'.

AbeFM

iTrader: (3)

I've learned one thing. NEVER assume how it works. Even when directly asking the guys who wrote it (with all respect due). You're going to have to check it. But it's something which I thought *could* sneak up and grab you. I get into this with myself every time I want to swap my 4 tooth. :-)

Joe Perez

iTrader: (8)

Well, yeah. But seriously- how many hundred times per second do you really need to re-compute the IAT correction and determine whether or not the fan should be on?

With an MS-1, there is sufficient free time even with a 36-1 wheel to run a 20 cycle EGO. That's really the only time-critical task other than squirting and sparking. I seem to remember reading somewhere that the max RPM with a 60-2 was something like 14,000. Idle happens when the wheel is at its very lowest speed, so that's not even remotely close to being a concern. I'm assuming that even with its non-optimized spaghetti code, the MS-2 is not significantly slower. I mean, how many clock cycles does it take to say "Hey, look! An IRQ! How cool is that? Has it been 18 teeth since the last ref? No? Ok, then tooth = tooth + 1, and back to the loop we go."

What is that, maybe 20 instructions including the put and fetch? As Han Solo said, "She's fast enough for you, old man."


Well, you'd need either 4-1 or 2/1 at a minimum. There are two references per crank rev on a wasted-spark 4 cyl.


It would vary in two ways.

1: The error will vary from TDC to BDC, as you can't guarantee that (to pull some random numbers) tooth #14 and tooth # 44 are in error by the same amount. So the 1/4 ignition event will have error relative to the 2/3 event.

2: On the MS2, the processor does not always start the timer on the same tooth. Instead, it waits until the last tooth that it predicts will pass prior to needing to start the timer, and starts the timer on that tooth. When advance is 10°, it till be triggering on a later tooth than when ignition advance is 30°. So you'll have different amounts of error depending upon desired advance.


Realistically speaking though, I've observed close to 10° of error on the early engines due to timing belt flex. If your maximum error is 1.5°, that's a major improvement. I'm not sure whether I can discriminate 1.5° by eye with the timing gun.

kday

That's a good point, but it is still a constant error from revolution to revolution. 1/4 spark may be a degree off from 2/3, but it will be the same degree off every time. I don't think that is a major problem, and it could be accounted for in custom software if it was a problem.

Right. Some degrees will be larger than others. But again, as long as the error is the same every revolution, the tuning parameters will be consistently applied.

Wow. How did you measure the error?

Joe Perez

iTrader: (8)

No, Abe makes a valid point here. Because MS2 uses different teeth to start the dwell countdown depending upon what the requested advance is, error will vary from one revolution to the next as advance changes and thus different teeth are selected. To minimize error due to the fact that the crank does not travel at a constant angular velocity, the MS2 always waits until the last possible tooth (the one closest to the firing position) to start the timer. So if two adjacent teeth are 1° off relative to one another, you'll have an error of 1° when the CPU switches from one tooth to the next.

It's a really clever coding scheme, but it rests on the assumption of a perfectly symmetrical wheel. I wonder how accurate your average laser-cut aftermarket wheel is?


With a timing light and the MK-1 eyeball. For the purpose of determining the latency through my signal conditioning circuit, I locked the advance at 10° static and then observed the timing mark while moving the RPM up and down. (latency through the system manifests itself as a decrease in advance inversely proportional to RPM). During the process, I observed jitter in the timing of close to +/- 5° in either direction at higher RPMs. I attribute this to flexation of the timing belt, and it was one of the reasons that I embarked on the whole crank trigger conversion in the first place. With my current setup, jitter is about +/- 1° worst-case.