New request: Direct km range indication.

[sordoneF]

What I am missing from the driving screen is the direct influence of the kw consumption to the range. Here is the calculation: SOC (in KWH) divided by current consumption (in kw) times the speed (in km/h) = kwh * 1/kw * km/h = km Example: 100% SOC = 22 kwh / 22 kw (or 11 kw) at 100 (or 60) km/h = 100 km ( or 200 km) range. To avoid "range jumping", take a consumption sample (or even a speed sample) every 5 or 10 seconds into an array and average the consumption (and speed) every minute over the array. Otherwise during acceleration you get an instant jump which is not real. A balance between sample rate and range updates should be considered. When the average 1 minute consumption is negative then ignore the values and km range should be "NA". This can happen during long downhill tracks. Speeds below 10 kmh or when the range exceeds 999 km (? for at least now :-) ) for example should also be ignored.

I think now the driving screen takes the km from the display to calculate the "dist. available at dest.". Please add another label which displays the above value minus the "km destination to the target". This will enable to "tune" your speed and consumption better and is an addition to the standard km range in the display which is also valuable.

[fesch]

I see a nice application for a virtual field here :-)

[yoh-there]

Pro: That would not be very hard to do.

Con: But I am reluctant to embark on the idea that we can do better than the BMS / EVC itself can. It will probably lead to more questions than answers. In essence, you are asking for a "better" range prediction, read, with a shorter consumption average than the car does. As the consumption per km is insanely jumpy, especially in start-stop traffic, I doubt it would be useful. On longer trips, the current range indicator never let me down.

If we decide to implement this, I propose a different mathematical approach, that would be easier to tune. Instead of a running average, just take the current measurement and average it with the result of the previous calculation (c = (c[prev] + c[measured] / 2)), possibly with some adjusted weight factoring.

[solmoller]

I do agree that a 1- or 5- minute averrage consumption would be beneficial to better estimate actual range.

Henrk

2015-12-30 10:42 GMT+01:00 yoh-there notifications@github.com:

Pro: That would not be very hard to do.

Con: But I am reluctant to embark on the idea that we can do better than the BMS / EVC itself can. It will probably lead to more questions than answers. In essence, you are asking for a "better" range prediction, read, with a shorter consumption average than the car does. As the consumption per km is insanely jumpy, especially in start-stop traffic, I doubt it would be useful. On longer trips, the current range indicator never let me down.

If we decide to implement this, I propose a different mathematical approach, that would be easier to tune. Instead of a running average, just take the current measurement and average it with the result of the previous calculation (c = (c[prev] + c[measured] / 2)), possibly with some adjusted weight factoring.

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-167967993.

[sordoneF]

The current range indicator works fine but has a long "time response" which does not work well when you shift your "speed pattern" and you miss a more responsive indicator. I agree that a jumpy range does not work, therefor the need for an average over time (make the interval selectable between 1 and 5 minutes) and the kw sampling in an array of say 10 since two samples is too short and will give a jumpy value. If the average kw is above +1 and the speed is above 10 kmh then the range calculation should be done, otherwise "Not Available" is given. I suggest an experimental form to test if it works while driving. In my spreadsheet it works so I think it will if the kw sampling works well.

[solmoller]

It should be fairly easy to make an intelligent calculation, simply store one 'old value', and compare it to the current value of both SOC and odometer. Every x minutes/kilometers, a new average is calculated, and che current value is stored as 'old value'...

2015-12-30 11:58 GMT+01:00 Sordone notifications@github.com:

The current range indicator works fine but has a long "time response" which does not work well when you shift your "speed pattern" and you miss a more responsive indicator. I agree that a jumpy range does not work, therefor the need for an average over time (make the interval selectable between 1 and 5 minutes) and the kw sampling in an array of say 10 since two samples is too short and will give a jumpy value. If the average kw is above +1 and the speed is above 10 kmh then the range calculation should be done, otherwise "Not Available" is given. I suggest an experimental form to test if it works while driving. In my spreadsheet it works so I think it will if the kw sampling works well.

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-167976792.

