Honda Insight Forum banner
661 - 680 of 770 Posts

·
Administrator
Joined
·
13,067 Posts
Motor heating has been discussed many times before since the first days of conversions well over ten years ago.

I don't live in the hot USA but temperate cool UK so my experience is therefore biased to the cooler end of the spectrum. But we do get odd hotter days.....

Using manual assist/regen over the years I have emptied multiple packs of 170+V or so and 20/40ah capacity into the motor in relatively short periods..

I have never suffered a motor failure in nearly fifteen years of hacking and modding for more power.. Even upto 30kw.

I even installed some temp sensors in one of my motors years ago but never connected it up to do any actual measurements. :( Sorry...

Based on my experience I would say yes in extreme temps in some of the places/circumstances you have mentioned the IMA motor might overheat, but so will the human driver, IGBT and the battery pack, probably well before the IMA motor.

The new 48S Lithium 5ah packs in this thread simply do not contain enough energy/capacity/endurance to burn out the motor in one long burst of manual assist. It will be exhausted in a minute or two, well before the motor dies. So unless you are towing a trailer full of lithium or have much bigger capacity with bottomless assist I doubt it will be an issue.

IMA Motors are cheap and plentiful as they don't break in normal use, so let's see who melts one first in death valley. (y)

As has been mentioned it's fairly easy to calculate a rolling motor power/duty value from actual motor power (kw) versus time, this value can tick up as the motor is working (assist/regen) and tick down as the motor rests, and power can easily be limited by LiBCM if it stays at too high a level for too long.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #662 · (Edited)
Thanks for the input, Peter! Your empirical observations are worth more than my similar assumptions.

...

I've analyzed the data from my test drive up/down Lookout Mountain last night, with a focus on determining cell ESR as a function of charge/discharge current.
Aside: It's so convenient living a few hundred feet from a 3 mile stretch of road with 1000' of elevation!

My goal is to develop an equation to compensate for the voltage drop that occurs as the battery sources/sinks current. This will prevent voltage sag during heavy assist from prematurely throttling power.

Example: If the resting pack voltage is 3.5 volts, but under -100 A assist it immediately drops to 3.2 volts (illustrative value), then ESR = (3.5 - 3.2)/100 = 3 mOhm. I can then use this ESR value to 'correct' the SoC at a given cell voltage and pack current: V_SoC_corrected = V_cellNow - I_packActual * ESR, which in this example is V_SoC_corrected = 3.5 - 100 * 0.003 = 3.2 volts. Therefore, the equivalent SoC values sent to BATTSCI are determined by this compensated value (i.e. 3.2 volts).

So then this conceptual first order approximation only requires a single ESR value... but alas, lithium battery voltage is highly non-linear as a function of SoC, load, etc. For this reason, the LiBCM firmware will eventually use a current accumulator to determine SoC, but since I haven't written that code yet - and since it's going to take some effort to create - the goal right now is to get a better SoC approximation by slightly modifying the existing method (which simply looks at the overall pack voltage).

So the easiest thing to do would be to simply change the limits from Vpack to Vpack/48 (because there are 48 cells in series). However, based on my testing, this causes the MCM to suddenly change its behavior under load, which is annoying. Hence the 1st order correction.

For now, I've chosen 1.953 mOhm as the 1st order adjustment factor. This value is convenient because it's 2^(-9), which means I can right-shift QTY9 times (i.e. x>>9), which is more efficient than multiplication and division.

Update: The final equation is even simpler, with no multiplication or division...
...one add and one bit shift:
vCellWithESR_counts = hiCellVoltage_counts - (latestBatteryCurrent_amps << 1);

...that's a fast calculation!
Works perfectly on the bench. Time to throw it into the firmware and go for a test drive.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #663 · (Edited)
Definitions:
vSpoof: the voltage MCM thinks the pack voltage is at. vSpoof is set to a constant value by the user at present, so that I can gather data on how the MCM behaves at specific setpoints. Eventually vSpoof value will be automatically adjusted by LiBCM (once we understand the best values to set).

vPack: the actual pack voltage, as determined by BMS (LTC6804).

ESR: effective series resistance... determines how much the cell voltage will drop under load (e.g. 2 mOhm ESR will cause cell voltage to drop 200 mV at 100 A assist).

ESR-adjusted cell voltage SoC ("ESR-ACV-SoC"): The code I've written to determine SoC as a function of actual cell voltage, plus an additional offset to account for pack droop/rise during assist/regen.
...

Notes on test drive with latest ESR-ACV-SoC code:
-If vSpoof is below 128 volts, the car will not auto-start (after auto-stop). Therefore, LiBCM must drop the voltage down to 120 volts when assist current exceeds some threshold, and then restore some higher value when the assist current drops below a certain value.

-If I set vSpoof to 130 volts, the car will auto-start, but won't regen when the brake is pressed. Therefore, LiBCM must spoof a higher voltage during regen; 160 volts allows full regen.

Peak power results (on this test run, and will improve with slight firmware mods TBD):
-with vSpoof=130 volts, vPack=170, 22.0 kW max assist (29.3 horsepower).
-with vSpoof=135 volts, 21.3 kW max assist (28.4 horsepower).
-with vSpoof=150 volts, 19.0 kW max assist (25.3 horsepower).

-As predicted, the voltage-based SoC spoofing isn't good enough to use long term... NMC lithium cell voltage under load has little to do with SoC... the first order ESR approximation isn't great, or at least it doesn't reliably predict the actual cell voltage drop under load.
Update: I had a sign backwards... the ESR-based voltage drop I was trying to correct for in the ESR-ACV-SoC code was actually doubled - rather than nulled - by the ESR-ACV-SoC code. I've struck-through all the statements that are no longer true (and will update them in my next post).

-Right now LiBCM only sends QTY5 SoC values to MCM: 20%, 40%, 60%, 72%, 80%. So when LiBCM changes from one value to the next (e.g. 40% to 20%), this causes the MCM to immediately change its behavior. The result is a jarring loss of assist when transitioning from 40% to 20%.

-The ESR-ACV-SoC code attempts to add hysteresis - to prevent these sudden changes - but it just doesn't work as expected, or well. I played around with various ESR values (e.g. 1 mOhm, 2 mOhm, 4 mOhm, 8 mOhm, 16 mOhm, etc)... they just don't work well, due to secondary cell voltage fluctuations related to the battery chemistry. These secondary influencers are why the correct SoC method is accumulating pack current.

-The per-cell ESR stays surprisingly low during assist:
At 0A, vPack was 178 v
vPack (volts)pack current (A)ESR (mOhm)/cellpower (kW)
1780-0
170126 (assist)1.321.4
Note that vPack is determined by the LTC6804 BMS ICs, which are connected directly to the cells... voltage drop immediately outside the battery modules isn't included (e.g. cabling, the cabling between modules, etc)... with 126 amps sourced from the battery, that's a 'real' 8 volt drop (178-170) across QTY48 cells (166.7 mV/cell).

-The ESR-ACV-SoC code fails to capture the time-based voltage rise/sag. As you continue to source current from the cell, the voltage drops rapidly... more than it would due to either ESR or any actual SoC decrease. This is easily verifiable by watching the cell voltage slowly recover after a large assist/regen event... it takes several seconds to recover.

...

Conclusions:
-The ESR-ACV-SoC code works even worse than I had expected. TBD on next test drive.
-Time to switch to a current accumulator, that only "checks in" on the SoC when current is low. This is how it's really done... I was just trying to kludge something together in the interim. TBD on whether I need to make the accumulator now, or I can put it off until other more pressing features are working.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #664 · (Edited)
With the sign flipped (i.e. voltage drop cancelled out, rather than doubled), the behavior is much better!

On the drive home I dreamed up the equation LiBCM might use to maximize power.
Basically we find the midpoint between the actual pack voltage and 120 volts (the maximum power point under assist):
Code:
                               vAdjustRange_mV = (vPackActual_V  - 12 - 120) * 1000
                                                        vAdjustRange_mV = (vPackActual_mV - 132,000)
Example A (vPackActual_V = 190): vAdjustRange_mV = (              190,000 - 132,000) = 58,000 mV
Example B (vPackActual_V = 144): vAdjustRange_mV = (              144,000 - 132,000) = 12,000 mV
And then we find the 'midpoint' pack voltage between those values, except that we actually want the "2/3-point", since the assist current can be twice the regen current:
Code:
           vPackTwoThirdPoint_mV = vAdjustRange_mV * 2 / 3 +120,000
Example A: vPackTwoThirdPoint_mV =              58 * 2 / 3 +120,000 = 159,000 mV
Example B: vPackTwoThirdPoint_mV =              12 * 2 / 3 +120,000 = 128,000 mV
Next we linearize the (constant) maximum possible assist+regen current (140 A +75 A = 215 A) across the (variable) spoofed voltage range:

Code:
#define TOTAL_CURRENT_RANGE_A 215
                   voltageAdjustment_mV_per_A = vAdjustRange_mV / TOTAL_CURRENT_RANGE_A
Example A: voltageAdjustment_mV_per_A =          58,000 / 215 =  270 mV/A
Example B: voltageAdjustment_mV_per_A =          12,000 / 215 =    56 mV/A
So now we put the last two equations together to determine the spoofed pack voltage:

Code:
           spoofedVoltage_mV = vPackTwoThirdPoint_mV - actualCurrent_A * voltageAdjustment_mV_per_A
Example A: spoofedVoltage_mV = 159,000 - actualCurrent_A * 270 mV/A
Example B: spoofedVoltage_mV = 128,000 - actualCurrent_A *  56 mV/A
And now we know what voltage to spoof for any given actual pack voltage at any given current. Note that the MCM controls the assist/regen current, so LiBCM simply needs to get that current value, which is easy because LiBCM itself determines that value (via the battery current sensor).

Let's look at some "Example A" scenarios:
-no assist or idle: spoofedVoltage_mV = 159,000 - 0 A * 270 mV/A = 159,000 mV = 159 volts
- +50 A (assist) : spoofedVoltage_mV = 159,000 - 50 A * 270 mV/A = 145,500 mV = 145 volts
-+140 A (assist) : spoofedVoltage_mV = 159,000 - 140 A * 270 mV/A = 121,200 mV = 121 volts
  • -50 A (regen) : spoofedVoltage_mV = 159,000 - -50 A * 270 mV/A = 172,500 mV = 172 volts
  • -75 A (regen) : spoofedVoltage_mV = 159,000 - -75 A * 270 mV/A = 179,250 mV = 179 volts

Let's look at some "Example B" scenarios:
-no assist or idle: spoofedVoltage_mV = 128,000 - 0 A * 56 mV/A = 128,000 mV = 128 volts
- +50 A (assist) : spoofedVoltage_mV = 128,000 - 50 A * 56 mV/A = 125,200 mV = 125 volts
-+140 A (assist) : spoofedVoltage_mV = 128,000 - 140 A * 56 mV/A = 120,160 mV = 120 volts
  • -50 A (regen) : spoofedVoltage_mV = 128,000 - -50 A * 56 mV/A = 130,800 mV = 130 volts
  • -75 A (regen) : spoofedVoltage_mV = 128,000 - -75 A * 56 mV/A = 132,200 mV = 132 volts

So let's streamline the code (so it runs fast) and see how it works on the road.

spoofedVoltage_mV = ((vPackTwoThirdPoint_mV )) - actualCurrent_A * ((voltageAdjustment_mV_per_A ))
spoofedVoltage_mV = ((vAdjustRange_mV) * 2 / 3 + 120,000 ) - actualCurrent_A * ((vAdjustRange_mV ) / TOTAL_CURRENT_RANGE_A))
spoofedVoltage_mV = ((vAdjustRange_mV) * 2 / 3 + 120,000 ) - actualCurrent_A * ((vAdjustRange_mV ) / TOTAL_CURRENT_RANGE_A))
spoofedVoltage_mV = ((vPackActual_mV - 132,000) * 2 / 3 + 120,000 ) - actualCurrent_A * ((vPackActual_mV - 132,000) / 215 )
spoofedVoltage_mV = vPackActual_mV * ( 2 / 3 - actualCurrent_A / 215 ) + 614 * actualCurrent_A + 32,000

