149: Cracking the CAN Code: Mastering Integration in Performance Builds

Yeah, I was trying to put it aftermarket engine management system on it, and everybody told me, you can't do it. It has a can bus. You're not going to figure it out. Challenge accepted. Yes, absolutely. Challenge accepted. Let's dig into this. And so it drugged down this rabbit hole. You know, I didn't know what can was in the grand scheme outside of the communication model from the get-go.

And in this episode, we're joined by Mitch Minton from Minton Performance. Mitch interestingly is actually one of the OG HPA members, and we've been friends with Mitch for about as long as HPA has been in existence. And it's been interesting watching Mitch's journey over those 12 or 13 years as he's really developed a passion for canned communication and really run off to the races with that in terms of what he's doing now with his business.

Anyone these days who's involved in performance aftermarket electronics would probably almost need some level of understanding of canned communications because it is such a powerful communication template in order to send and receive messages from different pieces of electronics. And what this means, it really unlocks our ability to now no longer be locked into the same brand for, let's say, an ECU, a dash, maybe a TCU.

Everything really communicates on a common protocol. And as long as we can understand that protocol and send and receive messages in the correct format, then we can mix and match our electronics components.

Now, one of the things that Mitch has done with canned communications is built his own canned gateway. He calls it his canned triple. And this is an interesting device because it really unlocks a lot of potential there.

Otherwise, we just wouldn't have. Mitch actually popped back on our radar after our interview with tuned by Sean. And the reason for this is that Sean and Mitch have partnered up to provide Haltech Elite Plug-in Play solutions for various late model cars.

One of these is the Z06 Corvette. Now traditionally, this would be impossible with the Haltech Elite because the canned communication template is locked down. It's not user definable.

And some of the other electronic components in the Corvette are expecting messages to be sent in a particular format. This is where the canned gateway comes in.

It can take the messages being sent from the Haltech, take those in and then send them out on the correct address and in the correct format for the other electronics in the Corvette system.

Now, I'll admit that this particular podcast episode does get a little bit nerdy at times but for those who are interested in letting more about canned is going to be an absolute gold mine of information in this episode.

Before we jump into our chat, for those who are new to the tuned in podcast, high performance academy is an online training school. We specialize in teaching people how to build performance engines, how to tune EFI, how to construct wiring harnesses.

We also cover topics on fabrication, 3D modeling and CAD, race driver education and data logging just to name a few.

You can find all of our courses at hpacademy.com forward slash courses. All of these courses are delivered in high definition video modules that you can watch from anywhere in the world provided you've got an internet connection.

This means you can learn from the comfort of your own place and you can learn at your own pace. All of our courses also come with a 60 day no questions asked money back guarantee.

So if you purchase them for any reason at all, decide it wasn't quite what you expected. No problem, let us know. We'll give you a full refund.

And for podcast listeners, you can also use the coupon code podcast 75. That will get you $75 off the purchase of your very first HPA course.

We'll put the coupon code in the show notes to make it nice and easy for you to find.

Lastly, if you like free stuff, then I've got a great deal for you. We are constantly partnering with some of the biggest names in the aftermarket performance industry to give away some great prizes.

You can always find our latest prize at hpacademy.com forward slash giveaway. It might be an aftermarket ECU or dash. It could be some engine components or engine building tools or just about anything in between.

They are great prizes and we will ship them free of charge to your door if you're the winner.

There's no tricks here. No purchase required to get your name into the drawer.

Alright, enough with our introduction. Let's get into our interview now.

Alright, welcome to the podcast. Much thanks for joining us. And as we always do, let's start by finding out about your background and specifically how you got interested in cars.

Yes. So thanks for having me on the show. It's a pleasure. Hopefully I can bring some value and entertainment to it.

Starting off, I guess the fast and the furious really is what sparked it when I was about 12 years old.

Before then, I didn't really have much of a fascination or interesting cars mainly because of my age. It was just more of the sports kid.

But after watching the fast and the furious, I thought cars were pretty cool and started wanting to learn a little bit more about them.

And from there, after getting turning 16, so to speak, it became sort of transportation.

So the next thing you want to know is how can you fix your car up to make it cooler? Like most every 16 year old kid, you know, you do all the wrong things to it.

Currently, I'm staring into my crystal bowl and on the back of the fast and the furious, I'm assuming there's maybe Hondas in the background somewhere.

Oh yeah, absolutely. My second car was actually 89 in court and it was it was carbureted. I didn't know anything about carburetors at the time.

And I was like, oh man, I can make this thing the fastest thing in the world. No, it didn't really have much option.

The great thing about the Honda world is the interchangeability of everything though. They are a pretty easy platform to go and buy.

The XYZ model and then upgrade it with B series or whatever it might be. So a lot of plug-and-play compatibility, which is nice.

Yeah. Once I kind of transitioned over to the Civic, so to speak, and the newer records, that was certainly what sparked the curiosity and fascination of how you can take this stock Honda and see cars in lane.

And he follows and see him making massive amounts of power on street fire at the time and say, oh, I can do that.

And start just digging down the rabbit hole of what swaps and what's interchangeable.

Yeah, that makes a lot of sense.

Okay. So you're building up your skillset and knowledge around the Honda platform and your mechanical skills at the same time.

Yeah. So I never could afford too, too much for parts or whatnot.

I ended up, if I wanted to fix it or modify it, I had to do it myself.

So I ended up, I had some issue at some point where I had a chip valve in one of the cylinder heads of my Civic at the time.

So I couldn't take it to a shop and they're going to charge me an astronomical amount at the time.

And I'm just a broke teenager.

So I had to learn how to fix it myself.

And so, you know, scary is all get out, you know, replacing a time of belt for the first time and things like that and getting in time.

But there was a few resources at the time that that helped me.

There's a guy Omni Power or Omni Man Steve, Steve Rothenbueller, I believe is his name, built a 200 horsepower in a B16 DVD.

I bought the DVD and you know, watched him rebuild this from the ground up.

It's a throwback.

I ended up, you know, figuring out how to fix the Civic and got it up and running and turned it into a little bit of a, you know, kind of like a teenage side hustle because there were quite a few cars that needed valve lashes as well as as well as, you know,

valetrain replacement because they had shipped valves as well.

So as a teenager, I made a little bit of a side hustle doing that and just kept growing on my knowledge base a little bit as a time.

So at this point, are you considering that cars, the career future for you, or are you still going on another path?

No, so I never looked at the automotive environment.

Everybody, when I was in high school, was like, oh, you really like cars, you should go to like NADC or the local, you know,

auto diesel college to learn, learn cars. And I was like, I really don't want to do that because, you know, a little bit ignorant at the time.

But I was like, why would I go to school to learn something I already understand and know at a decent level?

I was like, I just need to go into the field of anything.

And I was also more computer interested in computers and stuff and IT.

And once I graduated high school, I largely didn't have a plan.

I didn't go to college or anything like that, fresh out of high school.

You know, what I was going to do, I ended up just working at a local job here and there and doing, you know, just working on cars on the side,

making extra cash where I could and kept just kind of understanding how things work a little bit at a time.

Nothing too crazy there. I never actually went to college. I never followed in to go into a college or getting some type of collegiate degree at all.

So at what point did you sort of the penny drop to you figured out what the path forward was?

And how did you sort of continue to develop your skills with computers? I tell you programming et cetera.

So that's a big part obviously of what you're doing now.

I mean, I've always had a curious mindset. I never really stop asking myself questions.

It's a very double-edged sword because there'll be plenty of times at night where, you know, now, you know, the search engines are pretty capable of answering questions rather quickly.

You know, at the time, you know, if I didn't understand something, I would keep digging and not give up and just, you know, relentless research is essentially what I would do.

Which sometimes would be, you know, in the era forums, you would search and try to understand forums and see what people are saying on forums,

which sometimes could lead you down the wrong rabbit holes in certain aspects, but there's a lot of information out there that was disclosed.

So you took it all and made, you know, educated gas and sort of trying to understand things, you know, what's the next question you can ask to ask better questions to have a better understanding?

That never really stopped.

Yeah, it's going to say it doesn't stop. That is life now.

I think it's changed. The methods were used for research at a different back when I was building my drag car YouTube.

Where there wasn't a thing or was in its very infancy, you know, it was back to the days of forums, but as you mentioned, you know, you can put any information you like on a forum, doesn't make it right.

And I think there's sort of this implication that if it's out there as a written document, then it must be accurate, which is clearly just absolutely not the truth.

It's one of the reasons why HPA exists is to dilute all of the information, you know, you can learn how to tune a car if you want to put enough time into scrolling forums and YouTube videos.

But again, you've got to know enough to be able to decipher whether the information is accurate or complete garbage.

And yeah, when you're at the start of that, done in Kruger, sort of curve, it's difficult to know that.

And I think the same goes these days now, obviously, AI is another tool that's available, but the hallucinations it has are just outrageous.

So you can really get yourself in a lot of trouble if you just blind trust chat GPT, for example.

Yep, no, that's absolutely the case. I mean, I've seen a lot of people that will post like, you know, Oreo spelled backwards as Oreo to chat GPT and the GPT model and stuff.

It's definitely helped more than it's hindered, but you do have to give it a reality check every now and then.

And I feel that if you do ask chat GPT, hey, is this garbage you're supplying me?

It largely will respond back, you know what, you're right. Like I've had to do it a few times myself on, hey, I'm trying to solve XYZ problem.

And here's the methods I'm looking at approaching, and it'll tell you, hey, this is, you know, you need to go this route.

I'm like, hey, that doesn't sound right. I want you to reevaluate what I'm saying.

And make sure you double check, double check your work, I guess.

Yeah, I think that's exactly right. I mean, when it can tell you, when you challenge it, like, hey, no, that was, yeah, I got that wrong.

Well, if you know you got it wrong now, why don't you know you got it wrong before I asked you if you got it wrong. Just give me the correct information.

You obviously have it there. But yeah, probably oversimplifying what is a very complicated complicated model.

I don't even pretend to know what's going on in the background, but the fact that it is so powerful and innocent, see, does make you wonder what that's going to look like in another five years time.

Absolutely. However, I digress. Let's get this train back on the tracks.

So I would give us a abbreviated view of your work history and what you've done to bring us up to speed to current day.

So out of high school, I just work, you know, normal jobs. I eventually got a job at a factory.

Nothing largely related to the automotive field because I didn't want to also get burnt out because I noticed a lot of people that would, you know, go and work at a dealership or, you know, automotive environment.

They largely grew to load the atmosphere. So if they wanted to work on their cars and enjoyed it, they would get burnt out relatively quickly.

I can confirm that is a real thing. I was actually talking to someone earlier today about this back when I was running my old shop and building my drag car.

And after spending 40 to 50 hours during the week working on customers' cars and then in the nights and in the weekends, I'm sort of spending about the same amount of time again trying to get a drag car built or fixed or whatever it was.

After six or seven years of that, you sort of were thin. And I did find for the longest time that I just lost that passion for working on my own car, which is now nice.

