I would assume so, as reply data from your vehicle for PID 221005 is only two bytes: 00 A0, so it cannot contain pressure info for all the tires. The same issue is seen on Tire temperatures also.
First byte 00 could indicate tire index, but in your log its always 0, even when you make multiple requests for 221005.
We must assume that CSV data is right, but you could still experiment in RealDash OBD2 monitor if tire pressures are indeed in different PIDs. For example:
Initialize:
atz
atsp0
ath1
ate0
0100
Try LF tire pressure
atsh750
atcea2A
atta2A
221005
Last two bytes on reply should be 00 A0 (or close). Then try:
221006
To see if you get similar response to LF tire pressure (221005). You can also try what your vehicle responds with 221007, 221008 etc.
If you find something from the results, you can use the OBD2 monitor share functionality to get the contents of the terminal and share here.
The update you have done works perfectly and displays the one tyre we have sorted fine so thanks so much for that. I’ll just try and get my head around what you have said to try and see if I can get the others to work but this is all new to me so I’ll do my best
Hi I’m playing around with some variations of the xml file at the moment however I’m not getting any more data yes. However I have seen the PIDs that I have used pull data from the car for all 4 tyre pressures using other apps like torque etc so I’m not sure what they are seeing that we aren’t?. Would there be anything I can send you to help try and figure this out?
So to confirm it’s what I think. I need to go to garage and the touch the dash part of the car and then detect the protocol and then that will show me what I want?
No. Your protocol is fine as you are receiving data. I would need you to enter the commands that read tire pressures into the monitor and share the responses from your vehicle.
Unfortunately no, I do not understand how they work on Torque. This can be seen on your log also:
You send:
221005
Reply from vehicle:
758 2A 10 0D 61 10 05 00 A0
On the reply 61 10 05 indicates that it is a reply for request 211005. After that there is two data bytes 00 and A0. The Torque app specs show that pressure values are in bytes B (second byte), D (fourth byte), F (sixth byte) and H (eight byte).
As reply contains only two data bytes, I do not understand how Torque could read fourth, sixth etc bytes from the reply.
One option came to mind, that first byte would be an index of the tire (0,1,2,3) and second byte the pressure, but first byte per the logs you sent is always 00.
Honestly, I’m not an expert on interpreting Torque app custom PIDs. Maybe there is an explanation for this on some Torque documentation.
Is this a similar issue to the one regarding tire temps and multiline replies?
Is that one fixed out of interest? see: use-atcea-atta-command-in-custom-xml/5323
I think we would be expecting a multiline reply for 221005 header 750
Some debug replies from other ODB2 readers support this.
