[Mik325tds]

Originally Posted by Unklejoe

The hard part will be figuring out what messages we need to modify and what their effects on the overall system are. For example, there are multiple TORQUE messages that are broadcast on the PTCAN bus, so we need to figure out which of those are used by the TCU. I wouldn’t be surprised if there was some sanity checking against other messages as well.

This is where I will need help.

Hah! You come up with a capable HW for cheap, do all the low level programming and call that the easy part? I'd call that pretty awesome!

No worries, I got you covered on the 'hard' part
Below is a screenshot of all three Torque messages including the contained signals. There are really only two candidates for modding:
TORQ_AVL: The current available torque at the crank
TORQ_DVCH: Torque drivers choice. Torque requested by driver.
If there is sanity check between those we probably should affect both with the same rate.
But I agree with you, there is probably a lot more to figure out, especially when the car is in an active DSC maneuver for instance. It'll get more and more complicated once we get going. Just like every project...

Originally Posted by Unklejoe

One of the cool things about the MCP2515 CAN controller (and probably most CAN controller ICs/blocks) is that they handle all CRC calculations/checks. The controller automatically drops messages with a bad CRC before even signaling the software. The received messages read out by the SW are the CAN payload (including the address but excluding the CRC). Transmitted messages automatically get the CRC calculated and appended on the way out by the hardware. This is similar to how many Ethernet MACs work.

That's correct, most CAN drivers take care of the HW CRC defined in the CAN protocol, but that is only to protect against corruption during transmission of the CAN message. There is an additional application layer CRC8 (see CHKSM_xxx) and Alive Counter (see ALIV_xxx) in every safety related message. This is to detect corruption due to SW errors, CPU faults, rouge pointers, etc. We use lookup tables to speed up the process but it is still pretty CPU intensive.

[335dsleeper]

^ Awesome! I'm really hoping you guys get this licked. I need 5k power band! I'm a really good consumer. HA

If anyone can get this figured out, I'm pretty sure it's the guys posting in this thread. I'm super impressed with the ability floating around in here!

[_TB_]

Originally Posted by 335dsleeper

^ Awesome! I'm really hoping you guys get this licked. I need 5k power band!

You will not get a 5K powerband from manipulating with the CAN message to the gearbox - you need a remap for that.

Also - please note the warning given earlier in this thread - altering the CAn messages for torque can have rather negative impact on the longevity on the input shaft and TC..

I do understand your points about altering the messages - but if you need to do it right, it gets _really_ complicated.. eg. how will you distinguish a requested torque reduction during shift - and a requested torque reduction during a full pull? Throttle angle cannot be used since you're (well, can be) at 100% throttle in both scenarios.

It is not just a question about altering a single torque reduction CAN message, unfortunately. :/

IMHO our best bet is to get the bootloader to load a binary that has not been RSA signed - but has the file checksum correct.

[DWR]

Originally Posted by _TB_

You will not get a 5K powerband from manipulating with the CAN message to the gearbox - you need a remap for that...
I do understand your points about altering the messages - but if you need to do it right, it gets _really_ complicated ...

Furthermore, we cannot intercept messages on CAN for signals that come directly from the sensor to the TCU. Those signals include input and output shaft speed, common indexes for maps.

[DWR]

For the hot rodders in the group, this task is considerably more difficult. However, for the mileage misers it may be as easy as invoking one of the adaptive modes. For example, if engine oil or coolant temperature becomes hot enough to reach threshold values the TCM will go into "Hot Mode". In this mode, different shift and TCC lockup maps are used. These will call for higher gears and TCC at lower speeds. It will not, however, change any gear selection related TCC lockup prohibition.

Because exiting hot mode requires: 1) the gearshift selector lever must be moved or 2) the brake pedal applied or 3) the accelerator pedal applied 100%, getting into and staying in Hot Mode is simplified. Periodic CAN Massage would seem to do the trick. Everything else can just pass thru the gateway.

[Mik325tds]

I couldn't agree more. When it comes to full throttle and torque reduction requests by the EGS, things will get really tricky. My intentions are not for the drag strip but for the daily driver. As DWR mentioned, hot mode may even do the trick already.
If we can get our hands on a bootloader that would ignores the RSA signature, I'd be all game. But that isn't going to happen for a while I'm afraid.

[Hoooper]

Hot mode typically also triggers much reduced torque limiters, do we not have that programming?

[DWR]

Originally Posted by Hoooper

Hot mode typically also triggers much reduced torque limiters, do we not have that programming?

Yes, that is correct, but not sure I follow. What would be the problem with lower torque limits when trying to improve mileage?

[Hoooper]

Originally Posted by DWR

