Makes sense. I was focused on vehicle speed matching not drive shaft speed. Diff is expected to show up Saturday. Unfortunately, I'll be out of town this weekend.The problem is that with tyres you are not changing the ratio between wheel sensor and the transmission sensor. And this is where the calculation mismatch occurs.
|A perfectly functioning lock is critical to performance and driveability, especially in a powerful front-engine rear-wheel drive vehicle. For this purpose, the M3 DKG is translated in series arg long and can increase significantly with a shorter axle ratio again in the wheel torque respectively the acceleration.|
In the translation, I have opted for an i = 3.62 wheelset (15% shorter than series i = 3.15). For this purpose, the gear software must be adapted accordingly, which, as always , has done the software man of my trust Oliver Enenkel of OE Motors .
In the lock, the choice fell on a Drexler lock body with a Z4 GT3 similar setup with eight disk packs and perforated friction and outer disks for perfect oil circulation and thus optimal response. For this I have set a little bias to permanently ensure a nearly constant performance and to keep the maintenance intervals long.
Don’t think anyone’s ever seen a BIN for the GS40?
Over the past week I wrote a small script to unpack and merge the 0da/0pa, and have started an IDA disassembly project for the resulting bin after a few educated guesses at cpu type. At this point, even if the FD table were identified, I highly doubt you could just flash it with Winkfp as both the checksum and RSA signature would be wrong.I don't know anyone that has an actual bin, but an option may be 0da/0pa merge if we can determine the correct offsets and potentially write changes back through WinKFP. Not sure I'd want to be the guinea pig for that though lol
Cool, thanks for looking into it! I thought WinKFP corrected the checksum at flash time, but I've never attempted to flash a modified bin via WinKFP. Would still leave RSA as a problem even if it did though.Over the past week I wrote a small script to unpack and merge the 0da/0pa, and have started an IDA disassembly project for the resulting bin after a few educated guesses at cpu type. At this point, even if the FD table were identified, I highly doubt you could just flash it with Winkfp as both the checksum and RSA signature would be wrong.
The OE motors approach sounds promising, though it sounds more like an adaptation or coding change rather than than a reflash.
Well done @Stokes. Great news indeed.UPDATE...
I found other posts that said Oliver can only do 3.64 so I didn't expect to hear back. And then an email at 3 am central time saying he could do it but was super confused of why would you use such a long gear, didn't I mean 3.56?
I sent him details of the conversion to clarify.that I do indeed want 2.56 final drive adjusted in the M3 DCT programming.
Waiting to hear back.
I’m aware of the effort that’s required vs where we are now. Still, the fact that someone who has a track record of completing things like this is taking a look is very encouraging.Lol don't get too excited. What I did is very small compared to what would still need to be done.
I should be getting my car back from the shop either tomorrow or Tuesday with the full drivetrain swap and a 2.81 gear. I'm already running the stock M3 tire size (275/35-19). I've reset nothing at this point but will once I have the car back. I guess I'll find out if this is outside the "comfort" zone or not for the M3 software.@Stokes looking forward to see how the M3 software plays with the 3.08. That's only a 2.17% change (using more decimals 3.154/3.087), so it might just work even without tweaking tire height. That said, do you have a different tire height to make up the difference? I think you said you did but I forget.
Also, are there any M3 people who have changed FD? I feel like there has to be more than that one who went 3.64. There are so many options available and tons of tracked M3's. That's what makes me think there is an adaptation process for changing the FD stored in the TCU. Has anyone tried a full re-learn (not just clutches) to get a different FD to play nice?
For reference, the MSD8x DME has a constantly running routine to adapt the "stored" FD value for 6MT cars. It does work, but it works very slowly that's why I found it better to change the gear ratio table for correct gear reporting.
I was pretty sure that @BMWJunkie already runs the 2.81 and found that it still has the exact same problem? Or maybe i'm getting things mixed up.I should be getting my car back from the shop either tomorrow or Tuesday with the full drivetrain swap and a 2.81 gear. I'm already running the stock M3 tire size (275/35-19). I've reset nothing at this point but will once I have the car back. I guess I'll find out if this is outside the "comfort" zone or not for the M3 software.
|Thread starter||Similar threads||Forum||Replies||Date|
|J||Post Turbo Primary O2 Sensors||Octagon | Disputes | Off-topic||15|
|Black Friday Thread - post your deals here||BMW General||1|
|xHP Flashtool Transmission App released to public!||N54||57|
|F3X bootmod3 - Mobile App for Android OS - Now available to public||N55||2|
|bootmod3 - Mobile App for Android OS - Now available to public||S55, S58||0|