You only need to walk around the pits here
at World Time Attack Challenge and you're going to find a number of the top cars
are running MoTeC electronics and at HPA, while we're completely brand agnostic, we've
had a lot of experience with MoTeC ourselves, back in the day my old drag car set world records with an older
MoTeC M800, and currently our SR86 endurance car runs a MoTeC M150. However, as not too often, we actually
get to talk to someone who is in charge of developing the ECU and get a much deeper
understanding of what goes into this. So, we're here with Darren who's a lead
applications engineer at MoTeC and one could argue is really the person responsible
for the MoTeC M1 platform as it stands today. So, Darren for a start, let's actually
talk about what your job title even means. What is an applications
engineer, what do you do? I make our ECU work in various applications,
so whether it's a race car or a plug in kit for instance, there's a lot of CAN
integration, a lot of new control systems that we need to write to integrate
with the OE electronics that are there. So, maybe there's a new thermostat which
has a servo motor which is becoming quite common, things like that so it's my job to
make those systems on the engine work. So, essentially reverse engineering the
newest innovations from OE manufacturers and making sure that MoTeC
electronics can control it as intended. That's a much better way to put it, yes. Let's go back one step
as well, I'm interested, did you sort of grow up with a passion for cars and motorsport or was your passion
more around applications engineering and you've fallen into the role at MoTeC? Yeah that's interesting, I grew up on a
farm so there was lots of motorbikes and tractors and things and so there was
lots of engines and engine building. And then when I turned 18 I started to
get into cars and friends were going racing so it goes from there, I had my own
race car back in the day, a VL Calais. And yeah when I decided I wanted to get a
serious job I went where do I want to work? MoTeC, so applied for a job. The reason I ask that is I'm interested, do
you think that you could be as successful in your role and do
what you've done if you didn't actually have a
passion for motorsports and understand enough motorsports? No yeah you have to have a
passion I think, yeah it helps a lot. To see people succeed and to help people
succeed, that's what really drives me. So, to get that feedback that hey I won
this race and it was your help that did it, that keeps me going for sure. So, that was my assumption
but I just wanted to clear that up. The other element is what is your educational
background, what do you actually need to do in school or university or all of the above
in order to become an applications engineer? I didn't go to university so it's kind of a
learn on the job, but I'm the kind of person that if I want to do something I just
learn how to do it and I go and do it. And so it's been a lot of scrolling websites
and various things talking to a lot of people and that's where I've been, had electronics
as a hobby since I was very young and then that turned into
programming as just a hobby. So, when I was sort of 15 to 25 that kind of
thing and I was making my own electronics for my own race cars
and doing various things, not ECUs obviously, that's a little bit too far, but various little devices I'd build for
myself and that's where it came from. So, yeah. Alright, also just interested to get a little
bit of insight into the development path of the MoTeC brand. I mean I probably cut my teeth back with the
old M4 which was DOS based and at the time I felt it was cutting edge, now I sort
of shake and tear if I have to tune one. Then the 100 series, which is what I ran
on my old Evo drag car and then obviously we've moved to the M1. What drives the development requirements
in terms of that sort of movement from M4, 100 series and then M1, is it a hardware
requirement or the advances in OE electronics and engine technology that demand
more sophisticated control strategies? Absolutely yeah, and obviously one of
the biggest drivers there is emissions, it's not something that we have to dabble
in but engine technology is really pushed hard by the emissions
regulations and so things like I mentioned a
servo driven thermostat is driven from emissions, but then you get
a better heater out of your car and you get better temperature
control and things like that. So, yes we have to evolve with the times and
technology keeps moving forward so we're able to build newer better products with
the available processes that keep coming up better and better all the time
so we keep moving forward. The next question that sort of follows on
from this is again, having used all of those platforms, one of the big changes and we've
seen this across a broad range of aftermarket standalones now is that move from an
injection time based fuel model to volumetric efficiency or VE based fuel model. So, for a start could you give us a brief
high level view of what injection time based fuel models are versus VE and
then also why we've changed? Yeah sure, so the time based is under an
operating condition being a certain engine speed and a certain engine load, we say
we want the injector to open for a certain amount of time and that takes away any
changes in fuel pressure which would alter that time, any changes in air temperature
and lots of other conditions that affect the injection opening time. Those kind of compensations are applied
in terms of tables and so then you have to tune those tables and you have to
understand what you're tuning and what those numbers mean; where with the efficiency
based model we're taking the physical properties of air and pressure and things
like that and temperature, we combine them all together to figure out
how much air is flowing through. So, the efficiency based model is
not about calculating the fuel, it's about calculating the air and then we apply
lambda on top of that, what target lambda do we want and we have a characterisation
of the injector which includes pressure, the fuel pressure. So, once we know how much air there is in
the engine and what lambda we want to run then we know how much quantity of fuel
to inject and so if we want to then go and change injectors, we can change
the injectors, change the injector characterisation but our
efficiency model doesn't change. So, this is one of the big problems with
the injection time base which still works absolutely perfectly when there's just a
bit more work for the tuner, but a common modification that I would be retuning for
as a tuning workshop owner back in the day was customer would bring in a car, we'd
tune it, basically max out the injectors so we sort of cap that at whatever we're
comfortable with and then in two months time it comes back with a new set of
injectors that are bigger, you put those in, but then it's not quite, but it's almost
a case of really completely retuning that fuel table or injection time base
table, whereas as you mentioned there, with the VE based or efficiency based
model, as long as the characterisation data for the injector is correct and
accurate and you swap to another set of injectors with that same data, it really
is just plug and play and essentially the engine should operate exactly the same. Now, should is the operative term
here, it's not always perfect but generally maybe you'll be within 1% or 2%, maybe
2% or 3% at most so definitely takes a lot of work off the table for the tuner. You also mentioned the compensation
table, so conventionally we would have on an injection time base model, we'd
have a compensation table for intake air temperature and then it's up to the tuner
to actually fill that out at this load and intake air temperature, how much should
I trim in or trim out, there's some rules of thumb around, I sort of work on about
2, 2.5% fuel per 10°C change, but that's not always going to be absolutely perfect. Now, with VE based, this is all incorporated
into the base fuel model so we don't have to think about it? It's not so much you don't have to think
about it, there's always still, you want to change things when air temperature
changes, but the hard work is done. It's definitely the hard work. Actually, while we're on that, and it's just
something I wanted to dive into a little bit deeper, so when we're looking at intake
air temperature compensation and whether that's just a three dimensional table in
a conventional injection time based ECU or you're trimming on a VE based fuel
model, really that's kind of a workaround for measuring the intake air temperature,
but what we actually want to know is the charge temperature as the air's
entering the cylinder don't we? And that can actually be affected by
air speed so what I mean by that is at low air speeds, idle, light throttle, there's
a lot more transit time for the air, once it goes past the intake air temp
sensor, then it goes into the inlet manifold, can pick up heat from that, then the intake
port, so the actual charge temperature is going to be different to what the
inlet temperature sensor has told it. Can you talk us about the complexity
that adds in any workarounds and I know there's not an easy workaround? It depends where your air temperature sensor
is placed and the speed that it reads at and a few things like
that but generally we try and take the sensor
as gospel if you like, that it's reading the right value and we
compensate on that and so the air temperature effect on the efficiency is
always applied as the temperature. We do have a model to try and model what the
temperature of the housing of the manifold is and how that affects the air temperature
as charge temperature, but the biggest effect is the cooling effect of the fuel. So, when you spray the fuel in, that
evaporates and takes a lot of the temperature out of the air so we have a different
characterisation for that as well. And it's kind of, how would I put that,
it's not so strict in the way it's done. We have quite a loose kind of method of doing
that and you just tune it and it generally is only one number and it can be a table with
air temperature as well, but you can tune it with one number and it's a case of once I change my target lambda
from say 0.95 to 0.85, how much cooler is the air so then you end
up with a little bit more airflow going in and that will change the mixture. So, then we use this... It's charge cooling coefficient. Yeah exactly, so if you change a lambda
target for exactly the same operating point, that your lambda should stay on target. Which as I know from experience
is reasonably easy to dial in. Which sort of gets into the deeper question,
which I wanted to get to, is that engines are complicated, there's a lot of elements that'll be different from
one engine to another and trying to get a simple, relatively
simple model to work across the entire range, be universal across
almost any engine is difficult. So, then you can add more and more complex
inputs required from the tuner in order to sharpen up that model and get it more
and more accurate but of course then you're asking more work from the tuner. So, how, as an applications engineer, do
you sort of weigh up the accuracy of engine control, basically getting the right result
versus giving the tuner something that you don't need a PhD in order to actually tune? It's a fine line to tread and our higher
end customers always want better control and our lower end customers always
think it's too complicated already. So, I tread that line based on experience
from dealing with our customers and knowing what that level of competence is out there. So, I definitely have some
higher end customers which say why don't you do it this way and I have to say I know it's wrong or
I know it's not 100% right I should say, but we have it this way because it's
generally too hard for our customers to tune. So, yeah it is a fine line to tread. And I think that's something that our listeners, those who
are tuning for themselves, probably need to keep in mind as
well, irrespective of the platform they're tuning on, everything of course in life
is compromise and trying to tread that, as you say, that fine
line to make a product that works well for the
largest number of users. Now, I also wanted to talk about when the M1
was in its infancy, really one of the first and biggest projects that you've worked on
was the integration with the Nissan R35 GTR. So, this is a pretty
complex car, I mean it's mainstream today, but
particularly at the time, this was a leap ahead for
Nissan, it's a very complex vehicle. For a start, what drove
the decision to support that platform with a
plug in variant of the M1? It was just the most logical
choice at the time for sure. We'd done the plug in kit on the M800 for the
Evo 10 and it's kind of just, it was the next big car that had come
along and I'm a Skyline fan from way way back,
I've had a couple of R32s myself and so that was
one of my passions and we had the opportunity,
or had access to a car by a very nice guy who races locally in Melbourne and he didn't
use his car very much, and basically he loaned it to us for a few months
at a time here and there and we were able to, yeah it was basically
the access to the car really that allowed us
to make such a complete kit and make it all function correctly, but
yeah it was, I'm getting a bit lost here now. That's alright. In terms of that platform, you've got not only the sophistication
of running the engine, and that part in and of itself is really not
too complex, but then there's the integration with the other OE electronics and CAN bus
and then most importantly there's also the integration with the transmission control
unit with what is a dual clutch transmission. So, that needs some very very complete and
careful communication backwards and forwards between ECU and TCU in order
to enable the shifts to complete. So, I guess first up, what was the most
complex part of the process for you? Okay, getting the upshifts to function as
cleanly as OE, that was always the goal, to make it drive as factory as possible and so
it was just a lot of data gathered and we looked at what the OE
ECU was doing and the sensors that it had,
where it has one manifold pressure sensor where it's a dual plenum engine, but two boost
sensors and that straight away told us that hey Nissan are using the
boost pressure and a model of airflow through the throttle to actually manage
the torque in the engine. Where most of the shift torque is controlled
by ignition timing, so then there's also many times for the OE traction control that's
based from the ABS where it's commanding a torque by the throttles. So, there's the two factors there, there's
torque controlled by ignition timing, torque controlled by airflow and then
marrying those two systems together. So, I guess the hardest part about the integration part with
the transmission is about getting those two systems to work together
and control that torque accurately. So, let's come back to that in a second. So, my rudimentary understanding of this is
essentially the driver requests an upshift, that signal goes to
the transmission control unit, the TCU then
requests a torque reduction to the ECU so it requests a specific torque
value, it waits until the monitored torque reaches that, then it will progress the
shift and then once the shift is deemed to be complete, it will say to the ECU,
right you can reinstate full torque. Is that about right on a simplistic view? It's roughly right yes, based on operating
conditions, because if you're full throttle or half throttle it's quite different. It will request lower
torque and for a moment, as the engine speed
falls, the TCM will request that the engine ramps the
torque back in progressively. So, we've kind of got an understanding of
what happens there and we're only talking about the upshift for the moment,
let's just keep it relatively simple. Then you mentioned there's two strategies of
torque request essentially from the engine, you mentioned throttle control and
then you mentioned ignition timing. So, essentially with the ignition timing,
we retard the timing, we make less torque, throttle control, we close the throttle,
obviously the engine makes less torque. How do you decide which of
those two strategies to use? The transmission tells us. Ok, so it's actually telling you what to do? Two different torque numbers, it either
requests this torque number and says I want ignition timing or it requests this torque
number, I want throttle and sometimes it will do both at the same time. So, does that come down to whether the shift
request has happened at part throttle where the engine isn't producing much torque or
wide open throttle and a full pull on the open road or a drag strip? Yeah, it's almost always for shifting, using
the retard based, it's just a much faster response obviously. And it will use the throttle based during
downshift so you get that smooth transition from downshift that it
pulls the throttle torque down to then go back
into overrun usually. Ok, so this leads us to the next complexity,
we've talked about the M1 traditionally being a volume efficiency based ECU, now
we're bringing in a torque model as well. So, I'm interested, not having actually tuned
an R35 myself, how does this work from the tuner's perspective, what
additional complexities are there? Because again, this sort of comes back to
what we were talking about, you want good, good control and obviously in this instance
the torque management is very very critical but you don't want to make
it too hard for the tuner. Yeah, so we don't have a method of measuring
actual torque out of the engine, there's no torque sensor so we relate torque back
to engine load and engine load being the mass of air per firing of the cylinder. And there is quite a close relationship between those two
points and we just take it as literally a straight line, linear interpolation between this engine load is
this much torque generated. From that point, the things that become
more important to tune correctly is the efficiency model itself. Because the efficiency model is telling
us how much air is going into the engine. So, the... Actually, I'll stop you there for a moment
because this is one of the complexities, I know I've seen this myself because I've
fixed some errors, a lot of people that came from the traditional injection time based
fuel model, moving into efficiency based and not understanding the
logic flow of how that works. And what I mean by this, you already
mentioned, you've got a lambda target table and that's one of the first places we need
to start, basically set our air fuel ratio at lambda targets to realistic, what do
we actually want for a given RPM and load. Then, and it's also, we need to fill in
information about the fuel that we're using, the injector characterisation as you
mentioned, we need the engine capacity, and this all needs to be accurate. So, it's very easy if you overlook those
elements because you don't know how important they are, yes you can still tune the engine
but what you're actually doing is fudging the numbers in the VE table and they're
no longer accurate, then when you bring in this torque model, you now basically
built yourself into a corner, correct? Correct, and that's what I was trying to
get to was the accuracy of your injector calibration, of your manifold pressure
sensor calibration and all of those other factors, the displacement as you mentioned,
they all have to be correct so that the ECU knows how much air
flow is going into the engine. And then the torque control from that
point is actually a model of the throttle's air flow, as well as the engine's air flow
and that way we can, for a given throttle position, if we know the pressure upstream
and the pressure downstream, we can calculate the flow through the throttle. So, the main additional tuning component
for torque control is literally just a two-dimensional table of the throttle
opening versus the throttle blade position, throttle area, how much flow can go through
the throttle for a given blade position. So, at that point then the ECU can accurately
calculate the mass flow that is passing through the throttle into the engine
and if we know that, really everything else falls into place? Yeah that's it, so flow through the throttle,
if you're at steady state, it has to equal the flow through the engine and to get to
those two flows to match, the model changes the modelled inlet manifold pressure. So, if there's not enough flow going into the
engine, then the model will just increase the manifold pressure and so those
two numbers then will always balance out. And if the model's tuned correctly,
that will also equal the sensor's value. Yeah, I think that all makes sense, probably
pretty heavy going, but maybe if our viewers aren't quite picking this up, another run
through this video might be well worth while. So, once we've got this model working, we've
already talked about the fact that it's great for the TCU, but it also gives the tuner
some other functionality, particularly with obviously the R35 drag and roll race market
is very popular worldwide and these engines now producing 2500 to 3000 plus horsepower,
and torque management is key to getting that power to the race track. So, what tools have you then given tuners to
put in their tool belt in order to manipulate the torque versus gear versus
road speed or whatever it may be? Everything and anything I can think of,
so yeah, as you mentioned there's a gear based torque limit, there's a vehicle speed
based torque limit, there's an overall torque limit, there's a wheel torque limit
so it will automatically calculate the engine torque from your requested wheel torque. We have a whole traction model, which models
from tyre friction coefficient, so how much grip your tyre has to then work all the way
back to how much engine torque we can supply where that tyre will just
start to break traction. So, there's lots and lots of tools we have
in there to help make those cars go down the track as fast as possible. So, essentially from the tuner's perspective,
you've given them the ability to almost always match the amount of torque being delivered
to the tyre to the amount of grip that that tyre has so you're never overwhelming the
tyre and the benefit of that then is if you do end up with wheel spin, it should be a
relatively small amount of wheel spin, which makes the traction control
strategy less heavy handed. Yeah, that's exactly the
purpose of the traction model is to just give the wheel a little bit more torque than it can handle and then let
the closed loop part take up the rest, because if we're not turning the tyre, there might
be a little bit of tyre left and we don't know so to overshoot just a little bit and
then let the closed loop side measure slip and reduce torque either via cut or ignition
timing as well as closing the throttle, we have all of those methods available. This also begs the question, on a four wheel
drive platform like the R35, how do you accurately know when wheel spin is occurring,
because my experience with four wheel drives albeit much simpler
four wheel drive platforms is when you wheel
spin, all four are spinning, so yeah give us some
insight into this, are we talking high speed
GPS or what's the story? So, we can use high speed GPS and we
have plenty of customers using that method. The built in method is generally you don't
really get all four wheels spinning all the time, there's always one that's typically
loaded a little bit left, a little bit right and one that will be travelling
at the true ground speed. To go past if we do have all four spinning,
we have a maximum acceleration rate that you can set and that means that if all four all
of a sudden jump up in speed by quite a bit we'll have our actual speed only creep up
at a certain rate and so that will then, the traction control will work to that factor
and so that's quite a simple method. Once you go, we can
use a longitudinal G sensor as well to correct that
factor but once you go off the drag strip and go into some track
racing or driving on the road and where you have hills, the G sensor method
starts to have a lot of inaccuracies. So, limitations depending
on the application. Yeah and it's a limitation in the OE world
as well, it's very difficult for even the OE with many hundreds of engineering hours
to accurately calculate a true ground speed from wheel speeds. I mean I guess the OEs have the benefit that
they know that the platform isn't going to be messed with and isn't changed, you're
dealing with something that could be making 600 horsepower or 3000 and you're trying
to use the same strategy to go across that entire range. Now, that strategy, the torque model, as
I understand it, also been inherited by the Audi R8 and Huracán platform, which is also
incredibly popular for drag racing and roll racing, but it's recently also made its way
into the production firmware for an off the shelf M150 that can be used
on any car with GPRP Pro. So, is that just essentially exactly the
same but for any car, not just a GTR? Yeah correct, it's an evolution. So, we started with the GTR, the GTR used a
torque model, so we developed a torque model to run that car correctly
as the OE runs it. It was the logical choice to use for the
Huracán since it already had DSG integration with it and then with the Huracan
came a few more challenges as well. So, when we moved to that platform we
moved to a torque based throttle pedal. So, in the older GTR
firmware up until about 2018, we used our
traditional pedal to throttle translation, so it was
just a table where for a given pedal position
we got a given throttle blade position. So, the torque model worked on top of that
but it was that direct relationship we still had up until that point. With the very responsive V10 engine in the
Huracán, I found that to be quite difficult to drive and to make a nice feeling throttle
pedal so I tried to instead command a torque from the throttle. We've now moved to that method, it worked
fantastically in that car and I've had very very good positive feedback
about that using that method. Again that's really the method that OE's
have been using for a fair amount of time in terms of it's a driver's torque request
from the pedal, which is really what we're asking for isn't it, we put our foot to
full throttle, we want all of the torque the engine can produce. We made that move for the Huracán platform
and it's just been a progressive development path, actually right since the start of the
GTR it's just been a progressive development path continuing to build
on top of that torque model. I had a job back in 2018 running
some IMSA cars in the US. So, these are Le Mans style cars,
they're called the DPI Daytona prototypes. So, we fitted our ECUs to one of those cars
or two of those cars actually and for that class they use a balance of performance using
manifold pressure, and because we can control manifold pressure with throttles, we could
get a lot better response than trying to do it with boost control. So, there's a faster system than basically
trying to see the boost pressures increased and then changing the wastegate position and
waiting for the turbo to respond and then it affects the throttle a little
bit and have the same results. So, much faster reacting,
the cars ended up going from midfield to
winning races immediately then they got penalised with
weight penalties as happens. But from that point I then built a torque
package that then had paddle shift control in it, so we've had this sort of
under our belt for quite a few years. And it was just with COVID and things like
that, we had a little bit of extra time I guess, we're all working from home and
so it made it into a few of our employees' cars at MoTeC for a little bit of testing. So, this grew the general purpose GPRP
Pro basically just as a natural progression of that firmware. On that note, let's just talk a little bit about the commissioning
and validation process of a new product like that GPRP Pro, you
mentioned that it went into some of your employees' cars. What's that testing look like, how long is
it before you start pushing it out into the greater public and then when you start doing
that, do you have selected dealers that are preferred for doing
some of this testing before it actually gets a
general public release? Yeah for sure, there's various dealers that
we have that we prefer for doing various testing, ones we know that are very competent
that will give us really good feedback, really good data logging feedback as well,
and so those people are instrumental in us developing these kinds of packages so we
can't have all of those high end race cars in our workshop at any time. They get pretty expensive. Yeah, that's right so we definitely rely on
our dealers a lot for that sort of information. I guess the next obvious question
is where do you see the future going? What are some of the developments you're
monitoring in the OE world or the professional motorsport world that you see filtering down,
anything else that you can share with us that you're excited about working on
and seeing some improvement from? Good question. Without sort of giving too much away
obviously, some secrets must be kept. Yeah, we certainly have constant hardware
development going on, there's always, we have a whole engineering team working on
various products at various times and we are always pushing forward, obviously, so we do
have a new ECU platform that is in the works that is moving forward I would say without
giving too much away, but yeah the constant development we're seeing in engine technology
as well just keeps driving us forward too so we need faster
processes to do more work. We need more outputs in our ECUs to control
more devices as engines just get more and more actuators fitted for various things. We used to have one boost control solenoid,
now we're seeing two wastegate servos and so that takes a lot more. So, the hardware essentially has to evolve to
suit what is being developed in the OE world. Yep and then that filters
down into motorsport as well, so those
engines then get used in a racecar and people want to make a lot more
power out of them so then, and have all that flexibility in the tuning as well. I'm just wondering in
terms of the limitations as you currently see
them on the M1 platform and obviously there's
a variety of different models within that family,
the fact you mentioned you're working on a new ECU, what has become
the sort of bottleneck I guess, is it the IO, you mentioned
obviously newer engines, more actuators, more
things you need to control so that affects your input
and output requirement or is it the processor itself needing to do as you said more calculations
more quickly or is it all of the above? Yeah, it's all of the above for sure. So, once you go to a DI engine with dual drive
by wire we start to run out of outputs quite quickly in our current series ECUs. So, we actually use one of our M130 ECUs as
an expander for say an M142 DI ECU and so we can then easily run port injectors on a DI
V8 for instance as well as all of the other actuators on the engine as well. So, you've got options, but a new platform
is going to give you more flexibility. Yeah, and it's a cost factor as well, so it's
having two ECUs versus one so yes, the number of outputs or IO in general is certainly a
factor and yeah processor speed is certainly a factor with the communications getting hot,
the demand on communications getting higher and higher all the time. So, then there's also new
communication standards like CAN FD coming through, we're starting to see those too, so we
have to evolve with the times. Never a dull moment essentially. Look it's been great to get some insight into
what goes on in the applications engineering department at MoTeC and how you're taking
these new technologies from OE's on board and integrating them into something that
we in the consumer market can actually use. Thank you very much for your time Darren. No problem, thank you very much. If you liked that video make
sure you give it a thumbs up and if you're not already a subscriber,
make sure you're subscribed. We release a new video every week. And if you like free stuff,
we've got a great deal for you. Click the link in the description to claim
your free spot to our next live lesson.
