Jump to content

Jason-ABRP

Administrators
  • Posts

    1,009
  • Joined

  • Last visited

  • Days Won

    135

Jason-ABRP last won the day on August 18

Jason-ABRP had the most liked content!

Reputation

187 Excellent

4 Followers

Recent Profile Visitors

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

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