[DWR]

Originally Posted by iaknown

Zero Gravity's latest reply: "You probably downloaded the TCM 2000 software. That is not that same as the TCM-2650. The TCM2650 only acts as a CAN message Generator. The Original transmission calibration still controls the shifting and needs modified to change shift points and feel.

OK, so that sounds like one of the lesser options we had discussed. This would be fooling the TCU to behave differently based on incoming messages. It looks like an expensive option for little gain, however, I think there may be a way to leverage knowledge that could be gained from PCS. Sending CAN messages isn't so hard with the ELM327 bluetooth device many of us use with the Torque App.

Iaknown, can you find out specifically what messages they are sending that could be useful? - or, pass the contact info along to me and I'll give it a go.

[iaknown]

Originally Posted by DWR

Iaknown, can you find out specifically what messages they are sending that could be useful? - or, pass the contact info along to me and I'll give it a go.

Do me a favor and shoot me an email (don't have your email on me at the moment). Then you can contact him directly. I just gave him a heads up.

[DWR]

Originally Posted by iaknown

OK, so I contacted them. At first it was a no go and I got shut down. But then I asked this:

"Do you have the capabilities/pull with Powertrain Control Solutions to have the unit at least connect to our transmissions? That would get us where we need to be to tune them on our own."

This was his reply: "I can possibly do that. What volume are you looking on buying? Also it is only proven on 2nd generation HP26 transmissions. becomes non value added when we have to spend many hours on support with companies that do not understand this."

I understand the HP28 is a 2nd gen HP26 correct?

Yes, that is correct, but not all HP28 are controlled the same way. It is interesting that many do not realize that Ford, Jaguar, Rover, etc HP26s are not controlled in the same manner as the BMWs - like we are surprised, right?

Originally Posted by iaknown

So I gave him some more details, including the potential for being able to tune the gas cars and make a LOT of sales. And I asked what is needed from us to proceed to see if this is feasible.

I recommend I put one of you in touch with him if he bites since you guys are much more knowledgeable with the electronics side of this transmission. I can only do so much with my limited knowledge of it....

I really admire your tenacity. I don't think this is the ultimate solution, but perhaps we can learn something in the process of investigation. Nice job!

[iaknown]

Originally Posted by DWR

I really admire your tenacity. I don't think this is the ultimate solution, but perhaps we can learn something in the process of investigation. Nice job!

Well I don't have the expertise like you guys in order to get into the electronics side of these transmissions, so it's the least I can do to try to help out!

[DWR]

OK, I have an email out to the Zero Gravity Performance contact. I'll give PCS a call if I don't get a response by the afternoon.

[Mik325tds]

Originally Posted by _TB_

I do not have the OLS816 plugin - which is the checksum for "Bosch EGS". I'm unsure if this will correct our files, but it should..

The Checksum _must_ be in the *.0da file..

A funny thing is that the *.0da for the Alpina is much bigger than the *.0da posted here.. :/

Reaching out to @_TB_ and rjahl - you guys did some great research with what is located where in the EGS back in page 22. Did anyone of you ever get the WINols Plugin 816? I wonder how much it can do? Does it "just" correct all file checksums or is there a chance that is does something with the RSA, too?

[DWR]

Talking with Jim at Zero Gravity Performance, looks like the TCM 2650 controller is literally for a stand alone installation of a ZF6HP28. It is a gateway that isolates the transmission from the rest of the vehicle's BUS. So, in theory, all ECU signals to the TCU can be manipulated and vice versa. Since the TCU gets transmission speed parameters directly from sensors in the transmission, the only way to change shift points is by fooling the TCU about engine load, rpm, etc. Same for the torque converter. Essentially, we would be changing the lookup axis in the shift maps and not the map fields.

There are benefits and disadvantages to this approach. On the upside, it is a lot more forgiving, with reduced risk of mapping errors. The down side is potentially less control than some might desire.

In summary, it appears there is a gateway solution. Still trying to figure out the level of support we could expect. It would very much depend upon the number of commited customers we could gather. I think we can get them to sell us one controller to play with, for proof of concept. Not sure anyone here has time do that, right now. Anyone?

[DWR]

Regarding a call to Vince at PCS, he stated that PCS does not have a solution for us, in that they are not going to provide any support for our efforts. I didn't like the answer, but appreciated the candor.

Their business model is well defined. If it is one of their aftermarket products they provide mature GUI software and support. If it is not an aftermarket product, you must be a vehicle manufacturer. Our transmissions do not fall into their aftermarket product line.

So, it looks like Zero Gravity Performance might sell us a TCM-2650 controller, but no help will come from the mothership.
Furthermore, it does not look like either of these guys has any information on the BMW CANbus database. Therefore, what signals to send a recieve could be a challenge. Not impossible, but a good deal of work with a CAN analyzer and EDIABAS or Testo.

IMO, this option needs to remain on the back burner. Nizpro will find a solution for BMW gas vehicles, but then may move on to other more pressing business. We might be able to get indirect help on the RSA from them, at some point. Mik325tds is right to press forward with cracking the RSA from other sources. Hopefully, dave205t will get some relief from his other responsibilities and can continue the fine work he started.

[Mik325tds]

Originally Posted by DWR

Regarding a call to Vince at PCS, he stated that PCS does not have a solution for us, in that they are not going to provide any support for our efforts. I didn't like the answer, but appreciated the candor.

Their business model is well defined. If it is one of their aftermarket products they provide mature GUI software and support. If it is not an aftermarket product, you must be a vehicle manufacturer. Our transmissions do not fall into their aftermarket product line.

So, it looks like Zero Gravity Performance might sell us a TCM-2650 controller, but no help will come from the mothership.
Furthermore, it does not look like either of these guys has any information on the BMW CANbus database. Therefore, what signals to send a recieve could be a challenge. Not impossible, but a good deal of work with a CAN analyzer and EDIABAS or Testo.

IMO, this option needs to remain on the back burner. Nizpro will find a solution for BMW gas vehicles, but then may move on to other more pressing business. We might be able to get indirect help on the RSA from them, at some point. Mik325tds is right to press forward with cracking the RSA from other sources. Hopefully, dave205t will get some relief from his other responsibilities and can continue the fine work he started.

Thanks DWR for the follow up. Did they say what their fine piece of hardware will cost? As proof of concept I can use my CANcase and I found the database, just need the time to get to it.

[DWR]

Originally Posted by Mik325tds

Thanks DWR for the follow up. Did they say what their fine piece of hardware will cost? As proof of concept I can use my CANcase and I found the database, just need the time to get to it.

$950 is the retail price.

[Mik325tds]

Originally Posted by DWR

$950 is the retail price.

Uh. That's steep. If this works we should be able to come up with a hardware that costs around $50.

[rjahl]

Originally Posted by Mik325tds

Reaching out to @_TB_ and rjahl - you guys did some great research with what is located where in the EGS back in page 22. Did anyone of you ever get the WINols Plugin 816? I wonder how much it can do? Does it "just" correct all file checksums or is there a chance that is does something with the RSA, too?

I'm traveling with the family this week end but I'm pretty sure I checked my dlls last year and I don't have the one you need.

I have not looked at the transmission issues in a while. I've been busy trying to relearn how to program scripts. I've needed a little scripting tool too many times so I've started to toy around with VBA. I have one that's creating ODA file from full bins but still sorting out the checksums.

I'm doing this for the MSV70 but it might port to the ZF once the checksums are sorted. It will not correct the RSA protection schemes. I have those disabled in the MSV70.

[DWR]

Originally Posted by Mik325tds

Uh. That's steep. If this works we should be able to come up with a hardware that costs around $50.

Agreed. Remembered that you and I talked about doing something similar with the infamous OBD port tuner.

[RBT-Tuning]

Originally Posted by Mik325tds

Reaching out to @_TB_ and rjahl - you guys did some great research with what is located where in the EGS back in page 22. Did anyone of you ever get the WINols Plugin 816? I wonder how much it can do? Does it "just" correct all file checksums or is there a chance that is does something with the RSA, too?

I contacted EVC (or better said a friendly tuner did it for me) and the told him that the 0LS816 does NOT support BMW.

[Mik325tds]

Originally Posted by RayBan81

I contacted EVC (or better said a friendly tuner did it for me) and the told him that the 0LS816 does NOT support BMW.

Thanks Ray, just wanted to make sure we don't leave anything on the table here.

[Unklejoe]

First of all, Mik325tds, I saw your message and appreciate/respect the response. Sorry I haven’t gotten back to you. I’ve been busy with work.

On to my technical rant:

If we are going to go the gateway route, I have an implementation that is already 70% of the way there. The total cost of the hardware is under $70 (even less if you settle for the regular non-automotive grade HW).

I recently made my own progressive methanol injection controller which works by querying the current fuel delivery rate via the OBD port's CAN bus (by means of the UDS protocol). To accomplish this, I used an Arduino clone called the “Ruggeduino” coupled with an MCP2515 CAN bus shield (which communicates with the MCU via an SPI bus). I think we can leverage some of that work to get this done.

The Ruggeduino is essentially an Arduino UNO, but with a more robust power supply, protection on the GPIOs, and an extended temperature rating. The more robust power supply was important because the normal Arduino uses a simple linear regulator which can get quite hot if you’re pulling a decent load (driving relays, etc…). Also, the input voltage range of the Ruggeduino is like 3V-30V, so it’s perfect for an automotive environment. The MCP2515 is a CAN bus controller which handles all the low level CAN protocol specifics (arbitration, etc…). There’s also a CAN PHY chip on the shield to convert the TTL signals to the RS422 ? differential signals that CAN uses.

Obviously, the design wasn’t intended to act as a switch/gateway, but it would be fairly easy for me to code something up to do that. That being said, there are a couple of issues to consider:

- I only used a single CAN controller in my design, so we would need to add another one.

- The Ruggeduino that I used has only a single SPI bus, so we would need to use the chip select to bounce between the two CAN interfaces to process incoming messages (of course, this would be interrupt driven).

- The MCP2515 has a ghetto buffering system. Basically, there are two RX buffers (as well as a single reassembly buffer where the message first gets shifted into), but they’re not a FIFO. They each have their own filter configurations, so data can enter each independently. You can configure the first buffer to “overflow” into the second buffer if desired, but with one very important caveat: there’s no way to ensure message ordering with this approach. In other words, when you poll the device to see which buffer has data, and both are full, you don’t know which one arrived first. For this application, I would assume message ordering to be important, therefore we would only be able to use a single RX buffer. This means that we need to be able to service the interrupt and read out the message in less time than the time it takes to receive a single CAN message. I think it can be done if we bump the SPI speed to 8 MHz, but it may be tricky if we need to handle two full line rate 500 kbps streams simultaneously. That being said, I love a challenge like this.

As for the software effort required, here are a few highlights/general ideas of what I am considering:

- Each CAN controller will assert the interrupt when there's a new RX message. The ISR will perform the actual reading of the message and push it into a lockless (obviously) FIFO (exclusive to that particular CAN port). The reason for going against the "convention" here and actually reading the message in the ISR is that we don't have enough time to defer this task to the main program since we only have a single RX buffer. This shouldn't be too big of a deal though since the SPI bus will be at 8 MHz and we're only talking about < 15 single byte transactions.

- From there, the main program will consume messages from the port FIFOs in a round robin scheme. NOTE: Perhaps we could process them based on arrival time to get some type of ordering? This may work provided the system is fast enough to maintain empty FIFOs. The main program will push the messages (really a reference to them) into a "switch table".

- The switch table will be a system where callbacks can be registered when there is a "match" of a message. The list of callbacks can be considered our "rule database". For example, the interface would be such that we register a callback (function pointer) to be called when there's a message of ID 0x123. The callback would be responsible for performing any manipulations to the message (and retransmitting it out of the other port if requried). The callback would return TRUE or FALSE depending on if the message should be considered "consumed" or not. If not consumed, keep searching throgh the switch table's rule database to see if there are any other matches.

This general archetecture should be generic enough to accomplish whatever we need to accomplish.

What I will need help with is understanding the specific CAN message IDs and how they influence the TCU behavior, as well as just general brainstorming feedback.

Once we can prove the concept, the next step would be to migrate to an MCU with actual built-in CAN controllers so we don't have to play these juggling games. However, if we can prove that we can handle full line rate in both directions, there may be no need to upgrade. The only issue is that the physical dimensions of the device will be kind of awkward. It will basically be a 4 inch by 4 inch cube due to the way the sheilds stack up. If it turns out to work as intended, someone with knowledge in PCB design could help with making a custom board with the components on it.

For reference, here's my GitHub with the meth controller code:

https://github.com/jakemoroni/BMW-CA...eth-Controller

[_TB_]

Originally Posted by Mik325tds

Reaching out to @_TB_ and rjahl - you guys did some great research with what is located where in the EGS back in page 22. Did anyone of you ever get the WINols Plugin 816? I wonder how much it can do? Does it "just" correct all file checksums or is there a chance that is does something with the RSA, too?

The OLS checksum modules do not correct the RSA - opnly the file checksums. "Normally" the RSA is done by the flasher once you flash the binary to the hardware. This is how it's done in EDC1x, MEDx etc.

..but it looks like the OLS dll does not support the BMW binary. :/

[DWR]

Originally Posted by Unklejoe

If we are going to go the gateway route, I have an implementation that is already 70% of the way there. The total cost of the hardware is under $70 (even less if you settle for the regular non-automotive grade HW).
...

You da man! Thanks for that very thorough explanation.

Am I understanding correctly that you would provide help to develop the TCU gateway, or are you offering someone else a starting point? I think the problem recently is that we have the talent within the group but they are very busy with "real life".

The control strategies employed for meth/h20 injection have been one of my peeves for quite some time. Multi injections DI is difficult to measure by traditional sensing. I like that you have devised an alternative ... personally, I'd like to see EGT and AFR in the feedback loop.

[Mik325tds]

Originally Posted by Unklejoe

If we are going to go the gateway route, I have an implementation that is already 70% of the way there. The total cost of the hardware is under $70 ...

Wow! Very nice! I usually don't deal with the low level CAN stack as we usually have Vector CAN drivers that generate the callbacks based on which messages you're interested in. So our interface would match perfectly!
However, I share your concern with the micro being able to handle gateway CAN traffic and do some CRC calculations for the messages we modify. It's worth a try anyway.
First things first though - I need to get my act together on doing the gateway on CANoe level for proof of concept. Unless you'd like to attempt it with your HW. I'd be able to support you with the info you need .
Wouldn't it be nice if work wasn't in the way of doing fun things like this?

[Mik325tds]

Originally Posted by _TB_

The OLS checksum modules do not correct the RSA - opnly the file checksums. "Normally" the RSA is done by the flasher once you flash the binary to the hardware. This is how it's done in EDC1x, MEDx etc.

..but it looks like the OLS dll does not support the BMW binary. :/

Thanks for the feedback _TB_. I didn't think so.
GRRR. It could be so easy: Change HW number of the Alpina file, correct checksums and signature and flash it. Done.

[Mik325tds]

I recently stumbled across this interesting document. It explains how secret keys can be extracted by measuring the power consumption of the CPU with a very high sample rate. Seems like a very tedious task and would only get us the public key of the ECU. We would then still need a whole lot of work to guess/calculate the private key to generate the RSA signature.
This document turned my brain to mash about half way through, so be warned.
Anyway, I thought it was a pretty cool method.

[Unklejoe]

Originally Posted by DWR

You da man! Thanks for that very thorough explanation.

Am I understanding correctly that you would provide help to develop the TCU gateway, or are you offering someone else a starting point? I think the problem recently is that we have the talent within the group but they are very busy with "real life".

The control strategies employed for meth/h20 injection have been one of my peeves for quite some time. Multi injections DI is difficult to measure by traditional sensing. I like that you have devised an alternative ... personally, I'd like to see EGT and AFR in the feedback loop.

Regarding methanol injection:

I agree. AFAIK, one of the most advanced standalone systems out is the Aquamist HFS which interprets the injector pulse width and uses that as a basis to determine how much methanol to inject. The concept is sound, but I question its accuracy in practice. It needs to correlate the fuel pressure and IPW, and I image it’s hard to do that accurately for a wide range of cars. However, I’m not sure it’s even that important to have extremely precise control over the methanol flow, especially on a car like a 335i (which is what I have) where the progressive region between low load and high load is so short due to the quick spool. The solenoid probably spends most of its time fully on or off. Another option for the 335i is to use the JB4, but I opted for my own solution because it’s able to work completely through the OBD port (although I did hard wire it). Another reason I made my own system is because I’m using a medical grade, magnetically driven, positive displacement, gear pump. I needed a way to control the 5V speed input.

As for the variables considered for determining methanol flow, I thought about a few different approaches. I thought about using knock retard as a multiplier, coolant temps, etc…, but ultimately decided on current fuel delivery rate for simplicity purposes. Using AFR as a contributor concerned me because it was harder for me to analyze how the ECU’s fuel trims would react. I haven’t put that much thought into it though.

On a side note, my controller could probably be easily adapted to be used as a secondary fuel system controller, but I have no reason for that.

On to the CAN gateway:

Ideally, we can get some open source development going where we can each contribute towards the tasks that we're best able to help with. I’m going to order another Ruggeduino and a couple of CAN shields today, so I should have a general parts list for the prototype hardware (basically just three boards which can be purchased online for cheap). The hardest part will be re-routing the pins for the chip selects and interrupts, and that’s really just a matter of clipping a few pins and inserting a jumper wire. I’ll make the initial investment since I’m sure I’ll find another use for these components if this project doesn’t pan out.

Next, I’ll start coding the software framework (buffers, switch table, etc…). I’m currently working on a few small libraries in my spare time (lockless fixed-size buffer pool, GCC atomic built-in support for AVR), so I’ll be adding them to my GitHub soon. Once that’s checked in, I’ll start making the switch fabric library. I’m trying to make the software components as generic as possible so that they can be reused for other projects.

The actual coding effort required for this entire project is really not that significant. It really depends on how generic we want to make this. I could have something working in a few days probably. If all we need to do is modify a single message, we could have something working in a few hours. This is really the easy part.

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.

Step one would be to come up with a working design which can act as a simple message relay (passing unmodified messages). Then, we would need someone to volunteer to insert this gateway between their TCU and the rest of the PTCAN bus so that we can verify functionality.

Then begins the process of a lot of trial and error….

Originally Posted by Mik325tds

Wow! Very nice! I usually don't deal with the low level CAN stack as we usually have Vector CAN drivers that generate the callbacks based on which messages you're interested in. So our interface would match perfectly!
However, I share your concern with the micro being able to handle gateway CAN traffic and do some CRC calculations for the messages we modify. It's worth a try anyway.
First things first though - I need to get my act together on doing the gateway on CANoe level for proof of concept. Unless you'd like to attempt it with your HW. I'd be able to support you with the info you need .
Wouldn't it be nice if work wasn't in the way of doing fun things like this?

Good to hear! Vector is one of those mysterious companies who seems to have their hand in most of the CAN related automotive stuff that goes on in this world.

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.

Please do continue your efforts with CANoe. If you can prove that this idea will work, and even come up with some ideas regarding what messages to manipulate, then there's really nothing stopping us from implementing the same thing using some cheap HW!

And yeah, I wish I had like three weeks off of work just to finish up some of my side projects. Luckily, my work is somewhat related (embedded Linux/RTOS development), so work is still "fun" to me