This blog is where we share content that we hope you'll find interesting. This includes aspect of the development process, current project statuses, and general car and technology related items.
First off, we’d like to wish everyone a happy new year. It’s been busy so far this year already.
I’ve tested out the Torque-based model I’ve been using on the M3 with the 330 and it’s doing reasonably well considering how little I’ve put into it.
I recently moved the Ethernet cable onto the drivers side so that it fits nicely, since I’ve drastically reduced the length of wiring necessary for the harness, it made sense to move this as well.
I took the car out for a long drive yesterday, and it behaved well except at full throttle a bit…and then looking over the logs I saw why:
That…is a problem. I’m guessing there’s a bit of an issue with the MAF, as it should not be hitting 5.9-6.2 volts at 3 PSI of boost.
More work is in process, I’ll continue to update as I test and make progress.
What could bring about such a change? A blue, Dual Motor, Performance, Tesla Model 3 can.
Let’s rewind: I drove the 330 over from NY to OR from Septebmer 21 to 24th. I had just dumped quite a bit of money to fix a bunch of stuff, including the installation of a Radium Engineering oil catch can. The car made the drive over here wihtout too much trouble, but the catch can filled up much more quickly than I liked (every ~700 miles), and putting the car under any amount of load caused it to not want to accelerate. So the original plan was to return the car back to stock partially. I’d replace the fuel injectors with stock ones, the exhaust manifold with stock manifolds, and hopefully it’d be OK enough to enjoy. Then I was thinking of putting an S54 with an MSS70 ECU in there, as that has the code to control the SSG transmission.
But, then I got a call on Thursday saying my car would be ready for pickup on Sunday. I picked up the car, and laughed from the amount of joy of leaving from a light…or going from 30-60, or 60-something. Instant torque is fun! It handles pretty decently too, at least for what I want.
So, here’s the long and short of what’s happening.
First thing to do with the 330 is create a new, short harness. The existing harness took quite a bit of effort to remove from the M3, and it’s seen better days at this point. This time I’m going to keep the ECU where the stock ECU is, though I’m not sure how well this will fit.
I will still be working on Porsche related items after the BMW work has been completed, and any other cars that come my way that look like an interesting development candidate. But I will not be keeping my BMWs. It’s been a fun ride with the BMWs, but I don’t see myself driving them more than is necessary.
We’ve had the opportunity recently to work on some very interesting engine setups on the Porsche 996 and 997s. As some were dedicated race cars, some fairly aggressive camshaft profiles were chosen.
The car made 70kPa of vacuum at idle. It was at 90kPa shortly after opening the throttle. In short, Speed Density did not work on this car for calculating engine load. In the internals, Engine Load is air charge per cylinder, so if we have other ways to come up with this, why not use it?
Up until very recently, the common OEM method of load calculation was via the use of a MAF (Mass Air Flow) sensor. This directly measured the amount of air that was actually making it into the engine. There is some lag, but as it turns out, the response times of the MAF is significantly faster than the pressure sensor. There is also the assumption that the air quantity in the engine is that which is in the intake tubing. This is fine for steady-state, but transient fueling is definitely different than under speed-density. Thankfully the fueling model should still work, if you change the axis from MAP (Manifold Absolute Pressure) to Engine Load, which can be derived from simple math.
The assumptions behind the design for GPR do not work for engines which have a very high specific output, or individual throttle bodies. These engines do not make enough vacuum, or do not have enough range, to make precise control of fueling possible. We can, however, do some math on the MAF value, and calculate the same Engine Load, and therefore use that instead.
The entire design of GPR assumes availability of a MAP signal, or a table with an estimated MAP value. Unfortunately it is not possible to completely remove it at this time, without some complex math to determine pressure based on the airflow. So if you choose “Mass Air Flow” as the Engine Load Normalized value in any of the Drobnak Software packages, you only need a MAP sensor, or a MAP Estimate table, for fuel pressure calculation purposes. Load is not derived from it at all.
The problem with the MAP estimate table, is that it can make your efficiency map look crazy, with values well over 150% when they should not be. It occurred to me that it made much more sense to provide a table that is a fallback for if the MAF sensor fails, but does not rely upon the crazy values that playing with the MAP estimate table does. So we’ve added in an “Engine Load Estimate Main” table.
This is basically an ambient pressure and temperature compensated table with expected air mass values at a given Throttle and RPM point. It is similar to the Engine Efficiency map, but it is a direct value. If you have the correct injector calibration, and good ambient pressure sensors and temperature sensors, you could run the car off this with no other sensor, just putting in the correct load value at each point. This assumes a correctly filled out MAP Estimate table, again due to the fuel pressure subsystem needing it. However, it also allows for a fallback should the MAF sensor fail. This allows the flexibility of near-direct inputting of injector timing values, but with all of the advantages of being able to swap out injectors and not have to re-tune, as the rest of the air and fueling model is intact.
The upside of this: run your crazy cammed cars. Run your individual throttle body cars…with excellent results. The initial fluctuations are due to fuel film not being quite right, but as you can see, they are still well within tolerances.
Also, do note the negative values in the Airbox Mass Flow Sensor Translation table - modern sensors can detect reversion - when air flows back over the sensor in the opposite direction. The code we use takes a sum of multiple samples, so we can account for this effect.
In the past we’ve tried to keep as close to GPR as possible, but moving forward we will not hesitate to deviate from it where it provides advantages to our customers.
As a result of finishing up this round of the Porsche 996/997 package, I have returned to working on the M3 package. I have ordered dual wideband lambda, a MAP sensor, and a known air temperature sensor for the airbox so that I can calibrate the vehicle in the next few weeks. It’s been running on a very rough calibration, and to move forward I need to work on that.
I have recently gotten some interest in the Manual gearbox version of the package, and am in the process of cleaning up some of my features from the SMG version to generate a new release.
The idle control algorithm will be in grams/sec, as we know the actual duty-cyle to flow rate of the idle air controller. It’s unclear how I wish to handle main throttle control at this time, if it will be like standard GPR, or the whole system will be torque based.
In other news, M3 Instrument Cluster lights can represent either the current Engine Speed Limit, or Oil Temperatuere.
More coming in the next few weeks!
The 996-997.1 Porsche package is officially available from Drobnak Software through your local MoTeC dealer! The retail cost is $1600. Contact us via the Porsche product page.
Successfully fired up a Porsche 996 Turbo on the existing calibration for our 996 GT3. We now have verified that our package can support both the NA and Turbo variants without any issues.
“SMG sucks” is something often seen on M3 boards. When I first got the M3, I kind of agreed with them.
But first, a digression - I am currently in Portland, OR. I’ve been here for about two weeks, and I have found a nice condo to rent. I also drove here. In the M3. In four days. Since then, I’ve been driving from my coworker’s house to work, a 20 minute commute. In this time, I’ve made a discovery.
I was wrong. They’re wrong. The problem is, people don’t ‘get’ what the design goal is.
One of the things that irritated me very, very much when I first got the M3 was how inconsistent the shifting was. What I have realized since then, is that is by design. For contrast, the SSG, which is the automated-manual gearbox in the non-M series, does the same thing, every single time:
So you get a very consistent experience, with the exception of the 1-2 shift which is a little lazy in comfort mode. With SMG, the rate of acceleration of the engine, of the vehicle, the incline, throttle position, are all taken into account to not upset the chassis. So even if you have it on ‘Dynamics’ (the switch by the SMG gear lever) level 5, which is the fastest (with DSC on), if you’re only going 20 MPH and 10% throttle, it’s going to soften the torque ramp so that the shift is nearly unnoticeable. BUT, put the pedal to the floor, and it’s quick and efficient, and stable.
It also turns out that (at least in the code I’m looking at), there is more than just the transmission affected by the ‘Dynamics’ switch - the VANOS table is different for position 1 or 2 vs 3-6.
So I’ve come to like what it does, and once I get my head around how everything fits together a little better than where I am now (I’m going back and reviewing what I’ve written so far to try and fill in any gaps I left.), I’ll make it more easily configurable to choose what you want. More jerky, but consistent, or more smooth and stable (ie stock).
Maybe with a different perspective you may find that SMG does work pretty well, just not how you expected it to.
Successfully fired up a Porsche 996 GT3 on our 997.1 (Now 996/997.1) Package. Specifically, a 4.2L 996 GT3. Also, make sure your fuses are good. :)
In addition, we are working on making the integration work a bit more seamlessly to hide things that are not applicable for a given model or type. It will also allow you to choose individual subsystems to turn off, for use in a mostly-not-stock race setup.
We are currently adding support for the Porsche 996 (starting with the GT3 variant) to the Porsche 997 package. There are some differences between the vehicles, but some configuration drop-downs will allow you to select the correct model (996/997) and variant (Base/GT3/Turbo, etc). More information coming soon!
This week’s update on the M3. Still have to work out the subtleties of the torque demand during a shift, so it’s still a little rough. But I took it past my immediate block this time… Note there are some additional posts on Facebook, but this is a pretty significant update.
I’ve put a lot of effort into tracing down more code to accurately model the data right. I have not re-visited the shifting code, and will have to do so soon.
I try and run this company in a transparent as possible manner (without making it simple for someone else to copy me). That’s why I share the ups, downs, and laughs:
The object count just keeps going up… Oil Level code done. After getting through all of it, there’s a lot of repeated code in there, that’s the downside of auto-generated code. Will start with a 1:1 implementation of the MSS54 code. After I’m sure that it works as I expect, I’ll go back and simplify it.
So, having gotten some free time, I finished analyzing the oil level items from the M3.
As you can see from the picture, there is the main level routine, a correction routine, data for OBDII freeze frames, startup values, and getting the level signal from the sensor.
This will likely be the basis for all of the E46 BMWs, as it is the most comprehensive code I would think. The MS45 code supports more than one sensor type, but those are not used on E46, so that doesn’t matter.
The corrections are pretty thorough, it corrects for altitude changes, X and Y axis movement, as well as the current engine speed.
Thankfully, you can just put 0 for these when the correction data is missing, and you’ll get an approximate value. For other cars, they have standalone temperature sensors, so this is good enough. For the M3, you want the most correct data you can get to accurately determine oil temperature.
Even though the 330i and the M3 share the same oil level sensor, how the data is interpreted is completely different. On the “Time Processing Unit” level the signal is acquired with the same parameters, but after that, the code is very different.
Project 2016A1 is continuing to move along well. We now control the instrument cluster, have correct injector data, and some of the scaling factors have been determined.
BMW M3 has nothing newer than last update. Deeper understanding of the code is needed, due to lack of documentation.
The next two months will be a bit quiet - we will be out of the country, but will be working on code. Testing changes out will not be so easy however. So, expect lots of updates on the M3 the second week of May. In the meantime, we will be prepping a few platforms. Exciting things coming. We hope you’ll follow along with us!
While not quite where I intended to be today…
Started my day with:
Ended my day with:
Needed to bring in some variables from other functions, and remove some currently unused variables. The shift state function sets up some details for use in places we haven’t covered quite yet. This weekend I will be able to test this out. We hope to be able to demo the first SMG on a standalone.
Code is taking shape for the SMG shift function routines. I had some blockers in finding certain variables, but then realized the data was coming from the other CPU. Having a dual-CPU architecture just complicates everything. Thankfully the M1 has enough power to only need one.
Main function dealing with the flow of SMG related data has been found. This is now the function call graph we have to analyze.
Some of the sub-functions have been worked into C-like / M1-like code, but due to the way M1 treats things, some things will have to be re-worked once some of the underlying status bits are determined.
Wow. It’s been a crazy week. My family members have been dealing with health issues, I’ve had some house issues to deal with, and assembly code almost drove me nuts.
On the upside, after a large amount of searching, a member of m3forum pointed me in the right direction, and I noticed that IDA (the program used for analyzing this) missed a bunch of code. I spent time fixing stuff up, learning a little, and I finally found the function responsible for updating the shift state from the DME side. The downside is that it’s kind of large:
So while I had hoped to have some code written, and the M150 in the M3 this weekend, I don’t know if I’m going to have it done before needing to pivot back to Project 2016A1. We’ll get closer to renaming that soon enough. :)
On the Porsche front, I have some documentation on the SDI3 ECU, which is used by the 997.2 cars. So, some day the Porsche 997 package will work for both. No timeline defined at this time.
The main project being worked on at this moment is the M3. After learning a bit of the Motorola CPU32 assembly language, and the way things are done there, I got a lot of the data I needed. I am a bit stuck at the moment due to some lack of clarity on memory addresses being shared between the 2 CPUs the MSS54 ECU has.
Therefore I went back to looking into the 330 SSG support - by looking at MS45 code. This is a PowerPC based ECU. It looks extremely foreign compared to C167 processor code, but not so far off from CPU32.
The other ECU that is available for the 330 is the MS43. I already did some work on that, but there was some missing information which made a few things unclear. Using what I knew for certain, I was able to understand what I was reading enough to get all of the data for the ID that the transmission controller transmits.
As my good friend over at Obsidian Motorsport Group had alluded to in a conversation I had with him, I was missing a key piece in my control strategy, and that was confirmed by reviewing the code.
At this point, I am looking at another ECU which also controlled the S54 engine to see if I can find similar code in there as the MSS54, and expect to make progress on that.
After the M3 is done, I am confident I will have both variants of SMG/SSG working very soon.
Was battling being sick recently, so progress is not as far as I would like. There’s a difference in control algorithms between SSG and SMG2 that I am tracking down where it is happening currently. I understand where a lot more of the data is coming from now, but still have a bit more to go. I hope to have it roughly working by end of January.
All of the Porsche 997.1 tree has been updated to have help at all levels. The next thing to tackle here is integrating the various torque reduction and requests into the rest of the system. We already have something working for the BMW E46, but it is being re-worked to be cleaner and ideally more accurate.
The M3 SMG integration has had some additional progress made in some things, but not enough to warrant a video yet.
Project 2016A1 is on hold until after the new year, but the groundwork has been laid for significant progress once schedules line up.
Additional data analysis will be taking place on other Porsche vehicles during the next few weeks. There will be a more recent BMW project coming up next year as well. There might even be an American car on the list for next year too.
Our Porsche package is featured in the MoTeC product flyer at PRI!
How I spent part of my Saturday. I am getting some more stock ECU data to try and fill in some knowledge gaps. I have finally gotten the assembly in a state where I can start analyzing it, but Motorola assembly is a bit different than the C167 stuff I’ve been working on previously. Enojy!
Sometimes progress takes a detour. On Saturday, we achieved Cycle Lock.
And that’s where the problems started - my initial calibration for the TPS was off, so it would work a little, and then go into a fault state. The load method was set to Mass Air Flow, but I had my 330 MAF calibration in there. And finally…in my adapter piece, I swapped two cylinders! Oops. So things didn’t go very well. Oh, and then I got sick.
Fast forward to today, and the car now cranks, the throttle does what’s commanded, but it has not fired yet. Something is off with my fueling. Should be resolved on Friday if all goes well, as tomorrow is a day off for Thanksgiving.
This weekend was quite productive. We wrote some code for Project 2016A1 which allows us to get us control over the instrument cluster as we would like.
There was work done on the M3 project:
The picture above is the mounting bracket which was once for a ProEFI kit, which is where this all started. If it was not for the frustration there, we’d probably not be in business today. Also, do note the similarity between the AEM driver and the ProEFI one - they’re both made by the same company in Germany. Except one is cheaper. You’ll be seeing more of that grey connector in a moment.
This is the current state of the harness - far from pretty, but it’s grown a bit. In the bottom left, that is the extra wires that are only used on the 330. Again making use of spare parts - they have been put into a nice weatherproof connector for holding. Moving to the right, is connector A which has the SMG CAN bus connected, along with provisions for a CAN sinffer. Then moving more is connector B, and to the rightmost of the table is what is supposed to be my ‘extra sensors’ breakout, but lazy me never re-pinned the sensors. So it’s power and ground basically. Also boost control is on there. On the middle left you can see the grey connector which was originally used to connect to the resistors in the back to fool the DME there were still fuel injectors connected. Now it has been used for the ‘conflict wires’ - things that put sensors and ground, or sensors and voltage sources, or voltage sources and ground together if not modified appropriately. I used that connector so I can swap this harness between both vehicles with about an hour or so to just move pins around. Not recommended to do often. :)
It definitely took longer than anticipated - I had to add in more new wires than I thought I would. But I have the entire week to check using the multimeter that things are going where they are supposed to be. Then on Saturday afternoon I should be able to at least get the car started. At the moment I only have narrow-band O2, so I need to look up heater control algorithms for the LSH series sensor. I will then using the error codes from the SMG TCU determine what data is missing, and get that all going. As long as I can get the car to go into 4th gear, we can tune it and I can fine tune things from there.
Nothing on the 997 except some documentation cleanup this week. Just needs testing. There’s another Porsche project going on in the background. (Technically I’ve got 4 projects going in parallel including the M3 and 997. They will be time-sliced equally moving forward.)
Move this pin over here, check this splice over there…
1 part development wiring harness
1 MS45 / 330 pinout
1 MSS54 / M3 pinout
Generous amount of time
And hopefully a reasonable wiring harness for the M3 will emerge while I wait for the professional one to be done. Yes I know it looks messy, this is why we do the keyboard work, not the wiring work. :)
Every item the stock Porsche 997.1 DME is acting upon is at minimum being logged or being acted upon now in the Drobnak Software 997.1 package. We can even shut down the engine if the airbags deploy (user configurable, of course).
There are two main questions remaining to have the package finalized:
On the assumption that two different Engine Sync Reference modes are necessary, that means there will be a GT3 specific package, and a non-GT3 package for the 997.1. I have finished determing the torque values which are needed:
Most items are already completed. The rest will be finished shortly. The minimum torque items requires data from the stock vehicle - the manufacturer has put together tables which specify the maximum ignition retard that the engine still runs, and then another table which is the maximum retard that the engine runs without damage. There is a timer which switches between the two. I will be putting this functionality into the package, along with the data for the stock Turbo cars. I have data for the S as well, and with some work should have the data out of the GT3 RS ROM.
This protection functionality is only in reference to traction control / gearbox, as Anti-Lag would likely not be in line with what the imagined usage patterns are…
The package is available for Motec dealers to purchase immediately. While the crank pattern and cruise data is verified, I can send out a development ECU for testing. The MoTeC M1 is an extremely powerful platform, and I am glad to be developing for it!
A familiar sight to some.
I did something very similar a few years ago on my 330. This time I have my own Rigol DS1054Z scope, though. Checking continuity on a few pins going to both the instrument cluster and the DME. The Battery charging pin, oil pressure switch, and oil level sensor - all three of these have a simple internal connection in the DME on connectors 3 and 4. I had not noticed until today, but they are literally right next to each other - always on the extreme end of either connector 3 or 4.
Also, it seems, that the oil level sensor connection isn’t actually needed as of the build date of this car - the data (temperature) comes right off of CAN. I think older builds did use it though. Other things like “Engine Start Signal Feedback” - not even in the wiring harness. I did use the scope to look at the oil level sensor, and it’s the same as on the 330. I won’t have exact oil levels, but I should be able to get the temperature working, which is the important part.
I’m pretty confident with the harness I came up with - but I’m not sure of the timeline - the 997.1 work is coming first, as it’s needed first. I also will be lending out my development ECU for some quick testing, so that will also delay calibration of the M3.
As far as the 997.1 related items, 997.1 Turbo support is in the works. I am currently back in the assembly code, tracing data that was not needed in the initial firmware for the GT3 RS, but is now useful. Cruise control stalk has been found, so this enables cruise control again. Future alternate indicators may be possible (eg Driver Switches using the stalk, then oil pressure indicating A/B).
As additional subtypes are now supported, the correct vehicle and gearbox type must now be selected from a menu. No auto support yet, but there has been some interest expressed by some, item demand will dictate order of items being worked on.
The next few weeks should be very exciting.
Over a few days leading up to today, I received inquiries about my 997.1 package from two different sources. One is from a shop in NJ, and the other was from an individual with a 997.1 with a Tiptronic transmission.
Previous to this week, I had code which worked on the 997.1 GT3 RS without any issues. Due to that it was a manual transmission vehicle, and factory traction control doesn’t do all that much, having ballpark values for torque, and the correct multiplier in the data stream is enough to make it work. The rest of the important data going to the cluster was all correct. However, there is only so much you can get out of a working car without attempting to trigger error states on purpose - unless you look at the code that’s in the computer.
I drove to NJ, and set up the CAN sniffer on the 997.1 Turbo vehicle. The data I already had was good. I also found a few devices which only live on the AWD cars. Armed with this data, I went back home, and set about tracking down the IDs in the assembly code.
At this point, all of them have been identified:
After identifying all of the units, I went back to the items being sent out from the DME and got more exacting values. So now instead of a general idea of the torque values, I know exactly which each one is. I also have all of the error states for the items which are on/off switches for showing when things are happening, like when the pedal position sensor is an error state, or the brake switch is, etc.
I am in the process of refining the package with all of this new information, and should have something ready soon.
One of the pieces of information which I do not have is the engine reference sync mode. That will determine how the package is split up. If all of the 997.1 cars use the same sync mode, then there will be one package. If the cars with GT3 top-ends use their own sync mode, then there will be two packages to choose from.
Retail pricing has been set at $1400 for M150 packages. If you want to run this on a M190, please contact me.
We have reached the beginning of the prototype phase.
At this point, the car starts, runs, idles, and basic control functionality works. Throttle control, idle, fuel injection, ignition, fuel pump control are all being handled by the Motec. We have the base positioning data for the camshafts, but are not controlling them at this time.
The process consisted of verifying the pinout of the harness to all of the sensors, fuel injectors, and ignition coils first, with the power off. Then we verified power was correct before plugging in the Motec. We then captured the patterns for the crank and camshafts. We then got the car to start, after ensuring our data for the engine run switch was correct. The next step in this process is to verify where Top Dead Center is, and measure the offset from that and the crank position sensor. We then did that, and got the car to idle. We noticed the stock ECU and the Motec fighting as to what the correct idle settings were, so we took over throttle control at that point, and the car idles where ever we want it to now.
Without the work of Sander Marques at Obsidian Motorsport Group we would not have gotten as far as we had in as much time as we did. We still need correct characterization data for some sensors and the fuel injectors. The next piece fro myself is to write firmware which takes in the CAN data from the stock ECU, manipulates what is necessary to control the instrument cluster, and put that back on the bus. I will be working on this more in the next few weeks.
As talked about in the previous entry, the SMG2 CAN bus has it’s own data. I need some data I am familiar with in order to more easily figure out the unknown data, so I set about getting the other bus into the M1. For this case, I simply removed the two plugs that were in the harness, replaced them with my own, and split the signal to the car and to the M1. It didn’t quite come out like I would have hoped. No pics for now. :) This is only temporary for a week or two in any case.
I updated the M1 firmware to log all of the IDs that I am interested in, and will gather data with everything in one spot while going to and from work tomorrow.
Everybody’s favorite is wiring, right? I had a very busy weekend creating the pass-through wiring harness shown here:
The SMG gearbox talks to the DME on a CAN bus in connector 2. Since this is the smallest connector, it was fairly simple to wire up the pins to pass through, and then tap into the two wires I needed to bring over to the M1. As you can kind of see in the first picture, the pins on there are designed to go into a printed circuit board, so they must be bent out of the existing shape so that you can solder wires to it.
This is fast, easy, and simple if you’re doing this all the time.
It’s been months since I soldered last. So it was none of that.
Here’s how the car currently looks. This is with the stock suspension back in, and the removal of the tint from the front windows. You can kind of notice the difference during the day, but it is extremely different at night.
I don’t think the E-Box was ever opened:
Interestingly, there’s no relay attached to the cover on the M3 like on the 330 with SSG.
Stock wiring, all nice and tidy:
With the adapter mostly in place:
I already had a power connector pass-through, so that was used to power the M1.
One thing ProEFI got right in their design was the mounting hardware is cheap and functional. The first piece uses two of the three existing mounting places in the passenger bin to put a support bar…
…which a plate is mounted to which has the ECU, and on the back igniters (and on the original kit - reisistors to fool the DME).
So after this, we’ve got our ECU in place, our data line run…and no way to control things or get the data out of the ECU. We need one more item. USB to CAN!
USB is fast, but in practice even USB 2 isn’t that fast (hence why we have 3.0 now). Motec went for a very elegant solution here - Ethernet.
Ethernet, using IPv6. For those that don’t know, IPv6 is the ‘future’ (it’s been the future for 15 years) IP addressing scheme. It solves the networking problem of running out of addresses. Instead of 32 bits of addresses, or 4,294,967,296 addresses, IPv6 is 128 bits, which can have
That’s a lot of addresses. It’s enough for approximately every square meter of the earth (or something just as absurd).
It also supports auto-discovery, and fixed addressing using a known pattern. It’s these last two features which is what I think attracted MoTeC to using Ethernet. It’s also much more standardized…and if you get creative, you can do this over WiFi. No WiFi for now. So lets put in an Ethernet cable.
First we need to remove the screws for the glove compartment:
Then comes the real fun. You have to fish a wire through a grommet that thankfully is already available for use. But this requires a bit of contorting.
When all is done, though, you have a nice cable jack available for you.
The wiring in the engine compartment is pretty clean.
After this was done, we used the Motec CAN Inspector software to dump what was being transmitted on the SMG2 CAN Bus. As I had been told by someone, the data is indeed unique on that bus. It’s not the same as the data we already have on the rest of the E46 series. That data is on another bus.
This would be the right word to describe the process of bringing a new product to market for a vehicle. This is true whether it is a physical product, a software product, or in the case of aftermarket engine control kits, both.
There are only so many details that can be shared without giving a heads-up to others what is being worked on, so these posts will appear in two phases. The first will have the category name of the project, in this case 2016A1. After the product is released, there will be others, and these posts will have both categories associated with them.
So what does it take to do this?
Before we get to the process for an overall project, without some key people I would not be here doing this at all. So thank you, Adam from e46fanatics, Neel Vasavada from Apex Speed Technology, and Jamie Bopp from Dundon Motorsports.
Someone approaches you with an idea, or you have an idea yourself. Either way, you are looking for a potential market. As you will see, this process involves a lot of time, effort, and money. I always wrote off the saying that you needed money to make money - this is entirely true. Until I was able to get my life in a stable spot, and scrounge up some ‘extra’ cash, I was never in a position to get started. The key is to find a market that is just developing, so that you can get your solution out there before others. Or, even if yours isn’t first, hopefully it works better.
After your target vehicle has been determined, it is in your best interest to find out as much as you can before even seeing the vehicle. Wiring diagrams are extremely helpful here. Determining characteristics of the engine, such as what items will need to be controlled on top of the minimum of fuel and spark. Electronic throttle control, camshaft positioning, variable valve lift, direct injection. These characteristics determine how many inputs, outputs, and what kinds are necessary to make the car run as good, if not better, than stock.
You need to instrument the vehicle in order to determine how it is being controlled by the stock computer. This includes using an oscilloscope for capturing signals, and a CAN capture device for recording the data being transferred on the CAN bus. CAN stands for Controller Area Network, and is a two wire bus which is designed to be resilient against noise. It is the backbone of how the various computer modules in your car communicate with each other. The problem is that there is no standard - manufacturers are free to encode data in any which way they wish. Data gathering starts with…silence. Getting your CAN capture device connected before you even put the key in is crucial - as you can see messages which only happen once. These may or many not be critical to making the car work correctly. Then you control as much as you can - use the turn signals, press on the accelerator, brake pedal, push all the buttons, and see what changes. Then you can at least identify what’s going on with user interaction. Start the car, and let it idle. Then go for a drive, and gather as much data as you can. There can be tens of units in the vehicle, each transmitting multiple channels of data. These leads to hundreds of items to look through. This leads to the next phase.
After you have lots of data, you need to identify the patterns which can help you discern what the data is, as you need to be able to replicate it in order for everything to work correctly. Today’s cars cannot just have an engine swapped and everything expected to work correctly. Lots of systems rely on accurate torque values being transmitted from the engine control unit to the rest of the vehicle. Just as important is to filter out items which are of no concern to you, and will happily exist with no work on your part. Given the number of items in a modern car, this filtering is important. This phase takes some time, and may be concurrent with the next phases.
Building a prototype firmware for the car involves setting up the code to receive the data you’re looking for and transmitting what you will be responsible for. In M1 Build, you set up a ‘Channel’ (these are the things with the ~ symbol next to them - which will hold these values. In my experience, I also want to have the raw data available, at least during testing, so I also set up channels which are each byte of data that was received off of the CAN bus for the IDs I am interested in. A wiring harness is then built, with a varying amount of integration. Perhaps you take over only fueling and spark initially, and fool the existing computer with a set of resistors to simulate the fuel injectors, to keep it happy. At that point you can get a reasonably good picture of what is going on, with having enough data from your own sensors to help decode the data the stock computer is transmitting. This can also take quite a bit of time to shake out - getting the engine to run is the easiest piece. Dealing with a dashboard is usually not too hard, though sometimes you can miss a few things. Wheel speed, transmissions, and anywhere else the engine management interacts with directly are the parts where ‘simple’ can get very complicated, very quickly.
At this point, all is well, you are marketing your product, and hopefully have customers. Maybe even making some money. You’ve got supply deals in place for the rest of your kit, or you work the other end of the deal and you are supplying someone else with your software. Either way, you’ve made it. Depending on how much time is dedicated to the project, this can be anywhere from 3-12 months.
Bimmers Only has identified a few areas of concern:
There are a few others which I neglected to write down. Unfortunately I’m not sure if the vehicle had the solid lifters adjusted recently or not, that may be another item to address.
At minimum the next owner of this M3 can rest assured that proper maintenance will be done on it. I firmly believe in doing the right thing, even if it costs a little more during the lifetime of ownership.
The entire premise of engine load calculation is derived from the displacement of the engine, the manifold pressure, an efficiency table that is calibrated, and air temperature.
Here is what the M150’s diagnostic worksheet shows for the fuel calculation:
On the 330 we have, it has a Technique Tuning Stage 1 Turbo kit. The inlet manifold piping from behind the Mass Air Flow meter to the intake manifold is a metal pipe. This is easy to manufacture, and in the stock scenario is fine, as the MAF meter itself has a built-in air temperature sensor, which is in a plastic housing. As a result, it is fairly insulated from the engine bay heat. The problem here is that calibration data for this sensor is not readily available. Other sensors were, but as we don’t have the MS45.1 data, only MS45.0, it seems that the temperature sensor is different in US cars vs non-US. Thus, we have to build a calibration.
A Bosch air temperature with a known calibration curve was installed into the metal pipe mentioned earlier. Upon startup, if you compare the known sensor with the unknown, you can correct the sample at that voltage point for the unknown.
Over time you can correct the existing calibration curve. You would then put that data into a spreadsheet, and generate a fifth-order polynomial equation. This will create a smooth curve instead of the intermediate, messy curve that will be there during this comparison phase.
There are also ways to bench calibrate this, but in-situ is better, even if it takes longer.
A very nice feautre of the M150 is that you can use “Inlet Manifold Temperature” sensor to correct the Inlet Air Temperature reading, which is what is actually used in the Engine Load calculation. However, in this car we don’t have one of those. So we will make do with what we have.
After further analysis, some trending shows an approximate 18 degrees Celcius deviation in the curve of the Bosch and stock sensor, and I added that to the existing calibration curve. After doing so it is pretty close so far.
As you can see, the deviation becomes much more than 18 degrees at points, and I’m fairly certain this is from heat soak, not actual temperature deviations.
There are a few items which are of concern:
The engine seems to be in good shape.
See September 1 post for more information.
Multiple hours on Saturday were dedicated to removing the tint from the driver and passenger door.
I’m not 100% certain, but I think the tint was too dark to be legal in the state of NY. I left the tint on the rear of the vehicle.
It was very time-consuming and a lot of effort to remove all of the glue which is left behind after removing the tint film. However, in the end it looks very good, and I should stay out of trouble.
I brought the 330 to a local dyno to see how far we could get things done for the Inlet Manifold Pressure Estimate table, as well as setting up the ground work for the standard Speed Density calibration in the M150.
I encountered many issues with the SMG not wanting to shift out of first gear. As a result we did some steady state work in first, including some of the Inlet Manifold Pressure Estimate table, as well as Engine Charge Cooling, and getting the camshaft control much closer to where it should be.
Unfortunately things did not turn out as expected, but I should be able to use some on the street data to get things working. I am also doing more research into how to get the car to dyno successfully.
I took a train up to New Hampshire to pick up a shiny 2004 BMW M3 Coupe in Alpine White. The day started out fun with the original train being delayed multiple hours, but I was able to take an alternate which got me there in time. Spoke with the owner, looked over the car, and off to the DMV we went to get transport plates for the trip back to NY.
While in the passenger seat I didn’t think the ride was too bad, considering the car is on 19” wheels and a coil-over suspsension setup. The DMV took about 45 minutes, and the staff was actually friendly. I then stopped by the seller’s house, picked up the stock suspension (just in case), and went on my way.
Very quickly I realized the ride quality was not good with the way the car was.
The car is low, very low. It also has an aftermarket exhaust on it. It also has tinted windows. I tried not to attract attention driving through multiple states to get back to NY.