Energy /
\ Energy

Range Display

Making a better range estimator. It's an evolution of my SOC Display project

More project files at: See https://github.com/PaulKennett/LeafRange

The idea is to show:

  1. the estimated remaining range (based on battery State Of Charge, State Of Health and battery temperature)
  2. a plot of the estimated range over the duration of a journey and a line indicating the initial range estimate. This iallows you to see how your current driving compares to the initial estimate. That allows you to slow down to achieve the range you want, or if you're doing better than expected you can speed up. The chart gives you much more confidence on a long drive.

See also: https://www.openvehicles.com/ has another range solution, as does LeafSpy Pro. And on the Leaf there's the blue button on the steering wheel that provides a conservative range estimate (it is more accurate than the standard Guess-O-Meter estimate, but errs on the side of being too conservative)

11 May 2022

I've updated the PCB design a wee bit. It's now 80 x 55 mm which gives a bit more room to fit all the modules without overlapping them. (And 80 x 55mm is also large enough for a companion motherboard which will fit a Mega 2650 Embed board - which I have been using for development.)

https://oshwlab.com/paulkennett/LeafRange-for-Micro

LeafSOC usage

The LeafRange motherboard can also be used for the LeafSOC project. The jumpers on the LeafRange motherboard allow you to switch between the Car-CAN bus (for LeafRange) or EV-CAN bus (for LeafSOC).

This new motherboard also has the correct dimensions for the OBD2 plug, plus an onboard push-button.

Note that the LeafSOC project uses a 5V OLED display so the 5v-to-3.3V DC-DC converter is not needed. Just leave it off.

29 April 2022

New PCB's:

now depricated

The Gerber files for this are on the Github page: https://github.com/PaulKennett/LeafRange

3 April 2022

New update in the works. See https://github.com/PaulKennett/LeafRange

27 Aug 2020

