[Mik325tds]

Originally Posted by ddillenger

I ran into this problem in the range rover. After every shift over said limit=limp.

You'd have to scale down the torque input to the trans, and that can be done in the ecu, however that's also going to alter line pressure, converter clutch engagement, etc.

Hm, looks to me like we still have a lot to learn before we can tamper with the signals correctly.

[Mik325tds]

Originally Posted by Whitbread

Hoist was behind me to me to left when I took that pic . It's anchored now, this pic was last week.

Awesome! And you build all that in what - 3 months? Impressive, my friend.

[rjahl]

Originally Posted by ddillenger

I ran into this problem in the range rover. After every shift over said limit=limp.

You'd have to scale down the torque input to the trans, and that can be done in the ecu, however that's also going to alter line pressure, converter clutch engagement, etc.

This is what I expect and why I am thinking that all of the intercepted and translated/modified signals need to be done with non linear tables. For example, the Torque table could be something like

From DME - to Trans
10% 10%
20% 20%
30% 35%
40% 50%
50% 60%
60% 70%
70% 80%
80% 95%
90% 100%
100% 100%
110% 100%
120% 100%



The Transmission has no way of knowing how much power the Engine is really producing and will reach max line pressure some where in the higher engine loading. You can create your own trans tune by bumping up the reported torque in the mid range but capping the reported torque at the max.

If you built similar tables for the throttle input, kick down switch and even the TCU's request for the engine to cut torque for a gear shift.

I think you could get really close any result you would have achieved with a full remap in the calibration file. Without the risks associated with tuning a fully locked down TCU file.

The big negative will be losing the ability to move the MAX shift RPMs above their current RPM. Sure, someone building a really powerful motor is also going to run into limits but that person has already spend $$ and is probably going to need a different drive line anyways

You guys might find a different calibration file that gives you higher RPM limits that can be fooled to shift when you want. Don't know, maybe an RPM trigger on the throttle translation.

This will take processing power and some programming for sure. Certainly not simple resisters on sending units.

I'd love to see this go "open source" so we can get multiple talents working on it.

I'm I dreaming?

[rjahl]

Originally Posted by Mik325tds

One step after the next, my friend. Getting rid of the torque reduction request from the EGS is definitely worthwhile.
HW wise I'll need some help from friends. The micro will need to be pretty potent as it will need to relay as many as 57 messages to the EGS and 9 messages from the EGS. I also saw a CRC on the Torque3 message, so we'll need to compute that on the fly. Luckily, I also saw some lookup tables for those as well . I'm thinking of a V850 family candidate as we use those at work a lot - what do you think?

Do you have access to a compiler for the v850? My friend is telling me that the Atmel chips have more support in the microchip community.

[Mik325tds]

Originally Posted by rjahl

Do you have access to a compiler for the v850? My friend is telling me that the Atmel chips have more support in the microchip community.

Yes, I do have a compiler (greenhills), but since it is a company license it's probably not well suited for an open source project. I'm OK at application level embedded SW but would need help with OS, CAN drivers and such.

[DWR]

Originally Posted by ddillenger

I ran into this problem in the range rover. After every shift over said limit=limp.

You'd have to scale down the torque input to the trans, and that can be done in the ecu, however that's also going to alter line pressure, converter clutch engagement, etc.

Just curious what specific faults you hit? There are many ways to get to limp mode. Do you reset adaptions after each change? Just trying to learn more.

[dave205t]

Hi Guys,

Big news from my side: I have fully unpacked, analysed and corrected all compressed code of the "EGS_00000-FFFFF-00.bin" first bin and am able to fully correct ALL checksums and RSA signatures.

Best regards, Dave

[808AWD325xi]

Originally Posted by dave205t

Hi Guys,

Big news from my side: I have fully unpacked, analysed and corrected all compressed code of the "EGS_00000-FFFFF-00.bin" first bin and am able to fully correct ALL checksums and RSA signatures.

Best regards, Dave

That's great news Dave !!

Can the bin file be converted back to data (*.0da) and program (*.0pa) files so that the modified bin can be flashed with WinKFP?

[rjahl]

Originally Posted by dave205t

Hi Guys,

Big news from my side: I have fully unpacked, analysed and corrected all compressed code of the "EGS_00000-FFFFF-00.bin" first bin and am able to fully correct ALL checksums and RSA signatures.

Best regards, Dave

That's fantastic. What's the next move?

[Mik325tds]

Originally Posted by dave205t

Hi Guys,

Big news from my side: I have fully unpacked, analysed and corrected all compressed code of the "EGS_00000-FFFFF-00.bin" first bin and am able to fully correct ALL checksums and RSA signatures.

Best regards, Dave

Wow! That is big news! Fantastic!
So would you be able to change the HW version of the Alpina B3 files and create a new signature?
I'm not sure how much work it is for you, but for starters we could try this lightly modified file (see attached). I just changed one downshift point. I included the original for comparison.
If that works - you would be our hero, Dave!

[rjahl]

Originally Posted by 808AWD325xi

That's great news Dave !!

Can the bin file be converted back to data (*.0da) and program (*.0pa) files so that the modified bin can be flashed with WinKFP?

Small changes are easy to pack back into the .ODA file. The more you change the more complex that task becomes. Someone must have a script for complex modifications but I haven't seen it. I know WinOls will export in Intel Hex but they look a little different and I have not dug to deep into that problem.

