Per signaling sport mode... Any chance the JBBF or DME can take a signal directly? Hardwire is what I was wondering.
Discussion about issues encountered whilst converting to M3 Flash and GWS
- Thread starter aus335iguy
- Start date
Custom 2pc aluminum driveshaft getting balanced to connect my trans to the M3 diff:
I can’t tell from the logs but does the tune affect the shifts as first thought and do you guys think that it can be tuned out?
Tuning effects shifts, there's not even a question. Whether there's anything that can be done via DME to help this particular situation is still TBD. My guess is, will help with certain aspects, but isn't going to change the fact that DME and TCU have a ratio mismatch without a 3.15 FD.
What approach did you take here? Assuming you have a back out plan... M3 drive shaft plus another donor to blend together?
No back out plan. Forward, till victory is achieved.
EDIT: I was watching "The Darkest Hour" while I typed that. But I stand behind it. I'm not going backwards, only forwards.
Last edited:
@jyamona needs to address this, but here are my thoughts.
I've put a lot of thought into this, and I have intuition telling me the answer is yes. But it isn't based on TunerPro and the XDF definitions. Let me explain:
1. The DCT does throttle blips on downshifts. It does this through a PT-CAN request telling the DME to increase RPM to a new higher value based on the current gear, the rear diff ratio, and the new gear. So the DCT tells the DME to blip the throttle perfectly. I think we are all aware of this and it was something BMW marketed pretty heavey.
2. The DCT also does the same on upshifts. But instead of blipping the throttle to a higher RPM, it is telling the DME to perfectly rev match the RPM to the next preselected gear.
3. The DCT also sends a PT-CAN request during launch control to set a particular RPM. This is why flashing our trans changes the LC RPM.
What do these three points tell us? They tell us that the DCT is sending a request to the DME and that the DME is processing that request via some routine. And if this routine exists, and we can find it in the DME (@jyamona), then cracking the TCU isn't needed. We can simply have a flash time option in MHD where you can apply an offset to this routine based on your rear gear ratio! So if our rear diff is 23% off we can apply that offset to the requested RPM (inside the DME) and the DME can adjust while the TCU remains oblivious.
There is already progress made here even if we don't realize it. Jyamona has figured out what routine is being called during launch control and he has hijacked it. He can control it.
The LC routine is inherently simpler to account for, so make no mistake (if I am correct) that this would be a difficult proposition. But I am extremely confident that this can be addressed in the DME. I envision some flash time option on the MHD screen that allows you to input your rear gear ratio. MHD then would need to pull the EKG ZB# to determine what gear ratio the TCU is expecting, then a little simple math will spit out an offset ratio that would be applied inside the downshift and upshift routines in the DME at the time of flash.
Yea, I'm over simplifying it a LOT but I really believe this is the best course of action for us to be able to use alternate gear ratios.
That's a possibility but it would cause other issues. The wheel speed sensors feed into the DSC, and that unit outputs a PT-CAN message for vehicle speed. So installing 4 yellow box's at each wheel should in theory work but the DSC unit might behave funky. There would definitely be a problem with reported speed on your speedometer and the associated problems with the odometer too.
But in theory that should work.
Just adding a calculation to RPM in the DME would report the RPM difference to everything and very likely throw a different wrench in the works, yes. I was thinking specifically the RPM signal between the DME and TCU only, but don't know if there's a way to grab it and adjust it in and out right before the TCU.
Since tach, speedo and everything else appear to report/function properly for 2.56, it seems the only thing that's potentially out of the loop at this point is the TCU since it's mostly self-contained. The TCU internally knows the DCT shaft speeds via sensors and gears/FD from coding, but is being fed 2.56 gear RPM. If it's feeding out the next gear RPM back to the DME based on internal calculations using 3.15, the output RPM back to the DME would be much higher, so if that RPM signal (and only that RPM signal) could be converted between only the DME and TCU, might have a shot with, hopefully, no collateral.
Since it's via CAN, might be an option for Arduino if it's fast enough, but have zero experience with it. I would assume the in/out signals are different IDs and if they are, might not be a huge deal to grab both and perform the calcs on each. I may be very optimistic on the ease of doing it, but massaging a signal seems a whole lot easier and wouldn't be stuck with tall FD for those of us concerned about it.
I hope Jake or someone with CAN experience can chime in...
Since tach, speedo and everything else appear to report/function properly for 2.56, it seems the only thing that's potentially out of the loop at this point is the TCU since it's mostly self-contained. The TCU internally knows the DCT shaft speeds via sensors and gears/FD from coding, but is being fed 2.56 gear RPM. If it's feeding out the next gear RPM back to the DME based on internal calculations using 3.15, the output RPM back to the DME would be much higher, so if that RPM signal (and only that RPM signal) could be converted between only the DME and TCU, might have a shot with, hopefully, no collateral.
Since it's via CAN, might be an option for Arduino if it's fast enough, but have zero experience with it. I would assume the in/out signals are different IDs and if they are, might not be a huge deal to grab both and perform the calcs on each. I may be very optimistic on the ease of doing it, but massaging a signal seems a whole lot easier and wouldn't be stuck with tall FD for those of us concerned about it.
I hope Jake or someone with CAN experience can chime in...
Yea I have the routine which sets engine RPM based on the CAN msg from the TCU. Currently I ignore the value sent when the car is in launch control mode, and replace it with my own value. I'm sure I could apply a static offset to the value sent outside of launch control mode.
This would mean @doublespaces could run whatever rear diff ratio he wanted if the offset was applied to the upshift/downshift routine
This would mean @doublespaces could run whatever rear diff ratio he wanted if the offset was applied to the upshift/downshift routine
I haven't had my coffee yet so I'm struggling to think this through fully, but would it be the same static multiplier applied for both upshifts and downshifts? I am not sure I would be able to differentiate between the two in the RPM set routine.
Yes, the same static multiplier. Because the rear diff will always be a certain % higher or lower than expected. The M3 EKG ZB's expects a 3.15 and the N54 EKG ZB's expect a 2.56. You will always be deviating from one of those ratios and it will always be by a set +/- percentage.
Testing at that low of an rpm is useless. The % deviation means that the actual RPM difference below 2000rpm is minimal. I have no custom tuning and below 2000rpm I'm glass smooth.
To really see the problem this all needs to be looked at above 6000rpm.
Thank you, that's what I was thinking but wanted to confirm. So you have the 2.56 still and TCU software expects a 3.15, so your's would need to multiply by 0.812698... I am not sure how many decimal place resolution would be needed, but I imagine 0.813 would suffice.
Do you think a max adjustment factor of 0.5 to 1.5x would suffice?
Similar threads
