PART-2: More CAN BUS Reverse Engineering on my R8/Huracan Powertrain!
HTML-код
- Опубликовано: 6 сен 2024
- This is a continuation of Part-1 where I show the complete process, from start to finish, on how I reverse engineered the Audi R8 / Lambo Huracan Powertrain CAN BUS. I'm doing this because I want to display the OEM CAN data (telemetry) on my MoTeC C127 dash. The highlight of part-2 includes locating various temperature telemetry and creating our first CAN database [DBC] file, which is critical to get the MoTeC dash to report the data properly.
If you missed PART-1, I highly advise watching that first before this episode. Here's the link: • PART-1: I Reverse Engi...
Like episode-50 (Part-1), this video is much different than my typical build videos as it's more like a step-by-step tutorial...and very geeky!
Here are the links to all the software and equipment I use in this video:
CL1000 CAN BUS Data Logger: www.csselectro...
SavvyCAN (Free): www.csselectro...
VCDS (for VW-Audi Group cars): www.ross-tech.... (But any generic OBD2 scanner will work too)
Kvaser DBC Editor for Windows: www.kvaser.com...
DBC File References on GitHub (including the VW Golf MK4 DBC file I use in this video--see first link below):
1. github.com/com...
2. github.com/SBi...
3. github.com/iDo...
Small tip on finding temperatures: If you're able to get to the sensors connector without dismantly any other electronics you can simply disconnect that sensor and should see a drop to 0x00 in value. Most automotive temperature sensor application start at -40°C for 0x00 which is also used to detect a short to ground or open line.
On the flip side, if you short out the 2 pins of that connector you will see a rise to the maximum hex value.
Thank you so much for doing this, I had no idea there was software to read it bit by bit as well. This will be very helpful in decoding my vehicle from here on out!
From my perspective, you couldnt have started this series at a better time. You have just saved me COUNTLESS HOURS of research and hunting for data.
I am in the resource and data gathering stage for building my own digital dash on my mk1 Audi TT. Not only have you expedited my learning into a tangible stage of designing and developing, but youve even provided a MK4 DBC file that has 90% of what I need cutting down even MORE time.
Thank you for all of your hard work and dedication, and your thoroughness of your data analysis and discovery. Ive been geeking out so hard over these last two videos.
Ill be going through the rest of your build as well, super excited about what youre doing as a whole! Thank you!!
This is exactly why I created this video and happy to hear it helped you. It takes a village to reverse engineer this kind of stuff; more brains are better than one!
Bravo, engineer Dulac. We all appreciate the full disclosure and technical detail.❤❤❤
Hello Dan, What a great reference file of the VW Golf4 engineered in "Die Deutsche Sprache".
We as Dutchmen learn the German/English/France language as a basis at school in my days.
And that also turned out to be very useful in my Profession, which was based on e.g. (Technical) English and German Engineering.
I also noticed You have to be so precise to fill in all data columns.
In "cherry picking" - Unit Name "Celcius"---> "C" @wtr/oil temp.
Thank You again.
I really enjoyed this lecture and looking forward to PART3.
I am never going to do anything like this but I am loving seeing the process!
Another nice video. However, your description of endianess isn't quite right - you've probably been confused by how SavvyCAN shows the signal location in the diagram. The Byte Order setting does NOT change the BIT order within each byte, as you desecribe. If your 16-bit signal had a value of 0xAA55 in little endian it would have a value of 0x55AA in big endian. Starting at 6:04, for little-endian (Intel) byte order, the grey box shows the LEAST significant (lowest value) bit (LSb) in the signal. When you change to big-endian (Motorola), the grey box shows the MOST significant bit (MSb). The Byte Order setting does NOT change between the bits being read left-to-right or right-to-left, as you describe. This is hard to explain in writing, but if you try the same experiement in Kvaser Database Editor, you'll understand as this has an arrow showing the bit order within the signal. This won't matter for most of your audience but I just wanted to offer this explanation for completeness and in case it helps you.
Thanks for the detailed explanation! Since posting that vid, I since learned exactly what you describe here. It was a steep learning curve but I think I finally understand it 100%. Thanks again for your detailed explanation!
Glad I came across these videos. Fantastic info and delivery is spot on.
Nerdy…..in a good way. Really good ref data for other folks. Can’t wait to see the dash inputs!
I definitely geek out on this stuff!
Dan, impressive work, I cant wait for the next video.
Loving this, looking forward to the finale of the trilogy soon!
I’m working on Part-3 of this mini series now. It’s going to be awesome!
As someone that had access to the full internal docs of the CAN bus protocol on some cars I can give you some hints. By full I mean everything, every module, sensor and such. Sometimes there multiple versions of the data. From the actual sensor/package and then specially combined for things like instrument clusters. Engine temps are often combined, because they are shown by the single instrument cluster. But somethings like switches for mirrors, seats, lights, distance sensors a.s.o. are all over the place. Also, as seen on the example VW Golf file, some values are odds like 3 bits and often don't start at byte boundaries. And let's not talk about the offset and scale things, also all over the place. BUT you did a good job reverse engineering the stuff. Did not know about those advanced reverse engineering tool. Learned something new in the series.
Lots of research behind this so thx for sharing!
Another thing is the amount of massages, footrubbings and whatnot you owe to the wifey you'll have to endure 😂
Best tutorial video of reverse engeneering can bus. You explain very well. Thanks for your time.
I can't do it but this guy can. Great videos. Thanks again.
This is so helpful. I have bookmarked and will be reviewing for a future project. Thanks!!
Dan, to make life a little easier, when scrolling for Degrees C in Kvaser, couldn`t you click on the header "Unit" to group them all together ?
I'm nitpicking, this really is the most useful, comprehensive yet understandable guide for Canbus decoding I've found.
Good point! I’ll give that a try. 👍
Great work mate!
Amazing work! Surprised that the IAT logged so slowly. I guess that IAT temp signal is not the same as the actual MAF signal, even though it's from the same sensor, but still i would think they would want a higher Hz on IAT than coolant/oil. But maybe these CAN signals are only used for logging/display?
Yeah, I’ve learned that a lot of the critical engine telemetry is not broadcasted on the CANBUS. So to your point, I’m sure the ECMs are reading this data at a higher frequency directly from the sensor(s).
I have watched part 1 and 2 of your series and am impressed by this reverse engineering. However, I am not sure whether you have actually determined the intake air temperature. You have used the airflow sensor at 34:00 minutes into the video. As the sensor name suggests, it measures the amount of air passing by per unit of time. By blowing air through it using the heat gun you change this value. I am not sure whether the same sensor can measure the air's temperature as well. So it could be that you found the intake air flow, not the intake air temperature. In your particular case I suspect that you compared your finding with that of other dbc files to confirm the correctness. If somebody does the same reverse engineering on another car without having a reference the two signals could get confused. Air flow and air temperature can be distinguished in that case by blowing ambient temperature air through the sensor: the air flow will increase but the temperature will remain stable.
The MAF sensor usually comes with an integrated temperature sensor, especially in VAG cars.
Most if not all MAF sensors measure both air metering and air temp via two integrated sensors. The air metering sensor is way more sensitive and measured at a much higher frequency than air temp. Although I didn’t show it on camera, I used the heat gun at the same air velocity but varied the temp output to confirm I was measuring temp and not velocity. Plus, since the intake air temp value is in the same CAN ID as other temp values (oil and water), I’m 100% confident I have the right signal. Thanks for your comments and question!!
‘I have a maths degree’…. when 4 = 5… after watching a 2nd 40 min video on hexadecimal any man mathematics can be believed 😂
You're a trooper if you made it through both vids on this topic! The payoff comes in the next video, I promise. :-)
@@DanDulac Great, I assume you are going to teach (make me believe) 4 now equals 6 😵💫👍
@@jamest5149 nah. I’m all done with math. No more pain. 😆
@@DanDulac "And I have a math degree" was *the* subtitle of the entire series! 🤣 A brilliant piece of self deprecating humour! LOVED this part of the build (and I've watched every video since day 1) - you are inspiring me to reverse engineer all my cars' CANBUS data!
Awesome
where were you 10 year ago when i was doing this lol
i would be trying it just for fun but now my obdii port doesn't have a direct access to the bus
most new car have a bridge to prevent hacking
i had to find the value with obdii request instead
Yep, you’re right. I don’t have a “CAN gateway” in my setup so it’s easy to tap. But with a CAN gateway, you have to tap into the proper CANBUS wires directly and bypass the gateway. I meant to mention this in my video. You’re spot on. 👍
Would it be possible to write something to CAN to activate certain car features? For example, I have a button to enable sports mode, but its state is always off when I start my car. Wondering if I could reverse engineer what the button does and replay the CAN message via some microcontroller attached to odb2 to activate the sports mode every time I stat the car.
Yep, I bet you could do something like that. First you need to figure out if the button is a simple “dumb switch” wired directly to the ECM (like the brake switch in my video example) or if a button press sends a CAN message across the network. Either way, sniffing the CAN BUS while pressing the button will get you the answer. Once you narrow down the CAN ID and message that’s sent, you could replicate that with any number of CAN message transmitters.
Also, ECU Master makes an awesome little CAN device where you can program CAN frames to send. Might be the ticket for you.
100% you can. I rolled down windows or locked and unlocked doors on my laptop by sending the respective CAN messages in my Mercedes about 18 years ago. I also developed a MCU based control module to open the sunroof (tilt) when the temp is too hot and closes it when the sun goes down and it cools off amongst other features.
wow
Great video mate, what equipment would you suggest to allow a BMW m57 Ecu to integrate into a Chrysler vehicle canbus?
Hi! You would need a CAN gateway of sorts that could take signals from m57 ECU and 'publish' selected messages to the Chrysler CAN BUS (and vice versa). You might want to checkout the CAN Triple...it's a newer DiY product from mintonperformance.com. Check it out; might do exactly what you need.
another thought: if the m57 ECU and Chrysler canbus are both running at the same canbus speed (usually 500Mbps), you could try simply adding the m57 to the Chrysler powertrain CANBUS. You might get message collision (if CANID's overlap between the two) but doing a "sniff" independently on each would answer that question.
Just had a thought and not sure if it’s the same (not used it either) would VCDS HEX codes help finding the can bus codes?
I looked into this but unfortunately VCDS obscures the DBC between it and the CAN BUS. 🤷
Hi Dan, I am looking at doing this in the future and looking to use a teensy with CAN transceiver rather than the CL1000.
I am unsure of the format of the serial stream output from the CL1000 for use within SavvyyCAN.
Would it be possible for you to use putty to capture an example few messages from COM8 (as it was in your video). Not sure on baudrate used.
Thanks
Here's a snippet of a raw CAN log file as recorded by the CL1000. This is the format SavvyCAN expects to see for valid file import and playback. Hope this helps!
Timestamp;Type;ID;Data
01T000006660;0;12f;5510010e48230000
01T000006662;0;312;cee03f0000000000
01T000006662;0;80;090b000062680880
01T000006662;0;81;590b000000103cff
01T000006662;0;105;924b0000436200fc
01T000006666;0;144;f981985801000000
01T000006669;0;b5;8405b40028000000
01T000006670;0;82;0301fe03fe030080
01T000006670;0;83;77010000ff000a00
01T000006672;0;80;0e0c000062680880
01T000006672;0;81;5e0c000000103cff
01T000006672;0;105;954c0000436200fc
01T000006672;0;147;00000000f0ffffff
01T000006674;0;10a;a31f80031d7f5402
I read savvy can was made to work with arduino due. Why not Go simple and use arduíno instead teensy? Librarys already made. If you want cheapier, you can use arduíno nano with mcp2515 and can hack. Works well, less than u$10.
can you send canbus data ? like sending a 10% throttle positon to the ecu to make the engine rev without pressing the pedal ?
For CAN signals the engine ECUs are expecting to hear from other CAN devices, yes. But for something like throttle, this won’t work because the throttle by wire is connected directly to the ECU(s) and not a CAN device.
I have one of this cheap bluetooh OBDII diagnostic interface, do you think it can be conected to SavvyCan software other than CL1000?
I don’t believe so. You might be able to find a supported device list on SavvyCANs website.
ok thank you!
16:34 What might those graceful curves looked like if the endianness wasn't the same as the default? Would those integers curves look like completely random data?
Yes exactly. Since endianness defines which direction bits are read and converted to decimal, the resulting values would be wildly different even though the bit values/positions are the same for both cases. Knowing endianness for a given DBC is critical because of this very reason.
@@DanDulac Thank you. I think the implicit part of my question is: As this Detailed Frame Information window doesn't have a control to flip the endianness, is there another place to do it, that would have the corresponding visual effect on this screen? (I'm thinking, no)
@@douglasheld the data we’re looking at in the Detailed Frame Information window is raw decimal values. We need to convert these values to the actual values that have meaning. We define this in the DBC file, referenced at 19:32-ish. When defining the signal, you select the little Endian (LSB) checkbox or leave it unchecked for big Endian.
@@DanDulac Great, thank you!
Will you have to put a smoothing (moving average?) factor into this data so the display is cleaner?
In the testing I’ve done, it appears to be fine with no smoothing function required. So far so good!
Is this something anyone can do on any vehicle or would it break warranty / insurance or anything? And do I need to worry about damaging anything?
You can do it on any vehicle. What I’m doing here is simply receiving (reading) the data. Transmitting (writing) data is a different story as you’re actually manipulating information; which could create issues if you don’t know what you’re doing. But receiving/reading data is harmless and won’t void anything. You do have to tap the twisted pair of CAN BUS wires but if you have basic wiring skills, no problem there.
It doesn't break anything and you don't loose your warranty or insurance.
Audi R8 has MLB CAN data
BO_ 1600 Motor_07: 8 Motor_EDC17_D4
SG_ MO_Ansaugluft_Temp : 8|8@1+ (0.75,-48) [-48.00|141.75] "Unit_DegreCelsi" Gateway_D4C7,Getriebe_AL551_951_D4_C7,Getriebe_DL501_C7,Getriebe_VL381_C7
SG_ MO_Oel_Temp : 16|8@1+ (1,-60) [-60|192] "Unit_DegreCelsi" Gateway_D4C7,Getriebe_AL551_951_D4_C7
SG_ MO_Kuehlmittel_Temp : 24|8@1+ (0.75,-48) [-48.00|141.75] "Unit_DegreCelsi" Gateway_D4C7,Getriebe_AL551_951_D4_C7,Getriebe_DL501_C7,Getriebe_VL381_C7
BO_ 1089 Getriebe_04: 8 Getriebe_AL551_951_D4_C7
SG_ GE_Sumpftemperatur : 56|8@1+ (1,-58) [-58|196] "Unit_DegreCelsi" Gateway_D4C7,Motor_EDC17_D4,Motor_ME17_BY,Motor_MED17_SIMOS8_D4
Awesome--thanks so much for sharing!! I compared this against my reverse engineered DBC and it's an exact match, with the exception of the TransATF temp; my bias was off by 2 (-60 versus the correct bias value of -58). Oh and now I know the proper min/max values for each. Thanks again for sharing!! If you have any other R8 DBC entries, I'd love to see them...
@@DanDulac I have a DBC full of data for MLB
@@jeroenr36 Wow! I would love it if you could share. My email address is supraholic97@gmail.com. This could be a huge time saver for me. 🙏
@@jeroenr36 Does your DBC file include the Malfunction Indicator Lamp (check engine light) and gear position data? These are two key items I’m missing. You’d be a life saver!
@@DanDulac Yes on PQ CAN it is -60, MLB CAN is different