I've started this thread to document/discuss a fake/alternative BCM project to allow different battery chemistries in the Insight MK1 whilst eliminating the three bar soc bug, and allowing the gauge cluster to operate correctly.
I would like to design something that sits between the BCM & MCM intercepting the data from the BCM, modifying it with our own batteries current soc/temp etc before sending it on to the MCM.
Knowing me it will be based on 2 Picaxe chips probably 28X2 with 2 rs485 interface channels.
One rs485 chip and 28X2 listening to the BATSCII bus from the BCM.
One rs485 chip and 28X2 transmitting on the BATSCII bus to the MCM.
I think we should retain the old BCM and just intercept the signals between it and the MCM on the BATTSCI bus, modifying them as reqd. This would potentially be quite simple, allowing use of the stock BCM for the current, temp, voltage data gathering it does now.
No fancy connector problems. Hmm!?
Should it include a cut down version of my BMS to manage the new battery?
Should it include the suplementary dash display to give the user the extra battery data?
Once we start altering the SoC or battery itself... proper BMS becomes more and more important... I think it should be included... and if we are sending the signals to the MCM then we should have the same kind if not more influence that the OEM BCM had in being able to protect the battery pack.
Making use of the OEM BCM can be useful... but once we change the battery we have to alter / ignore most what the OEM BCM does anyway... once we know enough about the BCM to MCM communication to know how to alter it the way we want... the OEM BCM seems redundant / a waste of space to me... Perhaps a replacement BCM.2 would be a better direction.
I agree with Iamian. There is no real need for the OEM BCM when it becomes redundant. Get it out of there. At least with it gone there is no more question about what generates this or that signal.
__________________
Jim Isbell
2000, 5 speed, 250,000 miles
"If you are not living on the edge, well then,
you are just taking up too much space."
The OEM BCM does a fair bit though which we must consider.
It measures current in/out of the pack and sends the value to the MCM
It measures temp using the thermistors and the ptc strip sending a temp value to MCM
It measures the subpack/pack voltage and sends the pack voltage to the MCM
It sends Soc data to the MCM
Whatever we have in it's place must also do these things, and send data which is accurate enough so that the MCM is happy with the corelation between the data we send and the data it obtains for itself.
We know the MCM also measures voltage and current for instance. How accurate does it have to be?
Perhaps for phase one we/I should retain the BCM and intercept it's signals, manipulate them a bit, and see how far off they can be before an error occurs.
I think that's the way forward initially. Get the intercept/manipulate working correctly and then finally remove the BCM.
I guess I misinterpreted your first post to mean we were going to eliminate the NiMh battery pack so would be eliminating the temperature and voltage measurements in favor of a different set of data on a different chemistry. If we do that then the previous measurements would be meaningless wouldn't they?
__________________
Jim Isbell
2000, 5 speed, 250,000 miles
"If you are not living on the edge, well then,
you are just taking up too much space."
Jim, you are right I did mean we may remove nimh stock pack and replace it with lithium etc, but we also might supplement it with parallel packs from other hybrids, or make a big nimh capacity pack, when it (BCM) could still be useful even if just to provide the data about temps, current, voltage etc etc.
In fact a big nimh pack made from prius/insight cells is probably the easiest/cheapest way to a bigger capacity system. So a lot of the BCM functions remain useful, we can just intercept the data it sends out and modify it to reflect the actual soc of our mega pack etc. Also intecepting any codes it is trying to set and replace them with everything is OK codes where appropriate.
I just got some prius packs, I made an adapter for the BCM output connector, and was able to read SOC, pack voltage, and several other parameters via the CAN bus. I used my friends Scan guageII.
I expect that once I get the CAN codes for the other data that a factory scan tool uses that I will be able to read the subpack voltages, delta subpack voltage, pack temperature, and pretty much anything that the BCM computes. Using this approach, there is no need to develop a BCM for the auxiliary packs, only a CAN interface to the AUX pack/ packs BCM.
I expect that the CAN communications from a civic BCM would also be accessible this way.
I should get my microchip CAN development system tomorrow, so I can dig deeper.
In theory the assist/regen control in the civic, and insight 2 should be controllable via the CAN bus, so a CAN based MIMA for those cars may also be possible.
Here is my updated BCM Project schematic. I've sent it to my pcb chap today.
It uses a cheap pic and can use picaxe basic for testing which I can then convert into assembler or compiled basic later. It allows the picaxe to be programmed using the picaxe system or via an ICSP and serial programmer.
Initially I shall just try to pass through the data from the BCM to the MCM. To see if any timing issues rear their head.
So testing will be inserting module betwen BCM & MCM on the BATTSCI bus.
It will listen and store data from BCM in RAM then simply forward it unmodified to MCM. I imagine there must be some allowance for errors and lost packets etc in MCM so we can see how few packets we can get away with!! Once that works then we can start changing values based upon the great research done by Randy on the other thread.
I'm ignoring the METSCI bus at the moment as I think we can probably drive the gauge via the MCM by sending it the values we want indirectly Just like the stock system.
I have saved both sets of data, software and schematic. I dont understand the4 software, but I am a programmer and could understand it if I knew where to get the manuals for it. I program in "C" and "C+" as well as five other languages so if you can direct me to the manuals I will pick it up quickly.
I am surprised at the simplicity of the hardware. Looks like a simple project....but one that could expand dramatically as you learn more that you can do with it.
I have two "extra" NiMh packs and might put them all together with the in car pack as one pack. But I am also interested in putting together a PbAcid pack to replace all the NiMh just because its simpler to maintain.
Keep up the good work, I am following it closely.
__________________
Jim Isbell
2000, 5 speed, 250,000 miles
"If you are not living on the edge, well then,
you are just taking up too much space."
...But I am also interested in putting together a PbAcid pack to replace all the NiMh just because its simpler to maintain.
What weight & amp-hour specs are you aiming for with it? Using Optima D51s (or D51Rs)? If so, 26 lbs. x 12 = 312 lbs... with the stock drivetrain that would be a wee sluggish IMHO. How long would you expect the SLA pack to last? How much of a cooling system would you have for them for a hot summer day to keep sustained regen from sending them over 125 deg. F., especially after already heating up some from helping first climb the hill they're then coming down?
If using SLAs smaller than the D51(R), couldn't you expect issues under sustained full regen?
The AutoGuide.com network consists of the largest network of enthusiast-owned enthusiast-operated automotive communities.
AutoGuide.com provides the latest car reviews, auto show coverage, new car prices, and automotive news. The AutoGuide network operates more than 100 automotive forums where our users consult peers for shopping information and advice, and share opinions as a community.
BCM Project
Just like the stock system. 
