Mode 31?

Not sure Torque supports mode
31 in the core of the app?

Doesn't seem to follow the +40 standard.

Ian has added a R0, R2, R3 ... for reading the
raw byte values from the response. You might
try these to access the bytes of interest for this
non standard response. I would set ATH1 then
count every byte until you reach your desired
data bytes. (Where x equals count minus one
Rx & Rx+1)?

I would be curious if this works for you.

Thanks for getting back on this.

I do not know what the +40 standard is. So, I do not know how this response is not compliant. It seems compliant enough to me. Like I said, I tried with ATH1, but it did not make a difference. Also I don't understand why I would be able to count bytes with ATH1 and not with ATH0.

I did a few more tests. The total response (at another moment) was:

122
0: 61 02 10 02 10 02
1: 10 02 10 02 10 00 10
2: 02 10 00 10 00 FF FE
3: FF FE FF FE FF FE 10
4: 02 10 02 10 03 10 02
5: 10 03 10 02 10 02 10
6: 02 FF FE FF FE FF FE
7: FF FE 10 02 10 02 10
8: 02 10 02 10 02 10 02
9: 10 02 10 00 FF FE FF
A: FE FF FE FF FE 10 00
B: 10 00 10 02 10 00 10
C: 02 10 02 10 02 10 02
D: FF FE FF FE FF FE FF
E: FE 10 02 10 00 10 00
F: 10 02 10 02 10 02 10
0: 00 10 00 FF FE FF FE
1: FF FE FF FE FF FE FF
2: FE FF FE FF FE FF FE
3: FF FE FF FE FF FE FF
4: FE FF FE FF FE FF FE
5: 10 00 10 00 10 02 10
6: 00 10 02 10 02 10 02
7: 10 00 FF FE FF FE FF
8: FE FF FE 10 02 10 02
9: 10 02 10 02 10 02 10
A: 02 10 02 10 00 FF FE
B: FF FE FF FE FF FE 10
C: 00 10 02 10 02 10 02
D: 10 02 10 02 10 02 10
E: 02 FF FE FF FE FF FE
F: FF FE 10 02 10 02 10
0: 02 10 02 10 02 10 02
1: 10 02 10 02 FF FE FF
2: FE FF FE FF FE 10 00
3: 10 02 10 02 10 00 10
4: 02 10 02 10 02 10 03
5: FF FE FF FE FF FE FF
6: FE FF FE FF FE FF FE
7: FF FE FF FE FF FE FF
8: FE FF FE FF FE FF FE
9: FF FE FF FE 00 00 00

>

Forumlas were evaluated as follows:

(A*256+B)/1000	4,1
(C*256+D)/1000	4,1
(E*256+F)/1000	4,1
(G*256+H)/1000	4,1
(I*256+J)/1000	65,53
(K*256+L)/1000	65,53
(M*256+N)/1000	65,53
(O*256+P)/1000	65,53
(Y*256+Z)/1000	4,1
(AA*256+AB)/1000	4,1
(AC*256+AD)/1000	4,1
(AE*256+AF)/1000	4,1
(AG*256+AH)/1000	65,53
(AI*256+AJ)/1000	65,53
(AK*256+AL)/1000	65,53
(AM*256+AN)/1000	65,53
(AW*256+AX)/1000	65,53
(AY*256+AZ)/1000	65,53
(BA*256+BB)/1000	65,53
(BC*256+BD)/1000	65,53
(BE*256+BF)/1000	65,53
(BG*256+BH)/1000	65,53
(BI*256+BJ)/1000	65,53
(BK*256+BL)/1000	65,53
(BU*256+BV)/1000	55,32
(BW*256+BX)/1000	55,32
(BY*256+BZ)/1000	55,32
(CA*256+CB)/1000	413,86
(CC*256+CD)/1000	413,86
(CE*256+CF)/1000	413,86
(CG*256+CH)/1000	413,86
(CI*256+CJ)/1000	4177,53

Can somebody explain how I can have values larger than 65.535 when taking two bytes at a time and dividing them by 1000 😉

If I wanted to test with R0, R1, ... in combination with ATH1, do I skip the frame numbers when counting bytes (so 7 bytes per frame)? Or do I include the frame numbers (so 8 bytes per frame)?

BTW: Tested again with ATH1 and then the response is this:

762 11 22 61 02 0F FC 0F FA
762 21 0F FC 0F FC 0F FC 0F
762 22 FA 0F FA 0F FA FF FE
762 23 FF FE FF FE FF FE 0F
762 24 FC 0F FA 0F FC 0F FC
762 25 0F FC 0F FA 0F FC 0F
762 26 FA FF FE FF FE FF FE
762 27 FF FE 0F FC 0F FA 0F
762 28 FA 0F FA 0F FA 0F FC
762 29 0F FC 0F F9 FF FE FF
762 2A FE FF FE FF FE 0F FA
762 2B 0F FA 0F FC 0F FC 0F
762 2C FC 0F FA 0F FA 0F FA
762 2D FF FE FF FE FF FE FF
762 2E FE 0F F9 0F FA 0F F9 
762 2F 0F FA 0F FA 0F F9 0F
762 20 FA 0F FA FF FE FF FE
762 21 FF FE FF FE FF FE FF
762 22 FE FF FE FF FE FF FE
762 23 FF FE FF FE FF FE FF
762 24 FE FF FE FF FE FF FE
762 25 0F FA 0F FA 0F FA 0F
762 26 FA 0F FC 0F FA 0F FA
762 27 0F FC FF FE FF FE FF
762 28 FE FF FE 0F FA 0F FA
762 29 0F FA 0F FC 0F FA 0F
762 2A FA 0F FA 0F F9 FF FE
762 2B FF FE FF FE FF FE 0F
762 2C FA 0F FC 0F FA 0F FC
762 2D 0F FA 0F FA 0F FA 0F
762 2E FA FF FE FF FE FF FE
762 2F FF FE 0F FC 0F FC 0F
762 20 FA 0F FA 0F FA 0F FA
762 21 0F FC 0F FA FF FE FF
762 22 FE FF FE FF FE 0F F9
762 23 0F FA 0F FC 0F FA 0F
762 24 FC 0F FA 0F FC 0F FC
762 25 FF FE FF FE FF FE FF
762 26 FE FF FE FF FE FF FE
762 27 FF FE FF FE FF FE FF
762 28 FE FF FE FF FE FF FE
762 29 FF FE FF FE 00 00 00

>

Could the issue be related in the fact that there are multiple frames with the same frame number?

I have an idea about what the issue might be. The first block of 10 frames in the full response is:

0: 61 02 10 02 10 02
1: 10 02 10 02 10 00 10
2: 02 10 00 10 00 FF FE
3: FF FE FF FE FF FE 10
4: 02 10 02 10 03 10 02
5: 10 03 10 02 10 02 10
6: 02 FF FE FF FE FF FE
7: FF FE 10 02 10 02 10
8: 02 10 02 10 02 10 02
9: 10 02 10 00 FF FE FF

For this block, there is a mismatch for all PIDs except for the first four (8 bytes).

Now look at the last block of 10 frames:

0: 02 10 02 10 02 10 02
1: 10 02 10 02 FF FE FF
2: FE FF FE FF FE 10 00
3: 10 02 10 02 10 00 10
4: 02 10 02 10 02 10 03
5: FF FE FF FE FF FE FF
6: FE FF FE FF FE FF FE
7: FF FE FF FE FF FE FF
8: FE FF FE FF FE FF FE
9: FF FE FF FE 00 00 00

The first 8 bytes are exactly the same. From then on, the block is different, but it matches the wrongfully calculated PIDs. For this block there is a full match to the first so many PIDs!

Could it be that Torque, while receiving large multi frame responses, overwrites frames with the same frame number received earlier in the same response?

When I test for R0, it matches the first byte of the last frame labeled 0:. When I test for R14, the value I get back matches the first byte of the frame labeled 2:. Coincidence? I don’t think so….

Ian will have to weigh in on this.

The +40:

01xx request returns 41xx
22xxxx request returns 62xxxx

I don't believe Torque Pro recognizes
the mode 31 response in its core so
it doesn't surprise that the response is
not being parsed correctly.

Was hoping the R variables would allow
you to tell Torque the correct bytes.

Ah, thanks. I was aware of the 21 -> 61 rule, but I didn't recognise your "40+" as a reference to that rule.

Later tonight, I will set it up such that the request itself is 2102 instead of 3102. And see whether that makes a difference.