I keep to step away from that. So that passion comes back.

Yeah, absolutely. Yeah, I knew that that would be the case if I tried to jump into the automotive workforce. So I didn't do that.

If I wanted to go to a job, I hated. I wanted to make sure it wasn't in the automotive.

Which I did for quite some time. I eventually got a job building tires at a factory. And this is where I started digging into essentially your courses and courses all across the country that I could take.

I've basically went to every automotive training seminar for the automotive act for market that I could.

So anything that was offered on the East Coast at all, I've basically taken.

And that helped that helped, I guess, drive home the model of understanding that it's, you know, engines are subject to laws of physics and everything that is going on is associated with physics in some regard.

So there is no there is no magic. So it's like just peeling back the veil of the secrecy of things and just starting to understand a more and more.

I just kept digging into it and I never really stopped.

Yeah, okay.

Yeah, you were, I think actually one of our fairly early adopters of our courses. Do you have an idea of kind of what year that was?

I think it was 2014, 2015.

Yeah, okay. So we're circling years ago now.

Yeah. Okay. And can you, I don't want to, this isn't a paid ad for HBO, but just we don't get to talk to too many people on the podcast who have taken the courses.

I'm just interested if you could give us a high level view of what courses you took and how you found that information.

And then also if you can give us a comparison between how you found learning from an online platform versus in person training.

Yeah, absolutely. So the first course that I took was the wiring introduction in the beginners to wiring course.

At the time, it was Ryan Ryewire, which is what brought it into my light and understanding like, oh, okay, this has got to be a good course because it has Ryan on it.

Ryan's like this trademark at the Honda scene, it's definitely got to be great.

And it certainly was and I learned a lot from it and got a better understanding of ampacity and current limits and things like that based on wires and grounding and stuff.

And then I followed that one up with the traction understanding traction control model because I didn't understand enough at the time.

Granted, I didn't have a real, real need to because I didn't have a standalone engine management system or anything I could really play with traction control on.

But I was like, I just want to understand how, because in the drag race in the world, you know, your 60-foot is going to be a make it or break it in most circumstances.

So if you don't have a solid launch, you're not, you're not going to make it.

Okay. And just again, you know, that comparison between online learning versus in person.

I mean, obviously everyone learns differently.

Some people respond better to one method over the other I'm just interested in your personal takeaways.

So the online versus in person, the benefit of in-person training is you end up building relationships with, you know, the peers in the class as well.

And which is, you know, it's helped me, you know, develop better, you know, understandings on things because I can relay on them for stuff that wasn't directly talked about in the class as well because I've went to training with people that worked at drag diesel performance shops.

And so like the diesel stuff is still, you know, it's still outside of my realm of understanding.

But I was like, hey, like, how does this work with the diesel side and they could, you know, they could explain to me.

So I build related, you build relationships that you don't necessarily have online, but also the online space offers.

Typically, it's a whole lot better value when you're looking at it of education and knowledge per dollar, right?

Because the scalability of it, you know, you can only fit 30, 40, 50 people in a classroom and you can only handle, you know, handle those once a weekend.

So that's the best, right? Versus online, it did offer more value. So it's easier to take online courses over and over and over again. And that's, you know, largely, you know, I've subscribed to a lot of online educational and learning materials for that specific reason because you get a lot for for your money as well.

One of the benefits as I said as well is obviously taking a lot of in person training courses over the years on a huge range of different topics.

And you kind of go into a two day or like a weekend course, and you kind of get smashed with so much information.

And at the time, you sort of, you're retaining, you know, most, and then a week later, you're trying to remember everything and then two months later, I think it is nice with the way we operate our courses being able to just go back and review it once you buy the courses yours for life.

You know, I like to sort of suggest to people, hey, you take the course and then when you're actually on the dyno tuning and you're doing a particular task, you can go and rewatch, you know, a module on ignition time, where if you're ratio or whatever and really cement that knowledge and make sure that you're doing it right.

Yeah. So again, pros and cons of each method, obviously, this is the one that's worked for us. It's much easier for us to scale. There's only one of me.

It'd be very difficult to be flying around the world, hosting these in person. So I kind of really just wasn't an option.

One of the instructors said it best this weekend, you're going to be drinking through a fire hose of knowledge.

Yeah. Yeah. That's an excellent way of looking at it. I guess as well, like it depends on your current level of knowledge on whatever the particular topic happens to be.

If you're already semi-proficient, whether it's the fire hose might turn down to maybe more of a light stream, but yeah, when you are coming in fresh, and you're just going to be bombarded left right in center.

Absolutely.

So before we started recording, you mentioned that you also got involved in some sort of race engineering data analysis. So give us the rundown on how that all came to pass.

Yeah. So essentially, it's kind of odd, but I got a random message on Facebook. And the guy who lives in California and he told me to literally he said, can you meet me at a shop in your area on this date at this time?

That was his question. Hey, I've got work for you. Can you meet me at this shop? And you know, I'm looking at him. He seems that he's race oriented. He's like, I got to work on a race car that I want to see if you can solve a problem for us of senior skill set.

And I'm curious to see if you can answer a question for us. So I said, yeah, and I show up. I end up showing up at this shop. This is mid 2018 era.

I end up going there and walk in and they have an Audi R8 GT3. And the guy asks, I need you to find oil pressure on this car. We don't have access to all of the equipment. The Bosch data loggers locked and we can't infiltrate it. We can't log into it. We don't have the tools to do that.

But we believe oil pressure is on that car. And we want you to find it so we can add it to our MoTec dash. That's an ancillary dash in the car.

You would certainly hope that oil pressure existed and an R8 GT3.

You would hope. Unfortunately, I went through like essentially a line by line analysis and told him, I don't believe it's here. Wow. And we did, we did a case study. And I was like, here's all right. So we have to basically model it.

Cars cold. I want to log all the messages cold and analyze, you know, a value a signal that was high at start that was, you know, basically off when the engine was off started high once we started the engine.

Once it warmed up tapered off and down. And then that would be one log and then another log we're going to have we're going to we're going to start it again. I expected to be low. I want you to roll slowly into the throttle. I expected to raise.

And I want you to roll out of the throttle. I expected to drop. And then I want you to stab just three times lightly see if we can see a small jump after analyzing all this information and spending, I don't know, two, two and a half, three hours there.

Just walking through all of the messages line by line. I basically, I don't think it's there. And the guy kind of caught a scoff me off like, well, you know, I thought you would be able to do it. But, you know, whatever.

And so that was it. You know, I didn't, you know, hurt my ego. I felt concise that it was not there. And I got a call about three weeks later. And he said, hey, we were able to log into the bush.

You know, logger that has the oil pressure sensor on it. And you were right. And it's impressive that you were able to tell me that it wasn't there.

All right. So let's just sort of break this down because this could be quite confusing for a lot of people. So first of all, I'm assuming here you're talking about and logging all of the can messages that are being sent from the engine control unit to the Bosch data logger. That's correct.

Okay. So on that basis, if it's still, if it actually does have oil pressure, I'm assuming that that was a direct wired sensor for oil pressure direct to the dash as opposed to the EC and then being transmitted via can message that is that how that works. That is exactly how it was work.

Because I was starting to get really worried that this eight nine hundred thousand dollar GT3 race car didn't have oil pressure monitoring because that would be scary.

It was there. It just wasn't it wasn't actually transmitting on the specific bus that they said that it would be on going to the motor.

Okay. Well, it's always nice to kind of have that backup that you were right when you start question yourself to absolutely. Yeah. And especially in a circumstance like that, it's like, I, you know, I didn't have any, you know, like skill set or like there was no like, oh, yeah, this guy's done a lot of work.

You know, elsewhere, it was just, hey, this guy's in the area. Let's give him a try.

But a bit of a side quest here that if you're sort of not running a shop and you're not that well known, how did these guys actually find you and know that you kind of had this skill set.

So I'm pretty vocal on Facebook for sometimes for good and bad reasons, but mostly for good.

I ended up posting a lot of my, you know, explanations and videos on Facebook and YouTube and explaining how to analyze, you know, Canvas messages in certain regards on YouTube.

Those videos are quite dated now. But at the time, you know, I was like, hey, this is how this works at, you know, I was kind of at the little bit of the Dunning bottom of the Dunning crew real in some regards.

But hey, there's all these messages and these messages come through. And if I, you know, if I press the gas pedal RPMs increase and you see these digits go up from left, you know, from left to right here.

And yeah. And so, you know, did I understand it a little bit deeper? I did, but I was, I wasn't the most best communicator at it.

But at the same time, it was certainly a new era of information. And, you know, I wasn't as adept as I would be now, so to speak.

Obviously, these skills do continue to develop and the more you do, the better you get it.

All right. So that was sort of a bit of a hit and a miss on that one, but no fault of your own.

How did that continue to get into doing this data engineering race engineering?

So COVID hit, once COVID hit, every, you know, largely the whole country shut down for about three months. So racing wasn't going on for three months.

And I can't say for exact, but I do know that most of the racing sanctions, you have MSA, you have SRO, you have TransAm, NASCAR's in its own little world.

They don't really care what everybody else is doing anyways. But your SRO and your MSA, your MSA races, they typically aren't going to fall on the same weekend.

And TransAm tries to do the same thing as well, because largely you'll see a lot of overlap between MSA teams, SRO teams and TransAm teams trying to run on different weekends.

So one weekend will be SRO, the next weekend will be MSA, the next weekend will be TransAm and they may have a week off.

And so once the schedules got shifted and moved around, they were all overlapping each other.

They couldn't, you couldn't make both events. So all of these racing teams were sitting there having to make, you know, choices on what events they're going to go to, because now they have so much overlap.

So the guy that had called me worked as a race, he worked as a data engineer and DAG, so to speak, for this team that I had showed up for for this Audi R8.

And so they actually reached out to me and said, hey, we can't get the guy that contacted you to come in here.

You seem like you know your stuff. You've taken all this training. Do you think you can make, you think you can make something out?

We were taking the risk and we want to see if you're able to, you know, meet our needs. And so I said, sure, yeah, why not? It's worth doing. I like cars, let's go.

Yeah, just sort of differently jumping in at the upper echelon towards the upper echelon of data analysis as well, working at GT3 team.

Yeah, yeah, it was largely a jump into the lion's den, right?

And the colleagues that I was working with, I mean, there's some pretty stout resumes from Porsche Motorsports director for 30 years to Corvette Racing Director for 28 years.

That I'm working side by side with as this time progresses. But yeah, it was quite interesting once I had jumped in because, you know, my background wasn't a padded resume of all of this racing experience.

It was largely none. I was just, I understand this data really well.

Yeah, sure. I'm interested with that particular car. You mentioned that it has the Bosch factory-fitted data logger. And then they had fitted this, this auxiliary motor unit. So what was the drive behind doing that?

They're not versed with Bosch or what? Yeah, it was.

I think it was a little bit of not a depth with Bosch. The car had came with a secondary logger. They've added an ADL-3.

