Fast CAN in and out of M800

[Pavlo]

Time domain measurement, accross a number of teeth or every ms perhaps. At max speed we will have about 17khz waveform, and a 25mhz tick so 1462 clicks between each tooth giving +/- 6.16rpm accuracy on a single tooth, or 1rpm accuracy over 6teeth, or

We cannot know how accurate the ecu rpm is by using a timing light, unless we use a timing light and a high speed camera to capture the RPM transients from all 4 ignition events during a downshift. I have no doubt that holding the engine at a steady speed or even accelerating on a fixed ramp rate on a dyno the ECU rpm will be close. I wouldn't be so sure that the ecu is accurate enough to give correct RPM and position measurement during a downshift where the RPM rate is around 40000rpm/s. For that there is an easy fix, just add a 36-1, or 12+1sync timing setup and this will happen anyway in due time.

The issue isn't one of spark timing accuracy or any other sort of positional accuracy(although it could be improved with a better trigger wheel of course) but one of knowing the precise time to within a few ms when the dogs have disengaged so the shift can be timed correctly. The shift actuation takes place in about 4-5ms during a 40-50ms shift cycle. That is why it's not acceptable (to the people that designed the GCU system which I have to remind you we have no control over) to have an RPM or RPM rate updated every 5ms.

[Holmz]

Time domain measurement, accross a number of teeth or every ms perhaps. At max speed we will have about 17khz waveform, and a 25mhz tick so 1462 clicks between each tooth giving +/- 6.16rpm accuracy on a single tooth, or 1rpm accuracy over 6teeth, or

We cannot know how accurate the ecu rpm is by using a timing light,
...
The issue isn't one of spark timing accuracy or any other sort of positional accuracy(
...

The point was that if the sparks are coming out at the right time, then the ECU must know where the cranks is at "in position space", which means that it also knows the RPM "in phase space".

Have you considered using the frequency domain method ?
I believe that there are differences between the accuracy of frequency and time domain methods.
pretty much the time domain method relies on 1 or two points and the time resolution.
The frequency domain method relies on many points so you get a huge advantage in averaging out noise.

If one knew how the ECU computes the position...
Do they use the time domain or frequency domain?

[Pavlo]

The frequency method will not work unless we have many more teeth or sample the teeth over a long time period. They are in effect the same method but in period measurement we are measuring the number of processor ticks between tooth events, while in the frequency method uses the number of tooth events between a fixed number of processor ticks. If you were to measure in the frequency domain at say 4000rpm (lowest reasonable critical downshift speed) that equates to 7.6 teeth per 1ms. So you will either measure 7 or 8 so your rpm value will come out as either 3684.21RPM or 4210.52RPM so we are accurate to within +/- 263.16Rpm!

On the stock trigger the ECU does NOT know the position accurately if there is any sort of speed change over a whole 87deg of rotation. That is why the factory ECU for example uses one tooth in particular to trigger cranking ignition at 10deg BTDC, as in cranking the engine is subject to wild speed variations over a cycle, but the ECU knows to fire the ignition at a certain tooth event, not flexible for timing of course but you know it's always going to be accurate. We already have issues with timing scatter at startup on the M800 due to compression ratio and the stock timing pattern.

During normal running all of the trigger deficiencies are not a problem, but we are looking at events where the speed is changing during a single rotation of the engine. HOwever if the M800 could output the CAN as we wanted, then it would be a trivial matter of fitting a 36-1 or 12t crank trigger to ensure better accuracy at the point of measurement. Remember the point of measuring the speed directly is we want to output the RPM in the requested format and speed which the M800 simply cannot do.

An M150 is another solution, and that is something we are looking at.

[Holmz]

The frequency method will not work unless we have many more teeth or sample the teeth over a long time period. They are in effect the same method but in period measurement we are measuring the number of processor ticks between tooth events, while in the frequency method uses the number of tooth events between a fixed number of processor ticks. If you were to measure in the frequency domain at say 4000rpm (lowest reasonable critical downshift speed) that equates to 7.6 teeth per 1ms. So you will either measure 7 or 8 so your rpm value will come out as either 3684.21RPM or 4210.52RPM so we are accurate to within +/- 263.16Rpm!
...

