[mudder]

Jeff @jeffffej got to drive my Insight with LiBCM today. +40% 48S and v0.4.4 (beta) firmware

Glad you like it, Jeff!
I couldn't agree more: LiBCM (with +40% current hack) is a completely different car.
I particularly like that:
-I can just always stay in 2nd gear in congested traffic.
-I can stay in 4th gear down to ~20 mph, and then accelerate back up to speed.
-I can drive up Lookout Mountain in 3rd gear

 

[mudder]

Last week I drove 1700 miles on LiBCM in below-freezing temperature. Nothing major to report, other than that everything went well. After spending several nights in below-freezing temperatures, the lowest observed battery temperature was -9°C (16°F). After driving around for an hour, the cabin air temperature warmed the battery to 3°C; the the IMA system disabled, thus preventing regen (to heat the battery). After another couple cold nights, the battery was once again at -9°C, and then warmed to 6°C with both forced regen (to heat the pack) and cabin air heating.

One major conclusion from this is that regen-based heating isn't terribly useful, primarily due to the low cell ESR. On the contrary, cabin air heating (i.e. enabling the battery fan when the cabin air is warm) is quite effective at heating up a cold battery. Specifically, blowing air across the cells warms them up 400% faster than regen-based heating.

...

Tonight I'm back in Chattanooga and have just started recording the final installation videos. LiBCM is on the home stretch... at least for our early adopters.

 

[Balto]

Last week I drove 1700 miles on LiBCM in below-freezing temperature. Nothing major to report, other than that everything went well. After spending several nights in below-freezing temperatures, the lowest observed battery temperature was -9°C (16°F). After driving around for an hour, the cabin air temperature warmed the battery to 3°C; the the IMA system disabled, thus preventing regen (to heat the battery). After another couple cold nights, the battery was once again at -9°C, and then warmed to 6°C with both forced regen (to heat the pack) and cabin air heating.

One major conclusion from this is that regen-based heating isn't terribly useful, primarily due to the low cell ESR. On the contrary, cabin air heating (i.e. enabling the battery fan when the cabin air is warm) is quite effective at heating up a cold battery. Specifically, blowing air across the cells warms them up 400% faster than regen-based heating.

...

Tonight I'm back in Chattanooga and have just started recording the final installation videos. LiBCM is on the home stretch... at least for our early adopters.

Wooooo!!!! I'm so excited!

 

[Mario]

I don't have the datasheet for these particular cells, are they okay with charging below 0C? I know most li-ion cells must NOT be charged below freezing, or damage/fire can result.

 

[joeaax1j]

I don't have the datasheet for these particular cells, are they okay with charging below 0C? I know most li-ion cells must NOT be charged below freezing, or damage/fire can result.

Wow, I hope that isn't an issue. I know that our 2015 plugin Prius charges below freezing.

 

[mudder]

Regen below freezing is certainly hard on the cells, but is allowed at up to 25 amps below freezing. LiBCM is presently limiting current to 25 amps below freezing.
Charging below freezing certainly shortens cell life... by how much, I don't know. Honda specifies the operating range - with further charging current reductions - down to -30 degC.
FYI: The EHW5 cell uses an LiNiCoMnO2 (NMC) chemistry.

 

[100percentjake]

Really starting to wish I didn't miss the deals on the battery cells, now I'm very unsure of where to get them. This is exciting stuff, nonetheless!

 

[Natalya]

LiBCM calculates the actual lithium pack SoC (including aging).
My goal then is to send a remapped SoC - based on the actual SoC (including aging) - so that the instrument panel's SoC gauge updates... right now it never updates, since we haven't figured out the missing "magic" packet on the BATTSCI line. I'm actually gathering data for this right now.

With my current code it sometimes updates between drive cycles, or if it goes up to 80% spoofed SoC (such as a spoofed positive recal scenario) then it will fill out all 20 bars. The 20th bar is able to go out again when spoofed SoC goes down, but it's rare for the 19th bar to go out.

I did some experimenting today to try to force SoC gauge updates. On the 0x87 frame there's the byte that's usually 0x32. I tried sending it a bunch of different values after a set interval. I sent 0x32 5 frames in a row, then every 6th frame I sent a different value.

Many values did nothing, others caused CEL.

0x00 P1449
0x01 P1449
0x10 P1447
0x11 P1447
0x12 P1447
0x14 P1447
0x15 No effect
0x16 No effect
0x17 No effect
0x20 No effect
0x30 No effect
0x31 No effect
0x33 No effect
0x7F No effect

