Coding M modules in a non M car

RSL

Lieutenant
Aug 11, 2017
748
402
0
I'm all stock 335is right now, I can run a log at some point and see what it does. I can almost guarante that log was a long press though, I never used DTC ever. It's either all on or all off.

0x315 only works on Z4, which is a different setup (no on/off sport, 3 modes). It should work with the switch, some rewiring, coding and maybe DME/DCT bins though. Not sure if you're trying to do this all with mix of factory parts/programming/coding or using a shield/interposer?

M button doesn't just change throttle/rng_l, it enables B_sport flag for other functions, sets EPS/servtronic and DSC. I was never able to confirm it actually did anything with DSC though. It definitely didn't turn it off and didn't seem like it did anything to change intervention from full on.
 

dzid_

Private
Feb 22, 2018
36
17
0
US
Ride
135i 2011 DCT
Ok, all good info.

The reason I thought 0x315 would work on 135i DCT was the post from Olza:
About statuses (Program level, Sport and Spirited) in DCT.

Sport Status.
If Sport button (CFG) is true (x35/Z4), then Sport status triggered from Sport button (x35) or CAN 0x315 Vehicle info data bits (Z4).
Else logic compares raw Program mode with switch threshold (CFG, =5) and if >=, then Sport status in DKG enabled. This is P5-P6 (M3).
Raw Program mode is pure program level from GWS and Program button pressing. Interesting, that in Pre- and Rennstart, value is forced to 0x46 (M3) or 0x42 (x35/Z4). Seems high bits is Rennstart flag, low bits is max Program level.
This Sport status used in overrun and dynamic downshifts logic.

Program level.
Raw Program mode calculated. Then if Sport button (CFG) option is true (x35 or Z4) level is taken from 0x315 Vehicle info data bits (Z4, 1-2-3) or defaulted to P1 (x35).
Else for M3 it is taken from raw Program mode (masked low bits). Calculation of simplified Program level for x35 - if Sport status, then use Program level 2 (P2).

Spirited Drive Status.
Program level has used in Spirited drive status calculation like in this table.
View attachment 48016 GTS
View attachment 48017 x35/Z4
This status used in many logic calculations and very important.

So our target after all this manipulations with SZL and stuff to maintain correct status calculations.

About 0x399.
Status M-Drive.
As i wrote before somewhere, ST_MDRV_MOD_GRB (3 bits, 0:nochange 1:Automatic 2:Sequential), ST_MDRV_STG_GRB (4 bits, 0:nochange 1..6:Stufe) and something undocumented in DME docs which i have, lets name it ST_MDRV_ACT_GRB (2 bits, 0:not active 1:active?, 2:setdata?) - seems this is control status for incoming mdrive data interchange. Better have logs, this status is at byte 1 low two bits (mask 00000011).
, but I think I misinterpreted it that both Sport button and 0x315 are respected by non-M DCT. I think it is like you are saying, that 0x315 only listened to bu the Z4 DCT firmware.

My aim is to use stock part hardware + M DSC firmware + Servotronic + possibly a diy CAN thingy injecting extra messages. (I don't know if I care enough to manipulate its Servotronic assist level (presumably via injected 0x399))

I will not have M button, but I think DCT Sport button does the same as M button on 1M ??!!! :)

I think I will do one-way synchronization of the DTC using CAN injector (easy to do), so I don't have to press it or hold it (especially that its MDM status won't be visible on Kombi). My desire is:
1. GWS shifter lever to the left (M/S) shall turn fully off DTC/DSC.
2. DCT Sport mode shall just turn on DTC.

For that second one, I will have to see, because, as I mentioned, on the stock 135i, DTC-on or DSC full-off disable DCT's Sport mode accelerator pedal mapping (and "pre-boosting" thing and clutch slip snapping). Hopefully, "MDM" mode doesn't do that. I guess you can't clarify that if you never single press DTC/MDM.