And I think it was equipped originally with a DDU-8. So they wanted more sensors and the ADL-3 had the sensors to equip more information.

They added the ADL-3, and they used the ADL-3 as their base data logger, and they didn't really work with the Bosch DDU-8.

Which worked in my favor because I had taken Motech's training to understand, you know, data analysis within the Motech systems.

It also had a racelogic V-Box HD2, which was brand new to me at this time, and I had to actually troubleshoot why we were getting lap times only half of the time.

Ended up being that the auto track map was picking the wrong track and the wrong layout, and we were never going through the start finish line once it chose the incorrect track.

Well, I'm interested why not just to your lap timing within the Motech.

So it does bring a good point. The data analysis with Motech or with the Motech dash would certainly be more beneficial.

The V-Box, the racelogic V-Box HD2, it had basically two channels of video associated with it.

So if they're wondering what's going on on track, we could see out the front and look at the driver to see what the driver input is.

So we had one camera going out the front windshield and one camera facing almost directly on the driver to see what his hand position is, where his feet are to give him feedback and clue them in on where lap time could be improved.

Yeah, fair point. It's quite often you look at data without video and a particular lap will be slow in one sector and you're thinking yourself, why are you on the brakes here?

And then you talk to the driver and the reason he was on the brakes there is so that he didn't hit the car in front of him that's running slowly for whatever reason.

So yeah, video definitely does give you just that extra extra dimension of understanding the data so now we've got a comforted with three separate data synthesis essentially.

Yeah, absolutely. Yeah, I mean, we had live telemetry as well when the guy, his name is Brad would show up with us too, he would put telemetry on the car so we could watch the V-Box video in pits to understand what's going on in the car as well.

Wild, how do you find it is to adapt between different systems that say the V-Box and the MoTick, for example?

I mean, largely I tell people it's experienced driven. I will tell everybody no matter what system you use, learn the hot keys and learn how to learn how to utilize them as efficiently as you can.

Anybody that's done any level of tuning probably understands that quite well getting through data efficiently and effectively using hot keys is it'll almost separate you from struggling.

I also tell people to make sure your workspaces are set up, make sure you know, make sure everything set up the way you would like it or the way the driver would like it way, it should be before you get to the track.

I'm not chasing your tail a little bit on how to get more information that they're looking for on the video overlay perhaps or on the data page that they're looking in the data analysis system.

Yeah, I think setting up your worksheets for a particular task is really important. So for example, I'll have one for engine and that's just got the engine vitals and then maybe another one that's going to dig a lot deeper into fueling in more detail.

Then another one for chassis and driver performance so we can focus on what we want to look at and it would be generally with a developed race car other than a cursory glance over engine vitals.

We're probably not doing any sort of down in the weeds tuning. It's more really about is the engine going to start and run for the next session or all of the con rods currently hanging out the side of the block.

Optimizing the camera on the front right is probably not that important. It just doesn't matter anymore.

The other thing I find really important with analyzing large chunks of data quickly so we can sort of see trends or you know,

potential problems without having to go through every lap is using channel reports so we can sort of see minimum maximum values for let's say oil pressure,

oil temperature, engine coolant temperature and yeah minimum maximum average and kind of at a glance.

Yeah, the sort of as a go-no go. Yeah, it's these are all within and bounds that I'm happy with cook we don't need to look at those anymore.

So that that takes what could be several minutes of work into something that's literally a few seconds glance.

Is that something you also utilize?

Yeah, absolutely. In fact my worksheets were largely set up.

There was a group of about five people that would question, you know, ask questions in the post session like, hey,

well, how, you know, what was a coolant engine guy wants to know engine vitals gearbox guy wants to know gearbox vitals suspension guy wants

to look at histograms things of all these all these things just overlaying on top each other and as soon as we pull the car in,

they all want to know the answers first, right?

So it was a little bit of a challenge at first to have to have an understanding but as time went on,

I eventually set up pages for each individual person to say, hey, like, here's your gearbox page.

And I actually labeled them all to their names so they don't have to question which, which, you know, tab to, tab to click on.

And it works, it works beautifully because if they needed something, I left my laptop on the, on the workstation and, you know,

just take yourself out of the equation.

Absolutely. I just, I get the data. I set it up. I let the laptop run and I'll let them fight for the mouse.

If you're a fan of the podcast and you're interested in topics like engine tuning, automotive wiring, performance engine building,

3D modeling and CAD, or anything else in the high performance industry, I have something that you might be interested in.

Introducing the high performance academy VIP package.

This package of courses gives you lifetime access to all of HPA's online training for one price.

These courses cover everything from tuning and reflashing petrol and diesel engines through to motorsport wiring,

engine building, fabrication, design, car setup and plenty more.

Right now, you can get $500 off high performance academies VIP package using the code podcast500 at checkout.

But coming at VIP means you'll never pay for another course again.

You'll get instant access to all 40 plus courses we currently offer, plus every new course we ever release in the future.

Want to define maps or tune with Winnoe Alice? Curious about Canvas devices?

Or how CAD can help make your dream build a reality?

These in-depth topics, as well as many others, each have their own dedicated course that are going to help you master whatever it is you want to learn.

And as a VIP member, you're not just getting the courses.

You'll also join HPA's online community with lifetime access to our member forums and members webinar lessons.

Again, the code is podcast500 for that $500 discount.

Just head over to hpcademy.com to check out the full VIP package and everything it contains.

Alright, let's get back to the episode.

How did this all play out? Obviously, you're not doing that task anymore.

So, you know, it took us about how that all played out and how far you got through it.

And why I guess it came to an end?

Yeah, so essentially I did it for about three and a half years.

When teams change ownership and change people, you're going to have essentially a revolving door in some regards

to once the name changes, once the entity changes, once the crew changes, things like that.

They're going to want different people that they're more comfortable with in the position.

So I ended up mid-season getting essentially exited or terminated from one season and then tried to fill it in a little bit.

And work was two sparse mid-season, so I ended up going back to a full-time job locally.

I was doing a little bit of hybrid work as well.

Like Bridgestone where I was working had a work schedule that you work seven out of every 14 days.

So what I would do is just stack my seven days together and then have seven off so to speak to go work on the racing stuff.

So I had this stability of a full-time job.

But flexibility as well.

Yeah, and it worked out pretty well.

I eventually tried to walk away from it because I wasn't in agreement with where Bridgestone and the company was taking the building and all the workforce there.

Anyways, they were driving it into the ground a little bit and unfortunately it shut down here recently.

But I can see the writing on the wall that it wasn't going to exist and I wanted to take a leap of faith.

The leap of faith didn't work out that well because the so sparse work, how sparse the work was, it was a little bit of a challenge.

So I ended up just jumping back into the local workforce, ended up in the automotive field finally.

Oh, there we go.

That's the connection.

And what does that current position actually look like for you?

So I do mobile diagnostics and programming for a lot of body shops and repair facilities.

We'll get calls. I'll work for a firm. We get calls when they just give up on a car almost.

If they want, if they don't want to solve it or they've tried their efforts and they just can't figure it out, they'll call us.

We die. I get we address problems.

We do all the programming.

We have all the OE tools to program it from in the manners that the OE wants and sometimes needs.

And essentially get get cars calibrated and programmed.

Most of the body shops and some of the local repair shops.

Okay. Well, they're sort of going too far down the rabbit hole here.

Could you give us sort of a maybe a case study of what that actually looks like?

I mean, on face value, I'd think you crashed a car.

You know, you break some senses, break a headlight or something.

Great. You buy new parts, you put them on the car and the car goes again.

But with like model cars, that's not always the case.

No, unfortunately not. There's a handful of modules on most most cars.

Front radar sensors are probably the most common for for damages as well as blind spot monitors on the back cars.

So you're indicator on the far corner, you know, once your car gets crushed in the back end,

it probably isn't going to be stable or working or operable anymore.

And unfortunately, they're just not a plug and play affair.

It's not like you can just grab another one, another new one and put it on the car and they typically work.

Most of them have their own programming and configuration.

The OEMs want to probably use the same part on many systems.

But they say, hey, we want it to be applicable to this model and we expect it to be this configuration.

Yeah, so just coding it to the individual car that it's fitted to so that it knows what it's job is on that vehicle

as opposed to not the completely different vehicle it may also fit.

Yep, that's it.

And sometimes it's alignment and making sure that it's all in line.

So, you know, you're not when you're, you know, a lot of adaptive cruise control is on many vehicles.

And if it's not set up right, it's going to be looking at the car to the left or the car to the right and another lane.

And it could be in badly.

Yeah, and that's not going to be well.

It's not going to end well for most circumstances until they don't.

You want to make sure that they're squared up and centered up.

Yeah, yeah, okay.

All right, we've got that.

All right, let's sort of dive deeper into something we've touched on already,

which is can messages, which is I guess I call it one of your specialties.

I don't know if you'd call that your specialty, but I think that's why we've got you here anyway.

Let's crack into that.

I mean, can I think is something that scares a lot of people off when they're trying to communicate between different modules from different manufacturers

that are all communicating via a canvas.

But I think let's start at the high level in what is, what is can.

I'd typically explain to people that have never understood can.

Can is a wired CB radio.

So if you have a bunch of people on a CB radio and you try to talk while somebody else is talking,

you're not going to get through because they are already are speaking.

And that's essentially how I explain can to anybody that doesn't have any knowledge based on the topic.

It's essentially a, it's a communication model that a lot of manufacturers use.

It's pretty easy to work with.

It's cheap.

It's super effective and it has enough bandwidth to get most of your information through without issue.

Okay.

So with, it's a communication protocol that our manufacturers are using to send data or messages between different modules within a car,

which is obviously our area of interest here.

That's a reason why I've explained it.

So it's the wired CB radio.

So the wired part is important.

Talk about the physical bus itself.

What is that consist of?

So it consists of typically two wires.

You're going to have a can high and a can low wire.

Those, those will run to each individual node, almost in a hopscotch fashion.

They call it a bus topology, but you can, you can run it hopscotch and from point to point without issue.

And so at the end of both node or the end of this network, you're going to want to 120-ohm terminating resistors

to essentially say, hey, these are the ends of the network.

So you have the end of the network on one side, end of the network on the other side.

And that's what helps essentially the robust nature and how effective the network works.

Those terminating resistors as well, these can absolutely make or break the network.

I've probably lost count of how many times I've encountered canvas issues

and it has come down to a terminating resistor problem.

As you mentioned, there's a 120-ohm resistor.

Sometimes we're physically adding a resistor across the can high and can low wires.

But other times, a lot of the nodes or modules that we use now have either switchable hardware,

switchable, terminating resistors are even switchable and software.

So you can get yourself into a situation where you think you've only got the terminating resistor

at each end of the bus, but one or more of your modules that are on the bus

actually also are introducing 120-ohm resistor.

So that kind of brings the whole bus down, right?

It doesn't have to bring the whole bus down.

If I have to err on the side of caution, I always tell people,

if you have more than two, if you have one in the middle somewhere,

chances are you're going to be all right.

