Honda Insight Forum banner

21 - 40 of 533 Posts

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #21
Working

After having wasted several hours due to my pic programmer playing up and correcting some stupid errors in my code, (Thanks Fjord) I finally managed to get my latest code into my fake BCM pic!!

It seems to work. :)

I had my unit in between the BCM >> Fake BCM >> MCM and I changed the codes on the fly for soc to 19 bars.

The soc had been 7 bars according to the real BCM, and as soon as I turned the car on it went slowly upto 19 bars like a pos recal. If I then took my unit out of circuit and turned back on it went back down to 7 bars slowly like a neg recal.

Car started normally with no errors and 19 bars soc showing with my unit in situ. I'm off down to Norwich now so haven't got time for a test drive today. I'll try and do that tomorrow.

The working code is here.

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

Soc Before

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

and faked!

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

I need to add simple high low SOC control from my BMS and try a test run. There will be some other bytes that need faking i'm sure. So I expect some errors issues to appear.

For instance when real BCM thinks battery is empty it probably sends some other codes to prevent assist? I'll have to loook at what changes during a run to fake/intercept these.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #22 (Edited)
Test run tonight in lithium car with SOC forced to 19 bars.

Car ran and drove normally no errors. I went far enough to use half a dozen bars of soc but gauge was pegged at 19 bars. However as I am short of time I did not go far enough to use what the oem BCM thought the remaining soc was before I forced it to 19 bars. It is highly likely that when the BCM thinks the battery is empty it may set other codes to disable assist in the messages or via flags in the SOC bytes. So I need to discover these.

To help me do this I have built an IMA cycler for my spare standard car.

You start the car and leave it ticking over and it forces regen at about 12-15A loading the engine and charging for several minutes until the battery goes upto 20 bars and beyond and it won't accept any more charge. During this period I will capture the data on the BATTSCI bus and hopefully learn the following.

1) The code for 20 bars SOC
2) The code for disabling regen
3) The confirmed code for temp and possibly fan codes.

I'll then switch to the other mode for my cycler which forces 20A of assist and sits there reving the engine to about 2000rpm using up the battery until it is empty and won't allow anymore assist. Again I hope to learn.

1) The code for 0 bars Soc
2) The code for disabling assist
3) Temp and any error codes.

My plan with the cycler is to automate that later and add the BATTSCI listening feature to it so it becomes a stand alone IMA battery exerciser/cycler. It can cycle the battery up and down waiting for the codes on the bus to tell it to switch modes. This might prove useful in prolonging nimnh pack life? And it uses the heavyweight electronics already built in to charge/discharge the battery. Yes it would use a bit of fuel but interesting. The battery in my standard car is pretty weak and neg recals quite reguallry so capturing this data while cycling should be very interetsing. I'll keep you posted.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #23 (Edited)
Good Bye 3 Bar Bug and BCM Faker Device!

I had been using a BCM faker device to top up the soc gauge every so often with my lithium car by forcing a positive recal by raising the apparent battery voltage to 175v or so. A real cludge but it worked well for nearly a year, just a bit of a pain as you would sometimes need to pos recal when also requiring lots of assist to tackle a hill.

A further test today when I drove to work 13 miles using assist all the way with my BCM Interceptor in circuit and the SOC forced to 19 bars gave no problems.

A check when I got to work by disabling my BCM interceptor and allowing the OEM BCM SOC signal through saw the soc gauge drop down straight away to zero bars! This is quite interesting as it suggest the SOC codes (two bytes) also contain the assist disable flag bits as suspected by Randy in the analysis thread.

I'll do some capturing on my other car tonight with the IMACYCLER to see how the codes actually change at the extremes of the gauge/soc.

It looks like I can just send whatever soc I want. So I must add the code to collect my battery soc data from my BMS and relay that to the BCM interceptor. Or I can just leave my device as is, with the soc set permanently at 19 bars, my BMS already tells me when my real pack is low.

I could do with a decent name for the BCM BATTSCI DATA BUS INTERCEPTOR, ideas please.

