So I did some digging around and some Gemini and I found this PID for the A/C sensor. Now im not sure how to test it to see if it works. Like I said im not a coding guy so this looks Chinese to me.
View attachment 54792
The rough and dirty "PID requests 101" and not LSJ specific...
There's many types of read requests, but the 3 most common across manufacturers are:
1) Mode 21 - Read By Local Identifier. This maps out one and two byte values to a RAM map usually within an ECM, most implementations this is the "group request for speed" mode although you'll find that can vary
2) Mode 22 - Read By Common Identifier. Similar concept to mode 21, but applies over multiple families of ECMs (is the idea, in practice this rarely happens. Standards are only standards when manufacturers choose to implement them, and...in vehicles standards in logging are more like suggestions). Typically this is what OEM specific diagnostic tools will use because it covers a broad range without manufacturers having to define every single ECM in their tool
3) Mode 23 - Read By Memory Address. Exactly what it sounds like, and there's so many ways people implement this I won't even try to begin explaining it. Just know it's direct memory reading, and in the logging context that memory is directly from RAM. But it can sometimes be used to read the file from the ECM itself, just depends on restrictions in its handler
In the simplest 11-bit form of CAN you'll have an 8 byte frame request. There's a few different formats this can take, I'll choose a pretty generic one for this example, but in general arbitration ID will come first (where you want to send the request, ECM=0x7E0, TCM=0x7E1, etc), then header mode, then pid, then depending on the format it may require how many bytes you expect in return or not. So (with 0x00 padding), the frame request to send a request for refrigerant pressure to the ECM may look something like
7E0 22 3E 32 00 00 00 00 02
Where i'm padding out the frame with 00s and requesting 2 bytes on the end of the frame. Again, different manufacturers have different formats for requests, there are standards but as we just said, standards are suggestions.
The response you'll get IS fairly standard. Almost every manufacturer implements the response as arbitration ID + 0x08 (0x7E0+0x08=0x7E8) and successful response request as request + 0x40 (0x22+0x40 = 0x62), then will repeat the pid back to you and give you the data. So a successful response may look something like:
7E8 62 3E 32 69 69 00 00 00
Where 69 69 are your data that you receive back, and the rest is frame padding.
The negative response codes are pretty well defined too. Google search "UDS NRCs" and the first result has a pretty comprehensive list. But let's say you screwed up your message format. You sent it a request:
7E0 22 3E 32 02 00 00 00 00
So instead of putting the number of bytes on the end of the frame, you included them right after the PID. Well the ECM wouldn't leave you hanging, usually (unless you're Nissan, in which case loldon'tcare everything sucks) It's going to give you an NRC frame back, starting with 7F letting you know you screwed up.
7E8 7F 22 13 00 00 00 00 00
7F let's us know it's an NRC, 22 tells us it's not a positive response (no +0x40, so it's a 7F to the 22), and 13 tells us exactly what went wrong. If we go to our NRC list, we can see that 13 is an invalid format error.
There's like 100,000 more things to learn but if i had to give someone the crash course, that's where i'd start.