And this is where a mathematician could come in handy.
Let's say you frequency is 4000.
Q> Which FFT bin does that show up in?
A> All of them... Some are many dB down depending on the windowing function you chose to use.

Let's say it is in the 4210.52 bin.
Now ignor the amplitude and look at the phase in that bin.
And wait (the tiniest amount of time, like a mS)...
And quickly look at the phase again.
how many degrees has it moved?
The d/dt of the phase is the frequency.

...
On the stock trigger the ECU does NOT know the position accurately if there is any sort of speed change over a whole 87deg of rotation. That is why the factory ECU for example uses one tooth in particular to trigger cranking ignition at 10deg BTDC, as in cranking the engine is subject to wild speed variations over a cycle, but the ECU knows to fire the ignition at a certain tooth event, not flexible for timing of course but you know it's always going to be accurate. We already have issues with timing scatter at startup on the M800 due to compression ratio and the stock timing pattern.
...

I am not sure I agree, but I do agree that even at a constant RPM the phase is wavering on most engines such that there is not a frequency but a beehive of speeds around the main frequency (RPM).

...

During normal running all of the trigger deficiencies are not a problem, but we are looking at events where the speed is changing during a single rotation of the engine. However if the M800 could output the CAN as we wanted, then it would be a trivial matter of fitting a 36-1 or 12t crank trigger to ensure better accuracy at the point of measurement. Remember the point of measuring the speed directly is we want to output the RPM in the requested format and speed which the M800 simply cannot do.
...

I having recorded crank pickups and precessed them.
But I have not done that and compared the data with an M800 PRM and RPM-derivative.
If you can do a recording then it should be straight forward to work out if it is will work or not.
I think you would be surprised, and then you would know definitively the answer.
Or you can trust me that you can see the torsional vibrations of the crankshaft, which are significantly smaller (in phase) than whirling RPM rate.

What you do is to run the crank signal into a relatively high impedance resister and into one channel or the other of a lap-top or PC. Is you also get the cam signal that is generally helpful. Run the cam into the other channel.

I think I used a 10k resistor soldered to a 1k to ground to effect a divide by 10.
...and I had 50-60dB of SNR, when comparing the engine off signal with the engine running at the fundamental frequency.
At 6000 RPM you have 100RPS, and with 36teeth you have 3600 teeth/second.lets say you use 10 of those teeth to account for the missing ones. And the FFTs can be overlapped.

It would get difficult if you did not know the math or have the tools, but it is easy to find those sorts in todays world... Once you have the data captured then you could do both approaches and validate the concept.
I happen to know a good mathematician.

You could also simulate the crank signal and do the whole thing as a simulation, and you can add in noise and jitter.
In fact if you did that and presented the M800 with those signals you could test how well the M800's RPM and derivative worked, because you knew the answers a-priori !

You will need to have that understanding at some point, so why get the M150 before you've worked it out?

[Pavlo]

Using the FFT for measuring the flywheel teeth (114 per revolution) sounds interesting, my only experience with FFT is just using them to measure loudspeaker response and analysing some knock recordings to measure knock frequency. Trying to do something to code an FFT measurement in a small processor is not trivial, but the biggest issue is type of measurement we can do of the square way input, we have to count something, against something else. All we can do is count processor ticks between edges, or edges between processor ticks.

So how do you measure RPM accurate using FFT on 7 teeth, and then 8 teeth and work out the answer was 4000rpm? Remembering that we can't present our code with the timings of the 7 or 8 events? Only that in our window time, we have a certain number of events? Remember that we are trying to code this in a relatively simple way, and not go around the houses to reinvent the wheel.

How accurate will your RPM and position measurement be with one tooth per revolution? Lets assume we have our RPM (6k), and RPMdt and we know everything, but as soon as we know that, the power is cut and we get no more crank events until 10ms later ar (actually a little sooner or later depending on the RPMdt at the time). In fact lets assume that the RPM was 6000rpm, and the rpm was 1000rpm/sec, 10ms later the RPM would be only 6010rpm if we use RPMdt, and we could perhaps even use RPMdt^2 and lets assume that was -300rpm/sec^2 (acceleration rate reducing) we can now use a closer estimate of 6008.5rpm.