...hmm, doesn't exactly reduce more than that... time to approximate:
spoofedVoltage_mV = (vPackActual_mV * (0.667 - actualCurrent_A / 256 ) + 614 * actualCurrent_A + 32,000)
spoofedVoltage_V = (vPackActual_mV * (0.667 - actualCurrent_A / 256 ) + 614 * actualCurrent_A + 32,000) / 1000
spoofedVoltage_V = (vPackActual_mV * (0.667 - actualCurrent_A >> 8 ) + 614 * actualCurrent_A + 32,000) >> 10
(^^ always rounds to zero ^^^)
...so that doesn't work because our fixed point math truncates a major portion of the equation to zero.
So going back to this equation (two equations above):
spoofedVoltage_V = (vPackActual_mV * (0.667 - actualCurrent_A / 256 ) + 614 * actualCurrent_A + 32,000) / 1000

Let's multiply that zeroing term by 1000/1000 (i.e. '1'):
spoofedVoltage_V = (vPackActual_mV * (667 - actualCurrent_A / 256 * 1000 )/1000 + 614 * actualCurrent_A + 32,000) / 1000
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A / 256 * 1000 )/1 + 614 * actualCurrent_A + 32,000) / 1000

Approximate some more:
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A / 256 * 1024 )/1 + 614 * actualCurrent_A + 32,000) / 1024

