Honda Insight Forum banner
61 - 80 of 442 Posts
I agree... If only someone on this forum would hurry up and design one ;).
I'm trying to figure out the connector as we speak. Digikey to the rescue.
If I can find the connector, I'll design a BMS PCB specifically for the insight... it will be VERY SIMPLE, and will take place of the OEM BCM... certainly not Linsight, but it's what I have time for right now. Total BOM cost would be under $100... I'll charge more to nominally cover my time, based on minimum wage ;).
 
I have bought four sets but they will work out at about $1500 each by the time I get them to the UK and duty is paid.
Unfortunately I live a long way away.. :(
 
Alright, I cannot find this connector. I've poured through Digikey's catalog and I'm starting to think this is a Honda-specific connector. There are no identifying markings on the connector whatsoever. If anyone wants to join the search, we'll start with the 12S connector:
Rows: 2
Positions: 20
Row pitch: 3 mm
Column pitch: 2.2 mm

If we can't find the connector, then I'll make my own using two unshielded 1x10 2.2 mm pitch pin headers. This will be slightly less user friendly, but it is a simple solution.

This PCB is going to have a gargantuan legal disclaimer.
 
I have bought four sets but they will work out at about $1500 each by the time I get them to the UK and duty is paid.
That's still a good deal... half the price of an OEM Honda NiMH refurb, and also cheaper than a 3rd party NiMH cell swap. Were you able to work with someone here to potentially ship them via a cheaper method? As I mentioned previously, you can break the large box down and ship the two smaller boxes (which are properly labelled for individual shipping).

Peter, are you interested in collaborating on the BMS replacement PCB I mentioned previously? Basically I'd be looking for your knowledge on the BCM fooler data stream... I've researched it some, but I discarded that subsystem once I knew for certain Linsight didn't need it at all. If I develop the BMS PCB - with an onboard microcontroller that can send data onto BATTSCI - can you help me with the serial data stream you're using with BCM fooler? I don't want to have to reinvent the wheel.
 
John.

Can I suggest your BMS offering supports upto the full 3 x 18S modules as well as perhaps other combinations of packs thereof. (Note my 3x12S comments in later post)

So as you have them in the case have two socket footprints on the BMS board at each space.

Both sockets don't need to be physically present as they will probably be through hole people can/could solder in the socket combination they need.

So a footprint for a 12S and 18S socket in each of the three gaps.
May need some jumpers for configuring it at each socket.

Just an idea so we are not tied into only one layout and one module arrangement/combination.

That will also make better use of the available modules in multiple sets as well.

Yes I managed to sort shipping using a firm I have used before.
Fingers crossed.. ;)
 
Peter, are you interested in collaborating on the BMS replacement PCB I mentioned previously? Basically I'd be looking for your knowledge on the BCM fooler data stream... I've researched it some, but I discarded that subsystem once I knew for certain Linsight didn't need it at all. If I develop the BMS PCB - with an onboard microcontroller that can send data onto BATTSCI - can you help me with the serial data stream you're using with BCM fooler? I don't want to have to reinvent the wheel.
Of course.. (y) Lets keep it all on here in a special thread.

Your cpu will also probably have to receive data from the MCM on the METSCI line.
 
I'll have to look and see how much complexity 54S adds. There are many concerns that would require additional thought:

-Usability. The 12S and 18S pinouts are different, which would require two separate connectors per "bay" (in the OEM enclosure).

-Safety. The non-used male header (either 12S or 18S) would be energized once the used header was connected to the battery. Customers touching this header could kill themselves.

-Cost. Each LTC6804 circuit costs about $25 in parts... the IC itself is $21.40 EACH. Obviously we can depopulate the PCB, but that adds multiple build options. Adding this all up, a PCB that supports 48S is going to be ~$125 in parts, plus the cost of the PCB (~$20 in low volume).

