Fast CAN in and out of M800

[Pavlo]

I have a need to get Engine RPM out of the M800 at 1khz. I am just about to implement an external crank measurement that will export the info on it's own CAN transceiver, but I have a few questions nonetheless.

Using can slot 0 with Custom dataset 1 gets me to 200hz. But what happens if I send it multiple times? For example:

Base address 512h

RPM
Data
Data
Data
RPM
Data
Data
Data

Will that send out RPM at 400hz or will it be sent twice in quick succession (say less than 1ms apart) at 200hz? Will it just send the same RPM value as sampled at the time the CAN frames were formed?

Just to complicate maters I need to send the RPM on 4 frames that are not sequential.

I will also be sending general data out on can slot 1 with custom dataset 2, probably using a CRC32 packet.

What is the maximum input speed for sampling an ADL input, I am also looking to input a cut request and blip request as part of gearbox control.

Is the can info sent in a burst with a longer cap between?

Much of this will become clearer once my CAN analyser arrives I suppose. But currently I am thinking that to do what i need I will need to translate measured RPM and combine with other data into the fast frames I want to sent, and then receive the incoming data into the same box and output the cut and blip request on physical pins into digital or AT pins on the M800.

Cheers

Paul

[Holmz]

I thought that the CAN sends only when the bus is clear(?) and based upon a priority scheme.
If that is true, then the rate may fluctuate depending on what is happening on the CAN bus.

It must be some fast shifting to require 1mS resolution... combined with a really light flywheel?

If there was also RPM rate, or derivative, then that might allow for you get to the same place using some maths... and just interpolate the current RPM as the last RPM + (RPM-rate * dTime).
But I have no idea if the derivative is accessible.
It should be more precise even at 100-Hz CAN rate if it is possible - and you will probably need to know the rate to make the shifting optimal.
So could you measure the rate as a function of RPM and use a table based upon the measured RPM derivative??

[Pavlo]

The shift actuation is very fast, but because it's so fast it has to be precisely timed in a window that ensures that it will happen cleanly, rather than load it up then wait for shift to happen. For this reason the gear controller wants speed updates as fast as 1ms. It might not get it all the time, and ideally this will all happen on a dedicated bus so clashes are much less of a problem.

[Holmz]

I cannot see how to change the RPM logging rate or the CAN rate for RPM in the ECU manager, however there is an output for RPM rate of change.
So it should be possible to get the data out with RPM and rate of change and then output the computed RPM onto a different CAN bus for the GCU.
(Maybe with an Arduino in the middle, using a CAN(in) and CAN(out) ?)

[Pavlo]

We are using a small can transceiver box with some on board processing and measuring the engine speed at the flywheel to put the speed on the canbus. It will also output engine cut and blip requests directly into the M800 pins. The problem is the target black box is not flexible with it's CAN setup, otherwise yes we could use the M800 to generate the RPM rate for the black box to use.

However there is another problem in that with the current crank trigger setup we might have to wait as long as 2.6ms between crank teeth at 6000rpm, so even the M800 will not know the engine speed as fast as required.

[Holmz]

We are using a small can transceiver box with some on board processing and measuring the engine speed at the flywheel to put the speed on the canbus. It will also output engine cut and blip requests directly into the M800 pins. The problem is the target black box is not flexible with it's CAN setup, otherwise yes we could use the M800 to generate the RPM rate for the black box to use.

However there is another problem in that with the current crank trigger setup we might have to wait as long as 2.6ms between crank teeth at 6000rpm, so even the M800 will not know the engine speed as fast as required.

I don't think that you comprehended what I wrote.
If you know the current RPM and the current RPM derivative (RPM rate of change), then you know the RPM at any other time of the 2nd derivative is zero.
example if the RPM is 6000 and the rate of change is -1000 RPM/second, then in a second from now it will be 5000RPM.

Yesterday I saw that I can request a RPM rate of 200Hz but not 255Hz.
I also set the M800 to output RPM Rate of change to 200Hz.
So every 5 mS you would get both.

6000 RPM is 100 Rot/Sec or 100-Hz.
So you would see the SYNC every 20 ms, and the if you had a 1 tooth ref then every 10mS.
If you had 30 teeth, then 0.3mS between teeth.

[Pavlo]

The problem comes as we are looking at that speed in a situation where it is going to change rapidly, so it may or may not be accurate enough in all instances.

