Need to understand Offset and ID Mask please

[FoxSTI]

I am reusing this photos for illustration purposes.


My dash i running off of the ODB2 protocol for now:
When configuring a request we create a message that has and OFFSET of 1, then an IDENTIFIER, and ID MASK.

The dash will throw 010C to the car. I see what depending OFFSET or ID MASK the request will or will not work.
I would like an explanation of that the OFFSET value is during a request and reply message and what the ID MASK is.

I just can't seem to find this information anywhere.
I am clear on what the offset and length are when configuring a channel and how they related to the response received from the car. Correct me if I am wrong but what message with Offset 3 and Lenght 2 will ignore the first 2 bytes of the response and look at the 3rd and 4th (length 2).

It is important that I graps this concept because I plan to start looking at CAN messages to connect my dash that way.

Thanks everyone in advance.

[David Ferguson]

First, be sure to review this webinar:

https://www.youtube.com/watch?v=2m34nQ4i6KQ&hd=1

The Offset is the offset into the 8-bytes of data that a single CAN message can contain. Offset=0, length = 1 is the first byte, and offset=0, length=2 is the first word (2-byte value). Other values can be found (or set if transmitting) at the necessary offset. Since this offset starts at 0, be aware that when someone documents data as being in bytes 1&2, you may need offset 0, length 2 (unless you see the documentation refers to byte zero for a message).

The MASK allows examining only certain bits, this is sometimes needed with messages contain tightly packed fields with less than 8-bit or 16-bit values. It's unlikely you will need to use anything other than FF or FFFF for your Subaru.

Be careful with your ODB-II examples -- they are specific the the way that ODB-II PID's are requested -- see the "Query" and "Response" section of this page for details on that:

https://en.wikipedia.org/wiki/OBD-II_PIDs

[adrian]

Below is a screen grab of some OBD data and a quick explanation of why the dash is setup the way it is. The link David provided goes into much more detail on how the messaging actually works. One of the easiest ways to start reverse engineering CAN data is to log both the OBD messages and the standard vehicle messages together so you can compare them.

OBD Message.png (47.64 KiB) Viewed 28183 times

[FoxSTI]

Adrian, thank you for the reply. I was close but you pointed out some incorrect assumptions.

So by the same token when I'm requesting odb2 info there is offset 1 and a mask. Offset 1 ignores the first byte which (byte 0) which contains the "length" of my request correct?

[FoxSTI]

Can you guys recommend a canbus logher or device tor be able to start looking at this is formation. I know I have along way to go but really want to try and make this happen/learn in the process.

[adrian]

Yes that is correct, in the case of the dash the length parameter is hard coded in the background. If you were transmitting manually using some other device you would have to set this correctly.

In terms of CAN analysis device there are many different ones available, we use CANCapture, CANalyzer, peak CAN and Bus master as well as our own software (you can download this from our website and it works with our UTC device). These devices range from many thousands of dollars to a few hundred.

There are plenty of other options you can find on Ebay as well.

[David Ferguson]

...as well as our own software (you can download this from our website and it works with our UTC device).

Sure would be handy if MoTeC would complete/release the software that allowed the dash firmware to act as a CAN bridge for the CAN Inspector software.

[FoxSTI]

Yes that is correct, in the case of the dash the length parameter is hard coded in the background. If you were transmitting manually using some other device you would have to set this correctly.

In terms of CAN analysis device there are many different ones available, we use CANCapture, CANalyzer, peak CAN and Bus master as well as our own software (you can download this from our website and it works with our UTC device). These devices range from many thousands of dollars to a few hundred.

There are plenty of other options you can find on Ebay as well.

I went here : http://www.motec.com/software/latestreleases/ a
can't seem to find the CAN software, also what is UTC ?

I am really looking to get at least the basics on CAN
RPM, SPEED, WATER TEMP

I don't have thousands.. =(
What do I need to search for? CANBUS analyser ?

[FoxSTI]

I found this:

http://www.phytools.com/PEAK_IPEH_00202 ... 002021.htm

Would this work ?
Would it work w you software?

[David Ferguson]

Carlos -- you really don't need this for your project.

The MoTeC software is "CAN Inspector" is included with the "Utilities V1.12" found at the bottom of the download page. The UTC is the USB-To-CAN adapter that is required to communicate with the CAN bus for older MoTeC Dash (ADL), Hundred-series ECUs (M400/M600/M800), and PDM. The UTC connects to a Deltran/Neutrik connector typiclally in the CAN harness of the vehicle. We have the UTC in stock, $369.

What the CAN Inspector allows you to do is first, determine what CAN messages are found on the bus (this is the CAN address, or CAN Message ID). We already have much of this info for the Subaru CAN bus on this website: https://subdiesel.wordpress.com/ecu-ana ... -messages/

Next, the CAN inspector will also include the actual bytes -- but we can setup a template to capture that and log it in your C125 -- I sent you an example that does just this for a Nissan -- you just need to change the addresses for those templates to be the same as the ones on the webpage listed above.

So, my advice is don't get sidetracked capturing the raw bus information -- let's focus on getting the currently known data from your car and logging it.