Jump to content

xflow7

Members
  • Posts

    10
  • Joined

  • Last visited

Reputation

1 Neutral
  1. I use Torque Pro. Don't take 15min too literally. That was my stand-in for "some period I would guess was some number of minutes," but I was focusing on driving and not paying close attention to when it updated. Next time I'm driving some distance I'll check with the signal bars about the data availability. I guess the thing that most surprised me was that any update of current SoC was required at all with a re-route since the app clearly had a current estimated value from just prior to re-calculating. I expected that this value would itself be used as the departure SoC for the re-route.
  2. Hi Sofia, Thanks for following up. I use Android Auto (although I think I noticed this actually while just using the app on the phone. I've updated the app since I observed this (and haven't taken a trip where I'd notice it since) so I don't know the number. But the trip where I noticed it last was July 16th and I had the latest available Beta version from the App Store at the time. Dave
  3. Description: When you select a new Alternate route, the original route is still shown in ABRP when you replan. You need to again invoke Alternate Routes and select the new route again for it to correctly update the route. Type: App version 4.0.47 on Android. Link to Plan: If the bug is in finding a route, please copy the plan link here (found under "Share"). Replication Steps: Drive along a planned route Press Alternatives and select a different offered route Observe that the original route is still used Press Alternatives again and select the different route Route is now correctly updated. Remember, the more detail you can provide in your bug report, the faster we can fix it!
  4. Hi, I'll add my recent experience which is slightly different from, but may be related to, what the OP observes in (1). It's different mainly because I do typically have live data enabled. In brief, it appears that when the route gets recalculated (either because of a deviation from plan, or because of switching to an alternate route), ABRP resets the current state of charge to some other value than the latest estimated value. I have wondered if maybe it reverts to the the originally predicted SoC or maybe to some stale cached SoC from an earlier point in the route. Anyway, what results is ABRP suddenly showing the SoC (typically) much higher than it was, with the predicted arrival SoC also correspondingly higher. If you are using live data (as I typically am), after some period, the displayed SoC gets updated with the live data and is correct. However, the predicted arrival SoC still reads too high until yet another interval passes. Here's a more concrete example of the behavior. The values here are hypothetical, but this is the behavior I have seen on several occasions (as recently as last weekend) I plan a route from Point A to Point B that is 200 miles, starting at 90% and ABRP predicts my arrival as 20% SoC. I start driving At 100 miles, ABRP displays Current SoC a = 60% / Arrival SoC = 25% Just then, road construction forces me to use an alternate route. ABRP dutifully recalculates, but suddenly shows Current SoC = 70% (erroneous) / Arrival SoC = 35% (assumed erroneous) Some time later (say, 15 minutes), Current SoC suddenly drops from 68% to 58% (now correct) / Arrival SoC still shows 35% (still assumed erroneous) Another interval later, Arrival SoC finally also updates based on the corrected Current SoC and now reads 25% (assumed approx. correct). So my observation is there are two issues: ABRP fails to either cache or correctly restore the current estimate on a recalculate Once ABRP *does* update the current SoC from live data, it doesn't (at the same time) update the arrival estimate; but instead waits another update interval. Hope that helps.
  5. Hi all, Finally had the opportunity for the first time in a while to try AA integration on a meaningfully long trip. 2019 Bolt EV Latest ABRP Beta and Android Auto Moto Z3 / Android 9 It worked reasonably well, but I did encounter some issues: For the life of me I couldn't manage to get a multi-leg trip plan to work properly. I could configure it fine on the phone, but went it got sent to AA, AA would just sit saying "calculating route" or "estimating trip" or whatever the equivalent message is. Finally had to punt and plan each leg individually. Once underway, it seemed to work great for a while, but then AA seemed to start crashing periodically. I generally had ABRP up and an AA-aware music player playing music. First indication was the music would stop playing and AA was totally frozen. I tried two different music players (USB Audio Player and Rocket Player) and the crash occurred with both. I can't say definitively that ABRP contributed here, but I've never had a hard AA crash with Google Maps + a music player (which I have used extensively). One alternate possibility is that I had the phone up on a windshield mount and it got full sun, so it may have gotten hot and started de-rating, but there was no warning to that effect on the phone, so I'm a bit doubtful. Not sure how helpful that all is, but maybe it's useful.
  6. Nevermind. Just saw this *has* been addressed already here:
  7. Apologies if this has been asked and answered, but I did not see it after an initial search of the forum. It appears that there was a significant overhaul of the Bolt PID mapping by AllEV.com in December 2020: https://allev.info/boltpids/ which (aside from adding many new identified PIDs) did a certain amount of renaming. Will the ABRP Live Data correctly identify data columns using this new mapping for Live Data (not sure if ABRP gets only column names, or also PID #s)? I would like to update my PID definitions in Torque Pro, but I don't want to break the ABRP data sync. Thanks! Dave
  8. Hooray! Thanks for getting this up and running! Not sure where you want feedback directed, but I'll put my first thoughts here (based on one short local drive). This is in a 2019 Bolt EV connected to Moto Z3 phone Some odd behavior at first when I had to correct an address selection and it appeared that the AA presentation and the phone app got kind of out of sync or the AA interface hung (AA seemed stuck on Calculating Route, while the phone was good to go). Eventually unplugging phone and restarting AA and ABRP sorted it out. At first, it seemed like ABRP was preventing simultaneous podcast playback in Podcast Addict / AA. This seemed to correct itself at some point, though. Not sure yet if reproducible. Once running, it worked quite well and overall presentation looks great. Minor niggle: the automatic reposition/orientation of the map as the drive progresses is a bit jerky / erratic Questions: Is there a way (or a plan) to access the graph view or other data that is on the mobile app? (I tried pressing the time estimate and charge info to see if they popped out or anything, but that didn't do it.) Thanks again for all the effort to bring this out! Dave
  9. Yes, it's similar in my experience in Mid-Atlantic/NorthEast US. There are chargers at rest areas on the New Jersey Turnpike, as well as along I-95 in Maryland that don't show up in ABRP at all (which is really surprising; surely the absolute most desirable chargers for a road trip are those that are literally in the rest areas). Plugshare shows all of these along with charger status, etc. when available. The weird thing is I'm almost sure that these showed up in older versions of ABRP. So I'm not sure if the charger sources got changed or what. Dave
  10. Hi Jason, Just registering my interest also in ABRP on Android Auto. The app is working great for me, so I'm really looking forward to the AA integration when it comes. I won't harass you about priority or timing, though. I work as a product manager, so I am very well aware of the challenges of managing feature requests from users! :)
×
×
  • Create New...