How do I decode BMW CAN data (over OBDII)

Question

I'm using an ELM327 type device. I'm trying to poll and decode data on my BMW i3. I'm using some of these resources as a reference:

1. This post breaks down the init I need to do.
2. This further post shows some query types
3. This reply explains some of the decoding aspects.

However, without some kind of "frame breakdown", I can't really grasp how I can decode these replies. I've tried applying something like this from the CAN wiki page, however I cannot seem to get the data replies to line up with the explanation in dot point 3.

My goal is to understand the reply frame format so I can implement my own decoder in my own tool I'm scripting. To that length, being able to decode the frames in the post in point 3. would be useful "607F1100762DD69FFFF 607F121FE44FFFFFFFF".

To be clear, I understand that different frames have different data types in their "data payload". I'm not asking about those. Once I understand how to decode the frames and "isolate" the data payload, I'll be able to interpret the data from other documented sources.

Answer 1

I was able to get really good information from the legends over at /r/CarHacking.

In that thread I asked basically the same question. Cyrix2k replied with:

It's UDS, derived from KWP2000

which was a very good starting point as I had no idea there were transport protocols sitting on top of CAN.

Then CitizenItza replied with a very good breakdown of the packets in question. Here it is:

BMW adds an extra layer for ECU adressing so it could be confusing. The example you wrote is a 2 frame answer form an an ECU (Address 0x07) consisting one "first frame" and one "consecutive frame". Meaning of the frames/bytes:
607 - CAN Identification
F1 - Target Address, usually F1 is the target of the diagnostic tool 10 - Indicator that this is a "first frame" (more of this: ISO 15765-2)
07 - Number of usefull bytes sent (excluding this one, bolded the ones which are included)
62 - Service (0x22 + 0x40 = 0x62)
DD - PID High byte
69 - PID Low byte - (so the pid is 0xDD69)
FF - Data 0
FF - Data 1

607 - CAN Identification
F1 - Target Address again
21 - Indicator that this is a "consecutive frame" (high nibble indicates the frame type, the low nibble is a frame counter 1->F)
FE - Data 2
44 - Data 3
FF - Filling byte
FF - Filling byte
FF - Filling byte
FF - Filling byte

You can find older but full versions of these standards online, however the data representation is proprietary. UDS

Using the above information I was able to make my own basic packet parser for my tool.