Jump to content

Jason-ABRP

Administrators
  • Content Count

    998
  • Joined

  • Last visited

  • Days Won

    131

Everything posted by Jason-ABRP

  1. Jason-ABRP

    Torque Pro

    Sounds good to me! Let me know when you're ready to try integrating.
  2. @ANBO It is, and it's been implemented, thanks!
  3. This is something we have talked a bit about, and we only want to do if it can be done well, and cross-platform (IE, not just Android, but iOS too). Most recently we've been focusing on a relatively cheap device - the Freematics One+ though we haven't had the development time to focus on it yet: https://github.com/iternio/freematics-link The end goal would be to have a device which is cheap(ish) to buy, simple to set up, and very versatile. The Freematics would be able to do remote cell-connected data and direct BLE data to the app, depending on your scenario. This is the ideal se
  4. Jason-ABRP

    Torque Pro

    @ANBO GPS Data is fine to just get from the phone, although car is better (and typically much more smooth). We can handle Diag Start/Stop commands, so that's not an issue. Shoot me an email and we can dive in on it more. For kWh Charged we use that to calibrate SoH / capacity of the battery. Not absolutely required, but very nice to have. It needs to be live while charging so we can see % increase and correlate with kwh_charged increase. We've got some projects in the pipe to make it easier to use these PIDs, so shoot me an email and we'll see if we can get you testing them out w
  5. Jason-ABRP

    Torque Pro

    @ANBO - We use the built in server logging function in Torque Pro to send the data to ABRP, but when Torque packages the data to send to us it's formatted like: k{pid_hex}=97.5 So I need to know the hex address of the PIDs to associate with the values I receive in the server call. The data we want is on our Telemetry API documentation: https://documenter.getpostman.com/view/7396339/SWTK5a8w?version=latest And for convenience I've copied the list here: Telemetry parameters The required parameters (and expected units) in the tlm JSON object are the following, in
  6. Jason-ABRP

    Torque Pro

    Sorry for the delay, my kids picked up COVID (all recovered now!) so I've been a bit out of the loop the last couple weeks. The way Torque identifies the data to us is by the hex address, so I need the CSV file that you use to configure Torque. I'll also need it hosted somewhere so I can post that in the setup instructions for others to follow. If you like, we've got an open source repository where we're hosting these, and eventually we want to use that to drive in-app live data: https://github.com/iternio/EV-OBD-PIDs/
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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
  12. Definitely would be happy to make a '21 I-Pace with an updated charge curve if you can find the curve!
  13. More Live Data to tune the model to real vehicles, we still have relatively little with a lot of statistical variation.
  14. 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.
  15. For anyone who didn't see the announcements, you can sign up for the public beta test for Android Auto on the Play Store!
  16. @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
  17. 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,
  18. 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.
  19. 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
  20. 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.
  21. The next things I can think of would be to reinstall ABRP, and then if that doesn't work, in the vehicle settings select: EVNotify can provide GPS location to ABRP, and generally we trust the Live Data location more than the phone location. It's also possible we introduced a bug somewhere in the mix as well, so I've added a bug to our tracker to investigate.
  22. We actually intended to post a public beta for Android Auto this last week, but have been held up in Google's review process waiting for responses. I'm not sure why it'd show ABRP in Android Auto yet, unless a version go through review without notification. As soon as we pass review we'll have a public beta open, for sure!
  23. Android Auto support has been submitted as a public beta on Google Play, this thread is for collecting feedback on that version of the app. For directions feedback please submit that to this thread instead: This thread should be focused on the specific elements and performance of Android Auto including styling, capabilities and features, and overall usage flow of ABRP in Android Auto.
  24. This thread is for feedback on Car Play. If you've got directions feedback, please submit that to this thread instead: This thread should be focused on the specific elements and performance of CarPlay styling, capabilities and features, and overall usage flow of ABRP in Car Play.
  25. With the advent of Android Auto and Car Play for ABRP, we're expecting a lot more people using ABRP to navigate on their trips. This thread is for feedback on the navigation voice instructions, including: Wording Distances / Timing Accuracy Other suggestions for improvement It's also important to note that we use the Open Source Routing Machine to generate the directions based on Open Street Map, so your best path to improving directions accuracy is likely contributing to Open Street Map to improve the maps in your area. We recompile from OSM/OSRM every week,
×
×
  • Create New...