Putting this into computer speak yields:
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A >> 8 << 10) + 614 * actualCurrent_A + 32,000) >> 10
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A << 2 ) + 614 * actualCurrent_A + 32,000) >> 10

And so the equation is:
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A << 2 ) + 614 * actualCurrent_A + 32,000) >> 10

To prevent overflowing a uint16_t, we can divide each half of the above equation by 4 (prior to adding), and then divide by 256 (instead of 1024):
spoofedVoltage_V = (vPackActual_V * (667 - actualCurrent_A << 2 ) / 4 + ( 614 * actualCurrent_A + 32,000) / 4) >> 8
spoofedVoltage_V = ((vPackActual_V * (667 - actualCurrent_A << 2 ) >> 2 ) + 154 * actualCurrent_A + 8,000) >> 8
spoofedVoltage_V = ((vPackActual_V * (167 - actualCurrent_A) + 154 * actualCurrent_A + 8,000) >> 8

That's QTY8 shifts, QTY2 multiplies, QTY3 adds. Not great, but not terrible either. At least we got rid of the division.
So let's compare our CPU_optimized equation to the non-approximated equation:
92190


You can see that our CPU optimized function doesn't have enough gain to get us to the magical 120 volts we want (135 volts calculated, versus 121 expected). This is primarily due to our approximating 215 as 256, which we did because bit-shifting is considerably faster than division ("x/256" is equivalent to "x>>8").

So now let's manually massage the constants to see if we can get closer to the ideal 120 volt value during wide open throttle. <Beep boop boop> Sure enough, changing the equation to:
spoofedVoltage_V = ((vPackActual_V * (167 - actualCurrent_A) + 135 * actualCurrent_A + 8,000) >> 8

yields the following results:
92191


You can see we're much closer to 120 volts during hard assist, with the tradeoff being we don't spoof as high a voltage during hard regen. I doubt that matters.

So tomorrow I'll add this code and go for a test lap up Lookout Mountain. Lots of thinking for a single line equation.

...

For now I've just hardcode the spoofed voltage to always be 150 volts, which LiBCM can spoof across the entire usable SoC. Specifically, that works out to 3.375 volts per cell, which is less than 10% SoC; LiBCM now disables assist below 3.500 volts (20% cell SoC), so there shouldn't be any limitations beyond not achieving peak power.

This will let our beta testers implement a small hardware change and then play around with the latest firmware.
 

·
Registered
Joined
·
1,194 Posts
Excellent research and very interesting findings! Especially that at low voltages, braking does not cause regen. I wonder what led to that design decision.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #666 · (Edited)
Excellent research and very interesting findings! Especially that at low voltages, braking does not cause regen. I wonder what led to that design decision.
I've seen this behavior before with a severely unbalanced OEM NiMH pack. Basically you'd get ~3 kW when coasting, but as soon as the brake is applied regen drops to 0 kW. I suspect the MCM has two different modes, depending on whether the brake is pressed or not. One mode allows regen in an attempt to balance the pack... the other mode disables it because the pack is unbalanced. It's a corner case Honda probably didn't test for, given that they were likely using new packs, not worn out ones.

...

Unrelated: LiBCM firmware is only 3813 lines of code right now... I thought it would be more.
 

·
Administrator
Joined
·
13,067 Posts
Interesting and complicated but are you overthinking it? :unsure:

With maximum power voltage spoofing in all the cars I have modded (Insight G1, HCH1, CR-Z), they have always been based simply on WOT or assist current level being over a certain amount say 50A as an example. It's then like an instant turbo and a nice kick in the pants..

You can spoof the voltages (for the three system inputs) at two set levels if you don't want to use the voltage divider pack voltage derived variable methods. (Note you do need to have a variable VPIN to track the charge/discharge of the caps on ign on/off) However once the VPIN has reached your chosen set voltage during pre-charge you just hold it at that point.

Level 1 = say 165V. The G1 will start/operate/autostop completely normally and allow regen/assist etc.

Level 2 = 120V (only when assist over 50A or WOT) this makes the MCM deliver peak current and it reverts instantly to Level 1 when the assist drops/you take your foot off the throttle.

SOC is really a completely separate factor and not really relevant to max power voltage spoofing except perhaps as a low value cut off, i,e, if SOC is less than 30/40% then don't allow 120V hack.

Yes it's nice to calculate ESR etc but is that needed for the 120V hack?

SOC Will come later with current/coulomb in/out counting and some sort of top balancing and recalibration type routines.

My 120V hack simplified activation logic flow might look like this.

1) Is the assist current over 50A and/or is the throttle pressed more than 90%?
2) Are all the actual cell voltages above say 3.5V?
3) Is the calculated SOC above say 30/40%? (Not strictly necessary)
4) Is the battery temperature acceptable?
5) OK Engage 120V hack..
6) goto 1 ;)
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #668 ·
Your way certainly works. However, I'm looking for a more elegant solution than 'on or off'. My proposed equation:
-method coaxes the MCM into ramping the power up faster, due to the way the function acts as a bounded positive feedback loop. Specifically, as soon as the MCM applies current, LiBCM will proportionally drop the spoofed voltage, which will cause the MCM to apply more current, which will cause LiBCM to drop the voltage even more. This yields a much faster assist, and should make the car accelerate faster.
-proportionally ramps the current up, rather than suddenly activating it at an arbitrary set-point.
-is non-modal; the same equation applies at all times.

