Hello everyone! New here as a contributor but I've used these forums quite a bit to help answer questions and solve problems. One issue I've had that drove me nuts was the obd port battery drain issue.
My car is a 2016 F type R. Like many others I don't trust the dash temperature gauge to warn me in time if something is wrong. I set out to use Torque Pro and AAtorque to display information from Torque on the infotainment screen via android auto.
I got this working other than the dreaded red triangle staying on all time and draining the battery. I tried all sorts of combinations and torque settings to no avail so I decided to put together an obd listener to see what was being sent to the port and how the car responded.
What I found was the standard format that most obd devices use for Jlr vehicles, the iso 15765-4, was causing a can bus error in the gateway module or occasionally in the instrument panel module. This error doesn't really tell you much, it's just a can bus intermittent error. Clearing this error most of the time would alow the car to go to sleep again.
I remembered seeing a service bulletin from Jlr about obd2 devices needing to be Uds compliant so I looked into that but couldn't find an obd adapter that had that protocol. I've done some programming in the past as well as a few project's with the esp32 module so I decided to build my own adapter that would send the correct format. It's kind of confusing but I'lll try to explain. I'm far from an expert on this so feel free to correct me if I'm wrong. With the standard Iso format to request the engine rpm the adapter would send the following-
0x7Df,0x02,0x01,0x0C,00,00,00,00,00
0x7DF is the identifier, and 0x0C is the code for engine Rpm. The other numbers specify a request for data. With this request both the engine and transmission respond, and the error code is set causing the car to not go to sleep.
The Uds format for the same request looks like this:
0x7E0,0x03,0x22,0xF4,0x0C,00,00,00,00
0x7E0 specifically targets the ecm, and the other numbers specify a request for data with 0x0C being the code for Rpm.
Using this format the car is happy and only sends data from the engine with no errors. If you want to know the transmission temp you need to specify 0x7E1, which targets the transmission and replace the 0x0C with 0x69. I won't get into all the technical stuff but this is basically what I found.
I've had no issues with battery drain since using this format. It may be possible to use the custom pid feature in torque to send the correct format. I'll mess around with it this weekend and post the results here.
A few photos of my gauge setup:

 

Very cool, and nice work. I think a number of us have done embedded controller stuff. I did, for 37 years.

 

I am very interested in how you accomplished this. I am also running Torque Pro and AATorque in my 2016 F-Type and always have to disconnect the battery (via quick disconnect now) in order to stop the battery drain. I would really like to be able to keep an adaptor plugged in and have the option to pull up AATorque at any time, but it isn't really feasible to do the battery disconnect every time I drive the car. I do run this setup whenever I track the car so I can keep an eye on Coolant, Oil, and Trans temps.

 

I was under the impression that this app on Android didn’t work well with Android Auto. That’s what I thought I read. I guess thingsmust have changed?

 

This is a very useful finding, especially for JLR vehicles where gateway sleep behavior is sensitive to CAN activity. The ISO 15765-4 polling can easily keep modules awake if timing is not correct. Adding a proper filter or reducing background requests in Torque Pro often prevents the gateway from logging intermittent CAN errors and allows normal sleep cycle.

 

It won't work with anything over android 13 as far as I know. I'm using a galaxy s20 I picked up on Amazon. It stays in the car and is only used for android auto.

 

This is was my thought on it as well. I wanted to know exactly what Torque was sending over the network.

 

I'll post more info on the adapter I made. Not sure how the Track Addict functions. Technically you could put a converter of sorts between it and the obd port, analyzing what it is requesting then converting that to the correct format. I got tired of disconnecting the battery every time. Supposedly you can update the ipc and gateway module and that fixes it but that was a bit much for me as the ipc has the immobilizer and I don't need a 3800 lb paperweight.

 

Thanks! I'm not that good at it but somehow manage to get things working most of the time.

 

Oh wow, weird, so you’re saying it broke on later versions. That’s interesting.

Okay, well, I’m not crazy after all then ;-o I knew I read it, but I certainly didn’t know that it used to work. I thought it just never worked.

Thanks for the info.

 

