Torque Pro

[ANBO]

@Jason-ABRP i noticed several models having access to Torque Pro. Is this through an API, or Direct connection with the app?

Can this option be made available for selection also for Jaguar I-pace?

Is there a naming convention for the PID naming in Torque Pro for the connection with ABRP to funcion?

Which PIDs do you need to get maximum benefit of the connection. 

[Jason-ABRP]

Definitely! No PID list naming convention, just send me a link to a copy and I'll get it set up.

[ANBO]

Thank you for the response. Can you clarify the 'send a link to a copy'?

I must note all PIDs are custom.

[Kermit68]

I guess ABRP will not get the PID number but just a PID name and its value. Therefore we need a "standard" way to name the PIDs so the ABRP can understand the data is receiving. But I also guess that ABRP will need a limited number od PID (SoC%, ext temp, maybe battery temperature, maybe istant Power and reamining energy in the battery estimation). Just guessing, we need Jason to guide us of course.

[FuelOfEvil]

As OVMS can deliver data to ABRP too, you might have a look at their code. The script they use can befound at https://docs.openvehicles.com/en/latest/plugin/abrp/README.html

I am waiting for my e-up to be delivered and trying to figure out, if i could use ABRP with Torque Pro.

[Kermit68]

3 hours ago, FuelOfEvil said:

As OVMS can deliver data to ABRP too, you might have a look at their code. The script they use can befound at https://docs.openvehicles.com/en/latest/plugin/abrp/README.html

I am waiting for my e-up to be delivered and trying to figure out, if i could use ABRP with Torque Pro.

I have the OVMS box, it's very interesting for reverse engineering but for ABRP live data I think it's a little bit overkilling. Beside that, if I use he OVMS box I can't get easily many data as I can get with Torque Pro (now that we know the PID to look for) as there is only one OBD port in the car. I already tried a Y cable to connect both the OVMS box and a bluetooth adapter but the bus gets too busy and many times you loose data.

[FuelOfEvil]

Just have a look at their code:

      "utc": 0,

      "soc": 0,

      "soh": 0,

      "speed": 0,

      "car_model": abrp_cfg.car_model,

      "lat": 0,

      "lon": 0,

      "alt": 0,

      "ext_temp": 0,

      "is_charging": 0,

      "batt_temp": 0,

      "voltage": 0,

      "current": 0,

      "power": 0

Aren't these the PID names to use, regardless if you use OVMS, Torque Pro or any other App/Device?

[Kermit68]

PIDs have no standard names, only Hex addresses and that's why I asked for naming convention ABRP is using and of course what kind of data they need.

[Jason-ABRP]

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/

[ANBO]

@Jason-ABRPlad to

[ANBO]

@Jason-ABRP family first! Glad to hear they have recovered. 

So if I understand correctly, there is no existing link for Live data with Torque Pro, but you would be using the same protocols to pull the information from the PIDs in-app eventually? 

The list of PIDs you provided for the MG5 is slightly different from the list provided by @FuelOfEvil. What is it you need for your model to work best? 

Last question for now. "Is Charging" should that return a 0 or 1 value for no or yes?

 

[Jason-ABRP]

@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.

   

[ANBO]

@Jason-ABRP hope you and your family are doing well. 

Apologies for the radio silence. Have been gathering the data points you need. Still stuck on the GPS location. Since the response is longer than 8 bytes, I think Torque Pro is not swallowing it and I have to break it up in frames, which I am not familiar with. Are you able able to process those longer responses with Diagnostic Start and Stop commands?

As for kWh_charged. What is the purpose of this? Are you assuming this to work only when you are in the car, connected to OBDii? Or through a memory lookup able to calculate the cumulative delta over time upon return to the car? 

Thanks.

[Jason-ABRP]

@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

[ANBO]

Thanks @Jason-ABRP. Phone GPS in the I-pace is spotty and only really works on the door side.

Will give it a few more tries to pull from Torque Pro.

kWh charged as live data is understood. Don't have an actual read, but am calculating from Power, when charging. 

Conducting a peer-review before sending it over.

Happy to help in any projects.

[Jason-ABRP]

Sounds good to me! Let me know when you're ready to try integrating.