LiBCM is entirely capable of handling the additional CPU load. My rambling last night was just to figure out the math. I still haven't tested it today... today I'm dealing with non-Insight tasks.
If for some reason I'm not able to get my proposed equation working in the car, I'll look at adding your binary solution.
 

·
Administrator
Joined
·
13,067 Posts
The power hacks are two stages.
I assume in LiBCM they will eventually be toggled on/off in the firmware via the Nextion screen.

1) Current Hack (Two fixed values +20% or +40%)
These give an across the board % increase to assist and regen. Great for daily use..
Activate and forget.. (Needs DIP switches setting on MCM pcb)

2) Voltage Hack during assist. (Fixed or variable)
Hacking the voltage down gives a progressive power (current) increase of about 10A per 10V.
The minimum voltage is 120V and allows maximum current.
Anything between that and the actual battery voltage is a progressive increase as you go lower.

Advantages (Only active when hack is active, so only affects Assist) Regen remains the same.

It's nice to see these hacks being used more widely to improve the cars performance.. (y)
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #670 · (Edited)
Yikes: the lead time for the LTC6820 part is now 2023Q2! I've got QTY90 of them. Each LiBCM requires QTY1. I suspect I'll end up pulling the QTY11 that are on the alpha/beta units.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #671 · (Edited)
Just test drove the new voltage spoofing algorithm (discussed above a couple days ago). While the total power still isn't the 25 kW I expected... I was able to achieve 23.1 kW(peak) on my latest run. That's 31 horsepower from the electric motor! Even though that's only 1 kW more than my previous max, it feels different because as soon as the current starts flowing into the motor, LiBCM starts dropping the voltage proportional to that current. It works very well... almost too well: the throttle is a bit touchy, and downhill regen comes on a bit strong.

