CAN Module read vehicle RPM with ECU toolkit

[sfrosty]

Is it possible to read a vehicle's RPM values using a NI-9862 cDAQ CAN Module with the ECU Measurement Toolkit?

[JefeL]

Yes it is possible but with caveats. You would need the A2L descriptor file from the ECU manufacturer and some low level knowledge of the vehicle design. Engineers typically use ECUMC to do low level testing and programming of the ECU directly and not in-vehicle.

Diagnostic information such as RPM values are easily retrieved from production vehicles using one of the standardized diagnostic protocols with the Automotive Diagnostic Command Set (ADCS) instead of using ECUMC.

[sfrosty]

Thank You!

I chose rpm or engine speed to be sure of its' availability, there are numerous parameters I need to access that are only available from the ECU. Can someone direct me to a department within an automotive company that would be able to provide me with the parameters I have listed below. Our Engine calibration department doesn't appear to have this lower level information.

CRO ID CAN identifier of the Command Receive Object (CRO) (example:119d)

Data Transfer Object A message sent from the slave device to the master device (Command
Return Message, Event Message, or Data Acquisition Message).

DTO ID CAN identifier of the DTO. (example:23d)

Station Address (example:81d)
A property which specifies an address to generate a logical point-to-point
connection with a selected slave station for the master-slave command
protocol. One ECU may support several station addresses

SeedKey DLL
A Dynamic Link Library that implements a function to calculate a key to a
given seed to unlock access to ECU resources.

[Hooovahh · Accepted solution]

Who makes your ECU?  They likely won't share this information with you but you can talk to them.   The Seed/Key is probably the thing most protected, but a large majority of the parameters can be read (and a couple written) without it.  Find the group that write the software for your ECU and they will have the information you need.  They just likely won't share it.  These parameters are extremely hardware specific, and there is no one answer.  You will want to find a one or more of these files .DBC, .CDD, .A2L, or .ELF, which describe how to talk to the ECU using various protocols. 

[Minions]

Additionally, you will need to know if the information is being presented as Big or little endian.  Do you happen to know the Baud rate and BTR values?  All of this information should be present within the file extensions that Hooovahh mentioned.  Also, a .MAP file might also be benefit.

[sfrosty]

I wasn't successful to date with getting the information necessary to utilize the NI ECU toolkit to read data from the ECU. What I was able to do was read CAN data transmitted from a Intrepid NEO VI CAN device that is reading data from the vehicle ECU and sending it out its' CAN port. Now my question is in how to covert the CAN data to engineering values.

The transmitted data is in 4 byte lil endian decimal. The signal is engine RPM. I've tried my best but haven't been able to reverse engineer. A screen shot of the data is attached. the 10^3 bit switches from a 68 to a 69 at about 2K RPM. 10^0, 10^1, and 10^2 appear to fluctuate between 0 and 255. I've added the individual data bytes and added 255 to the data when 10^3 switches from 68 to 69 with no definitive results.

[Hooovahh]

Are you sure that only the RPM data is encoded in this frame?  4 bytes of data represents 4,294,967,296 unique values.  If your RPM range is something like 0-10,000 then that means values can change from 0 RPM to 0.0000023 RPM.  That seems like a very, very small amount of change that can be detected.

You could have a random bit in the middle that just means "The Signal Is Valid" and that might always be a 1.  Or you might have a couple of bits in the middle stating "The State of the ECU is X" where X is some set of values.  And other things may change with RPM.  What if at 2K RPM the engine said it is warm, by setting some bit in that frame?  Well now that will also change with the RPM and not just some decimal scaling value.

All I'm getting at is it is up to the manufacturer on how to pack what bits in to this frame that they want.  Trying to reverse this is possible, if you have a set of known values.  Like at 1,000.00 RPM the payload is this, at 2,000.00 RPM the payload is this, and at 3,000.00 RPM the payload is this.  Then looking at what bits changed and by how much.

You also have yet to mention what this ECU is for, and who makes it.

[sfrosty]

Attached is the XNET file, it's the only info I was given. The data is from the ECU of an American vehicle - best I can do.

---

@Hooovahh wrote:

Are you sure that only the RPM data is encoded in this frame?  4 bytes of data represents 4,294,967,296 unique values.  If your RPM range is something like 0-10,000 then that means values can change from 0 RPM to 0.0000023 RPM.  That seems like a very, very small amount of change that can be detected.

You could have a random bit in the middle that just means "The Signal Is Valid" and that might always be a 1.  Or you might have a couple of bits in the middle stating "The State of the ECU is X" where X is some set of values.  And other things may change with RPM.  What if at 2K RPM the engine said it is warm, by setting some bit in that frame?  Well now that will also change with the RPM and not just some decimal scaling value.

All I'm getting at is it is up to the manufacturer on how to pack what bits in to this frame that they want.  Trying to reverse this is possible, if you have a set of known values.  Like at 1,000.00 RPM the payload is this, at 2,000.00 RPM the payload is this, and at 3,000.00 RPM the payload is this.  Then looking at what bits changed and by how much.

You also have yet to mention what this ECU is for, and who makes it.

---

[Hooovahh]

Either that database information is incorrect, or your RPM is 198,645,060 from your last message.  Or 1,142,281,995 if the endieness is backwards.

[JGruenberg]

Off chance it's not a linear scaled number and is a IEEE 754 floating point (which I've never seen on an automotive network), you'd get 599.36 which seems not implausible.