[ Edit: Most of the below is wrong, see following posts.
It now looks like 784 messages are TO the BMU, 785 messages are FROM the BMU.
It also looks now that responses starting with 0x10 have 4 data bytes, not 3 as with the MG.
See my massively amended interpretation
here. ]
kiev said:
Some interesting new PIDs or CANIDs [783,784,785] seen while using the MUT.
My understanding is that PIDs and CAN IDs are different things; more below.
Piev (Paul) was doing a "read DTCs" while capturing the OBD traffic and we can see something that the MUT is doing...
Excellent! This is what I hope to be doing soon. Here are my guesses for what some of this means, based in part on playing with raw ELM327 commands to my MG ZS EV (not available in America), mainly in
this post.
21224:18:41:04.845 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 87 0 0 0 0 0
784 may not be associated with returning PID data. It seems to be common to always use 8 data bytes in the CAN data, and waste the first data byte by using it for the length of useful data (in this case 2). [ Edit: It looks like this might be a service byte, which often but not always corresponds with the length of the data after that point. ] So the data here is 1A 87, very likely representing 0x1A87 or 6791 in decimal. Note how the last 5 bytes are all 0s; unused bytes seem to be 0s, FFs, or occasionally 55s or CCs. However, since Paul was doing a "read DTCs", it seems possible that this 0x1A87 represents the last 4 characters of trouble code P1A87 ("CMU06 module temperature sensor abnormal").
[ Edit: As below, 1A 87 seems to be asking the BMU for hardware information. Paul has decoded this now. ]
21229:18:41:04.892 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 78 FF FF FF FF
By contrast, 0x785 does appear to be a PID response CAN Id, possibly for an ECU with a primary address of 0x785 - 8 = 0x77D. But since the first byte is 3 and there are 3 non-zero, non-FF bytes following, this packet may actually be normal data, not related to a PID. However, it could also be related to a trouble code like P1A78 ("CMU03 battery cell voltage sensor abnormal").
Or, it could be that 7F indicates that the ECU doesn't recognise the request, and 1A is the service code. But then the last byte should be 0x31, according to the standard.
Maybe it indicates that trouble code P1A78 is
not asserted.
21247:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 FF 0 4 10 0 0 34
21251:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 36 37 30 41 36 37 33
21255:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x23 0 0 FF FF FF FF FF
I would normally expect a sequence of packets like this starting with 0x21, 0x22... to be preceded by a packet starting with 0x10, and there are such examples later on. Perhaps the 0x10 packet got filtered out somehow.
Generally, 0x21 at the start of the packet means "extended data continuation frame 1". Note the third frame with only two nulls as real data; this seems to terminate an ASCII string (in this case "4670A673").
ASCII characters seen in the previous 3 lines: 4670A673 this looks like a Mitsubishi part number? It is a part number-- for the 2012 the ABS pump module!
That sounds reasonable, and helpful. Though I wonder if it's related to a BMS trouble code.
21285:18:41:05.033 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0
21289:18:41:05.033 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 12 FF FF FF FF
21320:18:41:05.126 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x4 18 0 FF 0 0 0 0
21326:18:41:05.173 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 18 78 FF FF FF FF
Strange how 784 data can be 2 bytes or 4. The 4 byte packet doesn't seem to be DTC related.
P1A9C seems to be related to renumbering CMUs (per
this page), which doesn't seem to fit this data.
Again, the 7F <service code> 78 may indicate request not recognised. Though the first 785 packet above does not end in 78, so that seems to rule out the idea that Mitsubishi use 0x78 instead of the standard 0x31.
21431:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 14 58 6 D1 4 20 D1
21434:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 5 20 D1 1B 20 D1 0
21438:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 20 D1 9 20 D1 8 20
This is formatted like MG PID response data. 0x10 means this is the first frame of a multi-frame response. 0x14 (decimal 20) means 20 bytes of real data after this one. 0x58 is the "custom service". It would appear in data going to the ECU, either as 0x58 or as 0x18 (0x40 is sometimes added to the service code (see
Wikipedia OBDII PIDs)). The next 2 bytes are a copy of the PID (Parameter IDentifier), which is just a code indicating what data is requested or provided. In this case, it's 0x06D1, although it's suspicious that 0x0
yD1 (
y is a varying hex digit) is common in the actual data. Then there is 3 bytes of data in this frame (04 20 D1), then 7 bytes in the next frame, and 7 in the last frame. That adds up to 3+7+7 = 17 bytes of data, plus the service code and PID (1+2), a total of 20 bytes, as given in the first frame. It just happens that there are no unused data bytes in this data set.
[ Edit: The first D1 is actually the first byte of the data. ]
I can't guess what this data represents. 0x20 followed by 0xD1 is very common in this particular response data.
21510:18:41:05.680 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 4 0 0 0 0
A single frame response. Doesn't look like a PID response.
21514:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 4 20 21
21517:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF
This looks like a 2-frame PID response, 12-3 = 9 bytes of data, service code 0x57, PID 0x1D1.
21548:18:41:05.805 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 5 0 0 0 0
Doesn't look like a PID response.
21550:18:41:05.805 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 5 20 21
21554:18:41:05.852 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF
PID response, 12-3=9 bytes data, identical data except for the first byte being one higher. This first byte may be a sequencing byte.
21588:18:41:05.945 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 1B 0 0 0 0
3 bytes, does not look like PID response.
21591:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 1B 20 21
21592:18:41:05.945 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21595:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF
A two-frame PID response, identical to two previous ones apart from the first byte, with a 784 packet interspersed. That 784 packet doesn't seem to fit the usual pattern, unless 0x30 is another framing code. Maybe it means "nothing to report, all is well",
[ Edit: as follows, 30 0 ... 0 is a flow control message. ]
21630:18:41:06.039 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 0 0 0 0 0
21636:18:41:06.086 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF
This continuation frame seems to be missing its first frame. Identical data to earlier second frames.
21670:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 9 20 21
21673:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF
Another two-frame response with the same data, again except for the first byte. This time the first byte isn't just a little more than the last time, i.e. this disproves the sequence idea, unless a lot of data is missing.
21703:18:41:06.273 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 8 0 0 0 0
Again, only the last byte of this data is changing.
21707:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 8 20 21
21708:18:41:06.273 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21710:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 FF FF FF
Another two-frame response, also with the 784 packet between frames.
783
18:41:11.752 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x23 20 20 0 0 0 0 0
18:41:11.845 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x5 58 1 D1 16 60 0 0
These don't appear to be a PID response.