The key is having the correct RSA and calibration file checksum.

[dave205t]

Originally Posted by rjahl

That's fantastic. What's the next move?

Well that's not so straightforward, i can correct the full binary, but for the ecu to accept it it would have to be written fully as well; To correct the RSA i have to replace the public key (or would have to factor the BMW private key). The public key is in a section which is normally not distributed with the program; but i think can be rewritten without to much hassle.

So the next step is testing if this section can be reprogrammed, but i have not received any logs (yet) from you guys of a full programming session. Also looking forward to more full bin readouts from other transmission variants to look into making a tool that works for all.

If it cannot be reprogrammed (easily) there are some other strategies that can be deployed, but more work.

Best regards, Dave

[dave205t]

Originally Posted by Mik325tds

Wow! That is big news! Fantastic!
So would you be able to change the HW version of the Alpina B3 files and create a new signature?
I'm not sure how much work it is for you, but for starters we could try this lightly modified file (see attached). I just changed one downshift point. I included the original for comparison.

That file does not use the same boot reference of the only complete bin i have: "EGS_00000-FFFFF-00 first.bin" which is "047G250P610Z", your is "0479S90T641Z" i would need a full bin readout to investigate.

Best regards, Dave

[RBT-Tuning]

Wow, i was wetting my pants when reading the news!!! Dave, you're the man!

I will program my car this weekend and try to save all the logs for you!

[Mik325tds]

Originally Posted by dave205t

That file does not use the same boot reference of the only complete bin i have: "EGS_00000-FFFFF-00 first.bin" which is "047G250P610Z", your is "0479S90T641Z" i would need a full bin readout to investigate.

Best regards, Dave

Ok. I'll pick up my K-Line this weekend from a friend. Then it's just a matter of years before I get around to installing it....

The biggy problem I see is, how are we going to write the whole corrected bin? That won't be possible with WinKFP and I'm not sure it'll be possible with K-Line...

[dave205t]

Originally Posted by Mik325tds

Ok. I'll pick up my K-Line this weekend from a friend. Then it's just a matter of years before I get around to installing it....

The biggy problem I see is, how are we going to write the whole corrected bin? That won't be possible with WinKFP and I'm not sure it'll be possible with K-Line...

Dont worry about it so far was able to solve all the hard parts, writing the bin is a breeze compared to that. From code analysis it should be possible to readout the TCU over CAN bus. Unfortunately i do not have an actual TCU to try things on, other wise i could speed this up this development cycle considerably; what does it actually look like, is it small or big ? Does anyone have spare one i could borrow ? Could someone copy paste a list of api jobs for the GS19D.prg (or whichever one is applicable) ??

Best regards, Dave

[Mik325tds]

Originally Posted by dave205t

Dont worry about it so far was able to solve all the hard parts, writing the bin is a breeze compared to that. From code analysis it should be possible to readout the TCU over CAN bus. Unfortunately i do not have an actual TCU to try things on, other wise i could speed this up this development cycle considerably; what does it actually look like, is it small or big ? Does anyone have spare one i could borrow ? Could someone copy paste a list of api jobs for the GS19D.prg (or whichever one is applicable) ??

Best regards, Dave

Yes, it would be nice to have a TCU on the table to work with. Unfortunately, I have not been able to acquire one either. The attached document has some nice pictures of it.
The GS19D.prg is the applicable one. How do I extract the api jobs?

[dave205t]

Originally Posted by Mik325tds

Yes, it would be nice to have a TCU on the table to work with. Unfortunately, I have not been able to acquire one either. The attached document has some nice pictures of it.
The GS19D.prg is the applicable one. How do I extract the api jobs?

Nice docs! No need for the job list anymore, i disassembled the gs19d.prgd and found the jobs in the source, as suspected there is a job to dump the memory "SPEICHER_LESEN". I'll write a small program anyone can run to dump their TCU (without any risk) to speedup the bin collection from various cars. This should work without K-Line over normal CAN bus.

Best regards, Dave

[rjahl]

Originally Posted by dave205t

Nice docs! No need for the job list anymore, i disassembled the gs19d.prgd and found the jobs in the source, as suspected there is a job to dump the memory "SPEICHER_LESEN". I'll write a small program anyone can run to dump their TCU (without any risk) to speedup the bin collection from various cars. This should work without K-Line over normal CAN bus.

Best regards, Dave

Very cool, can your script read the full DME as well?

[dave205t]

Originally Posted by dave205t

Nice docs! No need for the job list anymore, i disassembled the gs19d.prgd and found the jobs in the source, as suspected there is a job to dump the memory "SPEICHER_LESEN". I'll write a small program anyone can run to dump their TCU (without any risk) to speedup the bin collection from various cars. This should work without K-Line over normal CAN bus.

Best regards, Dave

Done, see attachment. Use a standard INPA D-CAN cable invoke the program with "TCU_flash.exe -p COMXX" XX = comport number of your INPA cable (When using the ICOM cable ""TCU_flash.exe --ifh=ENET" more options in EdiabasLib.config)

Since i do not have a TCU myself i could not run full test, but in theory it should work (at least not affect any harm).

Best regards, Dave

[RBT-Tuning]

Here are the Level 3 API Trace files! Had to up the filesize to 1024, as otherwise I had been to slow with renaming during the flash process. ;-))

Just rename to *.rar! Hope that helps!

[DWR]

Excellent!