Except 10ms later, rather than the RPM being 6008.5, it's actually 5900rpm because at the same time we got our last sample, the power was cut and the engine started to slow much faster than it was accelerating. When the ECU sees that next tooth, it's come around slow that expected based on the predicted speed for that revolution, if decides the speed was 5954rpm for example (assume slowed at 10000rpm/sec) So at one point it was 108.5rpm out, then 54rpm, and then the rate would be reported at -5000rpm/second which out by a factor 2, making subsequent RPM measurements spurious, the next cycle would be

RPMdt = -5000
dt^2 = -4700
RPM = 5879

So now the error is reducing, but still out, however we got an RPM measurement 20ms later than we wanted.

That is worst cast with 1 tooth per cycle, but at 4000rpm, those errors would increase in the extra time between teeth. So say we had 4 teeth, those errors would be reduced, on tooth for each cylinder somewhere close to the crank angles of interest for the purposes of ignition timing, much like an EVO, say at 45deg BDTC, the errors would be in the same ballpark as our 6 uneven teeth.

As I have said, this is not a case of looking at RPM in a generally stable system, it's a case of looking at it when you are trying to rapidly change the speed of the engine and get the fastest feedback possibly to know that what you have done (cut, blip or combination of the two).

However in other news, we have the thing working using just the ADL3 to send/receive the things we need to pretty much make it work, speed comes next, how important is 1ms RPM updates in the real world, I will find out.

As an aside, just looking at fft, I wouldn't be confident of it working for a square wave (well square with some rise and fall time/slope), and window time would be longer than 1ms that's for sure. Also, if the M800 could do this kind of work, every ms, or even every 10ms then I would like to see FFT carried out on our knock input to properly do something with it!

[Holmz]

Unless I do the work for you, I am at the end of the suggestions.
There is a big difference between looking at a PSD and knowing what one can do with frequency domain analysis.

I would still recommend a simulation, and you could put those signals into the M800 and know for sure rather than make suppositions or guess.

If you have a hall sensor then maybe you are better off using time domain.

Good luck

[Pavlo]

I don't think you understand what we are capturing. We are don't have a load of samples and a wave form like we might in the full ECU, we are not using a VR sensor and sampling it at 25mhz or something so we have a sample window to analyse. We are using a hall sensor as it can be hooked up directly to the processor board we are using, and it's going into a GPIO input, within the processor we will only see edges as on/off status.

But the problem is solved now anyway.

[Holmz]

I don't think you understand what we are capturing.
...

Pavlo - My suggestion was to synthetically generate a crank signal.
That can vary in RPM, and it should, which will need it to do.

Then play back that signal into the ECU's CRIP (and CAM inputs) and log the RPM and derivative in the ECU.
You can also use that same signal and present that into your other "1-ms" box.
Then you can determine how well both the ECU and your box determine the RPM and derivative (for the ECU), and the RPM for your 1-ms box.

Then you will know how well both work, against an engine which you know exactly what the RPM is and how it was varying.

Generating that signal file is relatively easy to do, whether it appear like a magnetic sensor, or a hall sensor.
If you are doing the hall then you may want to dither the time a bit.
If you are doing the magnetic sensor you can also add (amplitude) noise.
I would probably digitise a current ECU/CRIP signal and have that as amplitude every degree. The compute the crank's position every sample (44.1 kHz), and interpolate between the digitised sample points and output the data to a .wav file.
The you hook up the iPod, or whatever, to output the signal out of the ear piece port into the ECU's CRIP connector.

The ECU does not know if there is an engine or a iPod at the end of the connector... So it will tell the RPM of he engine.
Your 1-ms box also is just looking at a signal, which it roo assumes is an engine.
So you have just replaced the engine with an iPod.

I should probably make an iPod/iPhone app for this. It would make it easy to ensure that the ECU is set up.
And the ECUs do have a simulation mode for making sure that the injectors and coils are working, so it is not like it is a new approach.