I have an ECU that returns a very long multi frame response to a specific request. The response tells me (amongst other things) the battery voltage of individual battery cells in my drive battery.

The next picture shows the result for formula (G*256+H)/1000:

This response is correct. G and H are the 3rd (0F) and 4th (A5) byte of the second frame. This translates into (15*256+165)/1000 = 4.005.

The next picture shows the result for formula (I*256+J)/1000:

The response should be constructed using the 5th (0F) and 6th (A6) byte of the second frame, resulting in (15*256+166)/1000 = 4.006. Instead it shows 65.534, which would translate back into FF FE.

The previous PIDs, which look at A+B, C+D and E+F work well. The next PIDs which look at K+L, M+N and O+P fail as well.

I have tried with headers on and off and with spaces on and off. Found no difference.

Any thought?

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

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

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.

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

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

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

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

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