But to be honest, looking at my latest analysis of the issue, I do not expect much of it, as I cannot imagine it makes the difference between overwriting a buffer or not overwriting a buffer. If that is indeed what it is. Also, I have many other ECUs that respond to 3201 and 3202 requests, as far as I can tell, all without issue. But these all have much shorter responses. IIRC the next longest response is about 7 frames.

In response to Capp777s suggestion that it might have to do with the fact that the response was not compliant with the 40+ standard, I changed the request to 2102, but if did not make a difference.

Try to give your commands the terminal, most likely you will not be able to get the entire response
290 bytes in response to the exchange rate of 38400, I think a very large and small size ELM327 chip buffer, leading to malfunction and data loss
and clearing the buffer, after each received packet is not provided in ELM327

Thanks for that suggestion, but I am 100% sure that I am getting the full response (as I showed I in my previous posts)

First of all, I have Torque connecting to the adapter via a SW proxy, which allows me to log exactly what traffic is going back and forth between Torque and the proxy as wel as between the proxy and the adapter.

Second. I am using an OBDLINK MX, so the small ELM buffer is not an issue. But it was not an issue with the ELM either, as it takes about 200 - 250 msec to receive the full response from the Drive Battery ECU.

Btw: the proxy works in an A-Sync fashion (requests from the client are queued and responses from the adapter are buffered) allowing get to hook up multiple clients to multiple adapters simultaneously. Currently, I have TP running on a S7 Edge and a TAB 4 both showing data from 3 MX-es (one performing STMA monitoring against the main CAN BUS, one performing STMA monitoring against the secundary CANBUS that connects the ECUS of the hybrid drive train, and one running normal OBD requests to get data that I have not (yet) been able to extract from the raw frames).

The use of a proxy also allowed me to quickly move away from pid 3102 to 2102 as I can easily translate data in the proxy.

since response 6102....., it is understood that the ECU as a request 2102

That is correct.

Here at me the emulator so it turns out
Although response I give is much longer, it takes only Torque 054h bytes
https://yadi.sk/i/tCjUXqr3s5MrC
https://yadi.sk/i/aB-4-iczs5MsJ

Quote from anko on May 28, 2016 I have Torque connecting to the adapter via a SW proxy, which allows me to log exactly what traffic is going back and forth between Torque and the proxy as wel as between the proxy and the adapter.

What proxy software are you using?

Quote from cintakc on May 28, 2016
Here at me the emulator so it turns out
Although response I give is much longer, it takes only Torque 054h bytes
https://yadi.sk/i/tCjUXqr3s5MrC
https://yadi.sk/i/aB-4-iczs5MsJ

Thanks for staying with me. I have looked at your pictures and they do make sense to me. But I do not understand what you mean to say with them.

Are you saying TP works well as long as the response is not longer than 54h bytes?

Or are you saying you are sending more than 54h bytes and TP is receiving only 54h bytes? I assume the 54 is actually a part of your response? Or ...

The picture in my opening post clearly shows that TP is receiving way more than 54h bytes (although I cannot see whether it actually receives the full 122h bytes) as the screen is not big enough.

Quote from Automate on May 28, 2016What proxy software are you using?
This is a little Java program I wrote myself using Android Studio.

Or are you saying you are sending more than 54h bytes and TP is receiving only 54h bytes?
yes, limiting the number of bytes, it is likely this is a bug emulator
I'm have connected on the table parallel the connector and OBD2 ELM327 adapter VAG K + CAN 1.4
connected to a computer through a connector USB
and run the program on a computer emulator responses from 2 ECU
Utilities section

I am sorry, but I don't really understand what you are trying to say.

In my opening post, I have shown a picture where TP has received and displays at least 174 data byes (before running out of screen) out of the 290 bytes sent.

So, what is the relation to the 54h? Or are you saying a bug in the emulator stops you from reproducing my issue / situation?

Yes, I would like to say that the number of bytes for the 054(hex) I was able to check your case, I have at least everything is working properly

using OBD Link LX I could set the number of bytes in the response to the 0B4 hex
and shows unstable responses PIDs test in Torque
4.006 or 37.78 or No Data
possible program Torque can not consistently handle such great answers
https://yadi.sk/i/vibyTr-5s63zm
https://yadi.sk/i/tO6NnN43s642S
https://yadi.sk/i/h7YIaY2js642v