In the burndown chart, the real SOC is most of the time replaced with the planned SOC. On long trips, in my case, this results in very different resullts.
Attached screenshots are from a trip, where ABRP also planned to have a charging stop to top up 10% with planned arival of 11%. The real arrival was with 20% and no charging stop.
When I drive with my OBD dongle, ABRP is reporting the planed SOC and not the real SOC.
In the graph I see the dot jumping to the real SOC and back to planed line. See the screenshots. Carplay is reporting the wrong SOC and also the estimated SOC of the end of the journey.
The dongle show a normal connected state.
I can test this, probably on wednesday or friday
Hi everyone, we need someone who can reproduce this, as we could not so far. If anyone is interested in helping out on this let me know and send me a mail to email@example.com with your ABRP account details (mainly the mail used for registration). Then i can enable an additional tester flag where you can easily report driving data which would help us to investigate the issue.
I think it may be reproducable like this:
- Set maximum speed in the abrp settings way to high, like 150kmh.
- plan a route on a non restricted Autobahn. (it doesn't make sense when drive speed matches speed limit)
- drive below the target speed, like 120 / 130 kmh.
- drive for 100km+ to get a big deviation between planned and real soc.
For me it was like this. Got much better planning results with target speed of 130 and using the reference speed like 105%.
I am still on beta and have set my maximum speed to 140, but didn't have the chance for a longer autobahn trip so far. Easter is the next chance.
I also got the impression, that the maximum speed has too much impact on the planned average speed.
I've sent you a mail
direct live SOC is unexpectedly not stable. And the estimeted destination SOC is not accurated (doesn't change even if I accelerete frankly)
We just released 4.2.0 on iOS and Android. Please try again and report back here, if you see the issue again.
seems the update to 4.2.0 didn't change the behaviour. I had 2 trips with about 40km and both showed the same bug.
On some short trips around town I haven't see the problem of SOC toggling between good and bad values while using a BLE OBD dongle. I originally noticed the problem on a longer trip but would expect to have seen the problem by now even on these shorter trips so I'm hopeful that the problem I was seeing is fixed. It will be awhile before I can test this on a longer trip.
v4.2.0-beta3 (852), Android 12, Pixel 4a, 2017 Chevy Bolt Premier.
Merged with: Live Soc alternates between actual live data and SoC based on previous trip
Ioniq with obd2 dongle for live data using carplay
started the route with the obd2 dongle not activated, so SoC based on last usage.
Then activated dongle and live data became active
however % shown alternated between actual live data (~43%) and the SoC based on last usage with estimated % used since start trip subtracted (like manual data mode).
Also noticed that expected SoC at end of trip did not update (based on live data SoC) and when diverting from route the route is not updated.
I think i noticed this behaviour also 2 weeks ago, but not more then 6 weeks ago. I'm always up to date with the updates.
Same here I have a 'close' figure but never the actual, and then a random value that it switches between with an estimated arrival % higher than my starting level...
The soc is being retrieved correctly from leaf spy to abrp and shows in the startup soc but the map view swaps between estimate and actual soc
I'm on IOS and can confirm that it happens on every trip with the current version 188.8.131.52 (797) - seems to happen as soon as the difference from predicted SOC to actual SOC is more then 2% (no matter higher or lower)
Hi Haley, so did this also happen in an earlier version or really only since 4.1.16? Or did you just recently add live data?
I'm running live data since two years or more :) Always worked great and seems to be a bug in the current version. I'm note 100% sure if it is just this version or the one before. I noticed first time 2 weeks ago but I don't use abrp on a daily basis
did anyone try this recently on one of the beta versions? We for example released a new beta version which is publicly available since tonight. So if you are on android, please check if the soc still behaves as you described here, or if it improved.
On Android 4.2.0 831(beta?) I didn't notice this drop so far. Longest trip since reporting the issue was yesterday with 50km.
Same issue here with Android Auto and my Samsung Z3 fold. However. SOC on the phone itself is shown correctly.
I’ve got something similar and also seeing numbers bounce between values on the main screen for the SoC value. Photos taken seconds apart.
This happens with OBD and Tronity, so not linked to how its getting info.
Experiencing the same issue. Live SoC is not updating correctly.
Same effect while connecting either through Tronity connection or Veepeak ODB2.
I noticed though that the trip (drive) log registers the trip SoC correctly. It seems as a live navigation display issue.
ABRP 4.1.16 (797)
same error for me on every trip. It seems to receive correct data but displays incorrectly
I seem to have the same issue on iOS abpr version 4.1.16 (797). I’m using OBD dongle on KIA E-Niro 64kwh. Had a long trip recently with several stops and the bars indicating live data was always green but the value was always off (to low) compared to real value after driving for a while.
Any idea when 4.2.0 might be out for iOS?
Can you please make a screenshot and mark the areas where the soc is wrong? Can you please also check on the car details page, if the data is up to date? You can get there by clicking the settings icon behind your car.
Also which version do you use and which OS?
we just released a new beta with a fix related to the shown SoC while driving. We are not sure, if that fixes the issues you have seen, but it definitely fixes some problems related to SoC not being shown correctly.
You can join the beta (on Android only right now) by scrolling below the review in play store and then click on "join beta". Wait a bit and eventually it will ask you to update the app. Current latest beta is 4.2.0 (831).
Using an OBD BLE adapter for live SOC, SOC switched every couple of minutes between a correct value (as compared with the car's SOC display) and a significantly higher incorrect value. But the incorrect value seemed to track the correct value, changing as SOC decreased but always higher than actual. On a 2 hour trip the incorrect value was between 9 and 12% higher than the correct value. Then after unplugging the phone from the car while stopped for a short break, plugging it back in, and re-entering the destination that had been lost, the incorrect value switched to 100% whereas the correct value was under 30% by then. This makes me think ABRP is confusing the planned SOC with actual as reported by OBD. But I wasn't able to independently verify what the OBD adapter was sending. In all cases, correct or incorrect, the SOC display showed green bars, indicating ABRP was receiving data from OBD.
ABRP v 4.1.16 (797), Android 12, Google Pixel 4a, Android Auto, 2017 Chevrolet Bolt Premium
Just noticed v4.2.0 is out, will try that on my next trip.
If you see this again, please report it via settings, scroll to bottom and "click support & feedback" and then use the first entry which is either "give feedback" or "contact support", after that click "yes" to transmit the event log to our servers. Then choose the mail application of your choice and send me the data to firstname.lastname@example.org.
can you please do the following when you see this again:
Go to settings, then scroll down to support & feedback, then click on contact support and click yes to upload the latest event log. It will ask you to share that. Choose a mail client (like gmail) and change the recipient to email@example.com
Then I will get an eventlog and might be able to see what is going on on your device.
I can see that RHo uses EVNotify, FireflyDad which telemetry source do you use?
The button to click is labeled "Give Feedback" (the first one).
I'm not using EvNotify since long ago. I'm on my own sender via the generic api. May that be an issue?
Could be. If the timestamp for example is wrong or any data not in the format we expect it to be, it could maybe cause issues like that.
:) I thought it my be an issue, because of the double API registration - not that there are any issues on my implementation :-P
Fun aside, I'll have a long trip later this day, I'll restart my sending server (which is a non moving machine on 50Mbit at home), before the trip. Right now I see lots of these log entries:
- Timeout call api.iternio.com/1/tlm/send...
- Error. Url: api.iternio.com/1/tlm/send ... Status code 525
- About 170 not sent messages since 9th of march, because the api call was already running. As my car phone sends every 5s to my home machine, this smells like near timeouts while sending to the ABRP API.
I think I remember a case for the Zoe remote API, that sends data every 15mins only. When the telemetry value times out and is not refreshed for a while it will get close to the original estimate again. Could be maybe similiar to your case then?
I am using a odb device.
On my trip today it did not happen. After 1hour my car phone had GPS issues which made me to reboot the phone. (I think it got too hot)
While GPS was not really available the location marker jumped or didn't move at all. As I rebooted the phone, SOC dropped to the estimated value. Once the phone was back online and GPS was working again, SOC returned to the real value and the position marker was back at the real location.
In the screenshot you can see the GPS issues when SOC dropped to the estimated line.
I also have no timeout or other errors on the sender machine from during the trip.
The plan was really good today.
Before the phone reboot I drove with130-140kph, after that I hammered it with 150kph GPS speed.
I set max speed to 120kph and 105% reference speed. This seemed to be a good choice for today.
Should "120km/h" show the real speed or is this some calculated value? Shouldn't it be 126 in this case? I've seen slower values there, too like 52kmh, but I could not find out what this number means.
Is there a place in the app, where the current speed from the API can be seen (to check if the format is correct)?
I had the same exact issue on a long drive today. High winds meant we didn’t get the expected efficiency and ABRP had us bypass a potential fast charging stop. We made it to the next one, but only barely by turning off AC/Heat and driving 55. There aren’t too many DCFC in South Carolina!
This is a must fix ASAP!
I attached my two screen captures. They were captured seconds apart. It seems that whatever the issue is it updates the battery correctly, then it gets overwritten by something else a moment later.
Oh one other thing. It’s not just the burn down chart that is affected. The SoC displayed on the navigation map is wrong, as are the predicted arrival SoC.
I have the same Issue. I use ABOR to send live data to ABRP. The data in ABOR is correct, but ABRP sometimes uses the planned SoC