Beta testers, let me know what you think about the new behavior by installing this branch. Compare the performance to the main branch, which is identical except for this new code.

Let's zoom in on some data I gathered. Here are a series of assist bursts over 20 seconds:
92227


As expected, you can see that the actual pack voltage (dark blue) drops as assist power (light blue) increases (current * ESR = voltage drop). For example, towards the right side we hit ~22 kW, which caused the actualPackVoltage to drop 9 volts (from 179 volts to 170 volts). The actual current at that time was 129 amps, which means the 9 volt drop robbed 1.2 kW from the IMA motor. The 54S pack will be able to 'recover' this 1.2 kW and 'send' it to the motor* (*The power will still be lost in the pack, but the additional voltage headroom will make this moot).

Looking at vPackSpoof (red), we can see that this new proportional voltage adjustment has a gain function. For example, the nine volt actual pack voltage drop (from above) is spoofed as a 22 volt drop to the MCM (so more assist occurs). This is in addition to the 'static'** 40 volt offset (**not actually static, but rather a function of the delta between vPackActual & 120 volts).

One annoyance with the OEM MCM is just how briefly it will command full assist. I can't wait to install a manual assist/regen controller in the car.

...

Here's the peak assist event:
92229


In this case, vPackActual dropped from 183 volts to 176 volts, which yields a best-case possible current of 24.6 kW (i.e. @ 140 A). However, the MCM only commands 131 amps, resulting in 23.1 kW. I suspect that using a command & control joystick, you'd easily be able to hit that 24.6 kW value with a 48S pack.

