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
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
Mike, 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
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
Hi Mike: 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
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
Mike: 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…
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
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?
Maynard: 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…
Mr Mark, 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
Maynard: Here is a link to the Wireshark program that I identified previously: csselectronics.com/screen/page/re… Mark
Mike, 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
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
Hi Mike, Using your example above what would the signal look like coming from the BCM to Tipm if there was request for headlights? Mike
Who knows. 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
Hi Mike, 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
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
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
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?
Pico does a good job of buss decoding. picotech.com/library/oscill…
That is really awesome thank you!
. . . . and Pico offers a video that is specific to CAN decoding and identifies the unique identifier; however, it does not indicate what module/node the identifier is applicable to. Here is the YouTube address for that video: youtube.com/watch?v=bNzKc… HTH - Regards, Bob
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
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
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
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
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 …
Hi Steve, Email me the PDF and I’ll get it embedded. … Thanks 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
Hi Mark, 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
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.
Hi Robert. 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…
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
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
Robby: 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
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
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
Mark, 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…
Hi Mike: Thanks for the response and comments. It appears that your mind is already convinced. Best of luck. Mark
Mark, 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
This boot camp sounds like a great opportunity, I'm going to try and make one of those dates next year.
Hi Bob: 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. Best Regards, Mark
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
Hi Bob, 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
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