Jason-ABRP 180 Posted January 29 Author Share Posted January 29 On 1/11/2021 at 6:44 AM, TheRussian said: Actually no, anything specific. I don't have the premium live features. It's not a pattern, it's just like a constant "factor" across the entire trip, it's always about 8-10% error... Interesting, we actually ran into something very similar with the Model 3 a while ago and implemented a speed calibration where it compares to the GPS from your phone (assuming you've got ABRP open while driving) to correct any errors from your speedometer. Perhaps this is contributing? Do you run with ABRP while driving, or just make the plan and drive it, then check at stops? If you do run with ABRP open, maybe there's something else odd going on. Quote Link to post Share on other sites
SamCentUn 0 Posted January 31 Share Posted January 31 I've seen the same issue in my Kona, where the default model is always at least 10% wrong (as in, it plans for me to be at 10% and I end up there with at least 20%). When I aded live data with the premium features, it put my calibrated reference consumption at 4.11 (which is probably too optimistic as well 🙂 ) instead of the default 3.35. Quote Link to post Share on other sites
Bill N 8 Posted February 1 Share Posted February 1 15 hours ago, SamCentUn said: I've seen the same issue in my Kona, where the default model is always at least 10% wrong (as in, it plans for me to be at 10% and I end up there with at least 20%). When I aded live data with the premium features, it put my calibrated reference consumption at 4.11 (which is probably too optimistic as well 🙂 ) instead of the default 3.35. The default models purposefully include at 10% buffer in consumption, as I understand it. I’m so far finding 3.8 mi/kWh to be a good reference figure for the Kona, maybe a little more. Quote Link to post Share on other sites
Jason-ABRP 180 Posted February 5 Author Share Posted February 5 On 2/1/2021 at 9:11 AM, Bill N said: The default models purposefully include at 10% buffer in consumption, as I understand it. I’m so far finding 3.8 mi/kWh to be a good reference figure for the Kona, maybe a little more. Exactly right, we do that intentionally with the assumption that experienced users will set a consumption that more accurately reflects their driving style, while the default is very noob-mistake-friendly. 1 Quote Link to post Share on other sites
SamCentUn 0 Posted February 27 Share Posted February 27 (edited) I've started running this on my autopi for my Kona and I'm noticing my logs are flooded with "sleep cleared/added" when the car is off, every 5 seconds, that never stop. Am I missing some configuration there for sleep so that the dongle sleeps when the car is off? EDIT: Nevermind, it looks like https://github.com/iternio/autopi-link/commit/d74e90494ddf528e19ae0747cf097ddf6223e14d#diff-6e753c4b645094870c59ea4493d2c25763b885877c907e1694bb3484b9f842c7 removed sleep when power is under 0.1kw. Edited February 27 by SamCentUn Quote Link to post Share on other sites
AlistairB 3 Posted March 1 Share Posted March 1 I've been having a go at modifying the script for situations like when the car is pre-heating (switched on by app) or battery saver is running - which were showing up in my ABRP history as charges/drives, which kinds of messes up the stats. Those cause the `is_charging` variable to be set to 1 with the script as-is (due to ignition being off), but if I just detect those and set `is_charging` to 0 then they show up as drives. Is there any way to tell the telematics API that I'm sending data (so that SOC etc is up to date) but that it is not a charge or a drive? I've tried `is_driving` which appears in the script, but it doesn't seem to have any effect. I can't find any docs for this API. Quote Link to post Share on other sites
Jason-ABRP 180 Posted March 1 Author Share Posted March 1 On 2/27/2021 at 12:20 AM, SamCentUn said: I've started running this on my autopi for my Kona and I'm noticing my logs are flooded with "sleep cleared/added" when the car is off, every 5 seconds, that never stop. Am I missing some configuration there for sleep so that the dongle sleeps when the car is off? EDIT: Nevermind, it looks like https://github.com/iternio/autopi-link/commit/d74e90494ddf528e19ae0747cf097ddf6223e14d#diff-6e753c4b645094870c59ea4493d2c25763b885877c907e1694bb3484b9f842c7 removed sleep when power is under 0.1kw. Glad you solved it! Point of curiosity, would it be valuable to you to have a kwarg in the job config which disables sleep management by the script? I personally found the AutoPi's PID-based sleep management quite unreliable on the Bolt, so overrode it with the script's sleep management. But for others that might not be the case. 4 hours ago, AlistairB said: I've been having a go at modifying the script for situations like when the car is pre-heating (switched on by app) or battery saver is running - which were showing up in my ABRP history as charges/drives, which kinds of messes up the stats. Those cause the `is_charging` variable to be set to 1 with the script as-is (due to ignition being off), but if I just detect those and set `is_charging` to 0 then they show up as drives. Is there any way to tell the telematics API that I'm sending data (so that SOC etc is up to date) but that it is not a charge or a drive? I've tried `is_driving` which appears in the script, but it doesn't seem to have any effect. I can't find any docs for this API. Hmm, this is something which should actually be solved server-side, we have some pruning which removes 'uninteresting' drives (no distance travelled, no speed, etc), but perhaps this is not working correctly? I can also add support for the is_driving flag to avoid logging a session permanently, only updating status. (IE - If is_driving and is_charging both exist and are both false, don't log permanently) if desired. Quote Link to post Share on other sites
AlistairB 3 Posted March 1 Share Posted March 1 I definitely see "drives" that aren't very interesting. I see one in my history of 0 distance, and some up to about 50-60m from GPS drifting around. Filtering on the server could do it, but I think it could probably be most accurate with the device sending the is_driving and is_charging flags, as it can tell ignition is off. I also wondered if it could be affect the calibrated efficiency with these little GPS wanders whilst not driving. Quote Link to post Share on other sites
Jason-ABRP 180 Posted March 1 Author Share Posted March 1 Probably not, as we go off of speed not location for calibration. Depending on which vehicle type you use, if we have OBD speedometer speed available we'll even calibrate that speed against the GPS from your phone to get a multiplier which accounts for your tire size / slight variations in gearing, etc. I'll add both, we'll check to make sure we're properly pruning uninteresting drives, and I'll add support for the is_driving flag. Quote Link to post Share on other sites
AlistairB 3 Posted March 1 Share Posted March 1 Excellent, thanks. Just had another thought actually - would it be useful sending a flag to show that pre-heating (by app) is happening? And internal temperature? When it's cold outside heating can make quite a difference to efficiency in the early stages which could skew things. Might be tricky for you to work in though. Quote Link to post Share on other sites
AlistairB 3 Posted March 12 Share Posted March 12 @Jason (ABRP), I'm seeing an odd side-effect of sending data during battery saver events. So, last night battery saver came on around 7pm, but the car wasn't driven. Today, the car was driven and the trip shows up at the correct times in the history, but the graph for the trip cover the whole time since 7pm last night (so hard to see anything in it). I've attached a screenshot to show it. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.