Honda Insight Forum banner

1 - 20 of 496 Posts

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #1 (Edited)
What is the 'Bcm Replacer' and why do I need it?

A good question and one that is quite tricky to answer. :?

If your happy with the old Nimh battery tech, and the way the OEM Bcm manages the pack and reports information etc, then you don't need a 'Bcm Replacer'.. The OEM Bcm does a pretty good job of looking after stock packs, and has been proven over nearly 20 years.

If you are not happy with the above, like lots of information, have some good technical skills, and want to consider alternative battery chemistries, bigger batteries, higher voltage batteries etc, then the OEM Bcm is not ideal. It's not configurable by us the end users, and it's inner workings in parts are still shrouded in mystery. It's very limited in its ability to directly deal with larger capacity packs and or higher/lower voltages... It's reporting and monitoring capabilities are very limited, restricting information about our battery and IMA system condition..

Enter the 'Bcm Replacer' an OEM Bcm replacement, designed by long term Insight owners and enthusiasts RetepSnikrep & BullDog for the benefit of our cars, us the owners and drivers, and the wider Insight community..

If you have been following this thread you will know the 'Bcm Replacer' can mimic the functions of the OEM Bcm and has extensive reporting and control functionality. Including a video screen and keypad etc. It can interface with a commercial Lithium Orion2 Bms, and allow installation and monitoring of larger, higher voltage Lithium battery packs. It can also provide basic tap voltage deviation monitoring for batteries that don't have an independent Bms. It has a number of safety mechanisms and can compare and check information to report problems promptly to the driver.

It replaces the earlier 'Bcm Interceptor' when using Lithium packs and gives much greater functionality.

In short the 'Bcm Replacer' is a bridge or stepping stone between our old Nimh battery technology and the new world of Lithium and beyond. It will help to keep our cars on the road, and gives us flexibility in our battery choices. It removes the monkey on our back that has kept us in the past and mainly shackled to Nimh packs..

If you want to participate or just lurk that's great, enjoy the ride. ;)

The project would not have been possible without help and knowledge from many owners and enthusiasts on here over the years.
So our grateful thanks goes to them, they know who they are.

Of course if we hadn't had the internet and this forum, none of this would have happened, and we would never had heard of each other. We would in all likelihood be limping along individually with our cars and the quirky problems they present.

RetepSnikrep & BullDog



The above was added to bring the first post uptodate, the original first post is below.


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.

This project will draw heavily on what we have learnt in the BCM/MCM analysis thread. https://www.insightcentral.net/forums/modifications-technical-issues/14217-analysing-bcm-mcm-signals.html

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?

Please chip in with ideas etc.
 

·
Premium Member
Joined
·
2,818 Posts
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.
 

·
Registered
Joined
·
1,616 Posts
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.
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #4
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.
 

·
Registered
Joined
·
1,616 Posts
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?
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #6 (Edited)
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.
 

·
Premium Member
Joined
·
4,389 Posts
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.
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #8
Schematic

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.

Schematic and some draft Picaxe 18X code below.

www.solarvan.co.uk/bcm/BATTSCI_RS485_INTERFACE.jpg

www.solarvan.co.uk/bcm/BATTSCI_18X_AUSART_290909_V01.txt
 

·
Registered
Joined
·
1,616 Posts
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.
 

·
Registered
Joined
·
235 Posts
SLA vs. NiMH D-cell

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

Curious,
Roger
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #11 (Edited)
Jim

The pic I will be using is the 16F88

I will use either Picaxe 18X chip or a virgin chip programmed Picbasic pro or assembler. I have all three systems available

Picaxe system here Active PICAXE Forum - PICAXE Forum
Picbasic Pro here PicBasic Pro Compiler
Microchip Assembler here Microchip Technology User Forums


The fake bcm pcb has now been sent for manufacturing should be here in about a week. I ordered 20 so if anyone wants one let me know. Obviousuly this is a prototype and who knows how I will get on.

pdf of pcb layout here if interested.

www.solarvan.co.uk/bcm/BCM-COLOUR.pdf

Peter
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #12
The pcb's will be about $15.00 or £10.00 each.

If anyone else wants to play along I am using this usb-rs485 adapter for bench testing.

Active Robots - Products - Motion Controllers - Motion Mind DC Controll - UK

I am driving it with a very simple program called "serial player"

Serial Player