Here's more info on the setup and adapter. I'm using a GTA car kits android auto setup with a Samsung Galaxy S20 FE mounted under the center console lid. The adapter lives tucked under the dash, connected via an extension cable to the obd port. I cut the power wire from the obd port and tied it into an ignition source I use for my water meth system. I decided to use gps instead of relying on torque to query the vehicle speed. This allowed me to have the 0-30 and 0-60 timer on the adapter for higher accuracy. The GPS umit doesn't like it under the dash so I put behind the driver seat and ran the wires to the adapter.
The adapter itself is an esp32 development module. I have a 12v to 5v converter in there to convert the incoming power to 5v for the esp32. I also have a mcp2515 can module used to communicate with the car and a few other modules in there to provide a battery voltage reading without querying the obd port.
I can draw up a simplified wiring diagram if anyone wants to build one and I'm happy to provide my code as well. You will need decent soldering skills and an inspection microscope is almost a must if you want to make it all compact. I would also highly recommend building a can sniffer. I used a Seeed studio can shield for an arduino uno and got a cable to go to from the obd port to the connector on the shield. You'd need an obd splitter as well so you can make sure the adapter is sending out the correct data.
I had a can wire come loose when I was testing it and I think I got every error message possible on the dash. Barely made it home. The car wouldn't even let me put it in park. Had to go through every module on the car and clear the can errors. It's worth the time and money to have a way to double check everything is working correctly. I'll look into Torque and see if I can get it to send the correct format. Here's some pics of
the adapter and my setup.

The adapter plugged in to the obd extension.


Phone mounted under the console lid.

Gps unit mounted behind driver seat.

The adapter assembled.

Esp32 module on adapter.

Underside of adapter.

 

I tried everything I could think of to get Torque to play nicely but it won't. It's not specifically Torque but the adapter which is a obdlink lx. It seems elm327 based adapters simply don't support the correct format. You can do custom pids on torque to read things in the correct format but there's no way I could find to stop it from requesting supported pids. In the picture I took you can see the 7E0 message which is the adapter and the response from the car which is the 7E8. The response from the car is a negative response with the 22 meaning conditions not correct. I did find that when the car won't go to sleep if you clear the faults on the gateway module even when there's no error code it fixes it. Here's a link to a good explanation of the uds format UDS Explained - A Simple Intro (Unified Diagnostic Services). Here's a photo of the problem request:

The 7E0 is usually 7DF. I forced it to use 7E0 instead in torque but the rest of the request didn't change.
I'm using the iCarsoft LR V3.0 scanner to reset things. It doesn't cause the drain unless you use it's obd mode.

 

Thanks @JagCNC for a great write-up. That's some serious diagnostics work and R&D to come up with the UDS solution. Your hardware explanation went over my mechanical engineer's head pretty quickly, but perhaps my electrical engineer son can help me build something similar. Does anyone make a UDS OBD adapter instead of ELM327?

For those wanting to try out Torque Pro on Android Auto, here is my setup running Torque Pro and AATorque on a Galaxy S25+ (Android 16) paired with a UAD Auto piggyback unit for Android Auto:


I had to sort out a few different settings deep in Android Auto to get it to work on a new phone (enable Developer Settings, allow Unkown Sources, etc.). I relied on the comments on the AATorque GitHub page and AATorque posts on Reddit to figure out a configuration that worked.

 

That looks really good, I've just read his github and the comments on his YouTube, and it seems that some have difficulty getting it to work on android 14 and above. Some used kingstaller as per his guide and that worked but sounds a bit more complex.

it sounds like you just did the basic instructions (developer mode and click force update etc) - am I correct or did you need kingstaller or other things to get it to work?

 

I originally had AATorque running on an S21+ with Android 15. I used Kingstaller for the initial installation of AATorque. When I upgraded phones, AATorque transferred to the new phone without issue. I had to enable Developer Options on the new phone and in Android Auto. Also had to be sure Wireless communication was enabled in Android Auto. After all of that and a couple of reboots, I was able to get AATorque running and have it show up in the programs list in Android Auto. Hope that helps.