Create Towing Compensation in App

[aesculus]

While the power factor was intended more for driving aggressiveness, it was hacked to provide a means to support towing too.

But now that the power factor is moving more to a speed factor (issue #303 ), we need another way to describe the influences of towing on power consumption. There are two elements of this:

• weight
• drag area (frontal area x coefficient of drag)

Each element works independently but collectively on energy impacts while towing. You could have a very heavy load that has a minimal frontal area for example or a light trailer that sits up like a sail.

Ideally it would be good to have a way to describe both elements (slider for each?) and then a tutorial that describes how to set each element and samples of different types of trailers with their respective settings so a user can take a first stab at it.

These two factors should be placed in the My Cars settings so users can have a profile for their car with and without towing or one for every type of vehicle they tow.

[EVGrokker]

I'm opposed to two sliders, I think it's too complicated.

I'd be in favor of a single slider that combines the factors of towing into a single penalty factor. The help text can explain that the slider value should represent a combination of weight and drag inefficiency, but honestly it's going to be a hand wave at best. If there's some serious subset of users that want a formula to calculate the exact slider value for a 400-lb tongue weight 18' Airstream with a drag coefficient of .xyz, great, tell them how to guesstimate it. A slider with values of 1.0 to 10.0 with steps of .25 should be more than enough.

[aesculus]

I like the idea of keeping it to one simple control. But if it's only energy then we cannot deal with elevation and wind effects, two huge factors that can both hurt and help energy use while towing. And given that we are going to allow a speed reduction with the new Speed Factor setting, I think we need a solution that allows for slower speeds too.

How about a spinner control that has 10 settings in it? Off plus nine other values. They would be a combination of three weight and three frontal area values (3x3). A we could label them light - short, heavy - tall etc and I could do my magic in the background. You could write up the tutorial with examples of which types of towing vehicles would fit into one of the 9 values.

Check this out:

https://www.youtube.com/watch?v=iko35Oqzs2A

[EVGrokker]

Go ahead and implement your concept and let's give it a test drive. Let's allow for the possibility it may take a couple of iterations to get something that feels right.

[aesculus]

Sounds like a plan

[EVGrokker]

When you start working on this, I'd like to invite two TMC users who have posted frequently about their towing experiences, Ohmman and JimVandegriff, to help with the UI design and provide feedback about the accuracy of the results based on their documented trips.

I'm thinking that you could add them to the TestFlight list just for the duration of the 1.2 testing cycle.

[aesculus]

Well Ohmman is one of the first beta testers and I invited him to contribute here. He has been sending me some comments via email which I can share with you. Only have access to JimVandegriff via Ohmman so that would be a good add.

[EVGrokker]

I don't know how active Ohmman's been but this would be a good opportunity to ask him to really focus on this feature. I think you could just reach out to Jim through TMC private message.

[aesculus]

He's pretty hammered right now. Let me send the last message via email

[EVGrokker]

Don't send him anything until you're close to ready. That's at least a week or more away.

[aesculus]

Yeah. Basically if I recall the solution was to create the 2 parameter selector and back it up with help to explain what the two factors do.

There was a bit of skepticism in that he felt most trailer users might just punt anyway. He was going to take a back seat and see what came out of the model, not from a UI perspective, but could it really help? I sense a bit of frustration in that it seems there is not a lot that can be determined other than they suck energy big time. :-)

[EVGrokker]

Let's revisit when we're deep into 1.2 land.

[aesculus]

I just added back in power factor in V1.2 (35). It was a fair amount of work. Here is what I did:

• Used the trip power factor as a 10% increase to create a pf adjustment during energy calcs
• Applied the pf adjustment to the waypoint energy calcs for all but elevation and climate control
• Applied the pf adjustment to the consumption chart energy calcs for all but elevation and climate control
• Applied the pf adjustment to the soc chart energy calcs for all but elevation and climate control

I tried it out and the combination of speed adjust (less to force trailers to 55 mph), increasing the payload to 5000 and forcing the power factor to around 4-6 seems to give pretty reliable results for towing a large airstream like trailer. It will be interesting to see how this matches up with reality.

[EVGrokker]

This feature has been implemented. The only pending refinement was mentioned in #437, to increase the granularity of the Power Factor slider. If you don't intend to to do that, go ahead and close this issue.

[aesculus]

I think I will wait until he gets back and then helps us figure out if it would really have made a difference or not. To me that seems to fine grained.

[aesculus]

He sent me some trip segments and I ran it through V1.2 (56). Waiting for feedback from him to see how close it is.

[aesculus]

From ohmann

On my trip, I had to toy with it based on the kind of roads I was driving. If I’m driving a highway, speed adjust -10 or even -15 can make sense (speed limit 75 for instance). However, when I was on parts of 101 or through country roads in Montana and Canada, 0 or -5 speed adjust is more appropriate. It might be more useful to have a max speed function, but that sounds like a lot more work on the app side.