I used the rs485 device and serial player to record data from the BATTSCI bus on my car.

I then use the rs485 device on the bench with serial player to play that data back to the BCM prototype thingy on the bench. It saves having the car involved at this stage and should allow most of the debugging to happen in the warm!

The two data files I captured for serial player are here.

9600 baud 8,E,1

www.solarvan.co.uk/bcm/BattSciSerialData.zip

The actual data in the files is not that important at this stage, what is, is getting our BCM device to relay it correctly in the first instance without modification or error. Then I can start tweaking the values based on our/my particular battery data.

The BattSci data packets are about 30ms long and seperated by a 35ms gap. I'm hoping we can receive the data then send it straight out again in the gap. So it will be offset/lagging by about 30ms from an actual car. I think that will be fine. It's probably possible to overlap it as well but I'll see. The 16F88 chip has a nice onchip USART and the testing I have been doing with my Picaxe version shows I can rxd/txd the data.

I'm going to try and write the software in assembler :GULP: It's years since I did any assembler programming.
 

·
Premium Member
Joined
·
1,427 Posts
I would love to get my hands on one of your BCM mods. The 3 bar bug is pretty easy to work around, but it would be nice to know how much capacity is available. It would also be nice to have an instant positive recal when I know the battery is charged. Any chance that you BCM (addon) could work with a display to readout remaining capacity like your lithium based system does?
 

·
Registered
Joined
·
1,616 Posts
The pcb's will be about $15.00 or £10.00 each.

If anyone else wants to play along I am using this usb-rs485 adapter for bench testing.
When and how do I send the money? I can send it PayPal if you like. Probably the best way to go as it gets converted at the same time.
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #15 (Edited)
Jim.

Once I have the pcb's and have built one to test it then I'll let you know. The price is for the bare pcb only, you have to do the rest I don't sell kits or any other parts at the moment. However I may supply the pre-programmed pic later once I get something working. The system will prob def have to use assembler to get the reqd speed. You need a proper pic programmer of some sort to program the raw pic in assembler.

Uhtrinity. I use my BCM fooler hack at present to command a pos recal when gauge drops down, it is only really suitable for non stock packs that don't rely on the nimh voltage taps. It spoofs the voltage taps to the BCM with a potential divider resistor chain and dc-dc converter to up the reported voltage when activated for long enough to cause a pos recal.

The new system will hopefully remove the BCM fooler requirement as I will be modifying the data on the BATTSCI bus and sending my own values to the MCM for SOC/TEMP/VOLTAGE/CURRENT. I will pass through any unknown values until I learn what they are! Of course none of this would have been possible but for Randy's great work on the other BCM thread analysing the data!


My own BMS will communicate with this new BCM device using a 4800/9600bps serial bus.
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #16 (Edited)
First Tests

I've now built up one of my boards and started in car testing.

At the moment I'm sending some known good data out of my board on the BATTSCI bus to the MCM. The BCM is sending it's data into oblivion at the moment.

I'm sending two twelve byte data packets which equate to the car ign on but engine off and 19 bars Soc. I recorded it from the car earlier.

$AA,$10,$00,$00,$00,$20,$40,$61,$10,$01,$00,$74

$87,$40,$58,$15,$6E,$10,$01,$32,$2F,$2F,$04,$39

I started my data transmission before I switched on and the car turned on normally with no IMA errors and showed 19 bars SOC. So it seemed quite happy with the data/comms.

The car started normally and ticked over normally for several minutes before an IMA error finally appeared.

The error was as expected a communication error, and I strongly suspect due to a change or request sent from the MCM -->>> BCM which was not responded too as I had interrupted the return path BCM -->>> MCM and was sending the fake data to the MCM.

That should not be an issue as I will be monitoring the incoming data as well and modifying the data sent out to reflect requests. In fact i'll be passing though a lot of data unchanged, including battery voltage and current etc I'll probably only be trying to modify the SOC initially to suit my cells/pack.

I tried changing the soc byte in the message to see if I could make the gauge show 20 bars but I did not alter the message checksum byte and that threw an immediate IMA comms error. I need to add some code now to calculate the 12 byte packets checksum before I start further tinkering with the sent data.

I also need to move to assembler/PicBasic Pro to get suffcient speed for further testing.