Yes, that is correct, but not sure I follow. What would be the problem with lower torque limits when trying to improve mileage?

Not a problem unless you want to pass someone or get up a steep hill without going flat out. At least in other vehicles Ive seen trip trans hot mode, once you trip hot mode you would be hard pressed to get up a steep driveway, let alone maintain freeway speed up a hill. In other words, my concern would be that the limiters for hot mode are too low for normal every day driving. Again I dont know what they limiters are at for our car so maybe its not an issue.

[DWR]

Originally Posted by Hoooper

At least in other vehicles Ive seen trip trans hot mode, once you trip hot mode you would be hard pressed to get up a steep driveway, let alone maintain freeway speed up a hill. In other words, my concern would be that the limiters for hot mode are too low for normal every day driving. Again I dont know what they limiters are at for our car so maybe its not an issue.

Hard to image our engine being limited to that extent, as a disesel makes a lot of torque at low rpm with relatively small heat penalty. I think that is the point of lowering the rpms in Hot Mode.

But, I don't know what the limits are either and your point is a good one. I guess we will have to test this.

[RBT-Tuning]

Instead of triggering hot mode, I'd go for faking lateral g's. The trans closes the TCC as soon as it sees a certain amount of cornering g's.

[DWR]

Originally Posted by RayBan81

Instead of triggering hot mode, I'd go for faking lateral g's. The trans closes the TCC as soon as it sees a certain amount of cornering g's.

I'm sure there will be as many opinions on how someone might want the transmission to behave as there are options. Faking g's will inhibit upshifts. While I have not tested it, I believe 6th gear is prohibited. So, if that is what you are looking for, that's a good option.

Keep the suggestions coming!

[Mik325tds]

Originally Posted by RayBan81

Instead of triggering hot mode, I'd go for faking lateral g's. The trans closes the TCC as soon as it sees a certain amount of cornering g's.

Actually, the g-force thingy was one of the first things I wanted to get rid of. I hate how the trans inhibits shifting after just slightly spirited driving around corners.
But this will be the good thing about the gateway option. If we keep it open source and eventually maybe someone comes up with an options GUI - everyone can do their own tune. (In a couple of years or so...)

[RBT-Tuning]

Originally Posted by Mik325tds

Actually, the g-force thingy was one of the first things I wanted to get rid of. I hate how the trans inhibits shifting after just slightly spirited driving around corners.
But this will be the good thing about the gateway option. If we keep it open source and eventually maybe someone comes up with an options GUI - everyone can do their own tune. (In a couple of years or so...)

Really? I never experienced that, as I drive in manual mode 95% of the time. The only reason I got the auto, is because of that horrible manuals in the E-Series.

[Mik325tds]

Originally Posted by RayBan81

Really? I never experienced that, as I drive in manual mode 95% of the time. The only reason I got the auto, is because of that horrible manuals in the E-Series.

Hm. Maybe that is a quirk of the A7610591.0da cal that I'm driving now. I can't remember noticing it as much with the original cal.
What is so bad about the E90 manuals? I have not driven one so far, but I guess many here think "any" manual must be better than our automatic.

[335dsleeper]

Originally Posted by _TB_

You will not get a 5K powerband from manipulating with the CAN message to the gearbox - you need a remap for that.

I thought this entire thread was dedicated to providing a remap for the TCU. No?

[_TB_]

Originally Posted by 335dsleeper

I thought this entire thread was dedicated to providing a remap for the TCU. No?

yes - the TCU, not the ECU.

[335dsleeper]

Originally Posted by _TB_

yes - the TCU, not the ECU.

Yea, the TCU is what limits our RPM to 4800. Not the DDE or ECU at least according to the tuners capable of tuning the M57 DDE.

[Unklejoe]

Originally Posted by Mik325tds

That's correct, most CAN drivers take care of the HW CRC defined in the CAN protocol, but that is only to protect against corruption during transmission of the CAN message. There is an additional application layer CRC8 (see CHKSM_xxx) and Alive Counter (see ALIV_xxx) in every safety related message. This is to detect corruption due to SW errors, CPU faults, rouge pointers, etc. We use lookup tables to speed up the process but it is still pretty CPU intensive.

Interesting. I did not know that. After glancing at a CRC8 implementation (one without lookup tables), I estimate that it will take tens of microseconds to do the calculation on this MCU. It's definitely something to keep in mind.

Great screen shot, btw.

Originally Posted by _TB_

You will not get a 5K powerband from manipulating with the CAN message to the gearbox - you need a remap for that.

Also - please note the warning given earlier in this thread - altering the CAn messages for torque can have rather negative impact on the longevity on the input shaft and TC..

