Honda Insight Forum banner

1 - 20 of 32 Posts

·
Administrator
Joined
·
12,625 Posts
Discussion Starter #1
The attached txt CAN data file is from yet another IMA project and
has what appears to be a rotating checksum (D8 byte) at the end of the 8 byte packet.

This changes by $0F each time even if the data in the packet is static,
and then it resets and repeats every 4th packet ad infinitum.

Any ideas how it is being calculated from the data in the packets and possibly the CAN ID as well $115 in this case?

The D8 byte never reaches $40 so it looks like the top 2 bits are being masked off to give $3F max or %111111.

So it is always 0,1,2 or 3 in order..

Any ideas? :unsure:
 

Attachments

·
Registered
insight 2006
Joined
·
19 Posts
I
Ijust find the solution for the checksum start by 2.
just adition each byte and invert all bits of the solution
ex:
RD11 44.1678 115 22 FF F3 00 00 41 10 25
in hex 2 + 2 + F +F +F +3 + 0+ 0 + 0 + 0 + 4 +1 +1 +0 = 3A OR 0011 1010
ignore the 3 and invert 1010 = 0101 value is 5 (the 5 of the 25)
i made many test and it like to always work for the cheksumm start by 2

i am searching the solution for others, hope finding soon ;+)
 

·
Registered
Joined
·
924 Posts
What is this for and what system is generating the messages?
 

·
Registered
insight 2006
Joined
·
19 Posts
for the checksum start by 1
just adition each byte minus 1 and invert all bits of the solution
ex:
RD11 44.5178 115 22 FF EC 00 00 41 10 1E
in hex 2 + 2 + F +F +E + C+ 0 + 0 + 0 + +0 + 4 +1 +1 +0 = 42 or 0100 0010
42-1= 41 or 0100 0001
ignore the 4 it made 0001 and invert it : 1110 or E
i made many test and it like to always work for the cheksumm start by 1
 

·
Registered
insight 2006
Joined
·
19 Posts
for the checksum start by 3
just adition each byte + 1 and invert all bits of the solution
ex:
RD11 44.5378 115 22 FF EC 00 00 41 10 3C
in hex 2 + 2 + F +F +E + C+ 0 + 0 + 0 + +0 + 4 +1 +1 +0 = 42 or 0100 0010
42+1= 43 or 0100 0011
ignore the 4 it made 0011 and invert it : 1100 or C
i made many test and it like to always work for the cheksumm start by 3
 

·
Registered
insight 2006
Joined
·
19 Posts
for the checksum start by 0
just adition each byte -2 and invert all bits of the solution
ex:
RD11 44.5078 115 22 FF EC 00 00 41 10 0F
in hex 2 + 2 + F +F +E + C+ 0 + 0 + 0 + +0 + 4 +1 +1 +0 = 42 or 0100 0010
42-2= 40 or 0100 0000
ignore the 4 it made 0000 and invert it : 1111 or F
i made many test and it like to always work for the cheksumm start by 0

I hope that willl be helpful retepsnikrep
 

·
Administrator
Joined
·
12,625 Posts

·
Administrator
Joined
·
12,625 Posts
Discussion Starter #8
I've been testing this and it seems to work. Thanks.

Now onto a numerical pattern finding test.. ;)

You will see in the Excel spreadsheet data attached (rename from pdf to xls) I have highlighted the 115h packets amongst the routine IMACAN data flow.

Is/are there a consistent pattern of packets before the 115h packet?

(There may well be several different preceding sequences.) Can you/we identify them all?

If we can find all the sequences I can search/wait for them and then hopefully substitute alternate 115h data in the right place for my CR-Z project.
 

Attachments

·
Registered
insight 2006
Joined
·
19 Posts
It is hard to find sequence, when I think I found something, I see that earlier or later the sequence change...
so My first impression is some ID come after a certain period and probably all ID don't have the same period
may be some come after certain event like when the cylinder 1 is at top dead center?

personally my biggest interrogation is why on the ID 115H there is 4 way to do the checksum. Is it relative to each motor cylinder ? Do you know what each ID data contain ?

not shure, but if you send annother file with all ID data and time we can find something in that
 

·
Administrator
Joined
·
12,625 Posts
Discussion Starter #10
The bus data ECM <> PCM flow appears to be like this...

ECM is the ECU at the front.
PCM is the IMA in the back.