Interesting all the same. Pics show board and car gauge with 19 bars showing. The little connector board sits on top of the MCM in my car and is a tap/interrupt point for the BATTSCI & METSCI buses during testing. The micro rocker switches allow me to disconnect the various units BCM/MCM/Gauge from each other, and the pins allow me to introduce/receive signals from either side of the switches.

www.solarvan.co.uk/bcm/fakebcm001.jpg

www.solarvan.co.uk/bcm/fakebcm002.jpg

www.solarvan.co.uk/bcm/fakebcm003.jpg

www.solarvan.co.uk/bcm/fakebcm004.jpg
 

·
Premium Member
Joined
·
2,391 Posts
Nice work with the BMS. I like how you have professional PCB boards. I'm still using the ferric chloride one minute sponge method, although you've got a slick green pcb there. I'm not sure how to find a place that does that in the states, I'll have to look into that.
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #18 (Edited)
Good Progress

I have been doing a fair bit of work on this and now have my board relaying the data on the BATTSCI bus correctly!! The car is switched on but engine not running.

The very simple PicBasic Pro code is here

http://www.solarvan.co.uk/bcm/BCM12.pbp

The software has a fair bit commented out at the moment for later inclusion as it develops!

For those of you who have the LOGIC analyser software here is some data from the car/board.

http://www.solarvan.co.uk/bcm/BATTSCITEST241009.logicsession

For those who don't a couple of screenshots.





The top line in each pic is the car BATTSCI bus in, the second line down is the BATTSCI bus out from my board and you see it is the same. The two pics follow each other.

The program at the moment just relays the packets through untouched. But I also have the code for the 12 byte packet checksum calculation worked out.

You can see it waits until it sees a packet start code $87 or $AA and then recieves the next 11 bytes before squirting out the packet start code and the 11 bytes it had just recieved.

I shall try this today hopefully with the engine switched on and the board working in situ between the BCM & MCM. If it works relaying the data correctly then I will start adding the code to modify the SOC bytes, OHHH ERR! Scary.

Now my board has a number of analog and or simple digital high low inputs which I can read in between packets and use to modify SOC or whatever I want. My BMS could output a serial signal telling the board the current SOC of my Lithium Pack. I then use this value to modify the SOC bytes? Or any other ideas? I could use a simple high/low i.e. if my choosen input pin is high (pack not empty) then force 19/20 bars/max soc. If it is low force 0 bars/no SOC? Have to see how it responds to that!

Edit

Just got back from a 5 mile road test, appears no issues and car worked quite happily with my unit in between BCM & MCM relaying the BATTSCI RS485 data.

BCM --->>> My Fake BCM --->>> MCM

www.solarvan.co.uk/bcm/FakeBCM012.jpg
 

·
Administrator
Joined
·
10,589 Posts
Discussion Starter #19 (Edited)
I tried to substitue 19 bars soc data into the BATTSCI message but got an immediate comms error when I turned on the ignition. Now I don't think the soc data was the problem, but my checksum routine which calculates the last byte of the 12 byte packet. It seems to come out at $FF which I think is wrong.

Screen shot showing incomming data bottom two lines and my outgoing data with 19 bar soc added 0x15 0x6F top two lines. Note checksum byte at end $FF??



For those who want a closer look at the data and who have the logic software installed.

www.solarvan.co.uk/bcm/battscitest261009.logicsession

The free software to view this data is here, I'm using the beta 1.31

Downloads

The current fake bcm software is below if anyone wants to have a look at my checksum routine and give a hand!

www.solarvan.co.uk/bcm/BCM15.pbp

It's a simple text file & opens with notepad.

Help please.

Edit

May have been an idiot and included the AND part in my routine when it should be the receiving device which does that!! Comments.

Randy's thought on how the checksum is generated are here.

"Here's what I figured out so far: There are basically 10 data bytes per message. Before the first is the message type (AA or 87), and after the last is the checksum. You can compute it by adding the other 11 bytes, negating that (2's complement), then and'ing by 0x7f.
It makes the entire message add to 0 when you and by 0x7f."
 

·
Registered
Joined
·
30 Posts
It's this part:

BCMDATA[10] = CheckSum AND $7F

The AND is a logical operator... you need an & instead.
The rest of the code looks good though.
 
1 - 20 of 496 Posts
About this Discussion
495 Replies
47 Participants
retepsnikrep
Honda Insight Forum
We’re the ultimate Honda Insight forum to talk about Honda’s hybrid car and its fuel economy and specs!
Full Forum Listing
Top