Honda CR-Z Hybrid Car Forums banner

1 - 13 of 13 Posts

·
Registered
Joined
·
414 Posts
Discussion Starter #1 (Edited)
IMA Manual Control

IMA Manual Control has been a very desirable function for modders and tweakers with IMA cars ever since they came onto the market 20 years ago.
AFAIK it has only been successfully implemented in two Honda IMA models, the G1 Insight 1999-2006 and the HCH1 Civic Hybrid 2003-2005.

Both of these cars were pre CAN bus and had simpler electronics and were basically easier to hack.

In the G1 Insights case there were a lot of seperate computer modules joined using standard analog pwm type control signals.
In the HCH1 Civic a 10,400 bps serial data stream was used to convey assist control information from the ECM in the front to the MCM in the back.

The CAN cars from the HCH2 Civic 2006 onwards have proven to be a much tougher nut to crack.
The IMA CAN data stream between the ECM in the front and PCM in the back runs at 500,000 bps (500k).
A very fast and constant stream of data is passing back and forth/around the modules.

To gain control over the IMA we have to identify the relevant control packets in the IMA CAN datastream, intercept the packets we want,
modify, block, replace them as appropriate in real time, whilst allowing all the other packets and information through in both directions unmolested.

It's hard! :eek:

Why do it?

Honda's IMA control algorithm is very good but it isn't perfect, and it's a one size fits all middle of the road average driver solution.
Designed for simple operation and reliable results. It takes no heed of driving conditions, terrain or weather and cannot read the road ahead and plan accordingly.

Modders, tweakers, tuners, hypermilers really don't want tying into a stodgy setup, but with the IMA we have been pretty stuck.

Tuners for instance might want all or nothing assist and regen for maximum acceleration and deceleration during tracks days/racing etc.
The standard setup will only allow that for a very short time before the ECM cuts back to much lower power levels. :(

Hypermilers might want just a little dob of assist to get over a rise or to disable assist for a section of road due to unfavourable terrain.
In those mpg competitions every ml of petrol counts and parasitic regen can be a killer.

With manual control we can peg the assist or regen at maximum until the battery dies, the motor melts, or we can turn it all off completely.
The motor melting or the battery dying has not happened yet in any IMA modified car I know about even at 30kw+.
Honda engineered it all very well and the hardware (electronics and motor) can take a lot of abuse/tweaking as you have already seen from my CR-Z lithium mods.

So how will we do it?

I did look at this a bit some years ago and do have some IMACAN data gathered.
I wasn't so good with CAN then, but now it might be more doable with some extra effort.
Now though I/we need to gather a lot more data and analyse it to work out what packets and ID's are doing what.

It's important not to bite off too much and go for the whole thing straight away.
It's a big project that will take some time and effort.

Manual IMA control can mean different things and require different levels of complexity...

1) Complete control of the entire system, and the ability to command assist or regen at will, overriding whatever the car wants or was doing without error or complaint.
This will be the toughest and most difficult to accomplish. There may well be numerous critical interdependencies in the CAN data that need to be explored and resolved.

2) Increasing or decreasing car commanded assist or regen power levels.
Potentially much simpler and easier. We only need to identify the critical assist/regen level CAN packets and modify them.

So I will look at option 2 first..

I might need a willing Lithium CRZ owner who will let us gather some data from his car's IMACAN bus.
Anyone in the UK near Hull with one and few days/hours to spare after lockdown ends?

So the basic plan is gather some data, identify the relevant assist/regen level controls packets,
and modify the OEM ones or replace them with our own hacked packets.

I'll add to this thread as work progresses.

Help, ideas and feedback welcomed as usual. ;)

Now I need to work on my man in the middle CAN gadget...........
 

·
Registered
Joined
·
414 Posts
Discussion Starter #2 (Edited)
From looking at this it looks like we have 11 x 11bit Hex ID's packets on the CR-Z IMACAN bus.

Note when talking about bytes in packets I number from 0-7!

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.

I will need to program another one of my OBDIIC&C gadgets to sit on the IMACAN BUS and gather this data, do some conversion and spit it out to Excel for direct logging.
 

·
Registered
Joined
·
414 Posts
Discussion Starter #3 (Edited)
OK From my very amateur Google spreadsheet work we get the below which is a positive start..

A short drive. Tickover low level regen, then assist, regen, assist and finally regen.

CR-Z IMACAN ID 115h Spreadsheet

The assist/regen value appears to be an 11 bit number (0-2047) I have colour coded it so you can see it changing during the 30 second drive..

There is a rotating checksum or security byte (8) at the end of the CAN packet we will need to reverse engineer and replicate.

Ideas welcomed as usual.

I added a chart but I have screwed up somewhere with my formula conversions as the chart data is a bit weird. :unsure:
 

·
Registered
Joined
·
414 Posts
Discussion Starter #4
OK I captured some more data today so let's look at the checksum.

The attached txt CAN data file 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
Joined
·
414 Posts
Discussion Starter #5 (Edited)
No ideas on the data structure / spreadsheet etc?

It's a lonely furrow... :( Spreadsheets are not my area of expertise.

Anyway looks like I might have the D8 CheckSum byte calculation sorted.

I've got yet another OBDIIC&C plugged into my desk setup listening to the IMACAN ECM > PCM and sniffing the 115h suspect control packets.

It's generating a checksum based on the first seven bytes of the 115h packet data and comparing it with
the 8th byte checksum the car is generating and sending, and they seem to be matching 100% of the time (y)

We need to be able to replicate/calculate this checksum or the PCM simply will not accept any self generated control data we manage to get onto the bus.

