Determining CAN inputs vs outputs via Scope?
I am working on a small project concerning CAN communication. What I would like to be able to do is to be able to identify inputs vs. outputs of CAN signals.
I figure it is a long shot but I wonder if I can somehow scope amperage of can signals to be able to see which module is sending the signal by whether the current is flowing + or -?
I am wondering if there is even any measurable amperage of communication signals and if so would a low amp clamp be able to use it. I could also see putting opposing diodes inline to help create a better pattern.
Are there any other tools anyone knows about that might help me accomplish this goal? Maybe some way to use diodes maybe even LEDs, and possibly resistors with a slightly higher resistance than the LED in such a way that they could be put run parallel to each other inline to the CAN circuit to identify signal direction? I know that can communication can light LEDs in DLC bob boxes but what I would like to do is show it on a scope. If I could show the CAN waveform on one channel and use another channel to only show the waveform when it is coming from one direction. I've attached a drawing I slapped together to help me visualize this but I could use some advise from some of the bright minds on here on whether or not this may work, what type of Leds or diodes to use, and if there is a better way to do this.
I've been wondering the same thing. I would imagine that a micro amp clamp would work nicely but I'm not sure if they can handle the bandwidth well enough to produce a usable signal.
I planned on trying but I haven't picked up a clamp yet. I thought that I heard that Eric Ziegler mentioned this in one of his network classes but I could be mistaken. I haven't attended that class yet.
Thanks. Do you know who makes the micro amp clamp? I did a little Google research but didn't see much.
Try Hantek. I think maybe the cc-65. As I recall, it goes down to 10 or 20 ma.
Thank you looks like it's only around $50!
I have an esi 695 and I don't see any specs but I also have access to a pico low amp clamp which says it goes to 10mA. I guess I'm just assuming that still might not be enough. I'm going to play around with it next week.
AEMC K100 & K110 seem like the most popular. Hans posted something of a comparison on here a while back. I think the K100 is more affordable and based off the feedback I've received, it should work fine for most of what we'd use it for in automotive testing. I would look close at bandwidth though. I think that's going to be very important with what you're trying to accomplish.
This would be helpful in so many cases. I thought I saw a mirco amp clamp somewhere.
I'm not sure you're going to be able do what you want to do by strictly checking voltages. Canbus packets are broadcasted to every module on the network. As the packet passes through a module it checks to see if the packet is meant for them. If it meant for them then it analyzes it takes any action if needed. If it's not meant for them then it's just passes it on to the network.
You would need a can sniffer to see individual packets. Even if you had that information you'd have to figure out what the packet means. Unless you're a software guy it would be tough to do what you want to do.
Specifically what I'm looking to do is learn a little more about scan tool commands but I would like to explore using this in diagnostic practices.
A while back I worked on a vehicle that had had the can wires to the cluster swapped and with a scope on the bus it was easy to see when the cluster was outputting a signal vs. signals from other modules on the bus. I would love to be able to recreate that but without swapping can wires.
When you hook you scanner it becomes a node (module) on the network. When you are trying to get into a specific module the scanner sends out a packet to the gateway module requesting information. The gateway module will determine which network to send that request to. It gets broadcast to that network and whatever module it is intended for will receive it and send back its own packet back to the scanner with information that was requested.
I understand most of that. I'm really just interested to see how much of the talking is done by the scan tool.
A few weeks ago we prepped for a scope course and I wanted to demo CAN waveforms and we were trying to figure out which vehicles to demo each signals so we hooked an aftermarket scanner to my buddies 2019 RAM and got nothing on the scope. He mentioned that he had just learned about the SGW in those trucks and that we would have to use the Micropod which I have but we ended up just doing the CAN waveforms on another vehicle to save time.
That later got me to thinking about what is happening on the bus. I believe we should have at least seen a signal from the scanner to request the vin as part of the auto ID so I am assuming something wasn't hooked up correctly. I am in the process of writing up some content on the new SGW and I want to scope the difference in the CAN com between the Micropod and aftermarket tools as the aftermarket tools are allowed to function in read only mode.
I also don't completely understand how the scan tool works. My assumption is that it sends requests for things like data streams and VINs among many other things but I would like to be able to see it even if I cant understand it. I wonder how much of the signals are the scanner talking vs. the scanner listening.
My thought is that the SGW might be a really good way to see this. I am hoping to see a significant change in the communication between the Micropod and aftermarket tools that might might help my project.
Are you trying to determine when ANY message is transmitted as an input or output?
If I'm reading your posting correctly (and please feel free to correct me), you want to use a scope to monitor CAN traffic and use an amp clamp, diodes, etc. to indicate when there is an incoming message and an outgoing message to/from a controller? Or, are you trying to determine if a controller has received a SPECIFIC CAN message and if there is a transmitted (outbound) response to that CAN message? Or, are you only monitoring the CAN line in general and don't have interest in which CAN messages are being transmitted and received?
I may be incorrect but, it sounds like you want to reverse engineer CAN messages to determine if specific messages are being transmitted to a controller and responses from the controller.
Please provide some feedback. This would help me understand the goal and create a more cogent response.
Yes I really would like to if and when a module is sending a message or in my case the scan tool. I'm not a software guy and I'm not really interested in decoding or interpretingbthe messages but more so verifying that they are present.
As an example I worked on a Chrysler a few weeks ago that was sending a false alarm command from the cluster to the TIPM. There was no information in the service information to tell us which module was in charge of determining the alarm signal. In the scan tool se were able to find a pod that showed the alarm as an input on the cluster and an output on the cluster. Because this was a constant alarm command I may not have been able to identify that particular signal.
But let's just say in a scenario we have a vehicle that has headlights controlled by a TIPM and commanded by a BCM with a headlight switch hardwired to it. If we were to isolate a fault between the TIPM and there were no useful data pids showing what the modules were doing then my idea is to be able to connect in the can lines between those circuits and be able to set a scope trigger to catch a signal that is consistent with turning the headlights on.
Based on your response, if you want to see which modules are sending and receiving CAN for specific messages, you'll need to reverse engineer the CAN messages or purchase the EOBD databases for each manufacturer (very expensive). But, the EOBD databases will provide all of the CAN info that you would need to perform diagnostics. Reverse engineering the CAN bus is inexpensive method but, it a real grind to identify CAN messages and which controller is sending them for each vehicle (not recommended.....it will suck the life out of you). If you want to reverse engineer, some of the tools you can get to reverse engineer are NeoVI Fire, PEAK P-CAN, Kvaser, Wireshark, Intrepid Controls, and others.
I wish it were easier but, if it was, everyone would be doing it.
hmmm, wireshark..! that provides alot of info on an ethernet line, wouldv' never thought to try tapping into a CAN line with it
Yep......it has a lot of tools to permit filtering by controller or message so, it makes it easier to target the result of what you’re trying see. Even if you don’t have the EOBD database CAN messages (the database that gives you the CAN message ID and it’s associated human readable meaning), with something like Wireshark (or similar tools), it makes easier to get the result you desire.
It is imperative that the tech knows which controller is sending a message and watch the CAN messages to see how another controller responds to it. CAN tools can do this.
I have absolutely no idea if how this could be done with a current clamp or scope. To properly and accurately analyze the CAN bus, you need a CAN tool.
In my opinion, trying to analyze the CAN bus without a CAN Tool is like trying to do an accurate suspension alignment using only a string......you’re just guessing.
So if one were to try one of these programs on the CAN line (like wireshark) what ineterface would be used? or can some hardwire adapter be made up to fit an Ethernet cable port on a pc?
A device like Wireshark has an small interface box that comes with 2 harnesses: One harness has a 16 pin DLC connector (for vehicle connection) the other harness will permit connection of the interface box to a laptop. The laptop will have Wireshark software loaded. That's it.
This will get you started.
The stuff with the microamp clamp, etc. and monitoring currents won't work. Ditto for using a scope. You can see CAN messages on the bus but, you still wouldn't know what they mean or which messages are being transmitted. The only way to monitor transmissions and responses of a controller or circuit is the monitor the CAN messages. Some components are on a LIN bus and use another controller as the Gateway, and the only way to know for sure if the component is working, the controller on the CAN bus has to be transmitting/receiving CAN messages. As an example, if an electric vehicle has a high voltage heater, it is likely on a LIN bus from the HVAC controller (that is on the CAN bus). Therefore, you would have to monitor the CAN messages while monitoring heater temp to see if it's working. So, it's more than just monitoring CAN. It's also monitoring the device mechanically/electrically while your monitoring CAN.
Well, I tried to boil everything down into on paragraph. I hope it made sense.
I keep coming back to this, I have not loaded wireshark onto any of my PC's in quite awhile, so I did it once again yesterday. There is a list of interfaces that show up in the "interface list" but they are all wifi or ethernet or usb labeled. I googled interface for wireshark and have not turned anything up. Would you be able to provide a link to and interface unit that would connect to OBD port and then into computer? Thank you!
And maybe I am looking at the wrong program...? I just download the free wireshark program.
The cluster would be broadcasting many packets. As you can imagine there is a lot of information that would be shared between the tipm and the bcm. That is a high traffic network. I don't know how you would be able to decipher what packet contains the information you want to know without CAN sniffing and then knowing what the desired packet looks like.
If you are on a slower low traffic network or a linbus you might be able to see activity happen. You can see a window switch on a linbus that is requesting the window to be lowered. It would be much more of a challenge on the network between the BCM and TIPM.
I would assume it would be difficult to identify but in the case of that cluster with swapped CAN wires it was actually hard to find the signals from the cluster vs. the other traffic. In fact, I almost missed it because there was so little messages being output from the cluster vs. What was input.
I know that this strategy would not be ideal in most instances but picture it this way using the headlight system I described earlier. Using 4 channels on a scope I hook up the two can lines of that circuit. Then the 3rd channel goes to a 12v signal from the headlight switch and then finally a 4th channel goes to an amp clamp or some device that is able to tell me which direction the signal is traveling.
I set my scope up to trigger off of the headlight switch and if I can see a consistent signal that is output from the BCM that correlates with the headlight switch command than I would be more comfortable assuming that the BCM is doing what it is supposed to. I'm not necessarily trying to read the signal although it would be cool to be able identify it and it would be really cool to use something like the launch signal generator to try and command headlights on but I'm really just looking for a way to use this method for practical diagnostics.
After all nobody likes having to cross their fingers pulling the trigger on thousand dollar modules. Even if I wouldn't get accurate results everytime I would still likely try this in certain scenarios if I could find a way for it to work.
Using your example above what would the signal look like coming from the BCM to Tipm if there was request for headlights?
What I would be looking for is that there is a signal.
We could assume that the headlight command signal would look the same everytime right?
So if I was able to see a signal that looked the same, was an output from the BCM, and was sent from the BCM at the same time my headlight switch was switched on I could assume that it is the headlight command signal correct?
I do understand that the BCM/TIPM may be a bad example to use because of the high traffic but by using a trigger in that fashion wouldn't you think it may be possible to pick a signal out?
I will include a photo of the swapped can wires case I mentioned. My thought is that if there were a way to visually seperate in coming from outgoing messages (which is what this waveform inadvertently shows) that it might not be as hard to identify them. I could be wrong but it would seem that something like a headlight signal should be almost instantaneous so there might not be a need to go through a ton of data. Being able to "highlight" in a sense only data from the BCM I wonder if it would be easier to pick out? I am just wondering if there is an easy way to differentiate which way the signal is traveling.
You said you you found the signal. What did it look like? The signal should be a software packet. A standard CAN packet contains 11 fields (newer ones have more fields). If you were to scope it with no traffic you should ~2.5 volts steady on both CAN high and CAN low. When a packet comes to the network it will be 11 fields. To generate a zero (software guys use a series of ones and zeros) simultaneously CAN high will go to 3.75 volts and CAN low will go to 1.25 volts. That creates a differential voltage of 2.5 volts. When the software engineer wants to create a one the voltage on both CAN high and CAN low remain the same at 2.5 volts which means there is no differential and that constitutes a ONE.
You can scope the structural integrity of the software packet by looking to see if the voltages are switching and clean but you can tell what they mean. Arranging to 1's and 0's in different order mean different things.
Yes I understand that.
Are you saying that the software packet for the "turn headlights on" command will not be the same every time?
It will be the same but on a high traffic network I doubt you'd be able to see it through a scope pattern. Way too much traffic and it's really fast.
Read up on the link that Bob sent you. You can see the scope patterns but there are so many and they buzz by fast.
If you have that device it will have the capability to decipher the can packets into individual fields for each packet. If you look in the second field that is where the unique identifier is. That is how the module knows that message is for them. I don't know how the Pico tool works but the one I used you were able to filter out every other signal that didn't have that unique identifier which allowed you to see status changes.
The issue is knowing what that unique identifier is for each module. If it's a powertrain module there is plenty of information out there because every manufacturer is required to disclose that information. If its a body control module it's more challenging because that's considered proprietary it would have to be reversed engineered.
I don't really see a value in trying to interpret every message on the CAN bus for what I would like to do. If it is not practical for diagnostic purposes I am really not interested in pursuing it. I like the idea of using the unique identifier portion of the packet to determine where the module is headed but that is not the information I am after. Let's step away from the high traffic BCM for a moment. Let's say we have a module on a low traffic bus like a window switch module you mentioned. My assumption would be that on most vehicles that window switch module would only be outputting a signal when a window command is sent. Let's say we have a passengers window that is inop from the drivers switch. If we could throw an amp clamp around a CAN line at the switch that we could trigger to show only outgoing messages, and then operate the switches and see outgoing messages being sent for all switch operations except passenger switch command would that not help us with our diagnosis without requiring us to identify the content of the message? Simply put, from a diagnosticians point of view, I see value in knowing not what the message is but what direction the messages are going. Hopefully this helps clarify? I am not sure that it may be simple as reading the flow of amperage with a probe which is why I pitched the question.
I wasn't really advocating this as a good diagnostic tool. I like you would like to know if I press the window switch did the message actually get to where it was supposed to go. If it did was the appropriate action taken by that module to make the window go up or down.
I assume that is what you would like to see/know also. Is that correct?
Also what is "CAN sniffing"? Is that just a term for trying to identify the packets or is there software or a process for that?
If you read my post above you know that each software packet contains a bunch of ones and zeros (software code). The order in which they are organized means something different.
A CAN sniffer takes those signals and converts it into a software developers language. That is where you'll be able to see changes when you push your window switch. Every time you press the window switch you'll see a field appear then go away when you let off of the switch.
That is about the extend of what I have done. It sounds like it would be easy and probably is for a software guy but I truly don't understand the technical side of actually reading and writing code.
If you are a young guy in the field I think you should spend some time trying to learn this stuff as I think it will be even more prevalent in the future.
I dont think you are understanding what I am saying.
I am not concerned with trying to read the signal.
I am trying to identify duplicate signals in order to tie them to a command.
If I turn the headlights on we could reasonably expect that command to happen within let's say 100mS but probably much less wouldn't you agree?
Now imagine we have a way to identify incoming from outgoing packers. I'll use the swapped CAN waveform as a visual.
Now of we scan the 100 mS after the headlight switch that we triggered off of and we see a packet that looks identical every time the headlight switch is turned on we could assume that is the "headlights on packet" wouldn't you say?
I am not thinking this may be an easy task especially on a high traffic network but I have not attempted it yet as I would first like to learn to identify the direction of signals first.
Mike, the CAN image you posted is way too low a resolutio. The large groups at .6 .7 and .9 time are really clumps of signals. In order to interpret who what or why you would need to see each pulse. I asked a gener question about what scope I would need to see the signals at that resolution. About 15 years ago I got a reply from Randy Bernklau. He was stating that to do what I wanted I would need a CAN reader or some such (been along time). Too many signals, too fast. My MB scanner Xentry comes with a CAN signal reader. If you would like a copy of what and how it works. I would be glad to send the documentatio. I’m on my phone at the moment, I’ll try to post it here tomorrow.
I used that waveform to show the transition between an incoming and outgoing message on the bus. In that instance CAN wires to one module had been swapped. When that module was sending a message the CAN signals essentially switched colors on the screen. This created a visual indication of incoming and outgoing messages to the cluster. That is interesting about the Xentry tool. That is the last tool on my list to purchase as a mobile tech. I may be a ways out just yet though!
I recommend a book. The car hacker's handbook. Also, without going into much detail, research a program called Kayak. It records, plays back and defines CAN definitions. It works on any platform. It is a super powerful program.
I have a 5m pdf file that I was going to load here, but it seems that only images are accepted. If you would like to see it send me your email address to …
Email me the PDF and I’ll get it embedded.
FYI, we‘re testing the new file upload system now and it soon will be ready for production. Sorry for the trouble.
Seems to me what youre saying is that you want to see the "on" or "off" command sent via a CAN bus to a specific item,yes? It also seems to me that the people responding are saying there is never just 1 command on a CAN wire and even if you see the same signal over and over,you have no way of knowing if the specific command you are looking for is in the messages being sent out by just using a scope. I think they are saying you HAVE to be able to interpret the message being broadcast in order to determine if it is what you're looking for.
Each module has a transceiver that analyses information packets that are broadcasted on the network. There is a unique identifier in each packet that tells the packet is meant for them. If it recognizes it is a packet for his module it passes it into the module for interpretation. If it is not meant for his module it just passes it on so it can go to the right module.
There are different types of packets. Most packets contain data that other modules need such as cts, vss or rpm. A message could contain a request for data or status.
You can scope the network and see packets but you won't know what they mean.
I would suggest constructing a gateway and placing it between the target node and rest of the network. That way you can see which part of the network each packet came from.
I think you would still have to sniff packets because packets from every module on the network are sending messages one right after each other.
A CAN sniffer is another node in the network. As the packet comes through the transceiver it is recorded and sent on.
Unfortunately without very advanced techniques like oscillator fingerprinting, or knowledge of which IDs are transmitted by which controllers, you need to physically separate the nodes to figure it out.
Hoping Brandon Stecklar will chime in as we discussed this recently, he has done some testing and has determined that a micro amp clamp will show current, and he does have some theories and I believe some data that he collected while trying to make a useful analysis with this technique.
Hi Mike, I'm a little late to this thread, so I haven't read all of the responses. I'll be reading up that later.
I've played around with the K110 on CAN in the past. Take a look at this CAN waveform:
That's from a 2015 Chevrolet Malibu where the HVAC module would not communicate. Periodically, I would get 12v spikes on the LS CAN. If I unplugged the HVAC module, the spikes would go away. Just for giggles, I put my K110 on the LC CAN wire.
Here's another example of me playing around measuring current on HS CAN (+)
The amp clamp has a slow response when compared to the frequency of CAN so keep in mind the current waveform will have very little detail. Also, the phase of the waveform will be shifted from the actual timing of the CAN signal. You could use a math channel to shift the waveform "in time".
You're not going to know what inputs/outputs are happening. You might could decode CAN while using the current waveform to find a pattern of message IDs, but that really wouldn't help much since it's not likely you'll figure out what the message IDs mean.
Robby, That is interesting. I guess I wouldn't be surprised that it is a little slower.
I think I am missing something on this whole idea though. In my head if we were using a simple CAN system with two modules, the current you are measuring would be coming from whatever module is sending the signal and that current is flowing from the origin outward on the can wires which is how we are able to measure the current. If that were the case then we would be able to determine incoming vs. outgoing messages with current as current in one direction would show a + value and show a - value in another direction. So what am I missing? Maybe I need to refresh my electrical theory as it applies to communication signals?
Is that 2mA? Thanks for sharing these!
If you only had two modules, then you may be able to tell whether the module is receiving or transmitting. As others have alluded, figuring out the details of the message is a totally different story. Now you're getting into CAN hacking. It is possible without the manufacturer database, but it's waaaay above my level. To get an idea, spend a little time watching this:
The really cool thing about that video is they explain how they hacked into some late model Chrysler vehicles which, in turn, prompted Chrysler to issue a recall to prevent that from happening.
in my opinion, the value of technicians can be significantly enhanced when they can successfully manipulate electronic and software systems. Understanding electronic devices more thoroughly and writing & coding small software scripts would go a long way in reducing diagnostic time and the dependence upon pattern failure diagnostics. As systems continue to advance and iterate, pattern failures will fade thus, requiring the tech to truly root cause a failure.
CAN hacking is just another avenue of manipulating software......and is a skill that isn’t necessary but, would make life a lot easier for techs. It’s not for every tech but, those that want to become an invaluable resource to themselves, employers, and the industry at large will take the opportunity to advance their skills.
In my opinion, for auto techs and instructors to enhance their electronics, software and CAN skills is a matter of will.
The opportunities are there.......those that want it will execute and take it.
Thanks for sharing. I had read a little about that Jeep story a while back but I've never seen that video.
While it would be nice to be able to interpret the messages I would assume that even for someone who is very familiar with CAN hacking the time involved in that process would not make it usefull in diagnostics. Especially because most of our diagnostics situations do not include a known good to begin with so I don't see any value to CAN hacking for the diagnostician.
I could see being able to discern whether messages are being transmitted or recieved being useful. Nowadays everything is a module. Trouble tree diagnostics is often "replace module X, if concern is still present replace module Y". It would be nice to have something even if it wasn't foolproof that would help guide us in these situations.
Hi Mike (and others who are following this thread):
While I appreciate your (Mike's) comments, I have to respectfully and professionally disagree.
In your original post, you were asking about the possibility of using amp clamps, LEDs, etc. to discern CAN message traffic for the purpose of identifying inputs and outputs (summarizing here). I suspect that you've learned that this likely cannot be accomplished. So, this leaves you with the options of learning a little more about CAN and some of the associated tools that a diagnostician would use or, keep replacing module X or Y when using the diagnostic charts.
In my opinion, the job of a diagnostician is to use available tools and training to diagnose a problem. I'm surprised that you don't find any value in CAN hacking. Have you ever tried it to know whether it has value and the different levels of its value? With CAN, and the upcoming move to Ethernet on vehicles, you will likely start getting pulled into the world of digital communication in one way, shape or, form. I also think understanding electronic devices and how to manipulate them is just as important but, that's a topic for another thread.
When my partner company first spoke with Scott Brown about the launching of the Diagnostic Network, and his goal of providing its members a much richer (deeper) forum of discussing and solving diagnostics, I had no reservations about helping with its launch and posting about diagnostics, and desired to help Scott make this a great thing. I'm also doing the same with engineers through the SAE. With almost 20 years of my 28 years at General Motors Engineering developing diagnostic and control systems for all of their electric and hybrid products through 2012, I had thought that Diagnostic Network would be a great place to offload some of my experiences and offer some advisement - and gain some new insights from others (I love to learn). I still believe this but, not convinced yet that, technicians (at large) are willing to take the deeper dive into the world of electronic devices and software. Engineers have made the leap decades ago.......because they are forced by competition and governmental compliance. In short, engineers have to create or, die on the vine.
So, to help technicians and instructors begin to hone the deeper electronics and software skills, I've already committed to helping them by offering a 5-day short course on electronic devices and learning how to write and the basics of coding software by working on real circuits (futuretechauto.com/swbootcamp.htm…) - and no, this is not a commercial for the class, it's about demonstrating commitment. We're also offering a Level 2 and 3 course on the same topics. By knowing those two areas, a technician can begin to create their own tools without having to always rely on the scan tool or the scope. They can create tools that can be stand-alone or be used to augment them. As the products move quickly into more electrification and autonomous systems, it will be more important than ever that technicians and instructors have "flexible" skills. Flexible meaning that they need to have a more comprehensive understanding of electronics and software to create some of their own solutions, if necessary. I've already committed to technicians and instructors to help them transition into the next phase of the automotive sector (electrification, autonomous, etc.). I'm waiting to see if technicians and instructors are as equally committed. As a former technician, I'm pulling for every tech in the field.
In closing, I'm hoping that you and those reading this will take the posting as it was meant: a time for professional awareness, self-awareness, reflection, and a call to action. Basically, determine where you are today and where you need to be with your diagnostic skills (self assessment). Like it or not, automotive products are almost exclusively electrical, electronics and software driven systems - so, you'll need to at least tolerate it, and then manipulate it so it becomes your friend.
Enough of my rant............I sincerely hope that this has helped.
I appreciate your passion for the subject but I cannot envision a scenario where even someone highly experienced in CAN hacking could use that skillset to effectively diagnose a vehicle in the field.
Correct me if I am incorrect but if a technician got to a point in their diagnostics where CAN hacking could be useful it would likely be to verify if a signal was being sent or received. If that technician knew how to identify that signal they could confirm whether it was being sent. Since that is proprietary information we would need to figure this out using known good signals correct? If I can't find a known good CMP signal for for a 2012 Malibu how am I supposed to find a "window down" command signal? A database? Another identical vehicle?
I am not saying it is not possible I am saying it is not practical. Believe me I would love for you to change my mind on this.
As for using amperage to identify inputs vs. outputs are you saying that the amperage of a CAN waveform will not be directional based on what module it is being sent from?
Thanks for the response and comments. It appears that your mind is already convinced.
Best of luck.
Without intentions of being antagonistic I am truly interested in learning if CAN hacking has a place in the diagnostics space? I listed the reasons why I don't see it being practical above but maybe I am misinformed? Again, I would love for you to convince me otherwise.
If determining signal direction cannot be accomplished by measuring the amperage of a CAN signal than I would like to learn why and what I am not understanding. Is there something you might recommend for me to read/research?
This boot camp sounds like a great opportunity, I'm going to try and make one of those dates next year.
The Boot Camp Class scheduled for March 2019 in Las Vegas will be running for sure. We’re unsure if the other 2019 dates will be running as of today. If you can make the March 2019 class, this would be the optimum time.
Sorry, late to the game, but I agree with Mark. The OP should (needs to?) take some form of CAN Communication course, either the boot camp or maybe the SAE CAN Comms class. Many have shown great patience trying to piecemeal different parts of the CAN lesson together here, it is impossible to give all the information in this forum. I'll try a few more basic points. A CAN signal is a differential square wave - basically a form of alternating current living in the automotive direct current world. Therefore, no "signal direction." Not sure that any current readings are useful here. 11-bit addressed CAN messages are generally 10 bytes (80 bits) long - CAN identifier (2 bytes) and 8 data bytes. (This changes slightly for 29-bit addressed messages). CAN communication from the DLC side is request/response, i.e. the tool sends a request message (e.g. ECT), and the vehicle sends a response message. At a 500 kbit/sec transmission rate, a normal request/response is over in … = 320 microseconds. Unless you are setting a trigger/stop on your DSO, you may see just a blip when the scan tool asks for data. VIN is a multiple message response, but still < 1 millisecond. I'd say, take the (a) course to get an understanding of how CAN fully operates.
Thanks for chiming in. I'm not sure if this is your area of expertise or not. The biggest challenge I have is with intermittent communication codes where the voltages and the resistances are correct and the waveform of the packets are seemingly good but I still get a U codes.
I have a couple of questions of how information is shared amongst the different nodes. If a node is broadcasting some data that needs to go to more than one node, are there multiple messages sent by the sending mode with the same message just different identifiers or is the message sent to one node and he passes it on to the next guy who needs it?
Also, how do you as a programmer know the difference between a missing message and a corrupt message (like missing acknowledgement)?
Lastly, I understand the concept of arbitration where one message may be more important than another. Is there ever a situation where the message that wins the arbitration battle does not receive acknowledgement from it's intended node and just keeps sending the message in sense "clogging" the network?
Hi Mike, The operative word you used here is "seemingly." Unless you know that all the bits in the waveform are correct, you are shooting in the dark. One bit failure in a message, by a malfunctioning module can cause a U-code and/or MIL. Unfortunately, the answers to your questions are all "it depends" on the implementation of each OEM's approach to these scenarios. There is no one specific way that we do these things, but generally we adhere to the error handling methodology in the ISO CAN standards. That's probably a good place for you to begin. As above I highly recommend either the CAN boot camp or SAE course.