Jump to content

Jason-ABRP

Administrators
  • Posts

    1,009
  • Joined

  • Last visited

  • Days Won

    135

Everything posted by Jason-ABRP

  1. Jason-ABRP

    IONIQ 5

    Interesting on the strange 'obviously wrong' values. We could definitely filter them out, and ignore those calls if need be. In what way are they wrong? What should I use to filter those values out? Also, what sort of OBD reader are you using? If it's causing noise on the CAN bus, that could also be the cause of strange values.
  2. Yes, that curve has been implemented. Let me know if you find any further updates.
  3. I can use those estimates to refine the model, but realistically we need live data from the Zoe (including power). Does EVNotify work for you guys?
  4. @hyperleaf - we had resolved that for most Leafs back then, but if you're seeing the wrong values for a 2015, perhaps they had more buffers on either end of the pack in that year? As I said there, I need to know the min/max GIDs for the model year and we can resolve it
  5. Our intention with ABRP is to tailor the trip to you. You tell us where you want to go (and how you intend to drive), we figure out how to get you there. Telling you to drive slower or faster than you're normally comfortable driving (what you tell us in the settings) unless we really have to is counter to that goal, so we don't really want to spend the time implementing that. It is a neat thought exercise, though.
  6. Jason-ABRP

    IONIQ 5

    Ah, on the Torque receiver I needed to add the Ioniq5 and EV6 to the Kona/Niro PID parser (has anyone verified EV6 uses the same PIDs?) It should work shortly.
  7. I finally got around to looking at the code in the IDDataLogger, and that's pretty interesting. What are the chances that the: ["chargingStatus"]=> array(6) { ... ["chargePower_kW"]=> int(0) ... } Data is available during driving as well as charging?
  8. This is exactly why we are not so enthusiastic about API support for non-Teslas. For whatever reason, most car manufacturers have decided to leave any useful information out of their APIs. At best you get very slowly-updated position and SoC, and at worst you get completely stale data while driving, which is precisely when you need updated information. Using the on-screen adjustment buttons is the "right" way to do it, but it's cumbersome and takes your attention away from driving. I would actually recommend using an OBD dongle like the OBDLink LX and EVNotify or some other app. You'll get a much more Tesla-like experience without having to interact with the car screen. For what it's worth, I've used EVNotify with my ID.4, and it works well enough if you turn on the "run in the background" secret option (and disable the auto-termination of apps in the background). This should be improved in future versions of the app. Our eventual hope is that Android Auto opens up the same hooks to us that Android Automotive has (like you see in our Polestar 2 implementation), and the detailed driving data is immediately available when you plug your phone into the car / hook up to wireless. Apple and CarPlay unfortunately haven't given any indications that this will be available in the future, but we can hope there too!
  9. @AbuG I took a look through here, and came up with a few notes we should solve before implementing: The "!_ABRP" notation is a little unnecessary here, that's only used on the HKMC PIDs because there's lots of parameters under the same PID, and Torque ID's them to the server by PID, so I wouldn't be able to tell which is which when I receive it. These are all different PIDs, so no need for that. Ideally we should have complete PID lists for each region to simplify installation. @LiamWhales produced some equations to even out null readings, I'm not sure this is entirely necessary though, as I can do sanity checking on the ABRP server, so perhaps we should get rid of that to simplify the PID list. If you guys could submit pull requests to the repository here: https://github.com/iternio/ev-obd-pids/blob/main/mg/mg5_data.csv With the updated PIDs in two or more separate CSVs, one for each region I will get them updated on the server side and update the instructions. On the instructions, we'll need to specify which regions are good for which PID lists.
  10. Definitely interesting. I tinkered with them last year a bit, but was very limiting (and could get expensive quickly with as many calls as we typically make during a drive). I might try it again soon to see if anything's changed.
  11. @AbuG - That's great digging! I'm out the rest of this week, but I can get the Torque receiver and PID list link updated next week. Also, the integer charging status isn't an issue, as server-side we force it to cast to a boolean, so as long as it's zero = not charging and non-zero = charging we're good to go. We might have to get clever with the math in the PID to account for '10', but that's not too hard I think.
  12. Jason-ABRP

    Torque Pro

    Sounds good to me! Let me know when you're ready to try integrating.
  13. @ANBO It is, and it's been implemented, thanks!
  14. 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 setup to us. We're also not opposed to building in more basic BT OBD support to the app, but again we're development time constrained. We're happy to bring on extra help if anyone is familiar with iOS code and would like to help make that a reality. We've got the OBD and Android experience to make that happen, but not yet iOS, and we only want to do it if can be done on both sides (and done well). If anyone is interested in pitching in on either of these projects we're happy for the help, shoot me an email at jason@abetterrouteplanner.com
  15. 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 with your PIDs. jason@abetterrouteplanner.com
  16. 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 order of priority. Nothing is strictly required, but many features in ABRP will only be usable with enough data. High priority parameters: Telemetry parameters The required parameters (and expected units) in the tlm JSON object are the following, in order of priority. Nothing is strictly required, but many features in ABRP will only be usable with enough data. High priority parameters: utc (s): Current UTC timestamp (epoch) in seconds (note, not milliseconds!) soc [SoC %]: State of Charge of the vehicle (what's displayed on the dashboard of the vehicle is preferred) power [kW]: Instantaneous power output/input to the vehicle. Power output is positive, power input is negative (charging) speed [km/h]: Vehicle speed lat [°]: Current vehicle latitude lon [°]: Current vehicle longitude is_charging [bool or 1/0]: Determines vehicle state. 0 is not charging, 1 is charging is_dcfc [bool or 1/0]: If is_charging, indicate if this is DC fast charging is_parked [bool or 1/0]: If the vehicle gear is in P (or the driver has left the car) The lower priority parameters (and expected units) are: capacity [kWh]: Estimated usable battery capacity (can be given together with soh, but usually not) kwh_charged [kWh]: Measured energy input while charging. Typically a cumulative total, but also supports individual sessions. soh [%]: State of Health of the battery. 100 = no degradation heading [°]: Current heading of the vehicle. This will take priority over phone heading, so don't include if not accurate. elevation [m]: Vehicle's current elevation. If not given, will be looked up from location (but may miss 3D structures) ext_temp [°C]: Outside temperature measured by the vehicle batt_temp [°C]: Battery temperature voltage [V]: Battery pack voltage current [A]: Battery pack current (similar to power: output is positive, input (charging) is negative.) odometer [km]: Current odometer reading in km. To enable vehicle individual consumption calibration, we need at least speed, power and is_charging at a rate of at least once per 10 seconds (the faster the better). Edit: note - UTC is included in the default Torque call, so don't need that.
  17. 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/
  18. 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.
  19. 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 you can help us get this off the ground.
  20. 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.
  21. 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.
  22. 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), and we are actively pursuing better OBD support. Probably the best thing to do here is EVNotify for now. That said, if someone wants to work with us to implement an API poller, we're happy to help (and even host it on our servers / integrate it into the app), it's just not a high enough priority yet for us to spend our limited dev time on.
  23. Definitely would be happy to make a '21 I-Pace with an updated charge curve if you can find the curve!
  24. More Live Data to tune the model to real vehicles, we still have relatively little with a lot of statistical variation.
  25. 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.
×
×
  • Create New...