Hey Matt - a good point of study for this topic is the general "OSI" model. (think of it like a pyramid) There is tons of study material out there. The osi model applies to all forms of networking protocols. Some protocols have a simplified communication such as CAN (3 layers) versus TCP/IP has 4. Each connected element to the network has to have the 3 layers of the protocol applied - The physical(bottom of pyramid) then it hands it up towards the data link layer (communication handshaking) and finally the application layer (scan data to user). If the scan tool wants to communicate a request, it does the opposite of de-escalating the steps down the pyramid. Example - scan tool asks for LTFT1 it gets converted to data link layer, becomes a waveform on the physical copper wires to the ECM. Once at the ECM the physical copper info escalates the pyramid to the data link layer and pushes it up to the application layer to interpret the ltft1 request captures info, stages it and de-escalates back down the pyramid towards the scan tool. This repeats a million times over. The same thing would occur say between a ECM and TCM commanding a change of gear and giving confirmation feedback etc. In the TCP/IP world, there is a tool out there called Wireshark that can see similar effects of escalating, de-escalating of the osi pyramid. Also wireshark can filter communications to only display stuff from a specific "source ip" or "destination ip" or even a combination of both. Chad was very knowledgeable and is definitely reputable as a guest. Good job! (I suspect his career is a network technician / engineer etc)
I'm an electronics tech (hardware). Dude did a good job explaining this stuff. I just don't think most people care to look at this stuff at such a low-level... I know I didn't. But it really is very practical once you get past the technical terminology. It all comes down to reads & writes.
A great continuation of auto engineering. So many techy terms though that make it complex to understand. The transmission of information is actually a process which can br related to sending a letter. We need an envelope(Data link), a delivery mechanism(Transport) and a letter(Object) The envelope contains the field that have the destiation address, The post office (Transport) understands how to deliver the contents to the object. The letter has fields,(sentances, paragraphs) The reader(object) can interpret the letter contents knowing the language and format used. Each element is separate and unique. If the letter is to be read by a French person, it must be written in French by the sender but the envelope knows nothing about the contents of the letter. It must have the address formatted in a way that the transport knows where to deliver the letter. Again the transport knows nothing about the contents of the letter. Hope that helps
I don't know if the picoscope can trigger on a digital sequence, but the logic analyzer can. You should then be able to trigger on the scan tool command to request LTFT, then you could filter out the PCM's response with the LTFT data. All comms have a priority, source, and destination module. The voltage levels on the logic analyzer must be programmable because CAN has weird voltage levels. Another toy I'll have to buy now.
Yes I am just learning this but it seems apparent you either need known goods to compare and see what’s missing or added OR you have to activate things to see the changes. will have to play with this
So I had almost the same problem, Okay first of all I will admit that before yes, I was one of those #shoppers at Auto-Zone -// parts changer. Then I grew up and found your channel and learned to walk with shoulders back. You would be proud of me cause now I'm picking up my leg to Waaz like a Big Dog. So what I found was that the connectors to my ECU had lost some connections so henceforth we have an open loop. After much research, I found that because I live in the desert all Dielectric grease had DRYED UP.So perhaps check ECU/CMD Connection and apply Dielectric grease. Ps that you for your Awesome Channel, I'm off the Porch.
I watched them 5 times and still have a long way to go hahaha!! What I need to do is make some more videos showing a bit more practical application. for example maybe intentionally grounding a module and seeing how we would identify it using these techniques.
Very informative video ,, Love the channel. Taking automotive diagnostics to the next level and beyond. Keep up the fantastic videos. Big thumbs up !!!!!!!
Another excellent video series... I found it fascinating. I was so glad you circled back to the Ford with the Long Term Trim that would not display ... I remember thinking after that video, that you actually conclusively proved that A) LTT was working correctly internally, and B) since multiple scan tools of a variety of age and capability all reported exactly the same thing, I am quite convinced that the manufacturer has a flaw in the documentation of how to read that data from the CAN bus and since all the scan tool makers read the same documentation ... well you know. It wouldn't the be the first time the engineering made some kind of change, (possibly last minute), that didn't make it to the documentation. Wouldn't it have been cool to be able to isolate the LTT CAN bus message and get the raw data? ...
EXACTLY my brother!!! Man I wish I could get that Ford back in here and try this. To be honest though, I am still not clear on how I would identify that a specific message at all, much less one for LTFT is missing… I still don’t know how to do that yet.
Very interesting. I wonder if this is how some scantools build a tapology map of the network. On the Nissan factory tool there are a few can diag options that show a map of the modules and shows in different colors who is offline and where breaks appear. Super helpful.
Yes I do happen know that is exactly how it works. what I feel like I am missing though is whatever “key” or “cross-reference” the scantool has to interpret those specific messages and know high are from what modules and even PIDs. I still haven’t, for example, figured out how I can transcode a frame and know what module the messages are from. Obviously the scantool can do that.
@@SchrodingersBox so there are two features I'm thinking of. One of them shows the map, and another just shows a text list of the modules and which ones responded. It makes me think that while the test is running, it's just pinging them one at a time. The test takes about as long as it does to scan all modules for codes. I've got a factor can workbook I'll take a peek in to see if it has any additional info.
The CAN bus is but only one of the networks to be found in the car. The OBD interface is a completely different protocol than what is being used on the main CAN bus. There are "bridges" and "gateways" that control data flow between the various networks. CAN is weird, it's not a point to point link. When a device talks, it's kind of a broadcast and there is no way to know what device on the bus is consuming the message. It's really unlike most network protocols that people might encounter, such as Ethernet or internet where there is a source address and a destination address in the frames. CAN just has a message ID, any device could potentially generate messages with the same ID.
That’s interesting thanks! That’s how it I understand it too- that all modules see all messages but only filter what’s necessary to them at the time. kind of like how I feel when I am on a conference call I guess hahahaha.
Great video. I do however find it troubling how many people with a mouse in their hand think I can with my eyes and a mouse not connected to my brain follow the pointer on a computer screen. Every time you say "this is the", I'm saying "what is the". At least go to your settings and not only color the pointer but give it a long trail behind it. Please. TH-cam videos don't have a "go back five seconds" option.
Am I understanding correctly? "Objects" generate a message that's too big to be sent all at once. The "transfer" layer breaks it down to frames containing "identifiers" which can be sent out into the network. Another "object" detects frames in the network that contains relevant data based on the "identifier" and collects them in the "transfer" layer which can then be read by the "object". Am I anywhere close? Haha would love to understand this stuff. It's obviously very powerful knowledge to have.
Although I appreciate the video, I think we forgot to demonstrate how an ID can be translated to identify a specific module.😢--or am I missing something?…
Nice work guys I can't wait for the follow up video. Here's a vid I highly recommend to watch it will help with your follow up video MASSIVELY th-cam.com/video/Bc2R462dlac/w-d-xo.html
Hey Matt - a good point of study for this topic is the general "OSI" model. (think of it like a pyramid) There is tons of study material out there. The osi model applies to all forms of networking protocols. Some protocols have a simplified communication such as CAN (3 layers) versus TCP/IP has 4. Each connected element to the network has to have the 3 layers of the protocol applied - The physical(bottom of pyramid) then it hands it up towards the data link layer (communication handshaking) and finally the application layer (scan data to user). If the scan tool wants to communicate a request, it does the opposite of de-escalating the steps down the pyramid. Example - scan tool asks for LTFT1 it gets converted to data link layer, becomes a waveform on the physical copper wires to the ECM. Once at the ECM the physical copper info escalates the pyramid to the data link layer and pushes it up to the application layer to interpret the ltft1 request captures info, stages it and de-escalates back down the pyramid towards the scan tool. This repeats a million times over. The same thing would occur say between a ECM and TCM commanding a change of gear and giving confirmation feedback etc. In the TCP/IP world, there is a tool out there called Wireshark that can see similar effects of escalating, de-escalating of the osi pyramid. Also wireshark can filter communications to only display stuff from a specific "source ip" or "destination ip" or even a combination of both. Chad was very knowledgeable and is definitely reputable as a guest. Good job! (I suspect his career is a network technician / engineer etc)
I'm an electronics tech (hardware). Dude did a good job explaining this stuff.
I just don't think most people care to look at this stuff at such a low-level... I know I didn't.
But it really is very practical once you get past the technical terminology.
It all comes down to reads & writes.
A great continuation of auto engineering. So many techy terms though that make it complex to understand.
The transmission of information is actually a process which can br related to sending a letter. We need an envelope(Data link), a delivery mechanism(Transport) and a letter(Object)
The envelope contains the field that have the destiation address, The post office (Transport) understands how to deliver the contents to the object. The letter has fields,(sentances, paragraphs) The reader(object) can interpret the letter contents knowing the language and format used.
Each element is separate and unique. If the letter is to be read by a French person, it must be written in French by the sender but the envelope knows nothing about the contents of the letter. It must have the address formatted in a way that the transport knows where to deliver the letter. Again the transport knows nothing about the contents of the letter.
Hope that helps
good analogy!!
I don't know if the picoscope can trigger on a digital sequence, but the logic analyzer can. You should then be able to trigger on the scan tool command to request LTFT, then you could filter out the PCM's response with the LTFT data. All comms have a priority, source, and destination module.
The voltage levels on the logic analyzer must be programmable because CAN has weird voltage levels.
Another toy I'll have to buy now.
Yes I am just learning this but it seems apparent you either need known goods to compare and see what’s missing or added OR you have to activate things to see the changes. will have to play with this
So I had almost the same problem, Okay first of all I will admit that before yes, I was one of those #shoppers at Auto-Zone -// parts changer. Then I grew up and found your channel and learned to walk with shoulders back. You would be proud of me cause now I'm picking up my leg to Waaz like a Big Dog. So what I found was that the connectors to my ECU had lost some connections so henceforth we have an open loop. After much research, I found that because I live in the desert all Dielectric grease had DRYED UP.So perhaps check ECU/CMD Connection and apply Dielectric grease. Ps that you for your Awesome Channel, I'm off the Porch.
Those two videos took a lot of watching to absorb the information, I will definitely have to watch them again. So cool, Matt, thanks for sharing.
I watched them 5 times and still have a long way to go hahaha!!
What I need to do is make some more videos showing a bit more practical application. for example maybe intentionally grounding a module and seeing how we would identify it using these techniques.
Great video. Tons of information. Looking forward to seeing/learning the application! Thanks again!
Chad my hat off to you, your amazing.
He really is. He is a very very bright guy and also has a really good character too. it was a pleasure spending thanksgiving with him!!
Very informative video ,, Love the channel. Taking automotive diagnostics to the next level and beyond. Keep up the fantastic videos. Big thumbs up !!!!!!!
Thank you very much!
Another excellent video series... I found it fascinating. I was so glad you circled back to the Ford with the Long Term Trim that would not display ... I remember thinking after that video, that you actually conclusively proved that A) LTT was working correctly internally, and B) since multiple scan tools of a variety of age and capability all reported exactly the same thing, I am quite convinced that the manufacturer has a flaw in the documentation of how to read that data from the CAN bus and since all the scan tool makers read the same documentation ... well you know. It wouldn't the be the first time the engineering made some kind of change, (possibly last minute), that didn't make it to the documentation. Wouldn't it have been cool to be able to isolate the LTT CAN bus message and get the raw data? ...
EXACTLY my brother!!! Man I wish I could get that Ford back in here and try this. To be honest though, I am still not clear on how I would identify that a specific message at all, much less one for LTFT is missing… I still don’t know how to do that yet.
This was an awesome lesson. Thanks so much. We all need some advanced training
Glad it was helpful!
Very interesting. I wonder if this is how some scantools build a tapology map of the network. On the Nissan factory tool there are a few can diag options that show a map of the modules and shows in different colors who is offline and where breaks appear. Super helpful.
Yes I do happen know that is exactly how it works. what I feel like I am missing though is whatever “key” or “cross-reference” the scantool has to interpret those specific messages and know high are from what modules and even PIDs. I still haven’t, for example, figured out how I can transcode a frame and know what module the messages are from. Obviously the scantool can do that.
@@SchrodingersBox so there are two features I'm thinking of. One of them shows the map, and another just shows a text list of the modules and which ones responded. It makes me think that while the test is running, it's just pinging them one at a time. The test takes about as long as it does to scan all modules for codes. I've got a factor can workbook I'll take a peek in to see if it has any additional info.
Can you put that part the decoder part number where to find it and soft ware?
Excellent video thanks
The CAN bus is but only one of the networks to be found in the car. The OBD interface is a completely different protocol than what is being used on the main CAN bus. There are "bridges" and "gateways" that control data flow between the various networks. CAN is weird, it's not a point to point link. When a device talks, it's kind of a broadcast and there is no way to know what device on the bus is consuming the message. It's really unlike most network protocols that people might encounter, such as Ethernet or internet where there is a source address and a destination address in the frames. CAN just has a message ID, any device could potentially generate messages with the same ID.
That’s interesting thanks! That’s how it I understand it too- that all modules see all messages but only filter what’s necessary to them at the time. kind of like how I feel when I am on a conference call I guess hahahaha.
Great video. I do however find it troubling how many people with a mouse in their hand think I can with my eyes and a mouse not connected to my brain follow the pointer on a computer screen. Every time you say "this is the", I'm saying "what is the". At least go to your settings and not only color the pointer but give it a long trail behind it. Please. TH-cam videos don't have a "go back five seconds" option.
You've only scratched the surface. CAN hacking/reverse engineering is a deep dark hole.
oh indeed!!! very aware that MUCH more is to come
Am I understanding correctly? "Objects" generate a message that's too big to be sent all at once. The "transfer" layer breaks it down to frames containing "identifiers" which can be sent out into the network. Another "object" detects frames in the network that contains relevant data based on the "identifier" and collects them in the "transfer" layer which can then be read by the "object". Am I anywhere close? Haha would love to understand this stuff. It's obviously very powerful knowledge to have.
Thats one for Chad lol. I still don't totally understand it!!
Nice explanation Matt, thanks forma share☺👌
Hello. What hp model is that in the video ?
Gpod job sharing
More please!
oh there will be!!! believe that!! I will continue to try and understand this and then bring a video when we get to make practical application.
I don’t see any links in the description.
yes all links are in part 1. I will fix it to add them to part 2 here soon, I forgot to do that
Although I appreciate the video, I think we forgot to demonstrate how an ID can be translated to identify a specific module.😢--or am I missing something?…
Does that guy have a channel
I don’t think so but he should!!
Nice work guys I can't wait for the follow up video. Here's a vid I highly recommend to watch it will help with your follow up video MASSIVELY
th-cam.com/video/Bc2R462dlac/w-d-xo.html
ww