Exploring the complexities of modern ECU tuning, Ryan from PowerTune discusses the challenges of integrating aftermarket ECUs with vehicles' intricate electronic systems. The conversation delves into the advantages of MoTeC's M1 build platform, which allows for custom firmware development to control various vehicle functions, including CAN bus communication. Ryan highlights the importance of understanding these systems for effective tuning and the potential for one-off projects tailored to specific vehicles. The episode offers valuable insights into the future of automotive performance tuning.
Ryan Nicholls Powertune Australia answers these common questions and more in relation to what can be done with the right skill set and tools, in this case, MoTeC's M1 Build and knowledge of C# (C Sharp) development language.
Some key takeaways from this chat include some insight into CAN Bus, LIN Bus and FlexRay, plus the fact that reflash tuning is not equal for all platforms, and some are much better developed than others. Ryan also mentions how you are often relying on an interpretation rather than an absolute when it comes to reflash tuning software vs the lack of OEM information, as well as sharing encouragement from Ryan for anyone interested in learning the skills he has to do so, even at a hobbyist level.
This interview was recorded at GTR Fest Australia, where we somehow managed to film more about EVOs and MoTeC ECUs than GTRs, and had a ball doing it too.
"... like, say, for example, the modern ones like the A90 Supra and things like that. They can take weeks o..."
Select text to request an explanation
The modern crop of performance vehicles.
Obviously, the electronic side is becoming increasingly complex and there's a lot of interaction between different electronic modules within the vehicles.
The problem for us in the aftermarket is it makes it harder to replace the factory ECU with an aftermarket standalone.
We're here with Ryan from PowerTune in Australia to talk a little bit about the ways of getting around this.
Welcome to High Performance Academies' tuned in field report podcast series.
In these special midweek episodes we look back through our archives to find the best conversations we've had through years worth of attending the best automotive events across the globe.
We've pulled the audio from these tech filled interviews with some of the industry's most well known figures and presented it in podcast format for you to enjoy as a quick hit of insider knowledge.
Ryan, for a start PowerTune you're pretty heavily involved with the MoTeX product range, which allows you access to MoTeX M1 build.
So let's start with that.
What is M1 build and how does that give you an advantage?
So M1 build is basically an IDE or a development environment for the M1 platform.
So the M1 series of ECU, that's effectively M1's flagship model ECU and it's the newer one of the gold box or newer than the old gold box.
So M1 build is basically a platform that allows us to write our own firmware for that device.
So for us, the M1 is effectively a box of inputs and outputs and we write whatever we want it to do.
So it doesn't have to be an ECU for a car, it can be for any particular thing that we like to control, with inputs and outputs.
So you're essentially using it as literally just a black box, and that black box will do anything you want it to do, based on the firmware that you write for it, that's exactly right.
So this can literally control, say, for example, a mining drilling rig, or it could control an engine in a car.
So it's literally anything that we want it to be.
Okay, so in terms of that product M1 in general, people can buy an off the shelf M1 ECU from MoTeX or any MoTeX dealer with production firmware that MoTeX have written and that'll control most things you'd be interested in controlling.
Yeah, absolutely so.
They have their standard range of products, which are the GPA, gpr and GPRP range of products, and what they are is basically a standardized engine management system similar to the other ECUs that are around the place.
They control a modern engine, you know, variable camshaft, drive by wire, those types of things, but more intricate things that are, you know, targeted to one particular vehicle.
They may not actually control out of the box.
Okay, so this gives you the flexibility then to take a vehicle that you think there's going to be aftermarket demand for and then go through the process of engineering that ECU to control everything for that particular vehicle.
Yeah, that's right.
So for the older model cars, let's say, for example, pre 2008 we'll take in this example we use maybe the R34 GTR.
So the R34 GTR has an attessa control system which controls the four wheel drive split in the car and we can actually write firmware that controls that system.
So it's not necessarily can bus or anything like that.
That's really sort of, I guess, modern, but it's just a control system that uses PWM outputs, controls solenoids and controls the four wheel drive split in the car.
Now conventionally with other ECUs, you would have an ECU to control the engine and in the R34 GTR, as you mentioned, it's actually a relatively basic vehicle from an electronic standpoint.
There's no can bus, so reasonably easy to engineer a plug and play ECU solution for that vehicle.
But then you would actually have a standalone attessa controller if you wanted that functionality.
Now you can do everything within the same box.
Yeah, that's exactly right.
Typically in the past guys will use controllers like maybe the full race controller that would be standalone and separate from the ECU.
But there's obviously a few caveats with that and that is that you can't use the engine data that you're seeing in the M1 ECU into the four wheel drive controller to control the split.
It's typically done with a manual dial or its own inputs into that box.
So a lot more flexibility with an integrated solution in the way you can control the four wheel drive split, and obviously we see that a lot with the high end drag cars in terms of what they want to do with how much front torque bias is done off the line and then down the strip, correct?
Yeah, that's exactly right.
So, like a lot of the times, these cars, you know they'll get out off the hole in four wheel drive and they might want to turn that four wheel drive control off.
They might do it based on torque, they might do it based on manifold pressure.
It can be any number of different things.
The nice thing that we can do with the M1 build platform is basically allow us to write firmware that takes that and then controls that system on its own.
Okay, let's fast forward to something a little bit more modern and a little bit more complex, and, as I sort of alluded to in the intro, here we've now got cars with multiple controllers one for the engine, maybe one for the transmission, particularly if it's DCT or DSG, or even a modern automatic, then maybe another controller for the gauge cluster, air conditioning, abs, the list just goes on.
And that requires interaction between all of these modules.
Basically, the signals have to be present, otherwise you can make the engine run but the car won't drive.
And this is all related to CAN, bus and, more recently, maybe Flexray as well.
Yeah, that's right.
There's a number of different communications protocols that are in modern cars and, like you said, they sort of can range from maybe having one ECU in the car through to having hundreds.
I mean there's modules to open and close the boot and that runs from CAN bus that communicates with the body module and things like that.
So I mean, like there's a lot of modules in these cars and they all have to have their own communications protocols, typically CAN bus and for the sort of I guess the more manual or mechanical controls in the car, typically we see LIN bus.
And then on the really new stuff, there's a new protocol called Flexray.
Alright.
So if we look at one of the more common methods CAN bus.
For those who haven't heard that tune before, what is a CAN bus?
So a CAN bus is basically a network of computers within the car.
They all communicate over two physical wires and it allows a lot of information transfer with not a lot of wiring.
So we can transmit information like engine speed and sensor data all over two wires instead of having a bunch of, say, 30 or 40 wires transmitting, you know, voltages for sensors.
So vastly simplifying the wiring for the entire vehicle and giving that all of that information is then available to any other module, that is, on that bus.
That's exactly right and that's one of the big benefits of CAN bus, and that is that in a typical application where we have a physical wire from a sensor to a single control unit, we now all of a sudden all the 50 other control units in the car can all see that data as well, without actually splicing into that sensor.
Are you interested in expanding your automotive knowledge?
Start your free lessons with us today at hpacademycom.
Forward slash free.
Ok, so now we know what we're dealing with there.
And essentially, when we interrupt the messages on that CAN bus by replacing the ECU, that's why we get to that situation where we can make the engine run but nothing else works.
Let's bring this back to M1 build.
And how are you using that product, that software, in order to overcome these problems with CAN bus integration?
So with the M1 build platform and like we mentioned just before, we can write our own firmware.
Now part of that firmware allows us to write our own CAN messaging and emulate the factory unit.
So let's say, for example, we take a modern car, let's say a Subaru WRX, we remove the engine ECU and we replace it with an aftermarket unit of the M1 kind.
Now if we do that and we don't change any firmware, you'll have a Christmas tree on the dash and all the lights and stuff like that on there and basically our M1 firmware basically emulates the factory CAN messaging that the factory ECU would transmit to those other modules and keeps them all happy, basically makes them think that the factory ECU is in the car.
From a hardware perspective and actually figuring all of this stuff out.
What's involved?
What does the process look like from your standpoint?
What are you actually doing and how long's involved in doing a good job of reverse engineering, all of this.
So that really depends on the model of car.
So let's say, for example, 2008, where CAN bus was relatively new.
The process is generally, I would say, quite simple.
It maybe takes a day or two of reverse engineering, where we connect to the car with the factory ECU in it.
We start basically sniffing the messages that are in that car and then reverse engineering what they are so they come across as effectively unreadable data and we need to convert that into meaningful data.
Like I said, the older cars typically maybe one to two days to get those messages out.
Or the important messages, really modern ones like, say, for example, the modern ones like the A90 Supra and things like that.
They can take weeks of development time, maybe even months.
So let's talk about that A90 Supra because, off camera, you talked about the fact that you're pretty close to a solution for this and the first question I've got is the A90 Supra has been a very popular tuning platform and there are reflashing solutions available for it, so why would someone potentially want a MoTeC M1 or any other standalone ECU when it can currently be reflashed?
Yeah, so with reflashing, there is a certain level of power that you'll get away with with a reflash.
Now, modern ECUs are getting better and better at controlling engines and having safeties and all sorts of things like that, and flashing is also getting better.
However, at the end of the day, a lot of tuners use their aftermarket ECUs in all these cars and they don't want to learn a new platform.
Because, let's face it, learning a new platform is a big task and it can take for a tuner.
If you're doing one or two cars, that's a big ask on you.
You probably can't get that money back and we're trying to run a business.
I think the other thing that's worth mentioning there on that front is when we look at an aftermarket standalone ECU.
Within reason they're all the same.
Obviously there's different user interfaces, but they're generally operating on a speed density principle.
So you've got a fuel table that is going to be manifold pressure versus RPM, same with their ignition table.
So once you learn the interface, you can apply what you already know and tune it.
In the OE world everyone seems to have their own special ideas on which is the best way to control it, and particularly with some of these late model vehicles they are incredibly complex and, as you mentioned, the time involved in learning that is a difficult one to claw back.
Hard to charge a customer 20 or 30 hours for tuning one vehicle because you're learning the system correct.
That's exactly right, and I mean there is another big thing and that is with reflashing is that the definitions or the maps that you actually have access to as a tuner are someone's interpretation of what's actually inside that ECU.
The ECU manufacturer hasn't just given you open access to the ECU.
Someone's had to reverse engineer that data so it may not actually be super accurate.
And, on the same note, there, you may not have access to all of the maps.
Well, you almost certainly won't have access to all of the maps that are available.
They might be fine for a basic stage, one tune, where you've got maybe an intake and an exhaust, but once you start changing injectors, fitting bigger turbos, all of the rest that goes along with modified cars.
Sometimes you need access to parameters that you simply don't have access to.
Getting back to your task here with actually riding this firmware what's involved there?
Do you have to be an IT guru or a rocket scientist to do this?
How complex is this?
So I'm not going to say rocket scientist, because, let's face it, that's a pretty complicated job, but it's certainly not something that your average tuner would I would expect to be able to do.
So the M1 build environment uses a C-sharp or C-based development language, and what that means is that there's a whole heap of, let's say, code in there that is not necessarily easy to understand.
Now, my background is that I'm a software engineer by trade, and what that means is that that comes naturally to me.
So that's where I'm able to basically go in there and say, look, yeah, let's make this output, do this function with this table attached to it, and that all requires coding, so to speak, and that's not something that a normal, regular tuner just puts some numbers in and changing timing.
Fuel boost.
Very different skill set.
That's exactly right.
Yeah, I guess the question would be for the average enthusiast who doesn't have a computer science background, hasn't done any coding is this something that could be learned or is it a real layer of complexity and difficulty?
there.
I definitely think it's something that can be learned.
I'm a big advocate of soft learning and, let's face it, it's not rocket science.
Close, but not quite.
Yeah, something like that.
I mean, there is a lot of resources out there for free on the internet, though that would help people at least understand it.
The other benefit is that in the M1 build environment you can also look through the existing projects from MoTeC and kind of get a sense of, oh, this is how they did this.
And also, you don't necessarily have to write the entire firmware from scratch, do you?
You can use existing firmware and then add or subtract what you want to get the job done.
Yeah, absolutely so.
Motec provides you with a base GPA package and basically what that means is that that package will run your engine effectively.
If you want to make changes to that, then that's obviously on you, or if you want to make additions and other bits and pieces, that's on you as well.
But the basic fundamentals of running an engine has already been done for you and you don't have to do that from scratch.
In terms of how PowerTune work.
Obviously we just talked about this A90 Super project, which I can understand obviously a big market there, so I can understand that it's not probably too much of a punt to take, that you'll be able to sell these once you've finished.
But what about the customer that comes to you and wants something specific done for their project?
Do you do one off projects as well?
Yeah, we do.
We do one off projects.
However, obviously the cost of that we have to cover the cost of our labour.
So people, you know, if they come to us and say, look, I want a DCT firmware for a modern 8 speed BMW, I can say straight away, look, this is going to take a month of development or a round about that and you've got to be prepared to cover my time to reverse, engineer, write the firmware and create everything for that I mean that's fair.
time is money at the end of the day.
Look, it is a very powerful tool, a very powerful option and obviously the limits are really based on purely your imagination.
So thanks for giving us some insight into that.
And if people did want to reach out and maybe have power to do something custom and how they best to do so, so social media is fine, or email or phone us.
We're pretty much open to all methods of contact and feel free to reach out and ask any questions.
Perfect.
Thanks for your time, ryan.
Thanks, mate.
If you enjoyed this podcast, please feel free to leave a review on whatever platform you've chosen to listen to it on.
It goes a long way to help us getting the word out there.
All these conversations, and much more, are also available in full on our High Performance Academy YouTube channel, so make sure you subscribe.
It's a one stop shop when it comes to going faster, stopping quicker and cornering better.
Request an explanation for:
4 cars
4 cars featured
Request an Explanation
Heard something you'd like explained? We'll add it to this episode.
Sign in to request explanations for terms you heard.
Want to learn more?
Browse our glossary for plain-English explanations of automotive terms, jargon, and concepts.
See something that's not quite right? Our annotations are AI-generated and can sometimes miss the mark.
Click the flag icon on any annotation to suggest a correction.
