Tag Archives: motec



Nov. 16, 2015

you should really know what you’re doing

, , Leave a comment

you should really know what you’re doing.

11/16/2015

We’re not all born with knowledge. We’ve got to work for it.

I guess I could have entitled this post “really useful stuff you can do with a simulator”, but I think that the current title is equally effective.

A long while before this current moment, most of my pre Obsidian Motorsport Group professional life was based around figuring out problems. (I promise that I’ll try and keep the retrospective of my younger self to a minimum). I started my automotive life as a sophomore high school kid working at an automotive repair shop. They did general repair and specialized in fixing old air-cooled VW and Porsche engines. Looking back on that job, I think that it really gave me a solid foundation for my professional life (and arguably my personal life, too), but at the time that I was there, I hated it.

The reason for all of my misplaced adolescent hatred was based around the idea that my bosses (two guys) wouldn’t ever allow me to just replace a part to see if the problem got better. They required me to prove that every part I replaced, needed to be replaced. If that involved showing them there was a definitive dead short in a harness with an ohm meter, or showing a oscilloscope capture of an M112/113 Mercedes crankshaft position sensor as it loses its amplitude when the sensor gets hot. Again, hated it at the time, but it really beat in to my brain that it’s best to prove your hypothesis before jumping to a conclusion.

jump_to_conclusions_mat

(…I just had a great idea)

Fast forward to now, the mindset of proving your actions with quantitative data is really the basis of what I’m trying to demonstrate the power of.

Here are some basic examples of things that are made easier with a simulator:

4344_small

Do you know how the VE model works?

Fueling is (for me, anyway) one of the more interesting variables in an engine management system to wrap ones head around. As a basic recap, fuel injector pulse width is the output of an equation inside an ECU taking in to account a number of different sensor values. IPW is the amount of time that the ECU commands the injector to be open. The amount of fuel that is delivered from the injector during this on time is based on fuel pressure, measured injector flow rate, battery voltage, and density.

The following truth is unfortunate: You don’t need to know about any of that stuff (or the ideal gas law) to tune an engine mostly well with newer volumetric efficiency based ECU’s

You can pretty much input a few simple variables and set the VE table to 90 and the engine should start up and run mostly well.
So perhaps being ignorant of the ideal gas law or what determines injector on time, figure you’ve bumbled through the map enough to get the car running pretty solid and making a “number” for the customer. Great. Good for you. Say the customer comes back and wants you to install a flex fuel sensor and re-tune for E85 or E98 or something of the sort. Are you confident that the ECU is going to add the appropriate amount of fuel over your pump gas tune when you go to make that first dyno pull on E85? What about using multiple ignition tables? Do you know that the blend table is going to work correctly? What happens if your VE table is only scaled out to 20 psiG, and you have a run out to 25 psiG, what’s the ECU going to do if you ride off the end of the table?

That can all be simulated, on your desk while you’re sitting in your favorite thinking chair.

Beyond the initial benefit of just seeing what’s going to happen to the injector pulse if you add in some ethanol content or drive off the end of the load axis, you can spend the time to reverse engineer the fuel model that is being used in the ECU. I may be a bit of an outlier in this department, but I try not to trust or have faith in anything I don’t understand or haven’t tested, first.

What about fuel compensations / trims?

Not all ECU’s are created equal in this department. How do you know if the ECU uses a multiplier or a percentage value? You would think that this would be easy to find in some ECU software programs, but it is not always as easy as one would think. It’s a lot more relaxing to do that with a simulator and move independent values around to see how it is affected before you get to the dyno / track.
Are these the same? (Emtron and MoTeC)

(picture will be replaced, soon)

I should take a second here and give an honorable mention to Life Racing’s LifeCal. They have an awesome, easy to read layout of the entire fuel calculation. See picture below:

life_fuel_calc

What about secondary injection / blend tables?

Not all ECU’s are created the same here, either. Some of the wording is a little opaque on the Mx00 MoTeC ECU’s when it comes to secondary injection

What about boost control?

If you’re the type of guy or girl who just likes to “let it eat” with open loop wastegate duty cycle controls, then this probably doesn’t matter much to you.
However, if you take pride in what you do and find a need for precise boost control, getting a feeling for the PID sensitivity controls is much more relaxing at home with a cup of coffee or any other preferred beverage of choice. PID settings are ECU manufacturer specific. Settings that work in an AEM V2 / EMS4 box WILL NOT work in an MX00 MoTeC ECU and vice-versa.