It could also be used on the METSCI BUS if required.

The ultimate goal of this project is to do away with the OEM BCM in the end. I think that is looking quite acheivable now.

Without the OEM BCM the BCM interceptor would receive data from MCM on the METSCI bus and send data on the BATTSCI bus to the MCM. We already know the structure of the METSCI data and are now about 75% there with the BATTSCI data.

Peter
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #24 (Edited)
I've done a bit more capturing of data with the IMA cycler on my standard car. I'm also away on holiday for 10 days now, so no more progress for a bit. I'll try and sort my ICSD and make some changes to the codes I am sending to see if I can get the full range of soc on the display via the BATTSCI bus when i get back. I've done about 100 miles now with the soc faked at 19 bars and that seems to work very well :) It's not moved an inch!!

It would be very useful it others could revisit the data we have previosusly uploaded on this and the analysing thread including the spreadsheets and logic captures to add their own thoughts on what we have so far. Please also read randy's notes and our combined findings.

I'm a bit stuck on the maths for Current and the like with left shifting, high and low bytes. Arrgghh.

I've combined randy's posts into this resume below.

'2 x 12 byte data packets on BATTSCI RS485 Bus 9600,8,E,1

'0x87,0x40,0x58,0x15,0x6E,0x10,0x01,0x32,0x2F,0x2F,0x04,0x39

'0xAA,0x10,0x00,0x00,0x00,0x20,0x40,0x61,0x10,0x01,0x00,0x74

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.

The 10th byte in both messages is a copy of the B3/B4 byte in the METSCI channel. The 87 message has a copy of the B3 code, the AA message is the B4 code. They change whenever the BCM gets a new message on the METSCI bus. I tried sending fake messages to it, and it always replies (up to 0x7f) with whatever you send. Strange things happen to the BCM. The B4 code can turn the battery fan on, even.

The 1st byte of AA is like another comm check code. If it can't hear METSCI this is 00, otherwise it's 10. It doesn't need the B3/B4 codes to set this though.

The 5th and 6th byte of the 87 code, and the 8th and 9th byte of the AA code is current. It's normally 1000 hex for no current. Higher than that goes into the battery, low is drawing from the battery. The second byte is less significant, for example 1 amp is a 1016, 6 amps is about a 107c code, then 7 amps is 1111. It counts to 7f on the lesser byte, then increments the next one. Drawing 6 amps is an 0f06 code, 7 is 0e71. I ran a wire through the core to get the scale of it (without messing with the battery). 25 amps is a 0c01 code, or a 1401 code. I'm still figuring how to convert it, but it seems pretty linear.