[sordoneF]

https://upload.wikimedia.org/wikipedia/commons/a/a5/Analog_digital_series.svg Two samples will not work, see above example of a similar data stream. Sample 7 and 8 is 50% down (and range twice up ?) By taking more samples (only positive values), you get a more reliable average kw value. Off topic: how can I or somebody else flag this as an enhancement ?

[yoh-there]

@sordoneF just did that, you can't. Github's choice.

@fesch how would it work if a real field was queried every second, and a virtual field, using that same real field was queried every 10 seconds? I am asking as real (instead of intended) timing would start to be something relevant here.

@solmoller That would only work if you average the new sample with the old sample, and then store that as the old sample, which is what I proposed.

Let's call it the "fading relevance" method. Assuming one sample per 5 seconds (this is an entirely arbitrary assumption), a 5 minute array solution would require 60 positions. You avoid the usage of a value array and instead of weighting all values over a certain time span equally, you would weight the most recent sample at 50%, the previous at 25%, the one before that as 12.5% etc etc.

Cavg = 0.5 * Cprevavg + 0.5 * Cnow

A "fading relevance" would only need 2 variables and far simpler calculations. I would suggest a five minute old sample (so 60 iterations) should have about 1/10th of the relevance of the most recent sample and that would correspond to

Cavg = 0.9624 * Cprevavg + 0.0376 * Cnow

For 1/50th it would be

Cavg = 0.9368 * Cprevavg + 0.0632 * Cnow

[fesch]

Actually the query interval of the virtual field will be passed to the real fields, so what you need is actually not (yet) possible ...

[yoh-there]

@fesch I don't think that is a real problem, but requested calculation polls quite a few real fields, so potentially, it could lead to unexpected results (slower or faster polling), and if a corresponding real field would need to be polled faster, this virtual field would receive far more updates than expected. In this particular case (since there is a real time based low pass filter involved), we would need to make sure the averaging algorithm is only triggered once per intended period, regardless of the received updates. It is not hard to do, but not trivial either (and independent of the chosen smoothing method).

[fesch]

@yoh-there : Let's say, we will add a VirtualField requested once a second. Now this virtual field will receive updates from the real fields also once a second, but the virtual field value may only be updated lets say every 10 seconds. Just put the real fields into an array with an incrementing index. Each time the index overflows the virtual field value is updated (calculated from the saved values of the array) and the index is reset to zero.

Now this could be done with any number of elements in the array to achieve some other timings.

[solmoller]

I have some practice in this field: I have regularly been forced to 'optimize' battery consumption, as my work commute is 120 km, 70 km of it is motorways, so it's really close to what is possible in a Fluence. Anything that updates with a faster than one minute/km frequency is simply not usable.

We could use arrays and get a finer detail level, but really: what you need is something that is stable and gives you an indication that is not thrown off a cliff by climbing a bridge :-)

Henrik

2015-12-31 11:30 GMT+01:00 Bob Fisch notifications@github.com:

@yoh-there https://github.com/yoh-there : Let's say, we will add a VirtualField requested once a second. Now this virtual field will receive updates from the real fields also once a second, but the virtual field value may only be updated lets say every 10 seconds. Just put the real fields into an array with an incrementing index. Each time the index overflows the virtual field value is updated (calculated from the saved values of the array) and the index is reset to zero.

Now this could be done with any number of elements in the array to achieve some other timings.

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-168164348.

[yoh-there]

I think the "problem" with that approach is that if 4 real fields are involved, and the request is every 5000 ms, first of all, the virtual field would be updated (notified) 4 times in those 5 seconds. That could be countered of course by only passing on every 4th update to the activity. I think that is what you are proposing, and I think it is a good idea that we actually should implement in all virtual fields: it would behave more "as expected".