What about traction control?

Yes. This is where simulators are pretty great. The MoTeC M800 ECU’s have awesome traction control settings. The power of the M800 is the ability to make tables and compensations acting on other tables or compensations. After you get through a few levels of that, it can get a bit heavy to wrap your head around. So if you are using one of the Intermediate or Advanced simulators, you can simulate a driven wheel speed to see what’s going to happen with the timing, drive by wire throttle, fueling, or limiters BEFORE you get to the track. If you take a second to think about all of the time that can save you, it’s pretty immense.

What about setting up CAN devices to talk to each other?

You CAN do that pretty easily (I know, I’m hilarious). CAN stuff isn’t bad to do if you’re using all MoTeC products, as they provide really easy to set up templates. However it CAN get a BIT (sorry, I’ll really stop now) more difficult if you’re using MoTeC dash loggers and an AEM ECU (or Cosworth ICD and a Bosch Motorsport ECU or any number of other combinations) If you wanted to utilize all of the CAN data sent over from the AEM ECU, you would have to write a custom can template. This is not too bad to do if you can simulate values (say RPM for instance) in to the AEM ECU, connect the MoTeC dash to the AEM ECU via CAN and then work on the scalars and multipliers until the value is correct in the MoTeC dash.

So, why did I start this post by talking about myself as a young all-knowing teenager? Because I used to think that it was stupid to have to prove your work. If I could get the car fixed by guessing and maybe getting lucky, then that was good enough. The truth is that it’s really not good enough. If you can get by moving numbers around and making some power and you’re ok with that, then great. Although, I think that what’s going to separate “tuners” from professionals is knowledge and understanding. Buying a simulator isn’t going to give you the knowledge and understanding, but it can help you gain it much easier and much more safely. (and, it’s entertaining if you’re easily entertained).

2015-02-10 18.50.05

May. 15, 2015

knowledge reigns supreme over nearly everybody

, , , Leave a comment

knowledge reigns supreme, over nearly everybody

5/5/2015

I have been spending way too much time recently thinking about how I can convey the importance of data systems to you, my loyal readership. It’s the most important tool a team has in making strides in performance, diagnosis, and reliability. That’s really the best thing I can come up with. It’s used in EVERY professional race series, regardless of category. If that’s not enough to sway you toward a data system, then I’ll continue to ramble about it below.

I am in an interesting position in that I do private label work for a number of shops, teams, and individual customers. Basically, I get to see a lot of different stuff. I’ve done data analysis for a NASCAR Sprint Cup team, I’ve done analysis work for club level road racers, snowmobiles, drag racers, and a whole load of high performance street cars. The thing that all of these groups and categories have in common is that they all require some type of way to review and analyze data. Engine mapping, troubleshooting, and performance are all quantified and adjusted based around data. This all sounds super great, right? It is. Super great. But, it seems that there is a disconnect when it comes time for my customers to purchase one of these systems. Here are two problems that I’ve noticed over time.

The perceived gain problem.

There is a big problem with the understanding behind purchasing data systems. The problem, as far as I see it, is that there’s no direct connection in a customer’s mind behind purchasing a data package and performance gained.

For instance, customer A wants to buy a turbocharger that has a 50lb/min max flow rating. His current turbo is 30lb/min. This will yield an approximate 200 hp gain (all things being fair and equal in the world of physics). Customer A will go to a dyno, get his engine mapped, and there will be a before and after chart representing the difference in power. He will see and feel the money that he spent. With 200 extra hp, maybe he’ll drop 2-3 seconds off his lap time. Maybe. That’s if the extra power doesn’t through the cars balance off, or over drive the tire, or over heat the brakes.

What happens if the customer is told that he can spend the same amount of money on a data system that could take 5.00 seconds off his lap time by using accelerometer data and driving line evaluation, potentially identify faulty sensors, potentially identifying an engine failure BEFORE it happens, and allow for peace of mind if all of the data looks great?

He’s going to go for the turbocharger.

The problem at hand is that there is no perceived direct correlation between data and performance. It’s unfortunate because, when used correctly, this couldn’t be further from the truth.

Now it’s probably obvious by reading the other content on my website that I sell data systems, and it would be great if you contacted me to talk about them in more detail. But, all bias aside, they really are useful pieces of equipment that sometimes can result in the dramatic lap time reduction mentioned above, among other useful purposes.