Now with that being said, if you ask the SAE standard, the ISO standard,

they're going to tell you all bets are off.

But essentially, I've played with enough of each network topology.

It's going to be based on a handful of factors.

The biggest factor is how many nodes are on your bus and how long that total bus is.

And then the third one is essentially how long are the branches off of this network?

If you're not hopscotching and running a hopscotch fashion.

If you have these tree branches that are super long, you can have issues.

It's ultimately always a challenge if you don't have enough terminating resistors.

So if you're testing something that's two feet away, you can sometimes get away with zero.

You don't have to have any termination resistors.

And you go, okay, it works fine.

And then you put it in a car.

And if you have no terminating resistors, all bets are off.

It just does not want to work.

I think the generally accepted role as a few buses under two meters long,

you can get away with a terminating resistor at just one end of the bus.

And I think then the other one is if you're running a truck style bus with the nodes coming off it,

I think the recommendation is that the run from the central bus out to each of the nodes should be 500 millimeters or less.

That sounds accurate.

I tell people if you can keep them under a foot, you're good.

Now me, I'm quite lazy in the circumstances on most of my test models.

I'll test things and say, hey, I can make a lot of things work that you probably shouldn't.

I've had 12 devices on a bus that's essentially hopscotch and through and each branch is close to three, four feet long.

No problem.

But it's also not being put into an application in a critical nature.

It is only on a bench.

But you can get away with a lot.

But I tell people, how far do you want to figure out what you can get away with before problems arise?

Well, that's the thing.

And particularly if you're incorporating a can bus into a pretty complex wiring harness

and more so, if that wiring harness is a sealed harness with DR25, let's call it a race spec or a mill spec harness,

it's very difficult to come back from that if you've got a problem.

So there are industry best practice standards for how to construct a wiring harness, a can bus I should say.

So let's absolutely do that.

And then if we find that we've got problems where you can rest easy knowing that it's not because of the way you laid out the bus itself.

But you're right.

I think there's the industry best practice standards and then there's a lot of leeway which will still work, but maybe not.

So I like to not have that hanging over my head.

Will it work? I don't know.

I tell people if they're if they're working on a mock up and they want to see if it works.

Just try it.

But understand that there's a there's a spec for a reason.

Definitely.

Yeah.

All right. So we haven't also touched on the fact that the two wires, the canhion canlow are twisted.

What's the what's the purpose with the twist?

So the twist is to basically increases the shielding nature of it.

A lot of you know your ethernet cables are twisted for the same reason.

It prevents EMI from being able to inject itself as much.

To twist per inch is the standard, I believe.

Yeah. Again, I feel that sounds about right.

You sort of get to a point you do the stuff all the time and you don't need you're not sort of going back and checking the standards.

So for those listening and we say 500 millimeters, I think, you know, that's not something I'm probably looking up every time.

And as well, the two to twist per 50 mil, you know, yeah, give a give a take.

You sort of I tell people keep it between your wrist and your elbow and you'll be all right.

Yeah. So at your branch link.

Yeah.

Okay.

Cool.

What if we were to actually scope the canhion canlow wires.

What are we going to see in terms of what what the voltages look like?

The signals look like.

So you're going to see essentially two and a half volts at dormant for both canhion canlow.

So if you have no traffic on your network, you'll just see this like you'll see canhion high sit at two and a half volts and can

low also sitting somewhere around to an at volts.

It's not exact, but it's close enough.

Once you have a dominant bit, you'll see it drive drive up to three and a half volts on canhion drop down to one and a half volts on can

low.

There's a little bit of discretion there, especially there, there's this thing called an act flag that happens on the network.

You'll see a little bit of ringing on that.

So you'll see a spike at one point in the message most likely if you were to put out an oscilloscope on it and see all the act flags dropping at the same time.

So they create a little bit of a ringing nature on the act on the act flag.

But outside that, you're just going to see you're going to see two and a half volts plus or minus one volt based on canhion canlow.

Okay.

Why if they're sort of moving in different directions that almost sounds like we could get away with just a single wire.

So the purpose of the voltage is moving in opposite directions from that dormant to an a half volts give a take.

So it's essentially it's a differential signal protocol and they can look at each other and there's basically a comparator circuit that determines if it is high and low.

So if you take one of one of the signals and you know, essentially pull it off, it may work.

It may not.

I wouldn't recommend it.

But you can you can essentially run a single wire.

It's called single wire can.

You can run a single wire and run it up to about 250 kilobits per second.

It's much it's a much lower bandwidth than you would have with conventional can.

But I'm sure it will.

Yeah.

Obviously it's not something I'm recommending just sort of getting the full picture on that.

So we've sort of mentioned length and number of nodes and just again to to clear that term up any module that we're placing onto the bus is technically referred to as a node.

So that might be an ECU.

It might be a power distribution module.

Maybe a can keep had or anything else that you can imagine is there are a technical limit to the number of nodes or the bus length.

There is a limit spec for 40 nodes per network.

And that's what I would say if you realistically if you've got more than 40 nodes, I've got more questions for you on why they're all on the same bus to be honest.

I wouldn't recommend putting 40 nodes on a network.

I would try to keep it, you know, sub 20 to be honest.

But yeah, 40 nodes per network total branch length I think was 40 or total network length.

I believe is 40 meters on a one megabit bus.

I'd have to look at the specs.

That's close enough.

We don't need to get to down in the details with it, but there are thereabouts.

And I mean, obviously that's enough to loop around your car a few times.

So not something that's going to be a problem for an automotive application, right?

Correct.

Okay.

Let's talk about I guess the benefit of can.

So it's an already protocol and they use it so that there's a central bus or often multiple buses.

And all of these devices can talk backwards and forwards on this two-wire bus or multiple two-wire buses.

As opposed to each individual module in the vehicle needing multiple wires going to the different computers or whatever it needs to talk to.

So that first point I would say is it simplifies the wiring harness design greatly.

Yes it absolutely does.

Like for instance, if you if you wanted oil pressure, you know, from your car, right?

If your dash needed it to show you oil pressure as well as the engine and transmission body control modules,

anything that wants to say, hey, we've got a problem here and we have a redundant check.

We're going to say that there's a problem, right?

Any sensor that needs to be communicated in any manner across that network, you now don't have a physical wire attaching, you know, that sensor to that physical device.

So there's a lot of redundancy associated in the networks on OE applications, but you'll you'll end up finding that if you have an issue with one sensor,

you might have seven nodes tell you you have a problem with that sensor because they say, hey, we are not happy with that sensor.

They're relying on that information.

Yeah, signal implausible and now I don't know what to do with it.

So if I can't determine how much airflow is going into the engine, the engine controller can't determine how much torque it's making.

The transmission controller don't know how much pressure to run, things like that.

A really simple example of that simplification of the wiring is these can keypads that are pretty commonplace,

Blink Marine and Greyhill would probably be the two dominant ones that we see.

So they can be, let's say, a 15 key pad in each can have three states, three states, four states, I think, maybe.

Three states.

Three states, okay.

And you traditionally do that with the 15 switches, that's a lot of wires that you're going to have to run to your device, dash, ECU, PDM, whatever that may be.

Now we're down to four wires, can high and low, 12-volt and a ground.

So dramatically simplifies that wiring, which I think just as well as the OE world makes our life a lot easier in the aftermarket world as well.

The other aspect that I've seen is a real benefit in what I leverage highly though is because this can protocol is standardized

and these aftermarket, ECU, aftermarket electronics manufacturers have adopted it.

Now we've got the flexibility to run, let's say, a MoTeq ECU with maybe an ECU master PDM or PMU.

Maybe we want, you know, I don't know, maybe an MTROM dash and, you know, you can mix and match all of these units and it just works well seamlessly.

Yep, it's the benefit.

It's a fairly agnostic protocol.

So it doesn't require you to have proprietary, oh, you have this information, this dash where you have to have this and we're running it all via can.

That's usually not the case.

Now there is some constraints and limitations associated with the standard in some regard.

Some people do a little things a little bit differently.

But for the most part, yeah, you can take information on, you know, various applications or from various manufacturers and make them all coexist on the same bus.

It's purely awesome.

I'll do a lot for people doing OE integration solutions as well as trying to do retrofitting of OE sensors.

Right, so like how many cars, you know, have a factory IMU in them?

Well, most of them do because they typically are running it to control the analog braking system on any newer application.

And even then they're on motorcycles to have willy control.

So it's like, okay, let's find these sensors used and see what we can get because, you know, if you want to buy one new, they're, you know, IMU from Bosch is what?

5, 6, 700 dollars?

How much is one on eBay?

40, 50, 60?

So let's see if we can start integrating some hardware that we can find that's, you know, not broken, but it's not, it's just used and see if I can make something out of it and do a little bit, you know, kind of keep the cost down a little bit associated with integrating some hardware into a project.

I think for a lot of people, the sort of where we're going to go with this conversation about getting down in the woods with actually decoding can and what makes up a can message is going to go over a lot of people's heads.

And I think that that's absolutely fine.

When we're talking about integrating different aftermarket electronic components, the benefit is that these manufacturers know that it's in their, in their best interest to make their product compatible with the widest market possible.

So for a lot of these products, let's say, dash versus ECU, for example, most ECUs will have a canned template that you can just select that sends out a generic data stream of RPM throttle position, call and temperature, everything that you would need to display on a dash.

And then you take your dash that's from a different manufacturer and you select the template for, you know, motech, link, how tech, whatever the ECU is, it just decodes all of that data. There's no heavy lifting.

We don't need to actually know about can in order to make those two components work. That's not always the case. But in the most part, I think that's everyone's trying to make their product as compatible as they can.

Let's get a little bit more into what a can message actually looks like. So can you give us sort of a rundown on that?

This is going to be a little difficult as well without the benefit of some sort of visual cues, but you know, do you best?

Yeah, no worries. It's essentially I tell people there's two parts of the message that matter. You have your arbitration ID and you have your data.

There is a data length packet and there's some other things that help the network work, but none of those are really too important.

Essentially the arbitration ID is your message address. It's essentially the same thing like your physical address for your house. It needs to know it is a number to tell you where you are on that street.

And each node doesn't have just one of those. It can it can have as many as it needs in order to communicate information.

And then the data packet has your information that it is being supplied for that information for that address.

So if you have essentially an address that is from the ECU, you may have engine speed, throttle position, coolant temperature.

Thousands of others, yeah, potentially.

But yeah, it essentially the address is typically stay static for the information so that you don't see it like, oh, the address was, you know, one, two, three for this information.

And now it's four, five, six, once time has passed. That's usually not the case.

We know that if we're looking for throttle position information from the ECU, that is going to be on a specific address and it's always going to be on that specific address.

That's correct.

So the data though, it's not just limited to let's say sending out throttle position on a given address.

We can incorporate more data than just one message.

Yeah, you can incorporate essentially as many messages you need now that has a limit.

If you're talking a maximum data rate that can has, it's one megabit.

You can essentially fit almost 8,000 messages on that bus at a full payload, which is eight bytes that is essentially eight numbers between 0 and 255 and decimal that we can supply 8,000 times a second.