-End use. I believe the primary benefit is for customers to have a simple lithium solution. Most of those customers probably aren't going to want to swap out their OEM DCDC converter. For those of us tinkerers that want to push the voltage, I'll probably end up recommending people manually wire a 5th LTC6804 (e.g. using LT's demo PCB, which would require manual wiring).

-PCB real estate. This PCB is quite restrained by the OEM pack's small top space (with the OEM computers installed). Particularly the folded steel piece that surrounds those computers is all kinds of in the way. Therefore, I probably won't have enough room for a 5th isolated BMS circuit.

I think I'll go into this project with these configurations in mind:
QTY-12S QTY-18S Result Vnom Vmax
3 0 36S 133 150
1 2 48S 178 200
0 2 36S 133 150
After I've roughed it out, if I can make more configurations work for free (or little effort) I'll look into that. I agree 54S would be great, but I don't believe it will make the initial roadmap.
 
Your cpu will also probably have to receive data from the MCM on the METSCI line.
That's actually more effort than it sounds... I plan on using the 328p, which only has two hardware serial ports. I'll bit-bang a third serial port if I have to, but I'd rather not waste the CPU time, since I plan to use that to rapidly query SPI battery voltage and make realtime decisions. 25 MHz only goes so far ;).

As much as I'd love to port my existing code over to another microcontroller, my existing code works on the 328p... technically it also works on a much larger microcontroller, too, but that's more expensive. The code I kludged together doesn't have a simple HAL that I can easily rewrite... in short, using another microcontroller is more effort than I'm willing to commit to this project.

Is there a way we can tie my PCB into your existing BCM fooler? I can even replicate your (PIC?) circuit on my PCB, and then load your code.

People will scratch their heads, thinking "why does this PCB have both Atmel and PIC uCs?"
 
Re the BMS PCB Random thoughts in no particular order..

1) I was thinking put your PCB/s at the end of the pack where the fan would be.
A thin? PCB the width of the pack, or three small interconnected pcb's that fit into the openings, one per block. Connectors facing inwards accepting those plugs.
Maybe use the fan mount bolts holes or studs on the end of the packs to secure it/them, whatever.....

The OEM fan could mount over it as normal and provide airflow for the bleed resistors when balancing.

(I'll do a YT vid with some thoughts.)


2) If you want to replace the BCM you have to do a lot of stuff to keep the MCM happy. :eek:

a) Measure/count current in out and have a running or faked SOC that is stored between drives.

b) Have a serial data stream on BATTSCI containing current, voltage, temperature, Soc, flags etc.

c) Accept serial data from the MCM on the METSCI bus..

d) Other stuff I have probably forgotten.


3) Yes it would be possible to add a BCM Interceptor to your physical PCB.

The current version of the BCM Interceptor PCB fits inside the MCM and has two simple 5V logic level high/low inputs to control (enable/disable assist/regen).


I think we should keep the OEM BCM and let it do it's thing. That also avoids a lot of hardware development and harness chopping modifying. We get to put the 4x OEM temperature sensors in the new packs and use the OEM current sensor, SOC counting etc all as normal.

Fake the ptc strips with a 30R resistor as we do now for most setups.

Feed the BCM taps with a simple BCM Fooler resistor matrix.
That's well proven and reliable and is easily configurable for higher voltages than OEM with a pre-resistor. (This could be on your pcb)

Use a BCM interceptor (fitted inside the MCM or on your pcb) to interface between your BMS and the car. Again that's well proven and reliable.

Your BMS cpu just has to output a 5V logic high/low on two discrete lines to enable disable assist/regen.

The cell voltages could be output via CAN or more likely serial data on the HLine and be picked up by an OBDIIC&C like the LTO etc.

Most people doing mods like this will have an OBDIIC&C plugged into the car, might as well use it ;)

You could have your CPU listen on the serial HLine and when it gets a send me the cell voltages request packet from the OBDIC&C/Android app/etc etc it just spits them out onto the HLIne/Bluetooth for the OBDIIC&C/Phone to display.

That would be fairly simple to implement.


So if we kept the OEM BCM then we would need....

1) Your simple BMS pcb with two 5V logic level outputs to enable/disable assist/regen via the onboard BCM interceptor.
A 5V HLine serial 9600 baud I/O port to exchange cell voltage data or commands with the OBDIIC&C on request.

2) A BCM tap fooler resistor matrix. (You could put that on your pcb and use your HV connections etc)
The builder/converter would simply cut off the tap harness from their orange end board and solder it your pcb.

3) A simple BCM Interceptor inside the lightly modified MCM or on your PCB.


4) An optional OBDIIC&C to display stuff from your BMS and/or send/receive commands like adjust voltage/balance setpoints etc.

5) Your BMS would do all the balancing stuff autonomously and just toggle the logic level protection request outputs when things (cell voltages) get out of hand!
 
Peter, I'll have to dust off my Linsight IMA schematic tomorrow and see if there's a simpler method. I'll read your reply in more detail then (it's 4AM here right now).

...

I've been trying to find more information about these batteries. Here are my findings thus far:

The best rabbit hole I've explored so far is from the serial number label that was attached inside the box... it contains the text "UF121285H". That leads to this website:

Findings from that website:
From Honda immd hybrid system, which is used in both 2018-2020 Accord Hybrid & 2019+ Insight
Chemistry: LiNiCoMnO2 (ternary lithium battery)
"Panasonic used after localization, model UF121285H". I think he means that the battery was originally designed by Blue Energy (which itself is 49% owned by Honda)... and now Panasonic is making the pack instead. Remember: the box that these modules shipped in has Panasonic written all over it, as do the various labels.
"At present, the detailed specifications of this battery of Panasonic are not available online, but because Honda directly replaces it, we have reason to believe that the specifications of the two batteries (Panasonic vs Blue Energy) are compatible."
"UF 12 12 85" is based on cell dimensions (120 x12 x 85 mm).