Here's what I have so far:

  • the hardware is a duplicate of my SOC Display project (although I'd like to switch to a higher-res and colour display)
  • it's connected to the Car-CAN bus rather than the EV-CAN bus
  • it reads the Gids to provide the current battery capacity

I'm calculating my range estimate based on;

  1. Gids in the battery right now
  2. Turtle mode offset - I have my range reach 0 km when there are 8 Gids, which is about when Turtle mode kicks in (Turtle actually hits anywhere from 6 to 8 Gids depending on the voltage of the lowest cell).
  3. Max Gids based on my observations over the last month
  4. Watt-hours per Gids (I'm using 74.73 Wh/Gid) Note: the Open Vehicle Project uses 80, the 74.73 number comes from the early Leaf hacking days. I use this number to convert Gids to kWh. I may tweak this number later on to more accurately match my cars performance.
  5. average km/kWh
    • my 12 month monthly average is 6.9
    • my summer average is 7.3
    • my winter average is 6.7
    • my best month in 2019 was 7.7
      • my worst month in 2019 was 6.4
      • I'm using data from 2019 because my 2020 data has been screwed up by Covid19 lockdown(s)
      • I've been collecting monthly km/kWh numbers from my car as part of the Flip The Fleet project

Putting all that together my Range estimate formula is: km_per_kWh_12months * ((CarGids - Turtle_offset) * Wh_per_Gid)

For my range estimate example: = 6.9 * (Gids - 8) 74.73)

I've been collecting some data to see if my Range is any better than the standard GOM

This seems to indicate that my range estimate is better than the standard GOM, and maybe a little better than the secondary range estimate that the Leaf provides. [If you press the button on the steering wheel blue up arrow inside a blue circle - the center console will show a map with two range estimates; the optimistic GOM number and a more conservative number.] Cars with the cheaper center console won't get this though :(

Now I'm working on an option to display a range estimate graph that provides a visual projection of the range based on my best month, another line indicating the range based on my worst month, and then the actual range as it changes with battery SoC during the current drive. This provides an intuitive indication of (a) the likely upper and lower range possibilities and more importantly (b) how my current drive is tracking compared to those bounds. So if I'm driving 75 km from home to the Otaki fast charger I'll be able to gauge if I'm driving too hard or too easy.

At this stage the graph looks like this:

Attach:LeafRange_chart_20200901_cropped.jpg Δ

That's estimated range on the Y axis and km driven on the X axis. Then the top dotted line is the range projections based on my best months efficiency value from 2019. The bottom dotted line is the range projection based on my worst months efficiency value from 2019. And the line between them is based on the 12 month efficiency value from 2019. I'm not using 2020 data because it's wildly a-typical (eg. Covid lockdowns). On top of all that I'll plot the actual Range values as I drive.

Of course - in the ideal world (i.e. a Tesla) the car would use a terrain map to plot how the capacity is going to be utilised along a particular journey. My chart will jut tell me how my current driving compares to the long term average. Then I can use my knowledge of the terrain on my journey to gauge the implications of that.

Once I've used it for a while we'll see if this is actually useful or not.

My prototype display is only 128 x 64 pixels so I'm limited to roughly 1 km per pixel on the X axis.

I'd love to double the resolution - but still fit it inside the dash housing. Other cheap TFT display options:

A weird thing I found whilst working on this is that the Odometer values running along the Car-CAN bus are in Miles, not Kilometers. This is odd because mine is a Japanese Leaf (from late 2011) and Japan runs on the Metric system so I would have expected it to be a metric Odo. Also the Units on the dash are in km. The implications of this is the resolution for my range tracking graph is only 1.6 km :(

TODO:

  • get the chart working to show the trail of range estimates for this drive session [DONE}
  • auto adjust the scale on the chart to maximize visibility
  • switch to a colour display [DONE}
  • switch to a higher-res display

2 Sept 2020

More fiddling to get the graph working in a way that is helpful.

Attach:20200902_003342_LeafRange_graph-640x494.jpg Δ Trip Odo top left, my Range estimate top right

Attach:20200902_005321_LeafRange-250x132.jpg Δ The white dot indicates current range vs distance is well below the my projection for this ride (which was over the Wainuiomata hill and back - so that makes sense.)

  • The tiny size of this display makes this much less useful than it might be, so I need to address that.
  • I'll add a a tail to the dot so I can see what has happened during the drive. This will be more useful with a larger higher-res display
  • Might swap the Range number in top left and trip odometer in top left around. Should try a smaller font.

13 Apr 2021

  • I'm now using a 128 * 160 pixel TFT colour display, 1.8" (38 * 63mm) now https://www.aliexpress.com/item/4000016800528.html
  • Currently in horizonal orientation, but working to redo it in vertical orientation
  • I'm in the process of redesigning the chart function so that it uses a horizontal baseline, then plots current range estimate.
  • and the current range will be in a large font above the chart.
  • the new chart will project the range just based on the car efficiency data from the worst month in 2019, which is 6.4 km/kWh.

My reasoning for using that as the base case is it happens to also be about what I get when driving on the open road with 2 bikes on the back. In day-to-day town driving the range chart isn't that useful because I usually have plenty of range. The chart is most useful on long trips where the distance between chargers is important. So it's better to skew the range estimate towards that use case.

OLED display is connected to the Arduino Micro via a 5v-3.3V level shifter:

17 Apr 2021

I've removed all the page switching functionality and this completely removed the initialization delay that occurs on the old SOC display system. It would sometimes take over a minute before get it's first reading of the battery capacity. Now the Range display has "instant" initialization.

4 May 2021


Here's the current state of the project

The design is looking pretty good.

I'm considering switching to a Mega 2560 Pro board. It should provide a minimum hassle upgrade path to get more memory. That would also allow allow me to run both displays off the one processor. At the moment each display has it's own OBD2 module and Arduino Micro.

The program is currently siting at 92% memory usage and I haven't yet implemented a way to adjust the km/kWh number.

To do:

  • improve the odo resolution to be at least 1 km (0.6 miles) so that you don't see gaps in the plot trail (not super important).

5 May 2021

I've worked out a way to adjust the km/kWh factor using the Climate Controls and steering wheel. It's pretty cool. It goes like this:

  1. turn Climate control ON
  2. turn AC OFF
  3. turn vent selection to FEET ONLY
  4. turn circulation to RECIRCULATION
  5. and finally, turn the fan to FOUR BARS

(This is a combination that is unlikely to occur during typical use of the car.)

When, and only when that combination is met - the display will show the current km/kWh factor - and let you adjust it up and down using the steering wheel. Once you've got the km/kWh factor at your preference, then change any of the climate control options and the display will drop out of edit mode and store the new value in permanent memory (EEPROM).

I'm using this table to set the km/kWh value:

MonthTemp (C)km/kWh
Jan17.16.6
Feb17.26.6
Mar15.56.5
Apr12.96.3
May10.46.0
Jun8.15.8
Jul7.35.8
Aug8.45.9
Sep10.26.0
Oct11.96.2
Nov13.66.3
Dec15.76.5

The formula is kmperkWh = 0.09 * temp + 5.1. The R2 value for these temps vs my raw monthy km/kWh readings was 0.931. The temp value above is an averaging of the average NZ ambient temp (NIWA) and the average monthly T1 battery temp reading from Flip the Fleet users. The Flip the Fleet data set is sourced from almost 200 New Zealand Gen 1.0 (2011 & 2012) owners over the last 5 years. So - the temperatures are specifically calibrated for New Zealand.

The temperature value is derived from

TO DO:

  • have edit mode only engage when in PARK!

Program now takes 95% of memory. Partly that's due to using 3 different font sizes although I've compacted the fonts to only include the characters needed (using FortForge).

Considering switching over to using the EV-CAN bus (instead of the current Car-CAN bus) as there's better info available about all the CAN codes for the ZE0 model LEAFs. See https://github.com/dalathegreat

Next improvements

  • try auto setting the km/kWh factor based on the temperature of the battery. I've collected enough data on my car to get a robust correlation between temperature and km/kWh. Which that I should be able to read the temperature from the CAN bus and use a lokup table to set the km/kWh. What I like about this approach is it makes it zero hassle for the driver, and means the range estimates will adjust on a long autumn drive - where the temp is close to zero to start with, then ramps up after a few fast charges and warm sunshine.
  • auto set x scale to match initial Range estimate? Or, at least indicate on the x axes where the initial range estimate is. With my previous downward sloping design this was always explicit. I'll experiment and see what works best.

Wish list:

  • have the Trip odo go from charge to charge. Ie; auto-start at the Trip odo after each charge completes and run till the next charge starts. That would require storing the trip range data in EEPROM so that it can continue after short stops between charging.
Edit | History | Recent Changes (all) | Search
Page last modified on May 11, 2022, at 04:14 am
Powered by PmWiki