Thoughts on being emotionless.

There’s such a nice feeling associated with making decisions based off of objective data. It completely removes the need for “emotion” or “feelings”. In the context of engine mapping, this concept couldn’t be more true and to the point. Imagine you’re sitting in the drivers seat of a 1000 hp Supra strapped to the dyno and you’ve just started a pull in 4th gear. You’ve got a lot going through your mind. “Does this engine have a coolant leak?” “Does it actually have E85 in it, or is it diesel?” “What’s that sound? Rod knock? Valve tap? Oil spraying out of the cylinder head?” The list goes on and on. And then you’ve got the normal stuff you’re supposed to look at like lambda, fuel pressure, temps, etc…

How to remove some of those points of concern:

-If you have cooling system pressure sensors, you can derive if theres a leak, or if you have a head gasket that’s starting to leak, or leaking profusely.

-If you have an ethanol content analyzer, you can tell exact ethanol content and not have to worry if you’ve got winter blend E60 or E70 as opposed to the E85 that you should have.

-Oil pressure sensors in different points of the engine can tell you a lot about the oil system efficiency or if there’s any oil in the engine at all (…)

The more you can do to remove these questions, the more mental focus you can apply to doing the original job of calibrating the engine. Furthermore, you can set up safe guards with good ECU’s that can impose a fuel cut, a warning light, or a boost reduction if any number of things are out of your specified range.

See below for an example. In this instance the AEM V2 ECU’s allow you to create a predicted path for fuel and oil pressure. It’s pretty simple but cleanly executed. Oil pressure changes with engine speed and thus, you can create a low oil pressure threshold at different RPM’s to compensate for that. I.E. if the oil pressure drops below x oil pressure at y rpm, the engine will cut for a brief period of time. Same goes with fuel pressure. At different manifold pressures, 1:1 fuel pressure regulators allow for 1 pound more fuel pressure for each 1 pound of manifold pressure (a calculated differential fuel pressure channel would remove this requirement entirely, but that’s maybe for another article, some day). As manifold pressure rises, so does the fuel pressure low threshold.

fuel_press_protect
Just realized that I’m rambling a little bit, sorry.

So, I’ve explained how extra sensors or a data analysis package could help someone like me (who is someone who maps engines, regularly). Unless you’re like me, this probably doesn’t interest you tremendously.

A thing that is tremendously useful for road racer types is the time difference graph. Have you ever wondered if you’re making an improvement on track? Or even better, exactly where? Practically all worthwhile GPS based data systems give you this information. Attached below is a screen shot of two laps overlayed on each other.

sled_compare

The upper graph is a representation of transmission speed, and engine speed, from two separate laps. The lower graph is the time difference graph. The blue line represents the faster lap time and it is used as the reference. The red line is the slower lap time. Since these two are overlayed based on distance, they are equally located based on position. This allows for an easy representation of EXACTLY WHERE you’re gaining or losing time. If the red value is positive the vehicle is losing time over the faster lap, if the red value is negative, the vehicle is gaining time (going quicker) over the faster lap.

Even cooler than this, is that the software will auto generate a track map based off of GPS position. And since all of the data is located based on GPS coordinates you can select anywhere in the data and it will show up exactly where you’re at on the track at that particular data point.

So for example, the black circled area signifies where the cursor is selecting data.

sled_compare

Now all you need to do is to transfer over to the GPS track map and you will have an exact identification of where on track the selected data is correlated to. Neat.

track_pos

