Jump to content

Jason-ABRP

Administrators
  • Content Count

    992
  • Joined

  • Last visited

  • Days Won

    130

Jason-ABRP last won the day on April 12

Jason-ABRP had the most liked content!

Community Reputation

180 Excellent

3 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Agree, and on top of that it's not available outside of Europe at all. You can also do 1 with an AutoPi (which is available worldwide, and I'm using one for my Bolt EV), but again it's not cheap, and it's hard to do 2 with an AutoPi (but technically possible). The limiting factor is the AutoPi by default only allows local PID pulling via its WiFi network, which means you can't be connected easily to your car's wifi if you use wireless Android Auto / CarPlay.
  2. Yes, the Tesla API provides a lot more detail and updates very frequently. Any time we've talked to OEMs we've mentioned that this is the ideal, but they move very slowly. For now our ideal solution would be a standalone OBD Dongle with: Cell / WiFi connection so you can get status while away from the car (let you know when charging is done). Bluetooth connection so you don't lose data when you lose cell connection. We've actually got a few candidate devices in mind (Freematics, EVDash/M5Stack). If anyone's good with Arduino programming send me a message and maybe yo
  3. I'd be happy to support Torque or anything else, but need a PID list to work from. I wasn't aware anyone had decoded the I-Pace's PIDs yet. Send them my way and I'll get the support added. It's probably also a good idea to send them to EVNotify to get some support there as well.
  4. Supporting Tronity is relatively low workload (so we could fit it in our other priorities) but adds a lot of supported cars. Even if that support is not very complete, since it's only SoC.
  5. So, we've looked at this, and it's just not that useful. Updated SoC is nice, but it's very slow, and that's about the extent of the EV-specific data. You won't get a good calibration of your car model through most manufacturer APIs. They don't put anything aside from the SoC on there typically. To be useful for driving we really need insight into the power draw for the car, and this is almost never provided. So, with that in mind we haven't put any manufacturer API implementations close to the top of our list, we'd rather work on better app support (there's a lot to improve here), an
  6. Definitely would be happy to make a '21 I-Pace with an updated charge curve if you can find the curve!
  7. More Live Data to tune the model to real vehicles, we still have relatively little with a lot of statistical variation.
  8. Jason-ABRP

    Torque Pro

    Definitely! No PID list naming convention, just send me a link to a copy and I'll get it set up.
  9. For anyone who didn't see the announcements, you can sign up for the public beta test for Android Auto on the Play Store!
  10. Just installed the beta, I noticed the map is not zoom able on the head unit, 2020 Kia Soul EV Limited

    1. Jason-ABRP

      Jason-ABRP

      This is expected, Google doesn't allow any touch events on the map region for third party apps.

    2. Bert Hogendoorn

      Bert Hogendoorn

      Any chance to get minutes per charging stop similar to the web based browser charge station flags? This will simplify in route driving.

    3. Jason-ABRP

      Jason-ABRP

      Yes, we need to upgrade our maps API first though, the Android implementation currently lags like crazy with text attached to a marker.  We definitely want this too.

  11. @AlistairB - We do have a little bug right now on directions distances. For long-distance instructions we have a third notification when you're close to your exit (like when you're half a mile from the exit), and slow-speed directions are supposed to ignore that one. At the moment, it's not being ignored, which is where the distance readout is coming from. Typically the final instruction doesn't have a distance as you suggest. Thanks very much for your pull request! We've gotten very used to our own instruction wording, so it's very good to have outside ears hearing them too to help re
  12. Thanks for the feedback, @Bill N! That's some good insight. For the directions, we actually have these posted publicly on our translations Github page: https://github.com/iternio/abrp-translations/blob/master/en.json#L667-L701 So we welcome inputs here, either as issues for discussion or a pull request with direct fixes. The "to Bond Street" versus "onto Bond Street" I think makes sense, and is an easy change. Give the roundabout instructions a try, though, I think you'll like them. I especially like the context of knowing roughly which direction you ought to exit the roundabout,
  13. 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.
  14. 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. 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 fl
  15. Note that you're comparing low-temperature performance to mild-temperature performance between Bjorn's two tests, where ours are modelled at the same (mild) temperature.
×
×
  • Create New...