Bytes 3 and 4 on the 87 code seem to be battery level. It goes up when the battery is charging (or it thinks it's charging). Your positive recal actually just jumped from one level to another, then the display started moving. I don't think the BCM is directly generating the display data. It seems to be a 2-byte code like the current, except it also seems to have flag bits in the upper part of the more significant byte. So I think a 1232 or a 3228 are actually very similar codes, more like 232 and 228. I think 550 is totally full, and got some rough measures out of the drive: 32e is like 10 bars, 344 is 11, 358 is 12, 36f is 13, 407 is 14, 419 is 15, 42f is 16 bars. I think the only way to know the cut points for sure is to fake the BATTSCI codes and see what it sends to the display.

I think byte 2 of the 87 code is voltage. Current affects this a lot on the drive, but not when I was just faking the current meter. Your positive recal had a very high code compared to my battery... I think this is how it just spontaneously knew to recal upwards.

I think byte 8 and 9 of the 87 code is temp. Byte 8 always seems equal or higher than byte 9, so maybe it's highest/lowest. On the drive this kept going up until the 6 byte of AA went from 40 to 42, at which point it went down somewhat... I think that's the fan turning on.

That 6th byte of AA seems significant. It's not terribly consistent, but 40 hex seems to be OK, 20 hex is asking for 4 bars of regen/no assist, and 00 is like hidden charging. Except there seemed to be a lot of charging still after it went to 40 while also setting byte 3 of AA to 01 (which is normally 00). So I'm not sure. There were also other codes like 42 or 41.

The 5th byte of AA is a little more clear. A 20 hex there immediately stops regen (when on the brakes until it quits accepting current). A 10 hex might be the same idea, but for assist.

I've never seen the 2nd or 4th byte of AA be anything but 00. Also, byte 7 of AA is always 61, and byte 1 of 87 is always 40. I think I've seen byte 7 of the 87 message change, but it's mostly 32.


I put together a run I did last weekend, this time with time-coordinated METSCI. There's also a time-coordinated voltage from the battery's output terminals, usually 1 or 2 readings per Battsci set.

Similar to the last drive, it starts with a BCM-reset recal (with the engine running), then I drove around and forced it to assist until the battery was drained, then let it charge back up.

Unfortunately it got cut off due to a hard drive crash (apparently desktop drives and moving cars don't mix), but it's about as long as the last one. I removed the redundant bytes from the messages (the
AA/87 headers and the checksums) to keep the file size down. All checksums matched. I also deleted formula-derived columns after row 20 (which shaved off several megs), so just extend those down and copy-paste-values to keep Excel from exploding.

I think I've figured out the voltage code from BATTSCI. You just double data byte 2 in the 87 code to get voltage. The 87 code bytes 3 and 4 do seem to be related to battery level. The only other slowly-changing fields are, I think, temp, and my guess is double the degrees C. I want to test it out by slowly heating up/cooling off the car with the battery fan running.

The DMM (HP3456A: an ancient 19" rack) was blocking the battery vent inlet, so the battery fan ran a lot. I noticed a distinct relay click at 25 mph... I think it was the battery fan high relay (slower it only ran on low), but I didn't want to reach back there to feel for extra air. I think the MCM is relaying it through the b3 code, by any code that ends with 6 instead of 4. The BCM seems to say it's running the fan on high in AA message data byte 6, with codes that end with 2, but I'm not sure if there's any codes for running on low.

The checksum byte (last byte) is the same on both channels should be easier to compute than to store, even for the METSCI signals. You just add all the other bytes in the message (first 2 in METSCI, first 11 in BATTSCI), negate that (2's complement), then AND by 0x7f to extract the least significant 7 bits. To check just add all bytes of the message, AND by 0x7f and it should be zero.


The 10th byte in both messages is a copy of the B3/B4 message byte in the METSCI channel. The 87 message has a copy of the B3 code, the AA message is the B4 code. They update whenever the BCM gets a new message on the METSCI bus. Before it gets the first code from the MCM, they're 0x06 in the 87 message, 0x18 in the AA message.

The 1st data byte of AA also monitors the METSCI channel. If there's traffic on it, it's 0x10, otherwise 0x00. It starts as 0x10, but it can time out after a few seconds of no traffic.

The 3rd and 4th byte of the 87 code, and the 8th and 9th byte of the AA code is battery current. They aren't copies of each other, but they sample the same thing in the same format. It's normally 1000 hex for no current. Higher than that goes into the battery, low is drawing from the battery. The second byte is less significant, and only carries 7 bits. So 0f7f is a slight draw, 1000 is zero, then 1001 is slight charging.

I put another wire through the current sensor and ran a test current to get the scale. It's in units of about 1/20.5 of an amp (~50 mA). To get a single number from the code, left shift the first byte 7 bits and add to the second byte (e.g. 1000 code -> 800 hex = 2048 decimal). Then subtract 2048 and divide by 20.48 to get current in amps. I'm guessing on the last digit there, but it would put full scale at +/- 100A
SOC Bytes vague notes from today

14 21 when decrementing falls to 11 7A and then continues down to 11 6A.
Falling Soc. This could be the neg recal point during my discharge test.

14 7f when incrementing jumps to 15 00 and vice versa. Climbing SOC
15 7f when incrementing jumps to 16 00 and vice versa. Climbing SOC

16 37 = 20 bars SOC
16 39 = 20 bars with regen
16 3A = 20 bars with regen
16 3B = 20 bars with tiny bit of regen
16 3C = 20 bars no regen allowed

I feel a bit alone on here :(
 

·
Premium Member
Joined
·
2,833 Posts
I feel a bit alone on here :(
Sorry.

I wish I had more support I could offer / add... but I don't see much I can offer directly... I watch this project all the time ... I look forward to and enjoy every update... I see massive potential ... I have enjoyed all the progress made so far... I just don't see much I can add or help with. :(

Sorry.

I feel like the fan in the stands while you are the one down on the field.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #26
Thanks Ian, it was feeling like everyone had drifted off and I was just tinkering away and talking to myself. Any thoughts or ideas from others are very welcome to enliven the thread/discussion. People may have an idea/piece of data that seems insignificant or irrelevant to them, but that small scrap of information could be vital/useful so I encourage people to participate at all levels. Peter
 

·
Premium Member
Joined
·
1,431 Posts
Sorry.

I wish I had more support I could offer / add... but I don't see much I can offer directly... I watch this project all the time ... I look forward to and enjoy every update... I see massive potential ... I have enjoyed all the progress made so far... I just don't see much I can add or help with. :(

Sorry.

I feel like the fan in the stands while you are the one down on the field.
Same here, I'm frankly amazed at the progress you are making.
 

·
Registered
Joined
·
1,616 Posts
I too am following this. I haven't yet gotten into it as I had hoped to but I will try to read over that last post and am trying to get a programmer and some software so I can help. BUT...I have so many projects going on now that I may renege on that promise. I want to, but while the mind is willing, the body is weak. Summer is over now and we are getting some decent weather now where I can work outdoors and I need to take advantage of it. BUT...I promise I will TRY.
 

·
Premium Member
Joined
·
2,391 Posts
I too am following this project, the BMS project with picaxe microcontrollers, the PHEV thread, EV thread in its planning stage(which I would also like to duplicate with a 35 cell(112 volt nominal) 200Ah pack in a few years with the more powerful AC50 motor made by the same company as you planned in that thread, grid balancer, lifebatt thread, and various other threads you have up. This will likely prove useful to me as well since I prefer to keep things as stock looking as possible if I were to convert to LiFePO4 in the future. I've put in my 2 cents for other threads and I'd contribute to this one but I don't understand CAN bus signals, but I'll put my 2 cents in when I've got some information that fits the topic of this thread to help.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #30
More Tweaking

I'm now controlling my BCM Interceptor with a couple of push buttons and sending some different codes to see what happens. I'm still collecting data from the other car and I haven't worked out the codes to stop assist or regen yet.

I need these codes for the Lifebatt install as it has an Over & Under V output which I will use to trigger the BCM interceptor to send the right codes to MCM. I can make gauge go up and down from 1-20 bars but I am missing something in the flag bits to disable assist/regen at each end of the soc scale.

Got some more data today so need to look at that. Now my ICSP is working it's a bit easier to try different codes.

Been working on the BCM interceptor schematic and removed a few picaxe specific parts and developing a pcb specifically to work with a Lifebatt system with grid charging.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #32
The stop assist/regen may be the Qbat signal, and not be on the battery serial bus?
Well remembered Mike my tunnel vision had set in :) I'll have to get scope on that in next few days. I'll persist with SOC & BATTSCI codes for a bit longer though. Haven't got manual in front of me does, QBAT run from BCM to MCM or from ECM to MCM? My latest data capture failed as I had set serial device wrongly so will gather some more data tomorrow.

I'm driving around quite happily with SOC held at 19 bars though via the intercepted RS485 bus, that suggests QBAT may not be involved as surely that would be setting up some sort of conflict as it is not faked at present and must be sending empty message as OEM SOC will be at zero.

I have fitted a couple of buttons which when activated change SOC byte values to either full or empty as recorded from my other car, the gauge responds but assist regen seem unaffected!? More analysis required, wish I understood binary maths a bit better!
 

·
Registered
Joined
·
132 Posts
i'm a bit slow tonight, but in the end will this be a combo of the "fake module" and the module from the phev thread...? since i still need to save up money it will take some time before i get an insight

but it could be awesome to have one board that "does it all" and replace that with the bcm module... if "**** hits the fan" you could always keep the original bcm in a antistatic bag inside the spare wheel.....

while i'm in the crazy corner why not combine mima and this in to one?
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #34 (Edited)
At the moment it feels like I have 20 modules running in my car!!

BMS, BCM Fooler, BCM Interceptor, MIMA!!

Just to clarify a bit.

When I first did the PHEV upgrade I used the taps on my battery cells to produce the voltages required by the OEM BCM battery taps. I choose 50 cells as that divided nicely providing the correct voltages. However the three bar SOC bug caused some problems.

I then used the "BCM fooler" which uses a potential divider to break down the full Lithium pack voltage for the taps into the OEM BCM without requiring taps on the battery. This also helped as I used another DC-DC converter to boost the apparent voltage when SOC hit three bars and I could command positive recals at will. It worked well for over six months but could be a nuiscance if you hit a hill and needed assist but also needed to recal.

I then moved on to the BCM/MCM data bus and we now have a device the "BCM Interceptor" which intercepts the BCM to MCM signals, replacing the SOC with your choosen value. This is still developing as we understand the codes more thoroughly. It removes the need for the dc-dc boost converter and forced positive recals. Your choosen SOC can be maintained adinfinitum!! The "BCM fooler" potential divider is still required at the moment as the BCM is still in situ and there is still a lot about the BCM/MCM relationship we don't understand fully.

To replace the BCM we have to have a system which gathers the same data as the OEM BCM and sends it to the MCM in the same format, this includes.

Battery Voltage (We can't fake this)
Battery Temp (We could fake this and say battery is always at 20C) I need to try this.
Battery Current (We can't fake this)
SOC data (We can fake this :) )

At the moment I'm happy to let the OEM BCM do some/most of the work. Passing through data like current, temp, voltage unmolested.

The MCM also measures current and pack voltage so any system we use must produce readings which concur with the MCM or an IMA error will result. So reasonable accuracy is required and then conversion into the various data structures used to send the data.

The full fake BCM is not an easy project. But perhaps over the comming months it 'may' become a reality.

I would love a single PCB with everything on it which fits into an old BCM case, perhaps one day.

At the moment the Lifebatt Rally car upgrade is my top priority and I'm working hard with Paul on this. He will probably just use the interceptor to hold 19 bars soc until the Lifebatt BMS gives an under voltage alarm and he has to deactivate assist using MIMA. I'm trying to automate this by sending assist/regen disable codes in response to the BMS alarms at the moment. I have just been re-reading Randy's data and have some new ideas to try tomorrow. :)
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #36
when/if one day there is one pcb with all in it.. do you think mike would mind it also includes mima?
I have agreed with Mike not to do anything with MIMA apart from my own projects for the time being. His full MIMA system is available off the shelf, is well tried and tested and I highly recommend it. I bought one and encourage others to do the same, buyers of his system get great support and it will encorage him to develop it even more :) Mike spent a lot of time and money developing and building the MIMA kits, I have no wish to encroach on this development.

Of course if MIMA could run alongside any BCM Interceptor/BMS etc that would be great. Mike and I are in regular contact so are aware of each others work and progress.
 

·
Premium Member
Joined
·
2,391 Posts
When I first did the PHEV upgrade I used the taps on my battery cells to produce the voltages required by the OEM BCM battery taps. I choose 50 cells as that divided nicely providing the correct voltages. However the three bar SOC bug caused some problems.

I then used the "BCM fooler" which uses a potential divider to break down the full Lithium pack voltage for the taps into the OEM BCM without requiring taps on the battery. This also helped as I used another DC-DC converter to boost the apparent voltage when SOC hit three bars and I could command positive recals at will. It worked well for over six months but could be a nuiscance if you hit a hill and needed assist but also needed to recal.

I then moved on to the BCM/MCM data bus and we now have a device the "BCM Interceptor" which intercepts the BCM to MCM signals, replacing the SOC with your choosen value. This is still developing as we understand the codes more thoroughly. It removes the need for the dc-dc boost converter and forced positive recals. Your choosen SOC can be maintained adinfinitum!! The "BCM fooler" potential divider is still required at the moment as the BCM is still in situ and there is still a lot about the BCM/MCM relationship we don't understand fully.
Now that the 50 cell count isn't needed with the implementations of the "BCM Fooler" and "BCM Interceptor" Is the same low voltage issue there? I think you mentioned somewhere around 130-140) where the SOC would drop to zero and stop assisting. Now that it's pinned at 19 bars does it cause any issues if you were to use a short burst from the LiFePO4 pack and the pack sagged lower to say 125 volts, besides the packs issues regarding minimum voltage ranges, does the interceptor keep the low voltage disable from happening? If that isn't an issue, would you rather have more than 50 cells or less? I figure if 3.6 volts per cell at 180 volts works out well that 50 sounds like it would work the best, but with your experience, if not 50, which direction would you choose to go with the number of cells to use?
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #39 (Edited)
Good questions MN. Difficult to be definitive at the moment but.

My 50 cells are safe to a max pack voltage of about 192V when fully charged to 3.85v each. I don't charge them to this though, I use a max of 3.55v for a charged pack voltage of 177.5V. This gives a bit longer life. Under heavy assist in the cold when charged they sag to 3.10V (155V) or so. When warmer the sag is less, the average no load voltage is about 3.3V for mine and similiar lifepo4 cells.

My pack when fully discharged to about 2.7v per cell drops to 135v under load. I haven't tested this end of the scale for some time. I don't believe that this voltage would be a problem now as the SOC is held high until my BMS signals the pack is exhausted. Also the BMS is looking for one cell to go below minimum V and all the others will all be usually quite a bit higher so even though the pack is exhausted it's actual voltage is still quite reasonable. All the cells don't suddenly go flat at the same time sadly!! You probably don't reach the old BCM low pack voltage trigger point anymore. You certainly don't reach the cell variation trigger point as the potential divider in the fooler makes the pack appear perfectly in balance.

The SOC related end of assist we used to see with the OEM BCM/PACK is due to the SOC bytes changing. (neg recal or one cell reaching empty or pack voltage < X etc etc)

The Voltage related end of assist may not be sent seperately but in the SOC bytes which we are faking.

I will drive my pack to the edge over the next few days and report back.

I think 50 lifepo4 cells is a good round number and seems to give be a good working voltage range. You may get away with a few less higher capacity ones as they will sag less.

We have 52 lifepo4 cells in the Lifebatt rally car conversion but they are much higher C rated so can deliver the power without sagging so much. it is about 170v nominal voltage.

You need to operate with cells in a voltage window which allows full assist/regen without triggering alarms at either end of the scale. I think the maximum voltage the system will tolerate is about 185-190V, but you can't have a 190V pack as you have no headroom for charging/regen etc.

My pack is about 165v nominal no load voltage.

I think anything with a nominal voltage of betwen 155-165V should be fine.
 

·
Administrator
Joined
·
11,011 Posts
Discussion Starter #40 (Edited)
I've found the codes to disable assist or regen on command this morning :)

The BCM interceptor has been sending these codes now on button command and the effect is soft disable of assist or regen.

It takes 2-3 seconds for regen/assist to fade away when over or under V activated and a few more seconds to return when over or under V condition is removed. This should work fine for the Lifebatt rally car pack.

I also need to add this feature to my BMS so it can send the appropriate signals to the BCM interceptor. I do sometimes have to manually disable regen at the moment when pack is fully charged and it was wanting to charge!! Now it should all be sorted automatically.

I haven't even looked at QBATT, wonder what it does?
 
21 - 40 of 533 Posts
Top