On the AA frame I tried changing the 0x61 byte to a few different values with the same method as above.

0x00 No effect
0x01 P1440
0x32 No effect
0x60 No effect

So, I got nowhere, but I figured it was worth a shot.

 

[Natalya]

BATTSCI & METSCI DATA

docs.google.com

I found this old spreadsheet Peter put on Google Drive in 2018

I notice here SoC value sent from BCM to MCM is fixed for 17 of the 0x87 frames. Maybe MCM needs to see the same value 17 times in a row in order to properly blend the SoC changes? That's the next thing I'm going to test for sure.

 

[Natalya]

I like that bracket holding the OBDIIC&C. How is that connected on the back? How did you get it to be so stable? I didn't see it move during the drive...You have my curiosity peaked...

In the corner of the vent area there is a tiny panel that can be pulled out, which reveals a black screw. I made a very simple bracket out of aluminum and attached it to the back plastic of the OBDIIC&C and to the black screw. It doesn't hold all the weight very well, but the opposite corner of OBDIIC&C rests on the dash trim, so it works out.

 

[Natalya]

Discovery today while driving:
Spoofed 76.1% SoC = 20 Bars
Spoofed 76.0% SoC = 19 Bars

That's the cut-off point where the 20th bar will go on or off. My current code (it's pushed to the open PR) reliably has the MCM flip between 19 and 20 bars at the 76% threshold.

