SoC sequence looks suspicious - reserve energy not actually precharged - Githubissues

aesculus / EVTO-App-Feedback

A project to track bugs and ideas for the EVTO App

MIT License

1 stars 0 forks source link

SoC sequence looks suspicious - reserve energy not actually precharged #429

Closed EVGrokker closed 7 years ago

EVGrokker commented 7 years ago

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 94 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: 21673 Paloma Drive, [t76d93v2iqg0puzqa3c6k5]

Take a look at the last charging stop in Bend, the destination arrival SoC, and the reserve energy. It doesn't make sense that you could leave the Bend supercharger with 33% (according to the Waypoint Inspector) and arrive at the nearby final destination with 32% SoC (that's plausible) and a 19% reserve allocation.

arrivalsoc

aesculus commented 7 years ago

It doesn't make sense that you could leave the Bend supercharger with 33% (according to the Waypoint Inspector) and arrive at the nearby final destination with 32% SoC (that's plausible) and a 19% reserve allocation.

Bug for sure. 32% is the total energy at arrival, of which 19% is reserved for local travel. This gets you to 13% which is too low since you asked for 20% min. Need to look at why this is. It really should be 20% + 19%.

aesculus commented 7 years ago

I spoke too soon but there still appears to be a bug. Here is what I see after looking a bit more:

Had you not added the Bend SC you would have arrived at Bend from the Detroit Lake SC with 20% + 19%.
When you forced the Bend SC into the mix it has a minimum charge time of 15 min. That meant that you were going to get to Bend with 32% arrival SoC base, allowing for 1% loss on the way there. But that is wrong
I suspect an error in my algorithm that sees that you min charged at the Bend SC and did not do the math correctly adding in the destination requirements.

aesculus commented 7 years ago

I fixed this in V1.2 (36). I am not certain why this did not show up before. We need to keep an eye on this to make sure it stays correct.

EVGrokker commented 7 years ago

I think the challenge was probably the order in which I created the trip. I started with the street address as the destination, then added the supercharger as a waypoint, then added the reserve energy.

aesculus commented 7 years ago

Maybe. But the other day I had an issue where I was using an embedded waypoint count within the trip. Something got screwed up along the way and caused that number to be wrong. So I decided to just switch to counting the waypoints instead figuring the count was equal to the last waypoint order.

This area in the code is suspicious because just above that is the waypoint count thing. I cannot remember if this is the place I changed but none the less. Having said that the routine to add the destination reserve to the prior waypoint was not right. It never found it because it was actually trying to apply it to the destination itself. I have not touched that code in eons so I cannot understand why it worked before unless when I made the new last waypoint order I inadvertently left off the prior -1 which was there before. This is the most likely scenario.

aesculus commented 7 years ago

This has been addressed in V1.2 (57)