Cell information:
Model: EHW5
Ah: 5 (when charged to 4.2 volts)
Vnom: 3.6
Operating range: -30 degC to 55 degC (131 degF)
Cycle life: 50,000 (@10-85% SoC), continuous 40A charge/discharge!
Time Life: 10 years
Recommended charge/assist current: 200 A
Maximum charge/assist current: 300 A (60C)
Power density: 4.9 kW/kg

The reason the part number on the box doesn't pull up on Honda's website is that the pack itself is a non-user-purchasable subcomponent of the following parts:
1D070-6C2-305 (2018-2020) Accord Hybrid). OEM cost: $2762
1D070-6L2-A00 (2019 Insight Hybrid). OEM cost: $3126

So yeah, this $440 battery is ~$2800 from Honda.
 
Peter,
-I like your idea to use the fan shroud to electrically insulate the open connection.

-I think we'd need to move/add the/a fan to the right side of the pack... that's the way the air slots flow through the lithium cells. The "unused" side you mentioned (covered by the plastic cover) is where the fans would likely need to go. However, I think we'd leave the OEM fans installed, too, as they would cool the BMS discharge resistors. We can figure that out later.

-The master/slave board idea is good, too. The interconnect would be 2-wire isoSPI.

-I agree we can't replace the BCM with the amount of effort I'm willing to focus on this project. Replacing the BCM very quickly approaches the effort of Linsight.

-I like your earlier idea of cutting the OEM tap connector off and screwing it into the BMS PCB.

-9600 baud H-line is easy... 328p has a dedicated serial hardware protocol.

-Remind me: does the OEM BCM mind if the battery voltage is 200 volts?

-I'll think about this in more detail tomorrow.
 
With an appropriate value pre-resistor for the 10x10k 0.1% BCM Fooler matrix and identical VPIN resistor to bring the working voltages down into the OEM range, the car can tolerate actual battery voltages up to ~220V (DC-DC Shutdown)
 
-The master/slave board idea is good, too. The interconnect would be 2-wire isoSPI.
+ 5/12V Power/Ground presumably? Or will each slave board have a regulator/separate pwr/gnd??

-9600 baud H-line is easy... 328p has a dedicated serial hardware protocol.
Very easy to implement this with the OBDIIC&C as well,
it already talks to the IMAC&C P&P inside the MCM on the HLine using exactly this method.
(HLine 5V 9600,8,N,1) Idle line high.

We just have to give your device a unique ID on the H BUS.
I used a 5 byte packet including header $BB & simple summing checksum.
So ' BB 05 00 80 C0' for example is a packet I send to the IMAC&C P&P every 100ms or so..

I suggest your BMS could listen on $CC, I think that is free on the HLine

It can then send out the cell voltages with the header $CD when asked.
One large packet (max length 256 bytes including header and checksum)

So $CD + (48 cells x 16 bits per reading) 96 bytes + Checksum) = 98 bytes total or about 100ms
Or we can pack each cell voltage into 12 or even 8 bits bits depending on the resolution required.

It would be good if your cpu has enough free cycles to do the conversion from the weird LTC data into a real voltage say 2/3 decimal places it then sends out.

If you want to do total pack voltage, highest cell, lowest cell, average cell, cell deviation calculations and send those in the packet as well it means I don't have to do it in the OBDIIC&C. ;)

We probably only need/want to poll your CPU/BMS for all this stuff once a second or so.
 
I think I'll go into this project with these configurations in mind:
QTY-12S QTY-18S Result Vnom Vmax
3 0 36S 133 150
1 2 48S 178 200
0 2 36S 133 150
After I've roughed it out, if I can make more configurations work for free (or little effort) I'll look into that. I agree 54S would be great, but I don't believe it will make the initial roadmap.
The voltages/configurations in red will be too low IMHO for the IMA without boosting it at the VPIN and the Voltage taps.

IIRC If the unloaded pack voltage falls below ~144V the car will not IMA start etc..

It will also be trying to regen a lot of the time to get the voltage up into a more normal range.
It won't stop charging naturally until the detected IMA voltage gets well above the 150V, upto around ~175 in fact.
A BMS/control failure could be very risky with a low voltage poly pack and a lot of regen.

I found it much easier to reduce higher pack voltages with cheap resistors,
than boost low ones with op amps and inline dc-dc converters etc.

We can choose the BCM Fooler pre resistor and VPIN resistor to get the pack down into a nice optimal OEM comfort zone. The car will then naturally cut regen and assist as it's detected voltages reach the normal IMA limits adding some free backup/fallback inherent safety.

I think 48 cells should be the standard for most people.

All just my two cents of course.. ;)
 
Some other UK guys used BMW packs and replaced the BCM I believe. Using a teensy and esp32?
You might get some info from them and their thread on here, although we haven't seen much technical detail.

Called 'Bimsight'. LOL

 
61 - 80 of 442 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top