Important note:
I'm not sending any extra special info or flags or anything -- all I'm manipulating is SoC (as I'm driving by using clutch switch to selectively disallow//allow assist//regen to go back and forth across that threshold) and the MCM kept switching back and forth between 19 bars and 20 bars without fail. I did it about 5 or 6 times before I decided to drive like a normal person on my way to work.

In Peter's data log I also found that the SoC as interpreted by the MCM has its numbers wrapped. On the 0x87 frame sending the following:

0x11 0x48 = 20.0% SoC (this is what I had been using the last few months)
0x21 0x48 = 20.0% SoC (this corresponds to Peter's data)

The MCM responds appropriately to spoofed SoC data from either the 0x11 or 0x21 range, including with how it handles regen and assist. I've updated my code to now use the 0x21-and-up range for the spoofed SoC.

I also set it to update SoC every 17 frames.

The SoC gauge still doesn't operate properly. Going below 76% it seems to freeze, so I'm still not sending the MCM what it wants to see. My next area of analysis from Peter's data will be to look at battery amps in and out and how they affect SoC.

 

[Natalya]

If you look at Peter's data around line 3333 the first bit jumps from 22 to 32 for 17 frames, and then from 32 to 35 thereafter.

Progression:
0x22 0x28
0x32 0x28
0x35 0x6E

When it jumps from 0x22 0x28 to 0x32 0x28 going by what I learned earlier today, my guess is the MCM interprets 0x22 0x28 and 0x32 0x28 as the same number, which would be 29.6% SoC.

Then when it goes to 0x35 0x6E that corresponds with 75.0% so it looks like there was a positive recal in Peter's data a little bit after frame 3333, but in addition to recalibrating up to 75% it also changed the base value of the significant SoC bit by adding 0x10.

Frames 3334, 3335, and 3336
87    40    57    22    28    10    77    32    33    33    04    75            aa    10    00    00    00    00    40    61    10    77    18    06
87    40    57    32    28    10    77    32    33    33    04    65            aa    10    00    00    00    00    40    61    10    77    18    06
87    40    57    32    28    10    77    32    33    33    04    65            aa    10    00    00    00    00    40    61    10    77    18    06

The BCM only changed the significant SoC bit. Nothing else changes.

Frames 3351, 3352, and 3353
87    40    57    32    28    10    77    32    33    33    04    65            aa    10    00    00    00    00    40    61    10    78    18    05
87    40    57    35    6e    10    78    32    33    33    04    1b            aa    10    00    00    00    00    40    61    10    78    18    05
87    40    57    35    6e    10    78    32    33    33    04    1b            aa    10    00    00    00    00    40    61    10    77    18    06

So the significant SoC bit is 0x32 for 17 frames and then we get the positive recal up to 75.0% on frame 3352. The 77 -> 78 is current changing from 2 to 3 amps. Nothing else is happening. Positive recal on BATTSCI is pumping SoC to 75.0%.

On METSCI the SoC slowly climbs from 3 bars before the recal to 19 bars. It takes over 1000 frames to get there -- 4439 is the first frame with 19 bars. On that frame SoC is 0x35 0x70 which is 75.2% SoC. So the SoC from BATTSCI, because it was below 76.0%, probably limited the recal to 19 bars instead of a full 20 bars.

Frames 14639 and 14655
87    40    4c    35    22    10    0b    32    36    36    26    37        aa    10    00    00    00    00    00    61    10    0c    18    31
87    40    4c    35    22    10    01    32    36    36    26    41        aa    10    00    00    00    00    00    61    10    02    18    3b

On 14639 we still get from METSCI 0x33 0x6C on the 0xE1 (SoC) packet, so 19 bars.
On 14655 we get 0x32 0x6D which is 18 bars SoC. 0x35 0x22 SoC is 67.4% SoC.

Shortly before that SoC was higher, 67.5% and above.
Frame 14532 it's at 68.1% SoC.
Frame 14582 it's at 67.5% SoC.

So the 19 to 18 bar threshold may be at or near 68.0 // 68.1 or at 67.5% // 67.6%. I didn't immediately see anything between 14532 and 14655 that looks like a command or something for the MCM to change the SoC. Amperage changes wildly, it looks like an assist and a regen event, and the IMA battery temp goes up by 1 degree, but that's it.

Frames 15489 and 15505
87    40    3c    34    4b    08    69    32    38    38    26    45        aa    10    00    00    00    00    00    61    08    64    18    61
87    40    3d    34    4a    09    0d    32    39    38    26    1f        aa    10    00    00    00    00    00    61    09    0a    18    3a

SoC Bars don't change again until 15505 when they drop to 17.
0x34 0x4B is 58.7% SoC
0x34 0x4A is 58.6% SoC
A little earlier on 15465 it was at 0x34 0x4F which is 59.1% SoC. So the 18 to 17 bar drop might be around 59%.


I'm not seeing anything jump out at me at or before this SoC bar threshold either. I think a better amps in//out --> Spoofed SoC behaviour mimicry is what we're going to need to get the MCM to keep from freezing the SoC gauge.

 

[mudder]

This is great analysis. I'm working on the same problem at this very moment, and just finished gathering a bunch of data.

Notes on this data:
-bytes printed in decimal (whereas Peter logs in hex).
-"Sync BATTSCI:" is any data contained prior to the first '135d' ('0x87') byte
-"Sync METSCI:" is any data contained prior to the first '230d' ('0xE6) byte
-"Key:ON" is when the 12 volt IMA power rail turns on

I'll read over your findings, and will then post back with my own (if any). Here's a video of my setup:

 

[mudder]

FYI: If you want to manually update SoC to any value while the car is driving, take a peak at my "debugUSB_getUserInput" function. You could replace the SoC bytes sent over BATTSCI using this function.

 

[mudder]

Observations on the OEM BATTSCI/METSCI data I just gathered:
Notes:
METSCI data is generated by MCM
BATTSCI data is generated by BCM (OEM, not LiBCM)

When the car is running, the METSCI packet order is always:

However, each time the car is started, the first four METSCI packets don't follow this pattern:

At present, LiBCM's METSCI decoder discards any data that doesn't follow the "running" pattern (first sequence, above), and is thus discarding these first four 'car started' packets (E6,E6,E1,E6). Given that the MCM expects certain data back (via BATTSCI), it's possible that when the MCM doesn't receive that data, it then enters a "don't update SoC" mode? I'll need to look into this.

Supporting evidence: If the key is turned 'ON' - but the car isn't started - then the 'car started' packets are not sent (E6,E6,E1,E6).

If I unplug the MCM (but leave the BCM connected), then the 'car started' packets are sent the next time the car is started. Thus, it appears the 'car started' packets might actually be the MCM telling the BCM "I've received your SoC value and will send it to the gauge".

TODO:
-determine whether MCM sends the "E6,E6,E1,E6" packets with LiBCM installed. If not, then LiBCM isn't sending something the MCM is looking for.
-rewrite LiBCM's METSCI receiver to accept (and not discard) "E6,E6,E1,E6" packets.
-verify BATTSCI packet transmit period is correct

...

Update: The keyON "E6,E6,E1,E6" packets are only sent when the BCM has remained powered between keyON sequences. If you power cycle the BCM, then these packets are not sent on the next keyON.

...

Rationale on why I'm trying to figure this out now (rather than ship LiBCM units):
-I still haven't received the polycarbonate covers
-I only have QTY1 NiMH pack left... and will convert it to lithium when I record the final "LiBCM Install" videos.

 

[Natalya]

I'll try to have a look at this tonight or tomorrow morning. Super interesting.

 

[mudder]

It appears both the MCM & BCM are separately storing the SoC:

With the key off, if I power cycle (i.e. unplug) either the BCM or the MCM (but not both), then the SoC immediately comes back when I turn the car on.

However, if I power cycle both the BCM and the MCM, then the SoC screen is blank until either the BCM or MCM do whatever it is they do to decide it's the "right time" to display data.

 

[mudder]

I'm not seeing anything jump out at me at or before this SoC bar threshold either. I think a better amps in//out --> Spoofed SoC behaviour mimicry is what we're going to need to get the MCM to keep from freezing the SoC gauge.

If we can't figure SoC out tonight or tomorrow by looking over the data, then I'll add this functionality as an optional config.h parameter tomorrow.

FYI: I'm analyzing the data I gathered in the file "Analysis.ods" (openoffice spreadsheet).

 

[mudder]

Notes from the data:
-BATTSCI_SoC (0x87 bytes 3&4) don't have to change for the Gauge_SoC to start updating. See tab 'cold boot', where all BATTSCI_SoC values are 0x2242 and still Gauge_SoC updates.

-I didn't find any "magic" packets that we didn't already know about previously.

-If I power cycle both MCM & BCM, then turn the keyON (but not started), then BATTSCI_SoC starts at 0x0171 and stays that way for 236 seconds (up to line 2375 in "never started" tab). Then BATTSCI_SoC quickly changes to 0x2242, which is the final SoC value (determined after-the-fact, when I subsequently started the car). However, the Gauge_SoC does not update, even after several minutes (because the car isn't started yet).
...
Oddly, during this entire time the METSCI SoC packet value (E1) never changes... it remains 0x0127 both before and after the BATTSCI_SoC value updates (on line 2375). Given that the Gauge_SoC screen can't access BATTSCI (it can only see METSCI), it appears the gauge itself is locking out... but how?

 

[mudder]

It might be the "charge request" byte in BATTSCI (0xAA byte6):
After power cycling BCM & MCM and turning keyON (but not starting):
-0xAA byte6 = 0x20 until T=14 seconds, then:
-0xAA byte6 = 0x32 until BCM determines SoC (until T=236 seconds):
After BCM determines SoC (T=236+ seconds):
-0xAA byte6 = 0x52 until keyOFF

...

If we then turn the key back on (T=0):
-0xAA byte6 = 0x40 until we start the car, then:
-0xAA byte6 = 0x52 as soon as the car starts, until keyOFF
Given that the BCM already determined the SoC (in the above test), the Gauge_SoC displays SoC almost immediately.

...

Now if we power cycle ONLY the MCM and turn the key back to ON, then we get (T=0):
-0xAA byte6 = 0x00 until we start the car, then:
-0xAA byte6 = 0x01 until the enging is running, then:
-0xAA byte6 = 0x12 until keyOFF (not the same as 0x52 above***)
In this test, the Gauge_SoC displays SoC after just a few seconds, which suggests the MCM is trusting that the BCM's reported BATTSCI_SoC is valid.

***elsewhere while driving I saw the value immediately change from 0x52 to 0x12. For example, at line 2258 in "Driving uphill". This is just a single bit flip (b01010010 vs b00010010).

...

Now if we power cycle ONLY the BCM and turn the key to ON, then we get (T=0):
-0xAA byte6 = 0x20 until T=6 seconds, then:
-0xAA byte6 = 0x21 until T=7 seconds, then:
-0xAA byte6 = 0x32 as soon as the engine is running, then:
-0xAA byte6 = 0x52 when the SoC gauge updates

Again, the Gauge_SoC displays SoC after just a few seconds, even though the BCM was unplugged... in fact, the BCM 'knows' the SoC 200 ms after the key is turned on! Maybe I didn't leave the BCM unplugged long enough?

.............

Based on the above, I suppose we need to send "0xAA byte6 = 0x52" on BATTSCI; right now LiBCM always sends 0x40. I'll test this out tomorrow.

Standing by for Peter's "here's what you're missing" comment.