And that is for every device on that network total, and that would be the total bandwidth.

I think what I was getting at more there is let's say we've got a specific address.

So each of those addresses has can transmit eight bytes or contain eight bytes of data. That's correct.

Okay.

So within that, we can choose to send multiple pieces of information across those eight bytes.

So for example, we might split that into two byte messages.

We might send RPM as a two byte message, we might send call and temperature as another two byte message, et cetera, until we're fused up those eight bytes.

So you can have more data in that one address is what I was kind of getting at correct.

Yeah, that's absolutely correct.

You can have, essentially, I tell people, you can have up to 64 on-off states in each message.

That's another point.

We might be talking about a status flag for something, maybe as the fan on or off, so that can be a single bit of data.

That's correct.

Yeah, you can fit 64 on-off states on a single message.

If we have messages that don't require a lot of resolution, I'll use a coolant temp.

Our coolant temp only needs essentially one byte for it to run because we're not really running it in a spectrum that's super wide.

And typically, we're going to run it in a Celsius format.

So we can say that the minimum number is, let's say, negative 40 and the maximum value would be 215.

Well, that would fit in one byte.

And that's all it would take is one byte.

And now we have seven left to do whatever else we need to do.

But if you have something like engine speed, you're going to need more space because the step point you're going to use is going to be greater than that 255.

You know, 255 steps you have per byte.

So engine RPM, I don't know how many steps you really want.

But if you want your steps to be one RPM equals one bit, you're going to need probably 12 bits to get get everything taken care of on most applications.

And then if you just round it off, you just take it to two bytes, which is 16 bits.

So to sort of demonstrate this quickly because I know this can get really confusing really quickly, I just actually prepped a couple of examples of exactly this.

So the resolution that we need for a particular signal versus how we would decide to send that data.

So kind of slightly different to what you've just said there.

Let's say we've already talked about the fact that one byte is zero to 255.

So that's our maximum range.

So the example I used here was throttle position.

Obviously goes from zero to 100.

So if we're going to send that out over one byte, we'd basically divide our range of our throttle position.

Which is 100 by the maximum number of our single byte, 255.

And if we do that, we find that rounding each step, the resolution, each time we step up our throttle position is going to be 0.4%

which is probably for most instances going to be just fine.

But if we look at a signal that's going a wider span than just zero to 100 and an RPM, the one that you used, and I also used this,

let's say we need to span from zero to 8000 RPM.

So if we use the same little example there, divide our 8000 maximum by 255.

And that gives us each increment, each step is going to be 31 RPM.

Probably for some cases, that's going to also be just fine.

But for others, that might be a little bit coarse.

So then if we go from one byte to two bytes instead of our maximum value being 255,

we're now up to 65535. So it steps up really quickly.

And now if we do that same calculation there, 8000 divided by 65535, now we've got a step size of 0.1.

So hopefully that just demonstrates how the resolution we want versus how the information is encoded as important.

And if we look at something with a lot of resolution required GPS, for example,

if you're looking at your latitude and longitudinal GPS coordinates, those are huge numbers.

So those are typically going to be encoded over four bytes to give us the resolution.

We need otherwise the data's not really useful.

Yeah, your step points will be way too big.

It'll show you essentially in one state and then your next step will be next state over province over.

Yeah, yeah.

Now I don't think we need to go too much further into bits and bytes.

Hopefully that's enough just understanding that essentially one byte is 8 bits.

Each of the bits has the ability to be either 0 or 1 on or off.

So if we go from all of them off, that 0 decimal, all of them on that's 255.

And that's how the byte works and how our information gets sent.

Now how about negative values? How do we deal with negative values?

So essentially, there's two ways you can deal with negative values.

There's a sign bit, which is if you're sending a 1 byte value, it's going to be your most significant bit.

That most significant bit will be your negative flag.

And then the other seven bits will be your actual value.

So when we're decoding that, we look at whether that's that status flag for the negative is on or off.

And that will tell us whether it's a positive for a negative number.

Yeah, and you have to count backwards by doing so.

So for instance, if you have a value of 0 in a 1 byte message, you would have a bunch of bits being 0, 0, 0, 0, 0, 0, 0.

But if you have negative 1, you would have 1, 1, 1, 1, 1, 1, 1.

And the first, the most significant bit, that first bit, is your flag to say, hey, it's negative.

And then you have to count backwards, basically, from 0 to figure out where you're going.

So all the values essentially roll over, like it's a scoreboard going to 999, and you go backwards.

So negative 1 would be 999 on the scoreboard, negative 2 would be 998.

Things like that, if you were looking at it in a decimal form.

Okay, so that's very different to just flipping that status bit on or off and the number flips from positive to negative.

The whole number has to change.

That's correct.

All right, so that's one way, how else can we represent negative values?

I typically, you can also offset them.

So essentially, if you offset a value, you can say, hey, we'll say our 0 is realistically, let's say, negative 40, right?

Or negative 100.

So it says your temperature example before.

Right, yeah, so you just say, okay, set 0 is negative 40, because we offset it by a value of negative 40.

And let's just start incrementing from there.

So if we have a value of, you know, a raw value of 40, we really have an actual value of 0.

Yeah, yeah, okay.

Now this sort of brings us into how the data is actually coded and decoded, because you're not, if you're sending coolant temperature, for example, for that very reason.

You're looking at the data, it's not going to read, you know, 82 degrees C, for example, it's going to have that offset in it, but it's, you know, you're looking at hexadecimal values.

The example actually will probably be easier to come back to is our throttle position.

So obviously throttle position, we want to see 0 to 100%, that's what our brain is programmed with.

But what we already know from our little example there is that actually when that bite is a value of 255 decimal, that equates to 100%.

Now that's really easy. We're just divided out like we did and we know what we've got.

But, you know, when you start adding an offset in as well, that gets sort of a bit more complicated, and then we can also have multipliers and dividers.

So I guess for a start, why can't we just send the data and the raw numbers that we actually want to see?

It's a little bit on the computer science side, but essentially data types on, you know, and that the computer expects to see are, you know, they're not necessarily human readable information.

And it is encoded in a specific way that the computer understands it.

Now, as humans, we don't typically talk like computers or think like a computer for the most part.

There are some exceptions, I guess, for some people out there, but you're typically thinking, all right, almost all your values are going to be in decimal form.

We don't typically think binary. We typically, we don't typically think hex.

And that's a little bit of the challenge associated with, you know, kind of understanding or decoding this information in regards to

what the information is versus what the information is expected to be to a human.

All right, let's just come back again to my little throttle position example.

So generally when we've got a device that's allowed able to decode can messages, and we've got control over that.

As I mentioned, there will have maybe a multiplier divider, and we might have an offset or an adder.

So for the throttle position example, I don't really go through that in full detail.

So we know that value that we're seeing is 255, and we need to make that equal 100.

So how can we do that? Well, we divide it by 2.55, but generally we can't use decimals.

We're using integers, so we have to divide by 255, which is then going to give us a result of 1, which isn't what we want either.

But then we bring in a multiplier as well. So we're dividing by 255, multiplying by 100.

Now we've actually decoded that message, so 255 is going to represent on our screen as 100%.

We don't need an offset or an adder for that particular output, but obviously for a lot of them we do.

I want to go a little bit further into your process of actually decoding data, because hopefully that little example there is just showing that

it's not necessarily always straightforward.

And the first question I've got is, what hardware and software do we need to actually go about reverse engineering a canvas or sniffing a canvas as referred to?

Yeah, so you're going to need essentially, I want to say the easiest way is the candy USB adapter of some sort.

There's plenty of them on the market, anybody that's starting my recommendation is a peak pecan USB.

There's plenty of offerings and knockoffs on the market.

You're going to be challenged at some point with it operating with the knockoffs and things like that.

So I tell people, start with a known standard and the known standard is a peak pecan USB.

It's supported by many platforms and structures actually works with the ECU master hardware natively if you want to use it.

So you don't have to use the ECU master candy USB alongside with the peak pecan.

You don't have both of them in your toolbox. You can just use the peak pecan you don't have to worry.

But yeah, peak pecan USB with a pecan viewer software.

So you can analyze and log messages and create log files if you need to to review later.

So when we're looking at this data, again, when we're fresh to this, it's very confusing because we've got our addresses down the left hand side.

We've got 8 bytes of data.

Typically, we'll probably look at this in hexadecimal values.

And again, these are meaningless numbers.

We're not seeing our throttle position in our RPM.

So let's say you want to find oil pressure and let's assume this time that oil pressure does in fact exist on the canvas.

How would you isolate that out of what could be hundreds of not thousands of different messages?

Well, there's two ways to do it.

Looking at the data, when you know it would be changing.

So I always tell people, you want to be in control of if it possible, the men, the max, and the ability to change it.

Now, with oil pressure, it's kind of a challenge because you don't know, you don't have a starting point.

You have a starting point is zero.

So to speak, when the engine is not running for the most part, if the car is set there, you don't know a max, right?

Because you don't know how high it's going to go.

And you don't really have the ability to control how well it changes in a grand scheme.

Like you don't have direct control over oil pressure.

You have the ability to increase oil pressure by increasing RPM, which would effectively create more oil pressure.

But you don't have the ability to control it directly.

So you're going to take the note and go, okay, well, we're starting with zero, you know, starting with the engine off.

If we have data that's changing all over the place, while the engine's off, well, I can eliminate that as possibility, right?

That's not going to be it.

And then I'll go, okay, well, let's start the engine and see what's moving.

If the numbers are holding stable, if they're not moving wildly, once we have it warmed up and stuff,

okay, we have a possibility.

And from there, it becomes largely a crime scene to figure out, to plausibly exclude various bits of information.

It's not for the faint of heart, but you are able to do it.

It's not super challenging. It's methodical.

One of the ways just to add into that, that I go about that, and I admit, I don't do nearly as much as you,

with some of these signals you might be looking for, a real good place.

So I find this data is just unplug the sensor with the engine running.

And I mean, that might end up causing some unintended consequences.

Probably at idle, you're not going to do any damage to anything by doing this.

But you know, call in temperature, unplug the call in temperature sensor and see what piece of data,

what message actually changes.

And then plug it back in, does it come back?

Okay, that's going to allow you to probably quickly zero in on that particular sensor.

I'll do that with everything.

Obviously, if we're looking at messages going between maybe a TCU and an ECU, that's different as well.

The next obvious question, and you kind of reference this with the oil pressure sensor,

if you don't know what the value is supposed to be, how do we go about decoding it,

basically getting that multiplier divider and offset in order to turn that raw value into our oil pressure in PSI or bar.

Usually, I mean, I try to find any references I can, whether it's the dash,

you know, if it's an OE application, potentially a scan tool, if I'm working at information on a scan tool,

and it says, hey, like the oil pressure is at this value.

And I think I have it, so I'll increase, you know, do something to induce it and increase and do something to decrease it.

And then just kind of map it out and say, hey, like this set, it was this pressure at this, you know, at this raw value.