However, I think that solves only part of "the problem" (it is not really a problem, more something to recognize). If one of the real fields is requested earlier, the virtual field will destroy it's timing. The other way around, the timing of the virtual field would be destroyed, and in this particular case, that would really screw up the averaging (for simple immediate graphs or displays, more (or less) updating is no big deal).

To counter that, I think the implementation of this particular virtual field would better just check if the 5 seconds have really passed.

[yoh-there]

@solmoller Yes, you are completely right. If you look at the formula I propose, you can see that any "next" value influences the mean by less than 4%

[solmoller]

To clarify: We don't need to do a rolling average with lots of queries, if we just use odometer and SOC as input

Henrik

2015-12-31 11:42 GMT+01:00 yoh-there notifications@github.com:

@solmoller https://github.com/solmoller Yes, you are completely right. If you look at the formula I propose, you can see that any "next" value influences the mean by less than 4%

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-168168668.

[yoh-there]

What you propose is actually fully implemented in the driving screen??

That is not what @sordoneF meant, he would like to see a faster influence of change in driving style. I.e. when things get tight, reduce speed and "know you'll make it" after 5 minutes. Zoe (I don't know about Fluence) uses a fairly long wielded average for consumption for that calculation (some say it is probably a 200 km average; personally I would expect more of a "fading relevance" algorithm, but using a fairly low influence factor of the recent consumption values).

Maybe I am misunderstanding what you're saying?

[solmoller]

I am a bit handicapped in this discussion, as my Fluence is towed, so I haven't seen the screen for quite some time :-(

The average consumption as I remember it is either very very short time, probably near instantly, or the long term average. I'd like something that is between those two

Henrik

2015-12-31 11:54 GMT+01:00 yoh-there notifications@github.com:

What you propose is actually fully implemented in the driving screen??

That is not what @sordoneF https://github.com/sordoneF meant, he would like to see a faster influence of change in driving style. I.e. when things get tight, reduce speed and "know you'll make it" after 5 minutes. Zoe (I don't know about Fluence) uses a fairly long wielded average for consumption for that calculation (some say it is probably a 200 km average).

Maybe I am misunderstanding what you're saying?

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-168169725.

[yoh-there]

We're talking about remaining range calculation, that is dependant on SOC, or more precise "remaining kWh" and consumption in "km/Kwh". It is the averaging of that last calculation over time we are talking about.

Zoe uses a relatively long term average for that consumption in it's remaining range calculation. It doesn't show it anywhere. The values you cal pull up in R-Link are trip (both A and B if I am not mistaken) based.

In the newer versions of CanZE we calculate immediate consumption. It is a great feedback - feed forward tool for real time driving behaviour, but totally unusable (too jumpy) for remaining range prediction. That is what we're talking about, unless I am the patient shouting "No no no, I am not wrong, YOU ARE ALL WRONG", hehehe

ps: sorry about the towing, that sucks

[solmoller]

Well that is what I am talking about too - the long term number is too long term, and the short term is too jumpy.

What is needed is something that is calculated on data that is an average of the last minute or kilometer - it doesn't take much to store the odometer and SOC once per minute and calculate the consumption from just two data points. I will not insult anyones intelligence by listing a formula, I guess we are all engineers by trade... or something like that.

Henrik

2015-12-31 12:11 GMT+01:00 yoh-there notifications@github.com:

We're talking about remaining range calculation, that is dependant on SOC, or more precise "remaining kWh" and consumption in "km/Kwh". It is the averaging of that last calculation over time we are talking about.

Zoe uses a relatively long term average for that consumption in it's remaining range calculation. It doesn't show it anywhere. The values you cal pull up in R-Link are trip (both A and B if I am not mistaken) based.

In the newer versions of CanZE we calculate immediate consumption. It is a great feedback - feed forward tool for real time driving behaviour, but totally unusable (too jumpy) for remaining range prediction. That is what we're talking about, unless I am the patient shouting "No no no, I am not wrong, YOU ARE ALL WRONG", hehehe

— Reply to this email directly or view it on GitHub https://github.com/fesch/CanZE/issues/295#issuecomment-168173131.

[yoh-there]

Oh I see where you're coming from and where the different approach lies. BTW, I sure hope the formula's I stated were not insulting.....

Now, we use Power (kWh) and Speed (km/h) to calculate the jumpy immediate consumpion (kWh / (km/h) = kWh / km). That calculation really needs a low band pass filter to be useful for range prediction.

What you are cleverly proposing is to take an entirely different approach: sample a SOC value and a precise ODO, calculate the delta's to get a SOC change per x kilometers, and hold that against the remaining SOC. Good approach. We'd need a fairly precise SOC reading (1 percent resolution is not good enough), but I think that is available on the bus.

Yep, I agree, this approach is just as good and far easier to implement.

[sordoneF]

I was thinking of this scenario where you use the seconds of the clock (@sec) to trigger the calculations. Off course I am not sure if this is feasable in the Android app since I am no Android programmer. Maybe it is an out of the box experience. :-)

