Page 1 of 1
First CAN mapping, please help !
Posted: Thu Aug 17, 2017 6:14 am
by onthebeach7350
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 !
Posted: Thu Aug 17, 2017 6:14 am
by onthebeach7350
2nd picture
Posted: Mon Aug 21, 2017 7:52 pm
by onthebeach7350
Can anyone point me in the right direction please ?
Posted: Mon Aug 21, 2017 9:09 pm
by kijones
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!
Posted: Tue Aug 22, 2017 6:53 pm
by onthebeach7350
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
Posted: Tue Aug 22, 2017 8:14 pm
by kijones
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.
Posted: Tue Aug 22, 2017 8:27 pm
by onthebeach7350
Clear, thanks!
Posted: Tue Aug 22, 2017 8:33 pm
by kijones
No Problem!
Good luck!
Posted: Sun Aug 27, 2017 4:55 pm
by onthebeach7350
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????
Posted: Mon Aug 28, 2017 7:20 pm
by kijones
Have you checked to make sure you are using a refresh rate that matches?
Posted: Tue Aug 29, 2017 5:24 am
by onthebeach7350
Yes I did but the value remains the same no matter which refresh rate I select...
Posted: Tue Aug 29, 2017 2:03 pm
by dewittpayne
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.
Posted: Tue Aug 29, 2017 9:04 pm
by MikeD
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...