Yeah, correct. What I called M_ACT_2 just signals the KOMBI to display the M, people have this working. The M_ACT parameter is what's missing from IKM0S to actually enable M Drive in the JBBF (Servotronic) DSC, and DKG.
M-Drive and MDM in non M cars
- Thread starter aus335iguy
- Start date
I've only worked out the code checksums, not looked at the comms ones. I might be able to find how they are done, I'd imagine they are simple to reduce overheads, the other code checksums are quite complicated but they are only checked once, not 100 times a second.
Yeah I think it's tied to the counter some how, I just can't figure out the exact logic...
Here's a log of pressing the M button a bunch of times. I can't get a handle on the checksum:
| ARBID | BYTES | D0 | D1 | D2 | D3 | D4 | D5 | TIME | DELTA T |
| 0x399 | 6 | 0x89 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 659.8042 | 0.16 |
| 0x399 | 6 | 0x77 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 659.6442 | 0.16 |
| 0x399 | 6 | 0x66 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 659.4842 | 0.59 |
| 0x399 | 6 | 0x57 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 658.8942 | 0.16 |
| 0x399 | 6 | 0x46 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 658.7342 | 0.16 |
| 0x399 | 6 | 0x35 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 658.5742 | 0.69 |
| 0x399 | 6 | 0x22 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 657.8842 | 0.16 |
| 0x399 | 6 | 0x11 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 657.7242 | 0.16 |
| 0x399 | 6 | 0x00 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 657.5642 | 0.63 |
| 0x399 | 6 | 0xE1 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 656.9342 | 0.16 |
| 0x399 | 6 | 0xD0 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 656.7742 | 0.16 |
| 0x399 | 6 | 0xCF | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 656.6142 | 0.64 |
| 0x399 | 6 | 0xBC | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 655.9742 | 0.16 |
| 0x399 | 6 | 0xAB | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 655.8142 | 0.16 |
| 0x399 | 6 | 0x9A | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 655.6542 | 0.65 |
| 0x399 | 6 | 0x8B | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 655.0042 | 0.161 |
| 0x399 | 6 | 0x7A | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 654.8432 | 0.16 |
| 0x399 | 6 | 0x68 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 654.6832 | 0.68 |
| 0x399 | 6 | 0x55 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 654.0032 | 0.16 |
| 0x399 | 6 | 0x44 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 653.8432 | 0.16 |
| 0x399 | 6 | 0x33 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 653.6832 | 0.6 |
| 0x399 | 6 | 0x24 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 653.0832 | 0.16 |
| 0x399 | 6 | 0x13 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 652.9232 | 0.16 |
| 0x399 | 6 | 0x02 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 652.7632 | 0.98 |
| 0x399 | 6 | 0xEF | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 651.7832 | 0.16 |
| 0x399 | 6 | 0xDE | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 651.6232 | 0.16 |
| 0x399 | 6 | 0xCD | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 651.4632 | 1.081 |
| 0x399 | 6 | 0xBE | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 650.3823 | 0.16 |
| 0x399 | 6 | 0xAD | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 650.2223 | 0.16 |
| 0x399 | 6 | 0x9C | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 650.0623 | 0.56 |
| 0x399 | 6 | 0x89 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 649.5023 | 0.159 |
| 0x399 | 6 | 0x77 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 649.3432 | 0.161 |
| 0x399 | 6 | 0x66 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 | 649.1823 | 0.98 |
| 0x399 | 6 | 0x57 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 648.2022 | 0.16 |
| 0x399 | 6 | 0x46 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 648.0422 | 0.16 |
| 0x399 | 6 | 0x35 | 0x02 | 0x00 | 0x22 | 0x51 | 0x87 | 647.8822 | 9.102 |
Last edited:
I've found where the MDrive stuff is done in IDA so I might be able to follow it to see how the checksum is done.
That last screen i sent has a clue about it: CHKSM_ST_MDRV = CRC_CLC_CAN_STMDRV (Standart 4bit checksum)
There's no symbols for it so I'll only be able to find it if it's close to the MDrive logic in the execution order.
That last screen i sent has a clue about it: CHKSM_ST_MDRV = CRC_CLC_CAN_STMDRV (Standart 4bit checksum)
There's no symbols for it so I'll only be able to find it if it's close to the MDrive logic in the execution order.
NO. its just led status. We need that unused two low bits in byte1.
And i think its not used in DME, so no description.
Last edited:
Looks like @AzNdevil is right in that there's no logic for writing to that area of the telegram. I'll keep looking for a bit to see if it's something that could be added in.
Interested to see all the different DSC modes though. One thing that really bugs me about my 335i is how invasive the DSC is. My Z4 puts the power down much better and also manages slip a lot better. I'm sure some of that is tyre and chassis differences but most of it is the DSC killing power way too much.
Interested to see all the different DSC modes though. One thing that really bugs me about my 335i is how invasive the DSC is. My Z4 puts the power down much better and also manages slip a lot better. I'm sure some of that is tyre and chassis differences but most of it is the DSC killing power way too much.
@amg6975, looks like tricore mnemonic, good.
0. clear low four (crc) bits in byte0 of canarray(6).
1. Crc int16 = 0x399, i = 0
2. crc = crc + canarray(i), i++, Loop i<6
3. Tmp = crc >>8 (ie crc 0x854 = tmp 0x08)
4. Crc = crc AND 0xFF (ie crc 0x854 = 0x54)
5. Crc = tmp + crc (just add low and high bytes of initial crc = 0x5C)
6. Tmp = crc >>4 (0x05)
7. Crc = crc AND 0xF (0x0C)
8. Crc = tmp + crc (0x11 sum of high and low quarter bits)
9. Crc = crc AND 0xF (crc = 0x01 to fit into 4 bits crc)
Example:
1. clear low (crc) bits in 0x89 = 0x80
2. Calculate sum of all new bytes = 0x16B
3. Add can id: 0x399 + 0x16B = 0x504
4. Add low and high bytes to byte = 0x09
5. Add low and high quarter bits in byte = 0x09
6. Mask low four bits: 0x9
7. Insert in crc field that four bits.
8. damn! 0x89 ))
upd: as i can see, DCT did not check crc, only alive counter.
0. clear low four (crc) bits in byte0 of canarray(6).
1. Crc int16 = 0x399, i = 0
2. crc = crc + canarray(i), i++, Loop i<6
3. Tmp = crc >>8 (ie crc 0x854 = tmp 0x08)
4. Crc = crc AND 0xFF (ie crc 0x854 = 0x54)
5. Crc = tmp + crc (just add low and high bytes of initial crc = 0x5C)
6. Tmp = crc >>4 (0x05)
7. Crc = crc AND 0xF (0x0C)
8. Crc = tmp + crc (0x11 sum of high and low quarter bits)
9. Crc = crc AND 0xF (crc = 0x01 to fit into 4 bits crc)
Example:
| 0x89 | 0x01 | 0x00 | 0x22 | 0x41 | 0x87 |
2. Calculate sum of all new bytes = 0x16B
3. Add can id: 0x399 + 0x16B = 0x504
4. Add low and high bytes to byte = 0x09
5. Add low and high quarter bits in byte = 0x09
6. Mask low four bits: 0x9
7. Insert in crc field that four bits.
8. damn! 0x89 ))
upd: as i can see, DCT did not check crc, only alive counter.
Last edited:
You may be able to code the friction coefficients in the DSC to allow for more slidey. You certainly can adjust MDM, but I’m not sure about “On.”
Awesome, thank you! I want to make sure I/we fully understand the ins and outs of M Drive before I tear down my M3.
That’s why M3 coefficients are the ones to have. Pretty sure they’re different between “on” and MDM and both sets can be moved across to “on”and DTC on a non M respectively
Last edited:
No worries. Understanding how the iDrive sets the M Drive parameters is a bit self serving because I won't have iDrive in the M1.5 but I probably will make a CAN module to configure them.
yes it is possible to code the friction coefficients but the values from a m-dsc is not in the list in a non-m dsc
i looked into this a few years ago but i havent tried to forcefully change it through nettodat
i am not sure if it will work since the coding is just referencing from a preset list of parameters which we cant see...
eg. steering angle characteristic curve, values from both mk60_87.c0a and mk60_m3.c0<X> both refer to values 00 01 02...
imo the most annoying thing is if you do a servotronics retrofit with a m3 steering rack, traction control keeps on cutting in and apply brakes if you turn the steering wheel too fast (eg. crank the wheel hard at 40-50 km/h into a 90 degree corner) the car isnt understeering but with squealing track pads you can hear the brakes being applied
Nettodat coding was what i was getting at yes.
Ive long wondered how having an M3 rack without the SZL would behave. I think this is a key point that people miss. The SZL encodes the steering angle and tells the DSC how much the wheels are turned. If you change the rack ratio this goes out the window. So a question for later would be if the SZL has a parameter that can be coded relating to steering rack ratio.
Ive long wondered how having an M3 rack without the SZL would behave. I think this is a key point that people miss. The SZL encodes the steering angle and tells the DSC how much the wheels are turned. If you change the rack ratio this goes out the window. So a question for later would be if the SZL has a parameter that can be coded relating to steering rack ratio.
i logged from the szl and the wheel angles are actualyl correct without changing to a m3 szl but... on the m-dsc program its in the coding
however, this implies the brake pressure calculations in the dsc will be off if a m-dsc or m-dsc program running on a non-m dsc
another thing would be the different sized valving in the m dsc hardware compared to non m, different master cylinder, different caliper diameters, and the list goes on and on........
tldr; it is possible when mdm kicks in, too much brakes get applied and make things worse, but then it might not be a problem especially for guys with bbk since most kits out thre throw all of these considerations out the window
Similar threads
