Wednesday, May 11, 2016

Regenerative braking efficiency

As I drive along, I was always curious about regenerative braking efficiency. With Prius, there was small yellow tags on display to show 50 Wh (0.05 kWh) of energy regenerated. For a long down hill, I got multiple of these tags in any 5 minute window (Prius keeps track at 5 minute intervals). But the regeneration efficiency was always suspect. Prius regeneration is very weak, and brake pedal must be applied. Then how much of that is wasted as heat and how much to regen?

On SparkEV, there is no indication of how much energy was regenerated. However, it shows Watts in power being used and regenerated. It also has strong regen in L mode such that one does not need to apply the brakes for many hills. This makes it a good platform for testing regen efficiency.

Hilly road

My method is to take a hilly road of some length and drive down then up, both at same speed. Whatever regen power shown is compared against power to drive up the hill to come up with efficiency.

The key here is to pick the right road. The hill should be steep enough to allow only regen using L mode to slow the car on the way down while keeping up with traffic, yet not too steep that brakes must be applied. Once the brakes are applied, some energy may (or may not) waste as heat, so the experiment becomes invalid. The best is to have the hill long enough so that cruise control takes care of the speed.

Fortunately, I happen to drive on such road regularly: slope of about 8% and 4 miles long. Using cruise control at 50 MPH, I obtain the following.

Flat road: 9 kW to 10 kW
Up hill: 32 kW
Down hill: -9 kW

Power regenerated going down the hill is flat road power plus regen displayed, or 18 kW to 19 kW.

Power used to go up the hill is total power minus power going on flat road, or 22 kW to 23 kW.

Then the efficiencies are

18 / 23 = 78% (worst case)
19 / 22 = 86% (best case)

Power to the battery

These are power shown at the display. But exactly where is that power applied/coming from? Is it at the motor? At the electronics between motor and battery? At the battery terminal? Obviously, it's not inside the battery. We have to make some guesses.

When you step on the accelerator, displayed power goes beyond 100 kW, maybe even beyond 110 kW. Since the motor is rated for 104 kW, the power shown is not at the motor. It could be at the electronics or even the battery.

When you use DCFC, power shown is sometimes 48 kW, which makes SparkEV the quickest charging EV in the world. Given that the charger is capable of 50 kW, 48 kW would be 96%. It seems the power displayed is at the battery terminal.

Then we can adjust by considering the battery efficiency. Let's assume 96% is the estimate of battery efficiency. The result we get is

78% * 96% = 75% (worst case)
86% * 96% = 82% (best case)

Significant figures

SparkEV only gives integer values for power. Indeed, this is why I picked some high power speed and hill to do the experiment to minimize the errors. If I had done this test in slight hill that resulted in only 1 kW difference, I may not even see the difference and large errors would result. For example, 1 kW shown might be 0.5 kW or 1.5 kW, resulting in 100% error! But for 10 kW (roughly), the errors are about 10%.

However, it's not known how the rounding occurs. If 10 kW is shown, there are many possibilities. Some examples are 9.01 kW to 10.0kW, 9.5kW to 10.49 kW, 10.0 kW to 10.9 kW. Then which is it? Unfortunately, I don't dig that deep into this topic. I'll just assume 10% at nominal.

Then the new estimates are

75% * 90% = 68% (worst case)
82% * 110% = 91% (best case)

If I had to choose...

Well, there are lots of values, which one is correct? Probably none of them! We are trying to estimate the efficiency, not come up with absolutely correct value. My pick would be somewhere around 75%. Why? It's convenient to remember: 3/4 (three-fourth).


If one drives up a hill, one has to drive down a hill eventually. For a gas car, all that energy to drive up a hill would be lost as heat when coming down. In effect, that's money floating away as brake dust and heat.

For SparkEV, 75% of that energy gets put back into the battery. That's money in the pocket (or battery). In addition, it saves wear and tear on the brakes. Indeed, this is why my brakes had cross-hatch pattern on the rotors as if they're new even after 7000 miles of driving. Also the lack of heat would result in much longer life for brake components and fluid, although Chevy still has brake fluid change interval at 30K miles.

Combined, total monetary savings would be far more. Since gas car is 0%, it's meaningless to talk about percentage compared to those. But as energy cost savings and factoring in reduced brake wear, it could exceed 100% savings calculated as energy cost.

Alternative experiments

Above experiment was just on a hill. One could also perform an experiment on typical driving scenarios. If the regen efficiency I found hold throughout the speed range, one could think of low speed traffic (slow and go) range to be about 75% of what's shown in range polynomial blog post if one does not use the brake pedal to slow down. However, the efficiency may not hold at 75% throughout the speed range and regen power level. Also, one must apply the brakes to come to a stop or to stop rapidly. As such, 75% is meaningful only as one data point and nothing more. There should be more experiments to find out other values.

One such experiment would be to capture the video of the display as one's driving. Integrating over time would give data even without driving on hills. I asked my dog to hold the camera, but the result was camera with bite marks, and no usable video. Maybe you'll have better luck.

But even with video, one can only go so far. Display is still integer, and the update rate is about once a second and varying whereas hilly experiment was roughly constant power for many minutes. For slow acceleration and regen, this might be acceptable. But for high power regen (60 kW?) and acceleration (over 100 kW), there may not be enough to get much better data. As we all remember from second grade Simpson's rule, you need more boxes to get accurate result.

Beauty of SparkEV

As mentioned before, this test is not possible with Prius, even if it had power display. One reason is that regen is so weak that hilly road test would not be possible without using friction brakes. I suspect this is true with all cars that have regen always tied to brake pedal.