First of all the current setup uses an OEM pattern with a maximum of 87deg between ref teeth. At 9000rpm that is 1.66ms, but at 6000rpm is 2.66ms between updates, and even if you do get an update the M800 will only calculate the average speed. So not only will it not know the RPM but it will also not know the RPMdt for that time too and even when it does get those numbers, they will not necessarily be accurate. But I do understand that by knowing RPM and RPMdt at time = x, you can have a good calculation at time = x+1ms, x+2ms x+3ms x+4ms and then you will get a new up to date RPM and RPMdt on the CANBus. I think with more teeth on the REF trigger this would probably work out not so bad, as we could be very confident of the RPM and RPMdt every 5ms. But I suspect that in the situations where this becomes critical RPMdt may change significantly inside of 5ms, so I'm not so keen on chancing it.

It's really not much effort to mount the extra sensor and the coding time is going to be about the same, and at the end we can be certain of the speed regardless of any trigger wheel limitations (but the trigger wheel will change anyway).

[SportsCarRacer]

I think your bigger problem with so few teeth is how inaccurately your "measured" rpm is changing relative to the natural fluctuations of the rpm due to crank accel/decel each cycle...worse for small flywheel inertias and fewer cylinders.
In the my (the OEM) world, that's why HDR high data rate crank trigger systems are used 36-1 or 60-2, etc. They look at engine acceleration (to detect misfire), and also on DI engines, are used to detect the torque contribution of each cylinder to ensure complete combustion is occuring...
I will tell you categorically now, detecting the rpm rate of change (accel, omega.dot) to detect misfire is a much more "precise" task (at any rpm) than looking at your engine run up/run down due to gearchanges (unless your motor is an AVL drivetrain dyno electric machine, capable of >60,000rpm/sec!!)
At each tooth, the crank mean velocity is calculated from the rolling average of a numbe rof teeth (10-16), and no faster than 30Hz for low-demand calcs.
The instaneous velocity is calculated every tooth (ie: time period since last tooth), and the derivative (accel) calculated as well...the predicted rpm is calcualted for the next tooth expected by the current + RoC(t+1)..the sample rate is still not that ridiculosly fast, as you are using known current info and rate of change to predict the velocity in the next time period....
What people forget is a very valid point made by Holmz..velocity(t) and rate of change (t) are much better "indicators" of the RPM at high rates of change....otherwise, you are always working at the (t-1) point, regardless of your sampling frequency....
Also, you would be better off with a "predictive" engine speed being sent out, as used by every OEM rev limit for the last 10 years, for automated shift control, trans shift, etc.
I think the limitation of your setup for "accurate" velocity info is your tone wheel...if it is a 4 cyl, 80-100 deg BTDC is least rate of change of crank velocity, and near each side TDC/BDC the highest....and it gets very noticeable with decreasing engine inertia. In ~84 deg between teeth, the crank has gone from it minimum velocity to it max.....ie: it has experienced it's greatest acceleration! But, beware, with small tonewheels (<150mm), even 0.1mm (0.004") tooth-to-tooth postional variation makes a significant contribution to "perceived" engine velocity rate of change!!! That's why OE parts are often power met parts, to achieve the high accuracy to do precise acceleration calcs.

[Pavlo]

Which is one reason we are measuring the speed independently of the crank trigger using the 114teeth of the flywheel. The speed will be averaged to remove the effects of inaccurate flywheel teeth although they should be much closer than 0.1mm. The crank trigger will be updated to 36-1 or 60-2 in due course. And then we can work on some sort of solution within the ecu.

Regardless of the best way to do it. People here seem to have missed the point that we didn't design the gear controller so we have to work with the info in a format they want which also includes a "delta rpm" which is rpm rolling average of last 3 rpm readings. It's highly likely that RPMdt is calculated internally but I don't have any control over that side of it.

As has been touched on the current crank trigger system can't be relied on for an accurate RPMdt either, if the engine speed changes rapidly over the last 30deg within our worst case 87deg window the last update with be conservative and we won't have an update for 5ms available on the Motec canbus.

Thus system is widely used in the highest levels of motorsport so I am not going to tell them they need to change their systems to worth with the limitations of the m800 for one install in 500!

[Holmz]

Which is one reason we are measuring the speed independently of the crank trigger using the 114teeth of the flywheel. The speed will be averaged to remove the effects of inaccurate flywheel teeth although they should be much closer than 0.1mm. The crank trigger will be updated to 36-1 or 60-2 in due course. And then we can work on some sort of solution within the ecu.
...

How are you planning on calculating the RPM?
in the time or frequency domain?
and over what timeframe? (per tooth, or per cycle or per x-mS ?


Does the timing mark jump around on the pulley?
If not then the ECU probably has a good idea of the position on the crank.
If the spark timing is also stable when the engine is accelerating and decellerating then the EVU probably know the d/dt RPM.

If the ECU is accurate, then you will have a reference to see what your system says relative to that.