So for instance, I’d say max speed of 55, which would adjust downward for all highways but in a 50, I’d still be going 50.

Need to think about a way to implement this instead of what we have today for a speed adjust

[EVGrokker]

This seems like an either/or approach, either a percentage below posted limits, or a maximum speed.

I think his suggestion makes more sense than the blanket percentage reduction.

From an algorithm perspective, the implementation would be something like "if the posted speed limit is greater than the user's preferred maximum speed, compute this section at the preferred maximum speed."

[aesculus]

I think we can leave what we have today alone. It would be an overall adjustment (it actually does not get applied until about 40 mph).

What is needed is a 'not to exceed' speed. So after everything has been done with regard to Googles estimates and any application of SA, cap it at the user's max. That should be fairly easy to implement.

Now for the UI. I propose shortening the 90% battery field (can you think of shorter label) and having the other half be for this max speed field. Also probably should move the Speed Adjust under PF so it closer to the Max Speed input?

Also what should we do with the current trip? We could just ignore it and only have it use what the car is set at (I am in favor of this). I don't think its going to get changed enough from trip to trip. But I would like your opinion on this and suggestions to what to do to this panel if you think it should be a factor of the trip too.

[EVGrokker]

Now for the UI. I propose shortening the 90% battery field (can you think of shorter label) and having the other half be for this max speed field. Also probably should move the Speed Adjust under PF so it closer to the Max Speed input?

Logically, the Speed Adjust slider and the proposed Max Speed control are related.

Ideally, I'd like to see these two controls side-by-side.

The current values (percentages) for Speed Adjust are: -20, -15, -10, -5, 0, 5, 10, 15, 20

Proposed values for Max Speed could be (not sure of the country-by-country equivalents): 45, 50, 55, 60, 65

How about if these controls were both implemented as pickers, which would allow them to be placed side-by-side? We'd lose the color-coded background (I assume), but they'd be next to each other as they should be.

Also what should we do with the current trip? We could just ignore it and only have it use what the car is set at (I am in favor of this). I don't think its going to get changed enough from trip to trip. But I would like your opinion on this and suggestions to what to do to this panel if you think it should be a factor of the trip too.

Like you, I'm in favor of keeping this variable associated with the car profile. It's a fine-tuning feature that's only available to Pro users, and it would be associated with a profile designed to extend range, like 'Hypermiling' or 'Towing'.

[aesculus]

Proposed values for Max Speed could be (not sure of the country-by-country equivalents): 45, 50, 55, 60, 65

You would have to go up to 80 mph in the US and maybe higher in Europe (the autobahn?)

I still like the idea of making the 90% battery take half the space and the other half going to the max speed which would just be a number too.

Pickers take way to much room and are not consistent in the UI's. What looks good on an iPhone does not look good on an iPad for example.

[aesculus]

This is what I came up with:

[EVGrokker]

v 1.2.0 (71)

The image above makes it look like a spinner, but what I'm seeing in (71) is a directly editable numeric field.

My preference would still be to see both speed items on the same line, since they are so interrelated. Would you consider a narrower slider for Speed Adjust, maybe 2/3 width, and a numeric edit field for Max Speed with the remaining width?

Another alternative would be to move the 90% range edit control below the Battery picker. In that scenario, I'd place the Charger picker first, then the Battery picker, then the 90% edit control.

[aesculus]

The image above makes it look like a spinner, but what I'm seeing in (71) is a directly editable numeric field.

That was not an iOS image. Sorry for the confusion. Every platform (and sometimes device types) decide how they want to portray certain UI features. It is a text input but set for numerics only.

My preference would still be to see both speed items on the same line, since they are so interrelated. Would you consider a narrower slider for Speed Adjust, maybe 2/3 width, and a numeric edit field for Max Speed with the remaining width?