PS: My car is at customs in a freaking container so I cannot test anything :(
 

RSL

Lieutenant
Aug 11, 2017
748
402
0
I tried every which way to find 0x315 active anywhere with any mix of 335is/1M/M3 parts/bins/coding/settings. I bought the Z4 mode switch to try that setup last year, but haven't really touched anything since pulling the M3 stuff out.

0x399 works natively with IKM0S as far as MSD81 goes. 399 is fine passing to EPS and presumably DSC, but it will not pass M Drive settings to MDCT without work. The 399 message IKM0S builds has a bit disabled that MDCT needs to acknowledge it. Since 1M is MT only, that bit is hard coded off in the rom. You can pass the message on a shield with the bit enabled though and it will transfer settings to MDCT with the M button.

The only part I didn't follow all the way through on was the DSC from M button, but even M3 requires a manual long DSC press to fully disable, so that might take some work.

For the record, MDCT+M3 GWS alone will set rng_l when moving to sequential/manual mode (shifter right), but doesn't toggle the other settings that the M button does.

I can't imagine why it would take away rng_l for DTC on 135, it doesn't on 335is.
 

amg6975

Sergeant
Oct 27, 2019
275
177
0
Ride
2012 135, 2005 ZHP, 2009 fJCW
Btw, I was stupid. In all these BMW messages I always thought there are two counters. Of course, it is probably one counter and second one is a checksum that looks like a counter for mostly static messages. I thought the offset between them is the checksum - well I guess that is one way of thinking actually. :)

I would be extremely surprised if there was a checksum. There are several packets that have two counters. 0x399 is actually the only one I've ever seen with a true checksum.
 

dzid_

Private
Feb 22, 2018
36
17
0
US
Ride
135i 2011 DCT
0x399 works natively with IKM0S as far as MSD81 goes. 399 is fine passing to EPS and presumably DSC, but it will not pass M Drive settings to MDCT without work. The 399 message IKM0S builds has a bit disabled that MDCT needs to acknowledge it. Since 1M is MT only, that bit is hard coded off in the rom. You can pass the message on a shield with the bit enabled though and it will transfer settings to MDCT with the M button.
Do you think xHP DCT flash then would react to 0x399? I suspect xHP is based on M3 GWS, since it has some features (like kick-down clutch-open in 1st gear), that I haven't experienced on stock 135i DCT firmware.

For the record, MDCT+M3 GWS alone will set rng_l when moving to sequential/manual mode (shifter right), but doesn't toggle the other settings that the M button does.

I can't imagine why it would take away rng_l for DTC on 135, it doesn't on 335is.
I am assuming rng_L = better throttle response.
Then this thing is definitely happening and is super annoying. I have 135i N55, and it might be specific to its firmware. MHD didn't fix it. Someone mentioned that maybe 135is doesn't have that safety quirk.
 

RSL

Lieutenant
Aug 11, 2017
748
402
0
XHP for DCT is definitely not based on M3 anything for non-Ms. Everything it does is available in non-M DCT, it just changes to activate/use it the logics.

At the lowest level, 0x399 is only available if car is determined to be an M Drive variant. It may work in non-M DCT if that can be set, but I haven't dug that far. XHP will have no bearing on it though.

Might be N55 or 135i only thing, but that would be annoying. Glad I don't have it lol
 

aus335iguy

Colonel
Nov 18, 2017
2,144
739
0
Down under
Ride
335i DCT 2009
This is probably a better place to source info on and discuss this…
 
  • Like
Reactions: RSL

dzid_

Private
Feb 22, 2018
36
17
0
US
Ride
135i 2011 DCT
Final note on that:
I would be extremely surprised if there was a checksum. There are several packets that have two counters. 0x399 is actually the only one I've ever seen with a true checksum.

These "second counters" I saw are in fact checksums.
It can be surprising,... because why would they add checksums if CANbus has CRC already on a hardware level? Well, software checksums are still useful to detect if a sender had for example a memory corruption of some sort.


I used your algo as a starting point and I run it on different messages.

I only saw a 4bit checksum on 0x130, besides the 0x399.

The most common checksum is 8bit though. Ids : 0x19e, 0xb8, 0x1a0, 0xaa, 0xbf, 0xba, 0x3b1
- Very similar algo to yours, but without adding "upper nible".
(The checksum for 0x194 (cruise control buttons) was different because message id was not added to the other bytes.)
Python:
def calc_checksum(work_data, msg_id):
  checksum = msg_id
  # checksum = 0  #0x194
 
  for byte in work_data:  #checksum removed stripped from the data first
    checksum += byte     #add up all the bytes
 
  checksum = (checksum & 0xFF) + (checksum >> 8); #add upper and lower Bytes
  checksum &= 0xFF #throw away anything in upper Byte
 
  # checksum = (checksum & 0xF) + (checksum >> 4); #add first and second nibble 0x399, 0x130
  # checksum &= 0xF; #throw away anything in upper nibble

  return checksum

(Additionally, some checksums for accelerometers and angle position messages etc, I believe are CRCs since that don't change linearly and there are also checksums with previous sample memory, which doesn't make sense to me.)