Jump to content

Torque Pro

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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:


Link to comment
Share on other sites

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


Link to comment
Share on other sites

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


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

Link to comment
Share on other sites

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


Link to comment
Share on other sites

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


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...