$sample = 1 Dim $kilowatt[11] ; define empty array with 11 slots.

While True ; run in main loop of CANZE if possible (?)

if Mod(@sec, 5) = 0 and $sample_taken = 0 Then ; every 5 seconds take one sample If [get sample of kw from Zoe] > 1 then $kilowatt[$sample] = {get sample of kw from Zoe} else $kilowatt[$sample] = 0 ; eliminate negative kw $sample_taken = 1 ; make sure only one sample is taken if speed of sample is high within one second. $sample = $sample + 1 ; next sample EndIf

if Mod(@sec, 5) = 1 and $sample_taken = 1 Then ; reset after every 6 seconds to make sure one kw sample is taken $sample_taken = 0 EndIf

if Mod(@sec, 58) = 0 then ; if seconds is almost 1 minute ; calculate average over array $total_kw = 0 for $index = 1 to 11 $total_kw = $total_kw + $kilowatt[$index] Next $avg = $total_kw / 11 If {speed over 10 kwh} and $avg > 1 then {Calculate and Display range} else {Display "NA"} ; reset samples of last minute and empty array $sample = 1 $sample_taken = 0 Dim $kilowatt[11] ; or clear array EndIf

While_End

[fesch]

First of all, Android is no RT system and secondly the actual queue manager works on a "best" effort base. So if I request a given field once a second, the only thing I know for sure is that between two calls there well be at least a second, maybe/probably a bit more. This depends of the priority of the fields and of the number of requested fields with a higher priority.

So if precise timing matters, we absolutely need to deal with relative delta-timing, which will be most accurate.

Finally the field requesting is event-driven, meaning that the certain method is being executed each time the field is being updated. This said: if an error pops up from the side of the dongle, field requests may be separated far more than the requested interval, meaning that the corresponding update-event may not get fired at all!

[yoh-there]

I am closing this issue. The Consumption graph basically now has what we've been talking about. The application uses the kW/100km figure and processes in a very simple low pass band filter.

[sordoneF]

Can you look at this again ? The expected range now never comes above my display range. At SOC 0,30 x 22/11 (kw consumption) x 80 (km/h) = (I would expect to see a) 48 km range Even at 15 kw (as is in my chart below with SOC 29%) 0,29 x 22/15 x 80 = 35 km range The chart now seems to follow my display range and should be more "spiky" or am I looking in the wrong screen ? It seems like available energy is displayed (and calculated) too low. The chart gives 5.6 kwh. At a SOC of 0,29 % x 22 KWh (available to user) I would expect to see 6,38 Kwh. Can you change the text color so (km => red) becomes red so you know which is which. (%) => black. Now it is difficult to see which value is SOC or range.