111 From PCM (Probably 'Hi i'm awake in the back awaiting instructions')
115 From ECM (This is the prime suspect for the IMA control data packet!)
141 From PCM
169 From PCM
179 From PCM
17D From ECM
(This is a second suspect for the IMA control data packet!)

231 From PCM This is a 7 byte packet that contains the current SOC reading to two decimal places in bytes (2,3). i.e. 1D 4C = 7500 = 75.00%
24F From ECM
261 From PCM

307 From PCM
This is a 5 byte packet containing the current SOC reading to two decimal places in bytes (2,3). i.e. 1D 4C = 7500 = 75.00%
318 From ECM

The '1' series appear every 10ms so logically are probably the most important.

Lower ID's have a higher priority, so '111' is the overall CAN bus race winner.
It is also the only '1' series packet with 7 bytes of data, the others have 8.

The '2' series appear every 40ms and the '3' series every 100ms.

Looking at ID 115 from the ECM and some captured data showing assist/regen in a working car, we can see values changing that look like they may be relevant.
There are some flag bits in the data which need masking out, but we seem to be getting towards sensible values as assist/regen rise fall.
 

·
Registered
Joined
·
924 Posts
Does the CR-Z use lithium packs and are they configured similar to the Fit (balancing boards on each block that are commanded by another ECU?) ie, are you seeing battery voltages reported from the CR-Z lithium blocks via CAN message similarly to how the LTO packs do?
 

·
Registered
Joined
·
540 Posts
  • Like
Reactions: retepsnikrep

·
Registered
Joined
·
540 Posts
Okay...
The patterns are not steady. They change as you move thru the dataset. Each place (1st, 2nd,3rd) in the number the changes in its own way. For instance... Early in the sequence the first-place number looks like this:
89293


By the end of the sequence, it's this:
89294


The difference is obvious.

There are also transition points where it changes beween one type of pattern and another:
89296


Each place in the number has its own, unique pattern(s) and (I think) transistion point(s). Having said all of that, it appears as if the data is recording shifting "states of being" of whatever it it that you're measuring. Does that make sense?

Given some time (days, not weeks), I can probably work out these patterns and their points of transition. I'm willing to spend the time. Would you like me to give it a try?
 

Attachments

·
Registered
insight 2006
Joined
·
19 Posts
So for the timing you already find what I was think to search... The first sequence that I can see is
111 - 141 - 169 - 179 by the PCM and sometime the ECM cut the transition to say 115.
I continue to think there is a reason why in the 115 there are 4 kinds of checksum. Maybe with a file containing ID and data we can find a sens for that.
 

·
Administrator
Joined
·
12,625 Posts
Discussion Starter #17
I appreciate the effort and don't want you to waste your time..

If you want a file to look at with data here is a Google Spreadsheet of the entire CR-Z IMACAN BUS traffic for about 30 seconds from turn on.

IMACAN ALL IDS 190221
 

·
Registered
insight 2006
Joined
·
19 Posts
Maybe I am obsessed with that but, adding different checksum, must have a reason, It's more calcul and code for each processor, generally we try to optimize during coding. So if I was at Honda design table and I saw that some people "
play" whit my IMA system, maybe I would find a way to make that little more hard by adding a sequence in the IMA checksum. I think the 115 ID must be study bit by bit.
Maybe It will be more dificult if you want to switch online from ManualIMA to AutomaticIMA
Dont worry I like to search thing like that (for me is a funy game)
 

·
Registered
Joined
·
540 Posts
The 30-second data is the same way, the patterns they display are definite, but change over time. Some more than others.
 
  • Like
Reactions: retepsnikrep

·
Administrator
Joined
·
12,625 Posts
Discussion Starter #20 (Edited)
I think I am going to build a man in the middle device to try and control the packets..

We split the IMACAN bus and end up with a man in the middle configuration like this..

ECM >>>>>>>> PIC Device1 >>>>>>> PCM

Device 1 is the Master and deals with only the 115, 17D, 24F, 318 packets from the ECM forwarding them to the PCM (IMA).
This includes our suspect 115h IMA control packet!
(Only four packets to deal with now, and in one direction only) Much more cpu time to do stuff.
And we can directly replace 115h packets without BUS collisions, sequences and switching issues.

PCM >>>>>>>>>> PIC Device2 >>>>>>> ECM

Device 2 is the slave and deals with the 111,141,169,179, 261 307 packets from the PCM (IMA) forwarding them unmolested to the ECM.

Devices 1 and 2 can be connected together with a fast SPI bus incase we need to interact, but that may not be required.

I already have a half built prototype. ;)

89297
 
1 - 20 of 32 Posts
Top