Now take a few minutes to think about the usefulness of all of this information…
GPS based data systems can start around $1200.00. Fully featured GPS based dash loggers can start around $2500.00. (Be sure to ask me about all of the other functions that the dash loggers that I sell (from MoTeC) can do.

Pretty affordable if you really think about it.
Please feel free to email me any questions you might have. I’d love to chat.

Jan. 30, 2015

mcmuffins and half bridges

Leave a comment

mcmuffins and half bridges

1/30/2015

Things you can do with a MoTeC Dual Half Bridge:

41213

The MoTeC dual half bridge is a pretty neat device. Simply put, it allows you to drive reasonably large, variable speed motors, directly from the ECU. Why do you care about this? I’ll tell you why, because the world isn’t as simple as “ON” or “OFF”.

The DHB is effectively a solid state relay that can take a low current PWM (pulse width modulated) signal (driven low or high) from an ECU or a Dash and drive a very high current (20A continuous, maximum) motor at varying speeds or positions. There are a number of different cool circumstances where you could use a DHB to your advantage. I’ll run down a few below:

Example 1:

We’ve all heard that car. You know the car I’m talking about. The car with the big ass radiator fan that sounds like a jet is about to take off. I find that so annoying. No one needs a loud ass fan to turn on for 60 seconds just to cool your radiator off, so that it can turn back on again, 2 minutes later.

For instance, when you go to order your favorite McBreakfast from the McResturant, you don’t pull up to the window and scream at the top of your lungs “I WANT A MCMUFFIN”. You say, “I want a mcmuffin, please”. Your radiator fan is screaming “I WANT A MCMUFFIN” every time it turns on full blast for no particular emergency. Drives me nuts.
So the DHB can fix this problem. The DHB can do the high current work of fan speed control. All ECU’s that are worthwhile will allow the user to create a PWM output table based on user definable axis. So then just create a table that looks like this:

water_pump_speed

You’ll have coolant temperature on the X-axis and the values in the table will correspond to fan duty cycle (or speed). As temperature increases, so will fan speed until it gets to the point of being at full blast. The thing to note, is that it will only be turning at full speed (and screaming about the MCMUFFIN) if it NEEDS to be there. Cool.

Example 2:

Say you’re an R35 GTR owner, or a Supra owner, or a huge power engine owner, and you have 3 fuel pumps to supply your daily driven 1000+ hp engine. If you have 3 fuel pumps running at all times, you’re wasting energy in two ways.

-First, you’re going to waste a ton of electrical energy. Figure worst case scenario your pumps draw 20A each.

-3 fuel pumps. 20A a piece (average worst case scenario for your average 340-400LPH pump)

-20A times 3 pumps = 60A. Figure 13 volts while the engine is running. Amps times volts equals watts. So, 60 * 13 = 780 watts of power to drive your three fuel pumps at idle. If you’re like most in the US, watts don’t really mean much to you in an automotive world.

(sidenote of relevance) the Kilowatt is used to measure Horsepower in other parts of the world.

-However, for this example, it is relevant.
1 watt = 0.00134 horsepowers

So after doing some simple math, we can figure that those three fuel pumps are taking a total of ~1 horsepower to drive. That’s crazy. You don’t need that when you’re idling!

-Secondly, you’re going to heat up the fuel excessively. Fuel pressure regulators are just like any other regulating valve, they restrict the flow so that pressure can increase, and they allow less restriction so that pressure can decrease. The variability is based off of manifold pressure / vacuum (that’s what that hose from your intake manifold to your fuel pressure regulator does!).

So now think about your fuel pumps trying to force the maximum volume of fuel that they can flow through a tiny regulator and fuel injectors that are barely opening (because you’re at idle). This is a strain on the pumps, and when there is strain, there is heat. This heat will eventually be transferred in to your fuel system and you will watch your fuel temperatures steadily rise. Hot fuel isn’t so good, but not totally deadly. What can be bad is that if your car was tuned on a dyno with cooler fuel temperatures, and then you go out and drive your car around the city for an hour and then have a blast on a local highway, you might find that your mixtures are slightly leaner due to fuel density changes relative to heat. (Injector dynamics wrote a really great article about this, it’s short, and to the point injectordynamics.com/articles/injector-dynamics-newsletter-feb-2013/ )

Ok, now we know that running your fuel pumps at full bore all the time maybe isn’t such a great idea. Now what do we do?
What if you could slow down your fuel pumps at idle and part throttle conditions? What if you could have them speed up as you creep in to boost?

You can!

All ECU’s that are worthwhile will allow the user to create a PWM output table based on user definable axis. So then just create a table that looks like this:

fuel_pump_speed

(Sidenote of relevance: Even this table is over complicated. You can just have this referenced to manifold pressure without TPS, I just think it’s neat to be able to change the speed up relative to TPS too)

The DHB can take this small current control output from the ECU and drive the heavy current fuel pump with it. So when you’re on the throttle 100% at 0 manifold vacuum, the fuel pump duty cycle will be 61%, and will gradually increase to 100% by the time you reach 175kpa (a little less than 30 psi of boost).

Use your parts efficiently!

Shameless plug is that I usually have one of these around for sale, this moment in time is no exception. Email me if you’re interested in hearing more about it, or just want more of my rants. sander@obsidianeng.com