You may have noticed all the changes for small devices (iPhone SE) in the last two updates. I had to force a lot of stuff around to accommodate that. There is no room for text input and slider on the same line and I am down to pixels vertically. :-(

Another alternative would be to move the 90% range edit control below the Battery picker. In that scenario, I'd place the Charger picker first, then the Battery picker, then the 90% edit control.

This was my best arrangement to keep logical items together without having to add lines or merge content into lines that did not have sufficient room.

[EVGrokker]

The default installation displays a Max Speed value of 0. This is confusing. I see a couple of options:

• Set the default Max Speed value to an upper limit appropriate for the region, e.g. 85 (mph)
• Set the default Max Speed value to the max speed limit for the region, e.g. 75 (mph)

Of the two, I think the second option, using the national max legal speed limit, would be a good default. If the user wants to change it from there, they could do so.

[aesculus]

I considered this and then realized that settings and my cars are not tied together and can be done in any order. So a user could set the max speed to 75 and then go to the settings and change the region which could be different.

And the worse case scenario is that they set the Max Speed in imperial and then change the units to metric. Now the Max Speed is off by about 50%, one way or another.

So while I agree that 0 makes little sense, it essentially means Off.

[EVGrokker]

This reminds me of the discussion about the HVAC setting, where 0 originally meant off.

My suggestion is about the default value, which logically would be the maximum speed limit, unless the driver wants to explicitly say that they'll be driving slower (hypermiling or towing).

The likelihood of a user changing regions is low, and once the driver establishes their units they're not likely to change it, unless they're testing the app.

Can the field be empty instead of '0'?

[aesculus]

< This reminds me of the discussion about the HVAC setting, where 0 originally meant off.

Yes. Exactly the same. We solved that with a checkbox which we could do here too. Running out of room for the labels though, especially the 90% one.

I could put a checkbox to the left of the max speed vs between the two and also gray out the max speed when disabled. BTW I probably need to do that with the cc too.

[EVGrokker]

A checkbox would do the job. What is 'cc'?

[aesculus]

Updated in V1.2 (74). CC stands for Climate Control

[EVGrokker]

The on/off checkboxes look good.

Since the default value for the Max Speed checkbox is off, how about making the default value a suitable number for the region, rather than 0? For example, 55, 65 or 70 in the United States would be appropriate to support the meaning of the field, and with the checkbox now implemented, 0 is no longer a reasonable value. (For me personally, I set Max Speed at 65.)

[EVGrokker]

Question: How does the Max Speed affect the average speed calculation?

I have Max Speed set at 75 before planning a new trip (Seattle - Spokane, all interstate) and the Trip Browser shows an average speed of 64 mph, with 360 Wh/mi.

If I set Max Speed to 65, then Optimize, the Trip Browser shows an average speed of 62 mph, with 349 Wh/mi.

Obviously there is some difference, but not as much as I would have expected.

If the Max Speed is set above the posted speed limit, does that mean the app assumes that I will try to drive at that speed, even if it means exceeding the speed limit?

Or does it mean that I will always drive the speed limit, but never exceeding the Max Speed that I've specified?

[aesculus]

Doing what you want it problematic but not impossible. Here are the issues:

• The Max Speed is currently a per car setting, and would be tempered by Units vs Region IMHO.
• If the user changes the units it would void all of the Max Speed values (note 0 is 0 in any unitary system and therefore this rule does not apply).
• If I do apply a change to the Max Speed based on a conversion formula, there is a good chance it will be off by 1 every time. And this could compound.
• Units are in Settings and therefore a user will probably not notice the change was made. My guess is that even if they did think about their current car, they would forget that there was a setting for ALL the cars that was also being affected.

[aesculus]

The Definitive Guide to Speed in EVTO

Here is how EVTO determines what speed to use:

• Speed is dependent on routing and the routing legs, broken down into steps and is defined by Google. Who knows what their secret sauce is. It's like the weather. Nobody knows how it works, why it does what it does, rarely likes the results and loves to hate on it.
• These estimates only occur during the routing phase of EVTO which happens whenever a waypoint is added or subtracted from the segment. Note during optimization all auto-waypoints are flagged to be removed but turned back on again if they show up in the results, so optimizing does not guarantee a waypoint change.
• The steps are are basically each turn instruction (you can see these if you go to Segment Details and then Export). Each has a distance and estimated speed.
• Speed Adjust looks at each of these steps and applies a integer adjustment to them either increasing or decreasing the value reported by Google, but only if that step is greater than 40 kph.
• The default value comes from My Cars for the car associated with the current trip.
• Speed adjust and Power Factor are set by the car, but the user can change this on a per trip basis. The car value is only used to create the default value. The value used in the calculations is what is set in the Edit Trip Details panel
• Power Factor does not change the speed of the car, but will impact the energy estimates. For this discussion it is not really relevant.
• Max Speed is applied after all of the above takes place. It looks at the resultant speed and caps it at the Max Speed level, providing it's turned on.
• Max speed is currently only set in the car profile, not saved in the trip. So if you change it in the car settings and then change a route, it will use the current car value. This is different than how Speed Adjust and Power Factor are used. There currently is no place in the Edit Trip Details to manage a per trip value.
• The speed you see in any report/dialog (except the Export mentioned above) is the total distance / total drive time for that leg or segment or trip. It is not the maximum speed or the sum of averages etc.,
• The average speed will never be as high as your Max Speed. This is because at least some of the leg will be starting and stopping at waypoints.

So now try to explain all of this to neophytes who don't want to read, don't want to understand any of the above and want the app to intuitively know what their expectations are. Or said another way would accept a perfectly wrong result if it was simply presented.

[aesculus]

OK. You win. I set the app in V 1.2 (78) so the max speed is stored in kph. The default is (105 kph/65 mph). If it turns out there is a 1 mph shift then so be it. It was causing me issues in converting all over the place.

You will only notice this if you start with a clean setup, otherwise you will still see 0.