The alternative is record a complete repeating chunk of maximum assist OEM data and then simply send it out in a loop while we have our warp 9 button pressed.
It might be interesting to try that anyway in due course. But even that is tricky as you will see.

The next step is getting our data onto the IMA CANBUS using perhaps a man in the middle device or a changeover.

The packet sequence for the IMACAN is probably set in stone and with a bit of digging should be easy to order.
I might then wait for the packet before the 115h packet. This is our trigger signal ;)

As soon as the previous packet has flagged as received in my device we then switch over the PCM (IMA) end of the CAN bus to the output of my device.
We then send a fake 115h packet on the BUS while the genuine 115h packet the ECM is sending at the same time goes into the 'Ether' (the input of my CAN device)

As soon as our fake 115h packet and the ECM 115 packet have been sent/recd we quickly switch back to allow normal comms until the next time we need to send a 115h packet.

Fast ns BUS switching IC's are available and I've used them before.

EDIT..

Hmm the packet sequence looks like it is all over the place, so maybe scrap waiting for a previous trigger packet sequence.. Time to think..
 

·
Registered
Joined
·
414 Posts
Discussion Starter #6 (Edited)
You will see in the Excel attached 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 115h data in the right place.
 

Attachments

·
Registered
Joined
·
414 Posts
Discussion Starter #7 (Edited)
I've ordered some parts to build a prototype CAN bus switching gadget.
It will use a couple of the Analog switch IC's as per attached pdf.

The minimum time gap between CAN packets on the IMACAN bus seems to be about 22us which equals 22,000ns.
The analog switch chip switches in about 15ns typical. Pretty quick..
We have to factor in detection, propagation and flipping the logic, but we do have some spare PIC CPU time to work with.

If I can get that going on the bench while working on this data that will be a start.
I'll need laser eye o_O surgery to build it, as these chip are only available in a tiny surface mount package!
 

Attachments

·
Registered
Joined
·
414 Posts
Discussion Starter #8 (Edited)
Hmm.. Thinking out loud.

Let's imagine two of my PIC 64mhz CAN devices operating side by side, each with a CAN RX and TX Port.

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 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 have a half built prototype I can tweak..

63386
 

·
Registered
Joined
·
414 Posts
Discussion Starter #9 (Edited)
I have my IMACAN MITM gadget chugging away on the bench but all the PIC timing needs tightening up with some decent crystals to reduce data errors.

High speed CAN and SPI needs accurate mhz clocks.
Sadly my old woodworm ridden antique grandfather clock (internal resonator) just isn't cutting the mustard at 64mhz ticks. :rolleyes:

So yet another Farnell order placed for a selection of finely tuned quartz and ceramics.
 

·
Registered
Joined
·
183 Posts
:) Pleased you know what your talking about :)
Keep up the good work! Some really useful information coming out and future looks bright. Thanks for all your work Peter.
 

·
Registered
Joined
·
414 Posts
Discussion Starter #11
Well the crude prototype MITM device works in the car.... (y)

Passing IMACAN messages correctly in both directions between the ECM <> MCM without errors.

Now we can think about manipulating the data in real time and tweaking those suspect packets.


In the bench test capture below you will see I replaced the $115 data packet with my own... ;)

Code:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
250221 test 02 - 11:57:53 25/02/2021 - Hexadecimal
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TYPE  ___TIME____  ___ID____  D1   D2   D3   D4   D5   D6   D7   D8   _ASCII__   __COUNT___   __PERIOD__
RD11  31.0340      115        48   45   4C   4C   4F   49   4D   41   HELLOIMA   3102         0.0100  
RD11  31.0343      17D        00   00   36   00   3A   00   00   2B     6 :  +   3102         0.0100  
RD11  31.0466      111        80   00   00   00   08   21   02             !     3104         0.0097  
RD11  31.0468      141        00   00   00   00   00   00   02   00              3105         0.0097  
RD11  31.0471      169        00   00   00   00   00   00   01   16              3105         0.0097  
RD11  31.0473      179        00   00   00   00   40   06   91   12       @      3105         0.0097  
RD11  31.0144      24F        8B   68   02                             h         776          0.0399  
RD11  31.0147      318        00   FE   FF   03   FF   00   2E              .    311          0.1003  
RD11  31.0378      231        71   00   09   60   05   DC   2B        q  `  +    776          0.0400  
RD11  31.0380      261        13   88   EC   78   20                     x       776          0.0400  
RD11  30.9982      307        32   00   09   60   28                  2  `(      310          0.1005  

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Key
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RD = Receive Data
RR = Receive Request
TD = Transmit Data
TR = Transmit Request
EF = Error Frame
BA = Bus Active
BP = Bus Passive
BO = Bus Off
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CAN Baud Rate = 500.00k
CAN Bit Sample Point = 70.00%
Netronics CANdo  S/N 2641  H/W v6.0  S/W v2.0  Status OK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

·
Registered
Joined
·
414 Posts
Discussion Starter #13
My first plan will be to send (substitute) a few captured OEM IMA $115 assist packet sequences and see what happens.
i.e. Just replicate a sequence of known valid assist packets when I press my warp button.

If that works I'll do the same with a regen packet sequence with another button.
We might find some checking is going on, and if I request assist when the car is regeneing or vice versa it might fall over.

What may work more easily is increasing the assist level when the car is already requesting assist. Ditto regen.
That way i'm not trying to override it completely, just increase or decrease the actual amount of assist or regen being requested.
 
1 - 13 of 13 Posts
Top