First CAN mapping, please help !

onthebeach7350 · Post by **onthebeach7350** » Thu Aug 17, 2017 6:14 am

Hello,

I plan to do the first CAN mappings and have some issues in converting the doc from the manufacturer to the RCP MK3 parameters.

I attach 2 pictures of the manufacturer documentation.
Can anyone help me on how to convert this info to the RCP parameters, specially the 4 yellow lines?

They mention the Motorola byte order, what is that?

On the second picture, it is written MSB and LSB at the end of the channel name.
I guess it has to be related to the endian mode?

Thanks for you help !

onthebeach7350 · Post by **onthebeach7350** » Thu Aug 17, 2017 6:14 am

2nd picture

onthebeach7350 · Post by **onthebeach7350** » Mon Aug 21, 2017 7:52 pm

Can anyone point me in the right direction please ?

kijones · Post by **kijones** » Mon Aug 21, 2017 9:09 pm

So first you will need to convert that CANID from hex decimal to get the value you will need.

0x508 = 1228
0x50C = 1292
0x66E = 1646

Then you will want to select the "bit Mode" box
Startbit = offset
Lenghth = length
Select signed or unsigned based on the table
Edian = Big (this is what the motorola/MSB format means)

Scale offset will be what you multiply the value by
offset after that will be if you need to +/- in that data equation.

Good luck!

onthebeach7350 · Post by **onthebeach7350** » Tue Aug 22, 2017 6:53 pm

Thanks for your reply kijones.

I was not converting the CANDId, there my mistake.

One additional question: on my second picture, There is the SOFTWARE VERSION NAME parameter which is listed twice. One with MSB at the end and the second with LSB.
Does MSB means BIG endian as you write and LSB SMALL endian ? If this is the case, do you know why it is also written Motorola for the byte order for the second one (LSB)?

Regards

kijones · Post by **kijones** » Tue Aug 22, 2017 8:14 pm

MSB vs LSB
Most Significant Byte vs Least Significant Byte

Just determines what the first byte of the data is starting with, like reading right to left vs left to right.

It looks like the two channels that you have highlighted in the second pic are the exact same thing, just broadcast in a different patters. I'm guessing they did that so that if your setup was only able to read data in MSB or LSB that you could still get the reading. But you do not need both of them

Motorola format is Big Endian or MSB, unless otherwise noted most of the time. Again, i'm guessing, that is why they specifically called out MSB and LSB for those channels.

onthebeach7350 · Post by **onthebeach7350** » Tue Aug 22, 2017 8:27 pm

Clear, thanks!

kijones · Post by **kijones** » Tue Aug 22, 2017 8:33 pm

No Problem!

Good luck!

onthebeach7350 · Post by **onthebeach7350** » Sun Aug 27, 2017 4:55 pm

Hello,

This first CAN mapping is definitely not an easy one for me !

I setup 2 channels as follow:

Oil temp
Cannel 0x518 -> can Id 1304
Bit mode
Start bit 24
Length: 16
Type: Unsigned
Big Endian
Formula: value X 1 / 1 + 0

I houd get 25 as the temps is 25°C
In the data, I get the value of 6400

Coolant
Cannel 0x600 -> can Id 1536
Bit mode
Start bit 8
Length: 16
Type: Unsigned
Big Endian
Formula: value X 0.1 / 1 + 0

I houd get 25 as the temps is 25°C
In the data, I get the value of 6553,5

Where is my mistake????

kijones · Post by **kijones** » Mon Aug 28, 2017 7:20 pm

Have you checked to make sure you are using a refresh rate that matches?

onthebeach7350 · Post by **onthebeach7350** » Tue Aug 29, 2017 5:24 am

Yes I did but the value remains the same no matter which refresh rate I select...

dewittpayne · Post by **dewittpayne** » Tue Aug 29, 2017 2:03 pm

It looks to me like the scale factors are off and there's an offset. Change the scale factors from 1 to 0.01 and from 0.1 to 0.001 and subtract 40. That will get you to 25 degrees. Then see if the temperature changes correctly. A 40 degree offset is normal for temperature readings.

MikeD · Post by **MikeD** » Tue Aug 29, 2017 9:04 pm

problem solved... for the benefit of the audience the decoding issue was resolved via mail support and here is the explanation as follows:

If you look at the CAN description you may observe that none of the parameters of a new CAN ID start at bit 0 but most start at bit 8, which should be an indication for how this CAN documentation should be interpreted...

Let's take coolant temp as an example:
The CAN document for this specific setup tells us that when a parameter is described with bit 8 as a starting bit then in fact it means bit 8 -> bit 15 is the low byte and bit 0 -> bit 7 is the high byte of a 16 bit message (and with respect to motorola byte order i.e. BigEndian)

BUT within the RaceCapture CAN mapping you would need to assign the starting bit as bit 0 in this same situation (and a length of 16 bit
which means the first two bytes of the CAN frame) instead of bit 8 as the start bit...

Received feedback from "onthebeach7350" that CAN decoding now works as intended...