And then just go, okay, let's see if we can create a correlation map.

And if we can get it to correlate, all right.

And then also if, you know, if we can't get it to correlate, and I can isolate that message or eliminate that message on the network.

But still send that message with the peak began.

Maybe just maybe we may see that information on the dash.

Yeah, I think scan tools or a dash are a really powerful way.

As much as we can kind of get two data points, hopefully separated by a reasonable range,

that's going to be enough to decode it.

On top of that, you can also use, as you mentioned there, the, some of the, the, nothing software to actually send a message out specifically

to test that you've got, got the value where you want it to be.

So there's a couple of ways of going about it there.

What are some of the techniques, though, with more, the more sophisticated data, like I mentioned there, maybe talk values between TCU and ECU,

is that going to require some OE data on, on how, how they've encoded it?

Yeah, I always recommend it when you're dealing, getting down the rabbit hole with torque and torque values,

almost every circumstance that I've seen torque values on the scan tool can be applicable to the circumstances.

So I say, use your tools, tools to your, you know, to reference information.

So if we have torque values, and we see the torque values being supplied from the engine controller or from the transmission controller,

a lot of those numbers don't really add up.

Like, if we went and set the car on a dyno and said, hey, what power is this making?

And we look at what the, what the dyno says, the information actually doesn't line up.

Because the manufacturer does their own thing and they can say, hey, we expect it to be this number and we set the calibration to be at this number.

It's not actual.

It's not precise to the degree, which makes it a little bit of a challenge.

But it would be tools to use and verify the information that you're seeing correlates to the torque value increasing and decreasing over time.

Sure.

I'm guessing it's not possible.

Most OE manufacturers aren't going to make detailed accounts of all of the can messages that they send and receive publicly available.

They don't, they don't like us getting hold of that sort of information.

Man, I wish that they were a little bit more graceful on offering it.

Usually it has to come out of the back door of some engineer that's quaranted.

Unfortunately, there has been circumstances where information is supplied and it's because of the OE level, you know, with certain people.

And if you build those relationships and learn who they are, they might help you out a little bit.

But, you know, at the end of the day, yeah, the OE manufacturers aren't just publicly offering this information in any regards.

They don't want you, they don't want you knowing they don't want you working with it.

They don't want you assessing their information for I believe a handful of reasons because if there is a problem with your car, you can kind of call them out with the data if you knew that it was accurate, right?

Yeah, sure.

But, you know, it's also if you're from the warranty aspects, if you know how to manipulate it as well.

Well, now it's, it may be a little bit of a warranty claim that they have that they, they shouldn't have.

Yeah, fair play.

Well, let's move on to a product that you've actually created yourself, which is your, your can gateway.

I'm interested to sort of, first of all, understand where you saw a need in the market for this.

And I guess we probably should actually preface this with what is a can gateway.

So, a can gateway is essentially a device that can manage and route messages or information on any can bus

or any, essentially any device or peripheral associated with it to manage information on more than one network, right?

So, if you have information that needs to get from point A to point B, but they're two separate networks, a gateway could provide a link between one bus or one can, one can bus or network and another.

And then, you know, there's, there's more you can add to them and they can take substantial steps into deeper layers to almost become body control modules in the grand scheme.

They are, they offer ability to route and transmit information from point A to point B in various regards.

I think for me, the powerful aspect of this is being able to interface two devices that are not user programmable and make them talk to each other.

So, good example of this is one of the challenges, I guess, with any late model car now it's becoming increasingly difficult to replace the factory engine control unit with an aftermarket standalone

because you probably get the engine running, but the dash cluster won't work, maybe your aircon won't work, the automatic transmission absolutely won't work because all of the messages that those individual units are just mentioned that they're relying on is no longer there, the, the aftermarket ECU can't send it out.

But maybe it can, maybe, you know, just about any modern ECU now has can buses on it and consent the data that's needed.

But if it's not user programmable in terms of the address, it's going to send out RPM and the way it's encoded, then we're still back to square one.

So, with your can gateway, we can take, let's say a health ECU, whether it's generic template that it would send to a dash, and then you've got your RPM and you call them temperature, you can then pluck out those individual pieces of data in the can gateway.

And essentially shuffle them around and send them out on different addresses and coded differently.

Yep, that's absolutely correct. The essentially what drug me down this rabbit hole is I had a, I bought an E55 AMG back in 2015.

And I believe I reached out to you and I was like, hey, like this thing has a lot of can information and nothing met the needs on the market for what it needed on a via can.

So, like, if there was a circumstance where an ECU said it had can capabilities to send information, I was limited on the approach of how much information it could send.

I needed 16 messages to be sent and at the time I think link had eight.

So, what are you trying on this E55 AMG to put an aftermarket standalone on that, that's the, yeah, I was trying to put it aftermarket engine management system on it and everybody told me you can't, you can't do it, it has a can bus.

You're not going to figure it out. Challenge accepted.

Yes, absolutely. Challenge accepted. Let's dig into this.

And so, the drug down this rabbit hole, you know, I didn't know what can was in the grand scheme outside of the communication model from the get go.

I was like, I'm not going to let it kill my goal. And so, I started, you know, researching what is can, what does it have?

What can I use to analyze it, how am I going to get, you know, the information from the OE box into another box to make everything work.

And I kept digging down this rabbit hole and every time I would find a solution, it was either outside of my cost, it was too cost prohibitive for me to try.

Or it didn't meet my needs of what I what it had.

So, I ended up having to go, okay, well, let's just build my own thing, right?

I needed to control various aspects. And if I'm building it myself, I only can, you know, if it doesn't work out, it's on me, it's not on anybody else.

I didn't have a salesman giving me all the check boxes saying it'll work. It's me, it's, it's my problem now.

And that's largely what, what drove me to build my own can gateway.

I guess the question obviously is to, did it work? Did that E55 IMJ run on a link, KCU?

No, unfortunately not. I sold, I sold it when I bought a house back during 2020. And it never, it never came to fruition.

Now, with that being said, I, I do have a contract that I'm working on that's, that's two of the similar applications that they have approached me with because they saw my abilities and skill sets.

So, I may end up making the dream come true, just not on my own car.

That is so, it's not through a lack of capability. It could have been done.

Just the stars didn't align at the time with that, that particular vehicle.

That's correct. Yeah, it was, it was a situation where I had the ability to sell my car offload a bunch of equipment, you know, to, to transition from one house to the next.

It just wasn't, it wasn't my time at that moment. And I let the, I let the dream die obviously with selling the car, I guess, in some regards.

But I never let the dream die on what my goal was.

Sure. But just something that popped into mind while we've been talking here. And this might be a little high level.

But I'm interested just to get your take on it. How do you approach maybe something with a modern DCT gearbox or auto gearbox,

which is very reliant on accurate talk output from the engine control unit into the TCU.

Now we're going to get rid of the factory ECU. And we're going to put in, let's say a link ECU.

Something that's not talk based though, so it doesn't natively have an output for engine talk.

That can be translated through the can gateway and sent to the TCU.

So now you've got two problems. You need to encode the data to send it to the TCU, but you don't have the data to encode.

Yeah, so essentially everything that the, you know, I tell people all the information via sensors signals.

If you're doing OE integration project, it was largely already there from the get go.

While the aftermarket engine controller may not supply set info and package it up for how you need it,

they made a characterization based on some parameters. And for instance, like torque, it's going to be based on a handful of scenarios.

But for the most part, you have airflow, you have VE and you have your lambda values and your ignition timing pending it's at its optimal place.

So if you can figure out where your ignition timing is optimal and see if there's any timing, you know, a retard, your airflow and your VE and your lambda values,

you sense to make a, make a decent calculation and come up with your own torque value to supply to it.

Okay. And how's that going to be done? Are you going to do that essentially in the ECU, maybe with some auxiliary tables to output something near, near enough?

Or are you going to rely on something else out of the ECU that already does natively exist? Let's say airflow or volumetric efficiency.

And then do some clever coding inside if you can gateway, which I don't even know if that's possible. I'm kind of reaching here.

Yeah, it's absolutely possible. And this is where I say the possibilities are up to, you know, typically I try to say it's up to the end user. How do you want to do it?

Do you want to, do you want to have it to where it's able to be adjusted and edited inside your, you know, your standalone unit, which is typically what I recommend. It links in some manner.

Let's have a, let's have a table built up, build the table up based on two axes with airflow, ignition timing, retard, if anything.

And determine from there what we need to add to it and do some type of factors on the back end if necessary.

You know, your lambda values obviously aren't going to change drastically on power over time. So like if you have, you know, 0.92 is going to say 90% of your power based on wherever you're at.

And you know, lambda one is going to be of value a little bit lower than that. And as you go scale up, you're going to have a little bit of value, a little bit lower value on output.

So we can, we can say, hey, take the static values, put them in the, put them in the, you know, the gateway, but take all your dynamic factors that you're going to be changing drastically.

Go ahead and add those in the tables inside the ECU if possible.

Yeah, it's always nice to be working in just one location when, when you're doing a calibration rather than have to modify the calibration, then also access this can gateway and change whatever's going on in the code there.

I think it's probably also worth mentioning that quite often you don't necessarily have to be pinpoint replicating the original talk value.

There's almost certainly going to be some leeway. So if you're out by, you know, maybe 10 or 15 Newton meters, probably you're not going to smoke the clutches in the gearbox. It's probably still going to change gear.

But, you know, if you're starting to get 100 Newton meters away, probably that's the TC is not going to be happy with that. And it's maybe not going to change gear or something else is going to go, go badly.

All right. So I guess the, the, the next part of this conversation is how, how do you actually control and program this can gateway.

So it's, it's step into the lines then for most people, but essentially I had the option of, you know, graphical user interfaces and what the constraints are associated with them are.

And the struggle I always had was I can always think up something else needed, right? I can always think of, hey, like we need another table or we need another address.

We need this through that. And I want to control it in this specific manner. So I left it to be like programmed in C. And that gives the essentially the end user or the programmer complete flexibility to do whatever they need to do, whether good or bad with the box.

If you're ever considered in a situation where you have to, you know, consider, hey, like I could do this with, you know, another gateway that, you know, of whatever manner with a graphical user interface.

At some point I expect the graphical user interface to run out of limits. Now the limit that I have everything has limits the limits essentially memory for me.

It's not how many messages we can supply. It's not, you know, how many tables we can provide. It's just how much memory do you have available to use.

So it isn't the most refined for the end user if they're not from a development background.

Yeah, I would think that that would sort of take off the table for maybe 80% of the population. I mean, I'm out. That's beyond my skills.

I knew that use case coming in, but I also knew where does every box fall short or what does every other gateway fall short in the manner.

So my goal to check the box was where everything else can't meet expectations. I want to be able to meet them.

Sure. I mean, this is probably getting a little off course, but while we're here, would it make sense for you to offer sort of a standard and then a

pro variant, the standard worth the graphical user interface. And then, you know, for those niche cases where that becomes limiting factor, step up to the pro, learn to code and see.

