Jump to content

Jason-ABRP

Administrators
  • Content Count

    998
  • Joined

  • Last visited

  • Days Won

    131

Jason-ABRP last won the day on May 12

Jason-ABRP had the most liked content!

Community Reputation

181 Excellent

3 Followers

Recent Profile Visitors

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

  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!
×
×
  • Create New...