Unreachable destination shows "-Infinity" SoC; "Out of the way" threshold?

[EVGrokker]

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 0, Rear CC: 0, Bat Life: 90 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (35) IAP: Pro:1, Sub:1 Location: Unknown Trip: Boise ID, [v7mnix9te4p6dvfxlzp3c6]

This trip from Winnemucca NV to Boise ID is 255 miles without any superchargers along the way.

EVTO calculates the shortest route, but informs the user that the destination is unreachable using Auto routing.

However, it would be nice if the energy deficit (arrival SoC) were displayed a bit more optimistically than "-Infinite", for example -15%. This might be a clue to trying reducing speed as an alternative to sourcing a non-Tesla charging option. For example, if I introduce a -10 Speed Adjust, the energy deficit is recalculated to an arrival of -7%, which seems more reasonable. A Speed Adjust of -20 yields an arrival SoC of 2%. An additional adjustment to Power Factor of -10% results in an arrival SoC of 11%. So those sliders seem to be working as expected.

There is a 1772 charger at the Say When Casino in McDermitt NV. Adding that manual charging waypoint resolves the problem, with a 57% > 88% recharge, arriving in Boise with 20%. The total energy required for the trip is 74.8 kWh.

Bottom line, I think it's OK for EVTO to generate a route that's unattainable without manual intervention, either in the form of a manually added charging stop, or voluntary reductions in speed or load. However, we need to be able to describe about the "out of the way" threshold calculations that result in EVTO returning this result.

[EVGrokker]

When I now recalculate this trip, it routes through the Elko and Twin Falls SCs, with a total distance of 424 miles. I may have inadvertently taught the server that there was in fact an available (but much longer) route when I optimized the original trip.

But the discussion topic is still valid. Should there be a threshold, or should EVTO always strive to deliver SC results when possible, even if the route is considerably longer?

[aesculus]

This is one of my test cases. I route through Elko and TF to get to Boise. Then I add a charger in Jordan Valley, OR (a 14-50). The app was designed to charge to 100% at Winnemucca so when you get to JV you only have to charge the minimum time before making it to Boise. It's kind of novel IMHO.

So I don't think you did anything wrong, but if it's repeatable I would like to know. Same with the Jackson WY one. That mystery needs to be solved.

[aesculus]

This trip from Winnemucca NV to Boise ID is 255 miles without any superchargers along the way.

EVTO calculates the shortest route, but informs the user that the destination is unreachable using Auto routing.

Not sure why this happened. It should have routed you like it did via Elko and TF the first time.

[aesculus]

However, it would be nice if the energy deficit (arrival SoC) were displayed a bit more optimistically than "-Infinite", for example -15%.

I am not certain when this was introduced. In the past it has always been a negative number as you requested. I cannot duplicate this for some reason. If you make the trip manual it does show a negative number, so I suspect the optimizer delivered this.

When I tried this trip using Auto I get this (14% arrival at Boise). Using your trip it wants to charge at the Boise SC before arriving.

[EVGrokker]

When I initially created the trip (using Auto) it routed through McDermitt. When I optimized, hoping for a better estimate of the energy deficit, it re-routed. I'm guessing that maybe this trip subsequently was cached on the server and now it won't route through McDermitt again.

Regardless, the right answer is to find the supercharger route, as that's what the user asked for.

However, I was just able to fool it again.

I took the Winnemucca - Boise trip, then added the Say When + J1772 charging stop as a waypoint, thinking that it would then route me along the more optimal route without any supercharging. The route now goes east to Elko, then returns west to Winnemucca before heading north to McDermitt.

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 0, Rear CC: 0, Bat Life: 90 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (35) IAP: Pro:1, Sub:1 Location: Unknown Trip: Boise ID, [v7mnix9te4p6dvfxlzp3c6]

[aesculus]

I hope this is not the result of today's 'Fix'. Sounds suspiciously like it is. :-(

My test case (which I did not validate after the fix) is to do exactly the same thing but use Jordan Valley RV park up the road to Boise. Much better way to do this because you want to charge as little as possible with 14-50 and the best place to do this is when the battery is almost empty.

Once I get this fixed try your way and my way and see which is faster. :-)

[EVGrokker]

Battery purists, bah humbug.

[aesculus]

Time mizer.

Probably not a big deal with a 14-50, since it's so slow. But if you did it with a J it should make a difference. If the batter is fuller it will charge slower. Waiting until the battery is as low as you can means the energy will go in quicker.

[EVGrokker]

Of course I'm kidding. There was a thread on TMC recommending the Say When as a charging stop, so I tried it in the app. I'm always more interested in saving time than losing money!

[aesculus]

There was a thread on TMC recommending the Say When as a charging stop

This is why this is my test case. I saw that thread last year and wondered what I would do.

BTW I have relatives in Twin Falls area. Got there OK last T-Day. Getting back out not so easy. We charged to 90% at Elko on the way there. Late afternoon. Temps were in the mid 30's. Got to our destination with 36% soc. It was down in the Snake River but only 1000 feet or so.

On the way home around 10am it was 24 F. There was a good 20 mph headwind most of the way back to I80 and it's all uphill until you get just outside of Wells. We charged to 100% with 110V but that will not heat the battery. So before we went 5 miles we lost like 10%. Before we got 30 miles the car calc said we were not going to make it to Elko. I turned the heat way down and got behind a semi and drafted with following setting of 1 for 1 1/2 hours. My ace card was a RV park at Wells, NV with a 14-50. Drafting kept me from needing it and I ditched the semi as soon as I crested the pass about 10 miles for Wells. Got to Elko with 13%.

So one way I had 36% reserve and the other way I would have been under water. Ah the joys of EV's. :-)

[aesculus]

When I optimized it removed the Elko charger but kept the path to/from Elko. An artifact of my Directions saving routine? Looking into it.

[aesculus]

I fixed the directions route thing in V1.2 (36) but I think my server fix last night flummoxed the charger allocation. If I just have a trip from the Winnemucca to Boise and optimize, I get SC at both places, but they say they are not being used.

But if I make a trivial change in the trip, I get the Winnemucca SC to got from 90% to 100%. The Boise charger still shows no need.

So this trip will become another test case for me for the two issues above.

[aesculus]

There are a few issues with this trip that exacerbate the apps hidden problems:

• There is sort of a refined mechanism in the trip. The first pass it roughs out it's energy calcs. After that, barring any large scale changes, it will stick to it. But the first pass can be a few % off. You see this sometimes when a SC is green or yellow and then flips when you made some trivial change
• The server currently does not deal with the speed factor. It's on the todo list. So while the app does deal with the speed factor, the server decides what chargers are picked. This is probably what resulted in the Boise charger being picked by the server when the app had a lower speed adjust that negated it. Hopefully this will go away when give the server additional data. I am actually just thinking of changing the efficiency I report to the server. I am hoping that will deal with this issue. Issue #436 .

[aesculus]

I added speed affect to the efficiency for each waypoint sent to the server so this should eliminate bullet 2's impact via issue #436 .

[EVGrokker]

v 1.2.0 (36) This seems to be working correctly.

I retract my earlier thoughts about using a threshold to declare a destination unreachable. The purpose of Auto routing should always be to find a supercharged route. If the user wants to force a route, they have two options - Manual, or Auto followed by Add Waypoint and Optimize.