But there's another extreme. There are some cars that tout "one pedal driving" where releasing the accelerator pedal is used to bring the car to a stop. Since regen would get weaker at low speed, the car would expend energy from the battery to slow down. Some say BMW i3 and Tesla behave this way. In effect, this introduces the uncertainly similar to brake pedal induced braking (aka, blended brake); you wouldn't know if the car is using the power from the battery to slow down. That kind of car would be unsuited for this experiment.

The beauty of SparkEV is that regen in L is strong enough, yet knowing that it is only used for regen if the brake pedal is not applied. Supposedly, the new Volt and Bolt have even more modes of regen, but there's nothing like simplicity of SparkEV. In fact, if L is not max regen already, GM should do an update so that L result in max regen without using the battery or the brakes. You really only need D (regen like gas car for old timers), and L (strongest regen using accelerator pedal for most efficiency).


  1. Hello! I did a similar experiment few weeks ago, by going on top of Mont-Royal in Montreal. I used a ODBII bluetooth device to get the power data. I was having 74% of regeneration efficiency, which is in line with your results. I did the experiment at 45 km/h (~30 MPH). I'm impressed by the large proportion of energy recovered.

    You can find the charts and the data here:

    There is one sample per second. If you find any mistake, let me know.


    1. That's pretty good! Are you using torque pro? You can probably do lots of fun experiments, such as recording regen from various speeds and not just for hills.

      How did you get the number for cells E12 to E14? Also, you have to consider that the number from OBD may not include battery loss. I use 96% as battery efficiency, and if you apply that to your result, it turns out about 71%. My data is quite inaccurate due to sig figures, but it could also be that lower speed of your test is slightly less efficient than mid level of my test.

    2. E12 to E14: the distance is estimated from Google Maps, and the efficiency figure is for a speed of about 30 MPH. Indeed, battery losses should be taken into account, that's now fixed.

      I'm working on a trip planner for electric car, and I don't want anybody to run out of power, so I want to have the most accurate model possible. Your blog is a gold mine for information, for instance I didn't know about ecomodder. I also did experiments for efficiency according to speed, and we obtain about the same figures within few percent.

      One question I had was: what's the optimal speed that minimize the travel time for a long distance trip with charging? If one go faster, it needs more energy and more charging time, if driving slowly to save charging time, one needs to drive for longer time. It appears that for a fast charge of 45kW, the optimal speed is 130km/h, well above the speed limit here of 100km/h, and it uses 50% more energy to save only 6% of travel time.

      I also plan to visit all fast chargers here in Quebec, they are deployed sanely to cover the territory by the state utility. While I don't think I'll drive 1000 miles per day, I would certainly do 1000 km a day, and it may take 2-3 days. Here is the optimal route (which some segments are not reachable, but anyway) between all fast chargers in Quebec:

      Thanks again for your blog ;-)

    3. Glad you find my blog posts helpful. I write about questions that I'd like to have answers, and SparkEV gets no respect. Even Wikipedia lacks dedicated entry.

      See my range polynomial blog post and scroll down to 1000 miles a day explanation on optimal speed. I use 40 kW on average for DCFC (13.25 kWh per 20 minutes) since one may have to exceed 80%. Then it works out to be about 70 MPH for 2015 as shown in the graph. I provide Octave script so that you can play with the parameters as you see fit.

      I was going to work on a trip planner app, but things always get in the way. I have dozen more blog posts that are in half done states. I also need to make a "home" page to better organize existing posts. Too many things to do! I hope you make good progress with yours.

    4. Something strange in your spreadsheet is D13, efficiency shown is 0.083 Wh/km, but I think that should be kWh/km (or Wh/m). I'm assuming that is flat road at 30 MPH.

      In your recovered energy, you have to add flat road energy to abs of down hill energy found, because energy from going down hill is used to propel the car at 30 MPH as well as to the battery. Then applying the method I use in this blog post of (downhill + flat) / (uphill - flat) * 0.96

      (0.273+0.166) / (0.646-0.166) * 0.96 = 88%

      Another way to look at it is that available energy at top is 0.538, but the energy recovered is flat road + what went to the battery. Then

      (0.273+0.166) / (0.538) * 0.96 = 78%

      Something else strange is energy to climb. Potential energy of the car plus flat road energy should be less than total energy expended to get to the top, yet (0.538+0.166)=0.704 > 0.646. I suppose climbing resulted in better efficiency of the drive train, though 10% shown seems large.

  2. D13: yeah, unit mistake, right unit is kWh/km @ 30 MPH.

    In particular, the distance variable is flaky, and since the distance is short, it is difficult to have a precise figure. I'll redo the experiment and use the car's data instead of approximating with Google Maps.

    The code for the planner is on github:

    Here is a demo:

    It uses OSM data with the OSRM library. It's a web service that returns JSON with charging stops required, if any. The URL encodes the parameters, such as battery size and state of charge at beginning.

    A graph linking all chargers is built, and the edge weight includes driving time, time to charge and 5 minutes for the charging stop (otherwise, the algorithm returns trips with more stops than strictly required). A link is added from the start to all reachable charger, and from all reachable charger to the destination. The best path is simply done with Dijkstra shortest path.

    This solution somewhat elegant, but does not scale well with a larger number of chargers (O(n^2)), I need some heuristics to reduce the number of edges. In fact, the more range a car has, the more edges will be in the graph while charging needs is reduced. I still don't have a straightforward solution to that.

    If you want to chat, here is my homepage: