[PeterPerkins]

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!

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...........

 

[PeterPerkins]

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.

 

[PeterPerkins]

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.

 

[PeterPerkins]

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?

 

[PeterPerkins]

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

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..

 

[PeterPerkins]

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.

 

[PeterPerkins]

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 surgery to build it, as these chip are only available in a tiny surface mount package!

 

[PeterPerkins]

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..

 

[PeterPerkins]

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.

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

 

[Jeffd]

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.

 

[PeterPerkins]

Well the crude prototype MITM device works in the car....

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...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[96firephoenix]

I know you're not getting a lot of interaction on your posts, but PLEASE keep up the work and the updates!

CAN hacking is its own special breed, and I love seeing it, even though I have no skills at it.

 

[PeterPerkins]

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.

 

[PeterPerkins]

I am the IMA Master now and you are my Slave! Muwahhhhhhhhhaaaa.....

Well it's very early days but it is in and working. No IMA errors so far.

I have two magic buttons (Yellow Max Assist) (Green Max Regen)

If you press them at any time it does exactly what is says on the tin!
It overrides the car (ECM) and launches into whichever you pressed and keeps it there until you release the button!
If the battery gets exhausted or too full, BCM protection will still kickin to prevent damage, but other than that the world is your oyster.

I am currently sending packet substitutes which equate to high levels of assist or regen whenever the appropriate button is pressed.
Lots of fine tuning now required to establish the full range of numerical values available for assist and regen.
Then a full variable control system can be implemented.

I also pre-computed checksums etc for the packet series required in these tests, this will have to be done on the fly with full variable control.
With the max assist I also need to bring in the WOT 85V voltage hack at the same time as the max assist packet substitution for ultimate current and power.

All exciting stuff and significant step forward which will probably be applicable to all the Honda IMA CAN cars.

My giant clunky Heath Robinson rats nest prototype can all be reduced to the size of a business card or smaller in a later offering.

Grateful thanks to all those who have contributed to this research with funds, ideas, gadgets and data for analysis.
You know who you are.. Cheers.

 

[will-w]

I have only just seen this thread, I don’t frequent the forums as much as I possibly should.

It looks like you’re continuing to make great progress!

Geographically I’m a bit hampered, being in Kent and with the lockdown going on, but if there’s anything you need assistance with just say. Did you say in one of your other posts that you are looking for OEM lithium parts?

 

[Jeffd]

I want I wan I want waaaaaa. Are we nearly there yet waaaaaaaaaaaaa.
Absolutely brilliant Peter. You can try it out on mine anytime.
Great stuff. Keep well.

 

[PeterPerkins]

I have only just seen this thread, I don’t frequent the forums as much as I possibly should.

It looks like you’re continuing to make great progress!

Geographically I’m a bit hampered, being in Kent and with the lockdown going on, but if there’s anything you need assistance with just say. Did you say in one of your other posts that you are looking for OEM lithium parts?

Yes I'm looking for a complete Lithium IMA setup and possibly a Lithium car ECU and connectors from the harness.
I do have first dibs on one up in the north but am waiting for it to be removed from the car.

 

[PeterPerkins]

Considerations.

I managed another 30 miles test drive to collect some shopping and meds. No issues to report or IMA errors.
But there are a lot of things to consider.

With the current test setup there are no safety interlock checks now the ECM is out of the equation.

It's probably possible to launch the car through the garage wall if you press the warp 9 button while the car is sat in gear not running but with the ignition on.
The clutch and brake or gear checks are all further back upstream in the ECM. The IMA just responds without question exactly as per our commands!

It might be possible to pick up these missing signals from the FCAN or IMACAN bus by extensive analysis of the packets.
Then interlocks can be added to replace the ones from the ECM .

We can make it only assist when the car is assisting or regen when the car is regening fairly easily.
That means we preserve/restore the launch safety. But we lose the ability to override assist with regen or vice versa.

Regen with the button pressed at anything over 2k rpm is 100A at 130V or so, so 13kw.
That's a lot and the retardation is very noticeable.
Of course the brake lights are not operating in this situation as again the ECM is out of the loop, something else to consider.

For the next stage I might tie the max assist (button) mode into my other PPP gadget so it only works with WOT.
That way it will only operate when you are really booting it and the car is assisting hard anyway.

I'll add a few rotary pots so we can tweak assist/regen up down.
Lots of testing and tweaking to do.

Yes there may be a product at the end of this, but that won't be for some time.
I have ordered a commercial MITM device to have a play with, but I prefer to roll my own as we can incorporate a lot of other stuff.

Anyone any good at laying out SMD PCB's from a Schematic?
I'm useless at this So if someone took that on we could get devices made for us.

This new IMA control cannot be achieved without a relatively simple harness hack.
We have to insert our MITM device into the IMACAN two wire line that runs between the ECM and the IMA.
So it will never be a completely plug and play solution like my OBDIIC&C display device.

 

[NY-Z]

This might be relevant-
I've noticed I have some control with my foot, it's possible to be cruising with very light throttle and have one bar of charge putting 10-15A into the battery. So maybe there is already a "cruising charge" mode?

 

[smurfuk]

This is great Peter. I can think of plenty of real world uses for this that would really help when trying to eke out every last bit of economy.

Regarding the interlocks, if you have access to vehicle speed over the CAN could you not create a simple interlock that prevents your MITM device from working at all unless the vehicle speed is above, say, 10mph?