I do understand your points about altering the messages - but if you need to do it right, it gets _really_ complicated.. eg. how will you distinguish a requested torque reduction during shift - and a requested torque reduction during a full pull? Throttle angle cannot be used since you're (well, can be) at 100% throttle in both scenarios.

It is not just a question about altering a single torque reduction CAN message, unfortunately. :/

IMHO our best bet is to get the bootloader to load a binary that has not been RSA signed - but has the file checksum correct.

I agree that a modified bootloader which will boot unsigned images is the way to go. It would instantly render all of this useless (provided we can control every aspect of the programming). However, until one exists, we should continue to investigate other options, even if it ultimately ends up not working. I don't have the facilities to experiment with the TCU itself; otherwise, I'd love to help out on that front.

As for correlating requested torque reductions with their respective causes, I don't think we need to, but it depends on what we're actually trying to accomplish here. I'm approaching this project with the goal of being able to manipulate the shift characteristics such that I can make it shift "harder" than normal under certain circumstances. It seems like many components of the car can request a torque reduction (DSC, TCU, and the ECU itself). My assumption is that the load mapping inside the TCU is based off of actual current torque, rather than an expected value based on its own torque reduction requests. My assumption is that a requested torque reduction does not necessarily have to be obeyed by the ECU, and thus the TCU can not assume it will be. Therefore, we may only need to modify the current torque in order to manipulate our current position on the map which determines shifting pressures.

We aren't going to be able to increase the shift pressures to beyond that of the highest point defined on the existing mapping (which is why an actual reflash would be optimal). We also probably won't be able to adjust the RPM at which a shift occurs, as I believe the transmission has its own speed sensor on the input shaft (and we can't do anything to manipulate that signal).

The shift characteristics (clamping force, time, etc...) are definitely related to torque (as well as a bunch of other things). There is some hope that the mapping on the TCU doesn't stop (limit) at the highest torque normally requested with a stock engine under WOT, but it's impossible to know at this point.

Maybe the transmission runs maximum defined pressure at just 50% of the engine's peak torque. If that's the case, there's absolutely nothing we can do in terms of increasing shift pressures.

On the other hand, maybe there's headroom defined such that we can still gain a little by saturating the map to the highest value. This seems to be the case with the DCT guys who have to use back end flashes (so that the ECU sends higher torque values) in conjunction with the JB4 in order to reduce slipping.

I guess I should point out that I personally have a 335i, so my goals here are to simply make the Alpina flash shift harder and later in "D" mode, which is why the torque messages were the first place I was looking. I personally have no problems with my torque converter lockup behavior, shifting pressures, or the torque reduction during shifts. I realize the diesel guys have different goals, so it may be more complex.

To manipulate those charactaristics, we’re left with poking and prodding in order to see how we can influence the TCU.

Originally Posted by DWR

Furthermore, we cannot intercept messages on CAN for signals that come directly from the sensor to the TCU. Those signals include input and output shaft speed, common indexes for maps.

Agreed. However, we can potentially manipulate other variables which contribute to the final index on the map, which you touched on in your followup post.

Originally Posted by Hoooper

Hot mode typically also triggers much reduced torque limiters, do we not have that programming?

We could potentially intercept the torque reduction requests coming from the TCU.

Originally Posted by DWR

I'm sure there will be as many opinions on how someone might want the transmission to behave as there are options. Faking g's will inhibit upshifts. While I have not tested it, I believe 6th gear is prohibited. So, if that is what you are looking for, that's a good option.

Keep the suggestions coming!

Good point. I think we should figure out what the goals are here, and then address the feasibility of achieving them.

What do the diesel guys want to change regarding their transmission?

[_TB_]

Originally Posted by 335dsleeper

Yea, the TCU is what limits our RPM to 4800. Not the DDE or ECU at least according to the tuners capable of tuning the M57 DDE.

Well yes - and no

The TCU will not let you shift gears past 4800 rpm - but the ecu will not let you have enough diesel to be beneficial above 4800. The ecu needs to be remapped in order to allow enough diesel to be useful above 4.800 rpm.

You need both if you want it to pull all the way to 5.000 rpm, TCU alone will not do it. When I get back home, I'll try to find the Torquelimiter for the european 335d - then you can see how it is shaped in the ECU.

[335dsleeper]

My DDE is completely remapped. Bob from BPC can scale the fueling if we had the ability to modify the TCU to go above 4800.

[Mik325tds]

Originally Posted by 335dsleeper

My DDE is completely remapped. Bob from BPC can scale the fueling if we had the ability to modify the TCU to go above 4800.

Has anyone ever asked if Bob@BPC can do a bootloader replacement on the EGS?