SMG CAN Bus Decoding

[S54B32]

Thank you!



Well, there is no "general formula" for calculating the checksum, every manufacturer does it somehow differently. The checksum also does not exist in every message.

With the E65 (for example) the checksum (at least in the PT_CAN) is calculated over the whole message by adding the single bytes to each other, then adding with overflow and so on. The checksum is 8bit long.

This is the most common version of a checksum. Also often used in Kline or KWP communication, before trying anything else (only if the checksum is always the same of the message repeats, so no alive counter), try this.

[Tomba]

Thank you!



Well, there is no "general formula" for calculating the checksum, every manufacturer does it somehow differently. The checksum also does not exist in every message.

With the E65 (for example) the checksum (at least in the PT_CAN) is calculated over the whole message by adding the single bytes to each other, then adding with overflow and so on. The checksum is 8bit long.

Do you have some info on the PT_CAN bus checksum? How did you find it out?

[HeinrichG_V12]

Thank you!

I suppose there are many other calculations manufacturers can choose for this checksum.

Well, there is no "general formula" for calculating the checksum, every manufacturer does it somehow differently. The checksum also does not exist in every message.

With the E65 (for example) the checksum (at least in the PT_CAN) is calculated over the whole message by adding the single bytes to each other, then adding with overflow and so on. The checksum is 8bit long.

[Tomba]

Nice job you all are doing here!
I have been in to CAN-BUS for a while and stumbled over that specific checksum byte/nibble in many messages from various ECUs my self. Nice job you have found it. 💪
I suppose there are many other calculations manufacturers can choose for this checksum.

[HeinrichG_V12]

Hi guys,

I've got it

First of all, the description of Byte3 on www.ms4x.net is not absolutely correct... As I said before, there are two signals with 4 bits each in here.

That means:

Byte3:

• ALIVE_COUNTER[0 - 3]
• GEAR_INFO_CHECKSUM[4 - 7]

There are two posibilities to set (and to calculate) checksum:

• Nibble by Nibble:
  • Set the ALIVE_COUNTER signal in Byte3 (lower nibble)
  • calculate and set CHECKSUM signal in Byte3 (higher nibble)
• whole byte:
  • put GEAR_INFO and ALIVE_COUNTER into calculation function and set the whole Byte3 at once.

I prefer the "whole byte" methode and here is the code for it:

int calculateChecksum(int l_gear_info, int l_alive_counter)
{
  tmp1 = (l_alive_counter ^ l_gear_info);
  tmp2 = ~(tmp1);
  tmp3 = (tmp2 & 0x0f);
  tmp4 = (tmp3 << 4);
 
  // here says www.ms4x.net: CHKSM_GEAR_INFO = Or CHKSM_GEAR_INFO , GEAR_INFO
  // and it is wrong, because we don't have the counter value in Byte3.
  // the correct value is:
  tmp5 = (tmp4 | l_alive_counter);

  return tmp5;
}​

The variable tmp5 contains both signals, ALIVE_COUNTER and CHECKSUM.

[HeinrichG_V12]

It's the same like on www.ms4x.net just as Excel

[eacmen]

I will share. Maybe helpful for you!

Wow where did you get this info? I need to add more PIDs to my logger now!

[nickpiper12]

Got it. I only needed such info so my AIM dash could pick up gear and drivelogic.

[HeinrichG_V12]

Ist pretty similar to my message:


Your Byte3 isn't right, here you have two signals:

• COUNTER ( 0x00 to 0xF)
• CHECKSUM (COUNTER and DISP_INFO)

with 4 bits each. But the order is unknow. I thing lower nibble COUNTER and upper nibble is CHECKSUM, but we will see

[nickpiper12]

I will share. Maybe helpful for you!

[HeinrichG_V12]

Okay, so I'll look forward to calcule CHECKSUM and send them together with the rest of message.
I'll be in touch

[S54B32]

It‘s just a text document with logged canbus values.

you need to calculate CRC! And CRC includes the counter, so if the cluster assume let’s say at least 2 valid (CRC and data is ok) messages before display anything, I doubt you will get it working. But this is just guessing.

[HeinrichG_V12]

take a look at Byte3 and the Counter variable. I think you start at 0 and increase every time you send the message, to calculate the CRC.

At the moment I'm just increment counter signal, without calculation CRC. (I forgot how to do this in CANoe).

But if I send always the same message (yours) it should be okay, as long as I do not change any data in the message.

But I’m not sure if you gearbox controller is able to do this.

After the message definition on mx4x.net he does.

But: I' not using a gearbox controller, but CAN hardware (Vector CANCardXL) with Vector CANoe for the rest bus simulation.

Edit: take a look at post #14, I uploaded there a short log file

Which format is the logfile?

[S54B32]

Didn‘t remember, they where recorded some time ago, when I reverse engineered that message, before this info from robin was published on his page.

take a look at Byte3 and the Counter variable. I think you start at 0 and increase every time you send the message, to calculate the CRC. But I’m not sure if you gearbox controller is able to do this.

Edit: take a look at post #14, I uploaded there a short log file

[HeinrichG_V12]

Hello S54B32

Thank you for the both messages. Are these two messages consecutive or were there messages sent in between?

I've tested the two messages, no gear indicator to be seen.