Yeah, it is something on the table. I haven't taken the initiative to build in a graphical user interface just yet.

I'm probably going to end up implementing additional hardware to offer more features, because people have said, hey, I want, you know, I want some analog inputs, I want some digital inputs, I want some

additional IO outside of can to run on it. And so from that aspect, I'm like, okay, I need to take all of these ideas that people have said, hey, yeah, this is not.

This is good, but it's not great and build the next, you know, the next iteration to make it greater than the first.

Do you often do you think I guess when you're getting suggestions like this for features, what do I find particularly I've done some sort of consulting work for some of the the issue manufacturers in the past.

And as a high level user, it's very easy to say, hey, I want this feature here. I think this would be a great feature. And on face value, I mean, it makes sense.

This little widget that someone's asked to add, but is that widget going to be worth adding because is that actually going to be useful to the 95% of people that are going to use the product.

So where I'm going with this is, how much value or weight do you place on these requests, people are asking you for versus your own understanding of the product, the market and what people actually are using.

Cable for that is clearly, if you're starting to get the same request over and over again, well, obviously that does make sense. But yeah, I'm just going to take on that.

Yeah, it's, you have to vet feedback, right? Because not, you know, not everybody is going to have a great idea that suits everybody. But you are right, the next, the next iteration, I will be providing FD support for because of the C8 vet, because people are saying, hey, I want to run.

I want to run an aftermarket data acquisition system on my C8 vet, but it runs on can FD, which is not necessarily the most compliant to can 2.0. So everything's built on this current standard, but this, you know, superseded standard is what the Corvette, the C8 Corvette is running.

So it puts it into this little hard place on how people are going to acquire data from it.

But yeah, it's, you have to, you have to just take the approach and be like, hey, I can think about it, you know, look into it and see what we can do.

But yeah, not, not everything's going to make it, you make it to production, obviously. And, you know, you have to sit there and say, well, is the juice worth the squeeze, too, right? Because, you know, it's easy to say, hey, I want a box that has, you know, unlimited, you know, memory, process, there's blazing fast.

So everything under the sun, it's like, yeah, okay, well, do you want to buy, you know, something that's 30 times more expensive, you know, or 50 times more expensive than it currently is just to meet that expectation.

And most people usually have to take a step back and dial it back once, once, you know, you get them to that point.

I think the other problem with user generated feedback or suggestions is quite often people will use that to kind of flex their level of knowledge in the industry.

This really extreme feature, look how clever I am, but the reality is, like, no one, including that person's probably going to use it.

So there's a bit, there's a bit of filtering required. Now, you just mentioned can FD. So everything we've been talking about so far is essentially can 2.0.

What is the difference? What is so festival? What is that can 2.0 mean? And then what is can FD?

Can 2.0 is essentially the current generation that we've been using since I think 1992 essentially was the first, it was the first iteration that actually really took off prior to it.

It was essentially bosses like R&D stuff and stuff in the 80s. So you don't really see that at all.

Can 2.0 is what we used today and what you see on most of the motorsports applications and almost all of your aftermarket engine controllers and things like that.

Can FD is the successor to can 2.0 and it runs essentially it can run up to eight times faster right now.

So if you can fit, like, let's say 8,000 messages of 8 bytes in length on the current standard, you can fit 8,000 messages of 8 times 8 bytes in length on can FD.

And that's pretty much it. It just tries to add another layer to offering more bandwidth.

So there was going to be the next question. Is this a bandwidth problem or is it a speed problem?

I personally think it was neither. I think it was just the industry standard calls for wanting more and they finally gave in.

I mean, I think it is fair to say though that as things become more complicated that the bandwidth does become a limiting factor.

I have this exact scenario on our 86 endurance car. We essentially use, and this is actually an interesting analogy to your product, we have a variety of electronics.

So I mentioned earlier, we've got Motek ECU, Motek M1 ECU. We use a Motek C125 dash and we use ECMAS to PMU's.

But then I've also got a lot of Izzy Racing can-based sensors.

So I'm essentially using that C125 dash as can gateway because it is very user configurable in terms of receiving and transmitting can messages.

So a lot of flexibility there. So when I want to interface something, for example, we have an ECU master can switch pad on our steering wheel.

So all of the buttons, knobs, et cetera, the paddles all go into that. So wireless.

And then that can't, the upshift paddle, for example, cannot be read directly from the Motek M1 EC, which is ultimately where it needs to go.

So that gets decoded inside of the dash, and then it gets transmitted back out to the ECU in a mode or in a way that the M1 can understand.

And then all of a sudden, yeah, we can change gear again.

So that coupled with, I mentioned the Izzy Racing sensors, we've got internal tire pressure and temperature monitoring on all four corners.

Then we've got external 16 channel infrared tire temperature sensors. We've got three laser ride height sensors, and those transmit at one kilohertz.

So we're actually at a point where our bus utilization is kind of getting a little bit scary, sort of 85 to 90%.

And then, of course, we get into the problem of messages starting to drop away.

So I think bandwidth is definitely a problem. Yeah, I've got two buses on that vehicle, but for a variety of reasons,

I have to have a bunch of that on one bus, and then you sort of at the limit of that bus. So I'd like a little bit more bandwidth.

Yeah, yeah, absolutely. Yeah, as time passes, obviously, more sensors, more data, more everything is going to come.

Before we were talking, before we started recording, we were just talking a little bit about where you place the data in terms of addresses versus importance.

And I think that would probably be good to bring up here as well.

Yeah, so I always try to make sure the more critical of information is always at a lower arbitration ID.

So the arbitration ID will control if we have two messages trying to send at the same time, which one goes first, right?

So if you're essentially, if you're running to the line at Walmart for Black Friday specials, if you have a lower arbitration ID, you get to check out first.

I always put the critical nature items at the lower arbitration IDs and start working my way up.

And most of your manufacturers actually do this too, they have a very methodical way of setting information up.

So for instance, your powertrain information, your engine controller to your transmission controllers typically had a lower, pretty low arbitration ID.

And then from there, if you have things like coolant temperature or tire pressure, so to speak, on your OE application, it's a little bit higher on the bus.

Doesn't it really matter if that message drops off occasionally here and there? Yeah, absolutely.

I think that would probably go for hours as well. I would probably don't mind if I miss a few bits of data from a laser ride height sensor.

But I'd really like to know that when I pull the upshift or the downshift pedal, that data is going to go through.

Yeah, I always try to push if anything that has the highest, the most critical response time first, like that is going to be the most important.

And then errors in an error handling second and then from there, just kind of go by by priority and to say, hey, which one sounds more important?

Does your air temp sound more important or your, you know, your tire temperatures, things like that makes perfect sense.

Alright, back to to KNFD. So this is sort of an upcoming potential protocol that's going to be used.

How mainstream is it at the moment? I think you mentioned the C8 core vet.

Is it in a lot of vehicles at the moment?

Yes, it's coming around the 2019 and up global beach trucks. So your Chevrolet full size vehicles are now running KNFD, at least on one of the buses on the vehicle.

Because your C8 core vet's probably the most notable, but you also will see it in Mercedes, Aston Martin's, a lot of your luxury vehicles have been running it for a few years now.

And it's going to be the successor at some point. Once these cars kind of start getting into the limelight of the street street scene, I guess, you'll start seeing, hey, the need for an FD gateway to FD can 2.0 will will will be need to be filled.

I only assume that it's going to also trickle down into the aftermarket electronics industry as well.

Am I right in assuming that this isn't just a rewrite of software. This is a hardware change to go from KN2.0 to KNFD?

Yes, it is a hardware change as well. There's essentially a controller and a transceiver.

The controller is different. The transceiver is also different. So it's not just something that can be, you know, yeah, whipped up some programs.

If the hardware was already implemented in the device, yeah, it is a little bit easier to do. But yeah, it's it's going to it's going to require, you know, a new iteration of hardware to come out at some point.

And to fulfill its desires, if it hasn't already been implemented, there's a lot of devices that may have it already, but it's just not being utilized because they don't need it yet.

You know, sure, yeah.

In terms of other up and coming protocols or communication techniques, another one that I know very little about, but we hear about occasion is Flexray.

Can you can you fill us in on on what that is and how relevant that is?

Yeah, so Flexray is essentially a it's a four wire protocol that is a little bit more challenging than can and can or can FD.

I don't expect it to take off. I think it's a very niche protocol that was offered before can FD really took off BMW really invested on making it the next standard.

And I don't think it went very well for him, but it is there you'll see it on a handful of vehicles and applications.

They'll use it and it's more of a timing model, so you end up with information have suggested slots.

So every, let's say, second, you know, a device has they they slice it up in time and each device can talk within that second for a specific amount of time to say, hey, this is the information we can provide.

And this is what we got. And then the next, you know, if it goes from engine to transmission to body control module and then goes back in a circle, they have this round robin of

information being communicated. So there's no arbitration phase for it. It's a timing model that it knows it's your turn to talk, then it's your turn to talk, then it's your turn to talk.

And then we can proceed on over again.

Okay. Yeah, I guess when I was sort of having these battles as to what the next big thing is going to be.

It's sort of, I guess, like the CD, the cassette tape and now we're just streaming music.

All these technologies that come through some of them take off and some of them fall short. So to be expected essentially from what you've explained, I can't really see in the current model why we would need

anything more than K&FD that's got to have everything pretty well covered, I would think.

On top of that, I think licensing fees as well as the hardware to implement is what's going to prevent flex ray from being the next big thing.

Because the hardware, the hardware is much different than K&F, K&FD. It's much more costly as well.

There's a stumbling block for sure.

If it increased the cost across the board at an OE level, if you're building a million units, do you want to spend a million units four times the cost versus can.

So there's some definite challenges associated with it that may end up stopping it in the strax.

Now, sort of coming for Circle with one of the reasons we decided we should get you on the podcasters after our interview were tuned by Sean.

And I know that you two had been sort of co-labbing on some plug and play kits that he's now providing for the likes of the C6 core vet using a Haltech ECU and your can gateway.

So I'm just interested when you're looking at these newer vehicles you've got, obviously K&FD was talked about coming through, things are getting more complicated.

Is it going to just continually get harder for the likes of yourself and Sean to be making these plug and play kits for these later model vehicles?

Yeah, it's certainly not getting these years, especially as time passes.

You know, back, I want to say 10 years ago, when they were building vehicles and prior to that, there wasn't a lot of, you know, stumbling blocks associated with information just being sent.

So if you could send, you know, engine speed, RPM, you know, whatever the dash needed to read appropriately, the car would just be pretty much fine with it.

Up until about, you know, I want to say about eight years ago, you can, you'll start seeing that they have added more information to basically like, you know, I want to call it secret, secret information inside the message itself to know, is this message actually correct or has somebody just tried to emulate the information.

We put a call it checksum or a kind of like a math calculation that's recursive to the message into it that adds challenge to it.

And then, you know, if you keep going to what's being built today, there's a lot of initialization sequences on various applications that say, hey, we're going to do some, I'm going to send you a whole paragraph of information.