...

For completeness, here's regen voltage spoofing (the same function does both assist & regen):
92230


...

So yeah, that feature is working well... now it's just up to the beta testers to decide whether or not they like the throttle "jumpiness". I think I like it.

Update: I REALLY like the new behavior.
 

·
Administrator
Joined
·
13,067 Posts
For regen one of the reasons I didn't use the voltage hacking was that at very high levels it could possibly cause the front wheels to have more of a tendency to lock up in icy/slippery conditions, especially going downhill off the throttle. It can be colder here..

Have I not sent you an IMAC&C P&P? or are you going to make your own?
You will be able to command proper max assist/regen etc then for as long as you like. (y)
 

·
Registered
Joined
·
65 Posts
Yikes: the lead time for the LTC6820 part is now 2023Q2! I've got QTY90 of them. Each LiBCM requires QTY1. I suspect I'll end up pulling the QTY11 that are on the alpha/beta units.
When I looked on eBay and Aliexpress, I found these, among others:

Any reason these wouldn't work?
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #674 ·
When I looked on eBay and Aliexpress, I found these, among others:

Any reason these wouldn't work?
They're either rejects, recovered, or counterfeit... that doesn't mean they won't work, but in my experience about 10% of ali-sourced ICs fail.
 

·
Linsight Designer
Joined
·
2,626 Posts
Discussion Starter · #675 ·
The power hacks are two stages.
I assume in LiBCM they will eventually be toggled on/off in the firmware via the Nextion screen.
Eventually all the parameters in config.h will be runtime configurable on the Nextion screen. For now they're compile-time by commenting/uncommenting them in config.h.