[yoh-there]

We will not make a better range predictor, sorry. Explained earlier if memory serves me right, but here's a short version. Real time is way too spiky to be useful and even the low band pass filter used in the middle graph is changing too fast i.e. when climbing even the smallest of gradients (like approaching an exit ramp. Further filtering would render..... the car's prediction. I suggest using the driving screen and entering the distance to destination. I think it would serve you better.

You are right re. available energy. The car reports strange values and I think we should simply remove it.

We will not change color in the foreseeable future. Actually the usage has always been fairly consistent: first label = top number (and color) on the right top side = left scale

Mildly related: On the bottom graph I think we should remove the SOC% too. It has not much added value while driving. Driving screens should be extremely simple and instantly readable.

[sordoneF]

It is a pity direct predication can not be done in a better way. I had a situation where I was slowing down due to headwind and my Zoe gave 16 Km range left in my display and target was 18 km. Then we stopped to find a charger, found one occupied, went to the nearby toilet (was at Ikea) and all of a sudden my range went up to 27km after a new start of the car (without charging !). With a better range predictation I would have went on driving to my home. You might consider changing the SOC graphs to a deviation of SOC decline graph. So when the SOC is changing less then average decline, you get a positive value, when more then negative value. Similar to the Econometer graph. That is if you can grab the SOC real time to get a good graph. Would give you a "warning" of wind influence with high speeds on SOC. I agree on removing the avail. energie if it is not correct. Gives a more clean chart of the econometer. (will await any new canze version without the soc or a different soc chart).

[yoh-there]

In my experience it is rather tricky to rely on the "suddenly improved" range. It is often "poofed" in a few km's driving. I assume this is due to a slight ion redistribution in the battery and an overconfident reliance on that last km where you're driving very slowly between the ramp and the parking lot.

Then again, minus 2 km's is doable, see Alloam's "driving it to the bottom" video on youtube. Funny too, with the kids on board who love to trash it ;-)

[sordoneF]

Can you maybe implement something else on the driving screen ? It is the average consumption needed to reach your target destination. When a user enters the kilometers to his destination, you can add a field that will show the maximum average KW consumption (just "15 kw" for example) ) needed to reach the target with zero margin (to 30 km margin = setting). The calculation is SOC (kwh, %soc x 22 kWh) x speed (km/h) divided by (kilometer to destination (plus the margin)). Add a warning for inappropriate low speeds on highways, etc. when for example the value is below 5kw and to consider adding an extra charge in case of low values. I use the kw consumption in my display to tune my speed. This will do the calculation for you. All parameters are pretty stable so it could work. Cool would be if you can change the margin while you drive with a slider. Low margin when are daring or lots of chargers are available or high when you want to avoid the orange and red warnings.

[yoh-there]

I think what you really want is "max allowed speed to reach destination" ;-)

[sordoneF]

You got me figured out. But kw is leading, the right foot must follow. :-) "Max. KW for destination" or similar.

[yoh-there]

@sordoneF We have had one more internal discussion about this and concluded we're not going to pursue this issue. Feel free to have a stab at it though, after all, it is open source. We'd be happy to merge anything that makes sense in the main branch.

[sordoneF]

Is it for both items? Also max kW calculation? I have no intension to dig into the code. I might ask other people if they can do anything in a test screen.

[yoh-there]

To put it rather bluntly "maximum average KW consumption" makes no sense at all, neither semantically, nor is it (IMHO) a useful metric at all for what you want. You'd get in the strangest of feedback loops. Really, the "available distance [in the battery] at destination" is a far better aiming point for what you are trying to do accomplish. If you push the car it will rapidly come down. And your margin proposal is "build in" already: It is up to you to decide what your aiming point is.

To avoid muddling the waters, I will open the somewhat "strange available energy in the battery" as a new issue.

So yes, at this moment we are not considering to implement what you're proposing.