And if you don't send me back a whole paragraph of information that's correct, how you, you know, you got your password, we're not going to start.

We're not going to work. It's definitely a challenge.

Not one that I look forward to, but I also have confidence that there's some incredibly smart people like yourself in our industry.

And when it comes to beyond access and reflash these current generation vehicles, there's a very big market with a lot of money to be made.

And that's a really powerful driving factor for people to kind of figure it out.

And then as you alluded to earlier, you know, often there's sort of some factor information coming out of some of the OEs as well that possibly shouldn't be shared with the aftermarket.

But we know that that does tend to happen from time to time.

I wish it happened more often, be honest. I would be more on democratizing the information than hiding it.

But I understand why they do that because they don't want their car stolen.

You know, they don't want, you know, they don't want a lot of warranty claims for people, you know, basically voiding the warranty of the car and then putting it back to stock and then taking it back saying,

Hey, I got a hole in my block. I don't know why. Here you go. It's under it's under warranty. It's got less mileage and time frame.

No, I can totally say the reasons to try and lock it down, but we on the other side of the fence don't want it locked down.

Coming back to that C-Six Corvette project with Sean and using the Haltech ECU, could you just give us maybe a couple of ideas of what were the biggest challenges on that project.

So doing remote analysis is always a challenge because you're not there. You know, you're essentially looking at a log file trying to understand what's going on.

Right. And not only were looking at a log file, we're not looking at a log file that actually has information supplied in any significant way.

So you're, you know, you go take your car on the track, go drive it around. Hey, you know what the information is being supplied is. I'm just looking at a bunch of numbers and trying to make sense of it.

So you got to tell him, Hey, you know, as me to Sean, I have to say, Hey, I need you to go do specifically this task and then provide me as much context as possible on doing so.

So like, Hey, I need you to go take this car. I want you to go to 55 miles an hour and I want you to hold it at 55 miles an hour for one mile.

And then I'll want you to pull over and stop immediately things like that because I need to have those standards of where this information would have been held for that period of time.

How he stops immediately to know, you know, we're going back back down to zero. So I have reference points of it.

So getting the reference points and the communicating the reference points to understand what exactly is going on remotely based on asking somebody.

So it's like almost like if you're a service advisor at a car repair shop, like, Hey, what problem are you having?

But I need as much detail as possible. And you know, so a lot of the customers are saying, well, I hear this clicking sound when I'm going 30 miles an hour when I'm on the road.

It's like, well, what kind of clicking sound are you hearing exactly?

Those things you have to really drive into to understand because you're not, you know, you can't use your senses to have any understanding.

I just got to use essentially my brain and my eyes and that is it.

So it would have in fairness being much quicker and easier if you were on site doing the testing yourself.

Oh, absolutely, absolutely 100% and that's not, that's not a knock on anybody.

That's the nature of the beast. You know, if you're trying to, if you're trying to remotely diagnose just about anything unless you have a very, very high level understanding of the information that

that needs to be, you know, addressed and the issue is well defined, you're going to, you would rather be there at first hand.

Of course, of course.

I guess the, the proof is in the pudding, though, this conversion that you two built this parking plate kit.

Does it do everything just like our way or is it missing anything?

You give it to someone, would they know that they're driving a cesset's call that with an aftermarket ECU in it?

So nothing to my knowledge is missing, but I always tell people I don't know what's missing at all.

So, but given the circumstances that we had everything that we had on the table, all the check boxes for, you know, information, whether it was, it was traction control levels, you know, all the dash, dash functionality, everything works as it should.

And we haven't had any hiccups whatsoever so far, and I hope that maintains the case.

But there's always that level of question that, you know, did I miss anything?

Does anything that I did not add what I needed to?

Is there something else that I could have gotten?

And truth be told, I used to, you know, eat me alive, but nothing there that I'm aware of that we are missing.

And truth be told, if there is something that we find that's missing down the road, we can always add it back.

Yeah, that's a good point. I think it's fair to say that you can always expect maybe some weird situations to crop up that actually then show out that maybe something was missing that you couldn't see under normal driving circumstances, but like I say, you find these problems and you fix it, you add them in.

So often a bit of a work in progress, but obviously sounds like suffice to say 99.9% it's doing exactly what it says on the label.

That's correct. And I've reached out to a handful of ECU manufacturers.

We all deal with this, you know, I had this special edition that had a specific message that would prevent the car from starting.

And we didn't see it anywhere else, but this 25th model vehicle.

All right, much. I think we'll move towards wrapping this thing up. I want to respect your time.

And as always, we've got the same three questions we ask all our guests.

First of those is what's next in the future for you.

Man, I am working on the successor. I'm taking the feedback that I'm getting.

I'm trying to create a better training model to help people understand because I do want to have offered solutions to people that if you're determined, you can do it.

I don't want anybody to say, hey, like I just don't know enough about programming to do this.

Well, let's learn programming. Let's get you up to speed. It's not challenging if you're willing to take on this task.

I'm willing to bet that you have the knowledge and skill set to learn what's needed.

But yeah, offering a successor, adding KNFD to my gateway so I can implement it into the newer vehicles.

So if they need a KNFD, they can have it at will. And I don't have to say I don't have that yet.

But adding adding a little bit more IO as well, not that I need the IO because I typically tell people, you know, they're like, hey,

I want to add more analog inputs and it's like, well, what are we replacing by doing so?

Because chances are you're already replacing some IO expander and you're just trying to mash it all into one box.

Well, I'm not mad about that, but there's already a refined product there.

I want to solve problems that no one else has on the market yet.

Yep, that makes sense. I get it.

All right. Next question is there any advice you go to a younger version of yourself to help reach we are today in your career faster?

Yeah, outside of never stop the curious mind, always be curious, always try to dig for, you know, answering questions, right?

Because that's largely what's driven me down to this knowledge hall that, you know, people say I'm a so-called expert, right?

And I don't ever look at myself as an expert because there's always more for me to learn and understand.

And if you just give up on that that curiosity, it'll kind of like drag you down. You're not going to, you're not going to excel.

And build relationships with people in the industry because you never know when they're going to come in handy.

There's been times I've been struggling with a circumstance and, you know, I'll just like, I mean, I just can't figure this out.

And then next thing, you know, I have somebody that's, you know, contacting me saying, hey, I got information on that.

If you need it, here it is, you know, so everybody in this industry, you know, we struggle with, we struggle with stuff a lot behind the scenes.

And a lot of us, you know, we want to make this highlight reel and curated, you know, scenario to say, hey, like everything is great here.

But we all have challenges that we all know it, you know, and if you've been around it any long enough, you know, there's some car that's just kicking, kicking our tails.

And, you know, we just can't solve it or we just have a dilemma that we can't overcome in whatever way that is.

And it's okay to, you know, embrace that, embrace that, that heading.

Yeah, you're absolutely right. The Instagram highlights reel of everything's rainbows and unicorns is definitely not real life.

And there's always the struggles behind the scene.

I think the curious mind is a good one. It's why I'm still really passionate about what I do is because there is always something new to learn in the industry.

Yeah, again, the further you get along the stunning Kruger sort of curve, the more you know that you don't know, the more you realize there's still that body of knowledge to learn.

So, yeah, I think that is really important closing down your mind to that possibility, brings nothing good at all.

All right, our last question for today, much of people want to follow you, see what you're up to, maybe purchase one of you can get ways, how they best to do so.

Yeah, my website is mittenperformance.com. You can send me a message there, or if you want to find me on Facebook, it's just a Mitch Mitten.

Almost everything else social media, I don't try to keep up with because I found it, I found it too challenging to, you know, manage four different apps all doing the same thing for the most part.

So, you know, I have an Instagram, it's dormant, I have a LinkedIn that's also pretty dormant. I've never got involved in anything else, TikTok.

And I also have a YouTube channel mittenperformance that I try to post, you know, the nerdy tech details on explaining things and stuff like that as time passes.

And there's a lot of great information on it, and I get a lot of feedback like, hey, this, you know, you taught me how to, you know, use this software in a specific manner that I didn't know before.

Most of it's typically motorsports oriented, you know, sometimes it's, you know, nerd oriented, but for the most part, that's where I go to is YouTube and Facebook.

Okay. Well, as always, we'll put links to those in our show notes, make it nice and easy for people to find.

Oh, great chat today, much it has been ages, so I really appreciate you taking the time out to chat with us, and hopefully everyone's just a little bit more clued up on, on can, hopefully we haven't sort of managed to just confuse, but yeah, thanks again.

Thank you, and if they do have any questions, feel free to reach out.

I hope you've enjoyed this episode of Tundin, and don't forget by using the code podcast 500 at checkout podcast listeners can get a huge $500 off our VIP package, which includes over 40 current courses, as well as a long list of courses to be released in the future.

As a VIP, you'll also get lifetime access to our members only webinars and our community forum.

Lastly, we'd love it if you could leave a review or comment on your preferred podcast platform.

Your feedback really helps us to reach a wider audience which in turn allows us to continue bringing you more high quality guests.

As a thank you each week, we'll randomly select a review or comment from Spotify, Apple podcasts or YouTube, and send the winner a free HPAT shirt, shipped anywhere in the world.

It's also a great place to ask any questions you might have to, and if your review or comment is chosen, I'll do my best to answer them directly.

So this week, a big shout out to Jeff Jin who has said, I absolutely love your podcast and the wide variety of guests you've hosted.

It has really expanded my knowledge which I've been able to apply to my car.

Well, great to hear that you're enjoying the podcast, and you are finding ways to apply the knowledge you're learning.

If you get in touch with your t-shirt size and shipping details, we'll get a fresh t-shirt straight up to you.

That concludes our interview and before we sign off, I just wanted to mention for anyone who's been perhaps hiding under a rock and hasn't heard of high performance academy before,

we are an online training school and we specialize in teaching a range of performance automotive topics, everything from engine churning and engine building through to wiring, car suspension and wheel alignment,

data analysis and race driver education. Now remember, you've got that coupon code.

You can use podcast 75 at the checkout to get $75 off the purchase of your first course.

You'll find our full course list at hpacademy.com forward slash courses.

Important to mention that when you purchase a course from us, that courses yours for life as well.

It never expires. You can rewatch the course as many times as you like whenever you like.

The purchase of a course will also give you three months of access to our gold membership.

That gives you access to our private members only for them, which is the perfect place to get answers to your specific questions.

You'll also get access to our regular weekly members webinars, which is where we touch on a particular topic in the performance automotive realm.

We dive into that topic for about an hour. If you can watch live, you can ask questions and get answers in real time.

If the time zones don't work for you, that's fine too. You're going to get access as a gold member to our previous webinar archive.

Close to 300 hours of existing content in that archive, it is an absolute gold mine.

So remember that coupon code podcast 75, check out our course list at hpacademy.com forward slash courses.

149: Cracking the CAN Code: Mastering Integration in Performance Builds

About this episode

Request an Explanation

Want to learn more?

Help improve this episode

More from Tuned In