1) Current Hack (Two fixed values +20% or +40%)
These give an across the board % increase to assist and regen. Great for daily use..
Activate and forget.. (Needs DIP switches setting on MCM pcb)
I'll be sure to make it very clear to users that any value besides OEM (+0%) requires the current hack PCB to be installed inside the MCM... I don't want people thinking they can activate this feature without that hardware present.

2) Voltage Hack during assist. (Fixed or variable)
Hacking the voltage down gives a progressive power (current) increase of about 10A per 10V.
The minimum voltage is 120V and allows maximum current.
Anything between that and the actual battery voltage is a progressive increase as you go lower.
This dynamic voltage spoofing feature is working quite well in my car. No additional hardware (besides LiBCM) required for voltage spoofing.

Advantages (Only active when hack is active, so only affects Assist) Regen remains the same.
As implemented right now, this hack affects both regen and assist. You had previously raised concern about ABS activation if we also spoof pack voltage during regen. Note that LiBCM's implementation at present actually spoofs a higher voltage during regen... which will make the IMA motor less likely to break traction at the wheels. Given that any ABS activation disables IMA regen (until the next assist request event), I don't see any risk in spoofing a proportionally higher pack voltage during regen. Let me know if I'm missing something.

Ultimately if we do decide to disable pack spoofing during regen, that'll just be a one line code change (nothing in hardware).

It's nice to see these hacks being used more widely to improve the cars performance.. (y)
Today I drove a G1 I haven't added LiBCM or current hack to yet... my goodness it's slow! I'll never be able to go back to an OEM IMA system.
 

·
Administrator
Joined
·
13,067 Posts
I think ABS only works if you are pressing the brake, and therefore coast down regen locking the wheels on a slippery surface would not be disabled by the ABS system control signal..:unsure:
 

·
Registered
Joined
·
384 Posts
I don't know how my Chevy Bolt EV regen works as far as slippery surfaces are concerned, but the regen is dramatic, WAY MORE than the Insight. They call it "one pedal driving". You moderate the gas pedal rather than just take your foot off, because the regen is that strong. I hardly ever use the brakes in the Bolt. Also, there is an additional momentary paddle on the back of the steering wheel to add even more regen if needed.
 

·
Registered
Joined
·
384 Posts
I should add that in the Bolt EV, there are two drive options regarding the shifter, D and L.

D = driving without a lot of regen (the regen paddles on the back of the steering wheel are still active)
L = one pedal driving

(There is no change in RPMs that is typically associated with D and L. The gearing is the same in either D or L)
 

·
Premium Member
2001 5S "Turbo"
Joined
·
11,561 Posts
Curious, is there a "tach" in the Bolt? Did you get your recall on the battery?
 

·
Registered
Joined
·
384 Posts
"No" regarding the tach...there isn't any transmission per se, just 7.05:1 "differential" gearing.
"Yes" on the recall. I'm sure I'll get a new battery installed by the end of October. I just don't know which year!
(aka...check's in the mail....LoL)
 
661 - 680 of 770 Posts
Top