Oscilloscope Confusion!? lol :(

[871auto]

I'm new to using an oscilloscope.  I bought one a while back to check for clipping in audio signals in and out of amplifiers.  But now, I am using them to play around with learning how the Automotive CAN BUS operates.

My confusion is to do with the time scale.  Here's why:

If a typical vehicle CAN BUS operates at speeds of up to 500kbps, or 500,000 bits per second, and each bit can be a binary "1" (2.5 volts approx.) or "0" (3.5 volts on HI and 1.5 volts on LO approx.), how can ANY oscilloscope ever "keep up" and actually be able to display ever single change in the waveform?  Doesn't 500kbps mean theoretically the waveform could change 500,000 times in just 1 single second of time?

This is what I'm lost on!   It seems like CAN BUS would operate way too fast for a scope to ever be accurate?  How could I ever convert the voltage data to binary in order to be deciphered?  Or is that just impossible?

Here's some stuff I've read, but on one answers this question of mine:

https://en.wikipedia.org/wiki/CAN_bus

http://www.testandmeasurementtips.com/exploring-canbus-oscilloscope/

http://www.interworldna.com/pico/automotive/canbus_scope.php

Thanks everyone, sorry if this is a dumb question!

[tautech]

Even a slow scope can resolve waveforms many times that speed.

Triggering is the key....set the Trigger parameters to what you need to see and the display with be stable.
Look into the CAN Trigger operators you have available and set them for your needs.

[eysi]

wouldn't it be easier to use a logic analyzer?

[871auto]

OK thanks tautech.

So what you're saying is that the visuals on the oscilloscope screen doesn't necessarily mean that's what's happening at that exact moment on the data bus?  In other words, if I tried to see ALL of it, it would just be going crazy on the screen, but if I slow it down, I can see it in slow motion but not miss any data bits?  I just want to make sure I don't miss any data bits.  But, if what you're saying is I would be viewing the "past" or "history" on the scope and not necessarily real-time data, then I think I'm OK?

Or am I more confused now? lol

[katzohki]

Here's a few things to read up on:

Nyquist frequency - In order to sample a signal without aliasing you must have a sampling frequency at least twice that the frequency of that being measured (more than twice, in practice). This, in theory, is only 1MHz in your example.

Sweep speed - If you were to sweep the (analog) oscilloscope 500000 times per second you would probably only see one transition of the data. In practice you will want to see probably a whole byte (8 bits) or maybe a few bytes.

Sample Rate - A (digital) oscilloscope, (e.g. the popular Rigol DS1000Z), could have a sampling rate of 500 Million samples per second. Although your bitrate is 500kbps, that oscilloscope is sampling at 1000 times that rate.

In short, yes you can absolutely measure a CAN bus using an oscilloscope. You wouldn't even need a good one. A lot of digital oscilloscopes will have an option to automatically decode the CAN bus as well.

[ataradov]

It should be noted that you can forget about analog scopes, here they are useless. [/me hides from all analog scope fansboys]

Even the cheapest, most basic scope will have at least 200 MSPS, which is plenty to capture 500 kHz signal.

[barry14]

Consider a 1 MHz square wave.  One period occupies 1 microsecond.  In that 1 microsecond, the level of the square wave changes twice.  This is the same as a digital data stream running at 500,000 bits per second for which each bit is the opposite of the one before, i.e. a 1 is followed by a 0 and a 0 is followed by a one.  It is usually considered sufficient if an oscilloscope has a bandwidth at least 10 times that of the square wave it is trying to display.  Thus the 1 MHz square wave could be displayed on an oscilloscope with a bandwidth of 10 MHz.  If the time base of the oscilloscope is set to 1 microsecond per division, you would easily be able to view each bit.  Now consider that there are oscilloscopes available with bandwidths as high as 100 GHz (i.e. 100,000 MHz), and you can see that displaying high data rate digital data streams is well within the present state of the art.

[ataradov]

But, if what you're saying is I would be viewing the "past" or "history" on the scope and not necessarily real-time data, then I think I'm OK?

Exactly. The typical workflow is following: setup a trigger condition -> wait for a trigger event -> capture as much data as memory allows -> look at stored data all you want.

[tautech]

OK thanks tautech.

So what you're saying is that the visuals on the oscilloscope screen doesn't necessarily mean that's what's happening at that exact moment on the data bus?  In other words, if I tried to see ALL of it, it would just be going crazy on the screen, but if I slow it down, I can see it in slow motion but not miss any data bits?  I just want to make sure I don't miss any data bits.  But, if what you're saying is I would be viewing the "past" or "history" on the scope and not necessarily real-time data, then I think I'm OK?

Or am I more confused now? lol

You're getting your head around it.....realtime, no. Close to realtime, yes.

You don't say if you're using a CRO or DSO.
Split screen mode is real handy for decoding, it allows you to see the full conversation at slow timebase settings while the detail is seen in the Zoom window (faster setting) in which you can pan along the unzoomed window examining it in the zoomed window. Hope that make sense.

Or like this:

But, if what you're saying is I would be viewing the "past" or "history" on the scope and not necessarily real-time data, then I think I'm OK?

Exactly. The typical workflow is following: setup a trigger condition -> wait for a trigger event -> capture as much data as memory allows -> look at stored data all you want.

[871auto]

OK, I think I'm starting to get it, but perhaps need to back up to the basics for a second. lol.  I'm so used to audio stuff, not raw data like can bus stuff.

So, basic question 1)  Oscilloscopes only work with frequencies, right?  So, 500,000 bits per seconds is the same thing as 500 kHz when talking scopes?

The scope I want to use is just handheld because my home scope is obviously too balky to take with you inside a vehicle all the time.  It's rated at 10Mhz with a realtime sampling rate of 40 mega samples per second, which I have no idea what that even means? lol  Why the word "mega"?  It also says AD Resolution is 8 Bits?  Not sure what that means either?

Anyways, when I'm hooked up to my own vehicles can bus, and I adjust the time scale to slow down, is the scope still going to show all the same information it would have if it was going crazy fast across the screen?  When I adjust it, am I basically just equivalent to slowing a movie down on bluray/dvd?

Oh yeah, one last question is:  How do I know how much of the waveform I'm seeing represents just 1 bit?  If a bunch of 1's or 0's are sent in succession, how do I know if it's 5 or 10 or 15 in a row etc.?  When I'm looking at the screen, it's almost impossible to tell?

Sorry again if these questions are annoying!? lol  But I truly appreciate the help and really want to understand it better.

[ataradov]

So, basic question 1)  Oscilloscopes only work with frequencies, right?  So, 500,000 bits per seconds is the same thing as 500 kHz when talking scopes?

Not at all. You want to have at least 10 points of digitized signal per bit, so you need a scope with 5 MSPS capability to reasonably sample this signal. You can do with less, but it may not be the best experience.

The scope I want to use is just handheld because my home scope is obviously too balky to take with you inside a vehicle all the time.  It's rated at 10Mhz with a realtime sampling rate of 40 mega samples per second, which I have no idea what that even means? lol  Why the word "mega"?  It also says AD Resolution is 8 Bits?  Not sure what that means either?

Because "mega"  goes after "kilo". 40 MSPS == 40 million samples per second.

PS: https://en.wikipedia.org/wiki/Metric_prefix

Anyways, when I'm hooked up to my own vehicles can bus,

Unless your scope has dedicated CAN bus decoder (and it probably does not), forget about it. You will not be able to reasonably decode stuff manually for any sort of data volume.

Laptop and a logic analyzer will be much better, but I see no reason to connect anything to a car, unless you absolutely know what you are doing. You risk to kill all devices attached to CAN bus, essentially killing a car.

[871auto]

I guess I see what you're saying, but I failed to mention I co-own an automotive shop in my city and we specialize in electrical diagnosis, air bag replacement, programming, module updates, immobilizer programming etc.  So the reason I wanted to know was just to add something to my own knowledge, not necessarily to diagnose or decode or debug the CAN BUS just by watching a waveform. lol  I know I'm not that good.

The best article I've found on what I'm talking about is actually here:

http://copperhilltech.com/content/CIA_article.pdf

As you can see, in image Fig. 2, it shows a waveform which is just the differential voltage between CAN hi and CAN lo, and somehow using that, they can determine that ECU ID # 010 (in HEX) is sending a data signal of 055 (in HEX).  This is really all I want to do.

Lets say for example, one of our many scan tools, some of which are OEM, are not communicating with a vehicle, yet it starts and runs fine and has power/ground at the obdii connector, I want to be able to tap into the CAN BUS and see what modules are sending and receiving data.  Assuming this is possible?

But again, I thank you all for helping me understand the oscilloscope itself much better.  I found a company that does sell logic analyzers for a decent price with can bus decoding.  But again, this is not really the goal in the sense I don't want to manually sit down and try to figure out an entire waveform.  That wouldn't be the greatest use of time. lol

[ataradov]

As you can see, in image Fig. 2, it shows a waveform which is just the differential voltage between CAN hi and CAN lo, and somehow using that, they can determine that ECU ID # 010 (in HEX) is sending a data signal of 055 (in HEX).  This is really all I want to do.

Yes, it is possible, but there thousands of those massages going around from all sorts of systems. They showed some random frame they have captured as an example. This is easy. The hard part is to capture a frame you need in some specific situation.

That's why they later switched to a logic analyzer, or even better, dedicated CAN bus logger.

Lets say for example, one of our many scan tools, some of which are OEM, are not communicating with a vehicle, yet it starts and runs fine and has power/ground at the obdii connector, I want to be able to tap into the CAN BUS and see what modules are sending and receiving data.  Assuming this is possible?

Yes, but given the amount of stuff on that bus, it is impractical with cheap scope.

[katzohki]

Even a cheap scope would give you the ability to see at least noise / interference on the bus, check the proper frequency, what lines are sending data, packet is sent but not returned and probably a few other things. Not a cheap scope, but I've analyzed serial comms simply by seeing that Rx had data, but Tx doesn't or the voltage is too low etc.

At any rate, if you want to look at a CAN bus look at the CAN bus and have fun. 

[871auto]

So ataradov, are you saying that watching the waveform on the scope in "real time" isn't really giving you a single frame from start to finish?

I guess I just assumed that if I watch it "live" and pick-up a total of about 60 bits of data, give or take some for bit stuffing, I could possibly decipher a frame?

But, you're saying that the data I'm looking at might be from different modules sending different data?  I know that with CAN, only one module is allowed to send a message due to the arbitration rules, but I guess that doesn't mean other modules aren't trying to send their data as well?

This frame thing has me more confused now. lol

[ataradov]

So ataradov, are you saying that watching the waveform on the scope in "real time" isn't really giving you a single frame from start to finish?

It will give you a frame, but unless you are looking at one device in isolation (no other devices on the bus), how would you know that this frame you have triggered on is not from some other module?

That's where you need a scope with advanced triggering, so you could trigger on ID. But doing this manually for any sort of production work is insane.

I guess I just assumed that if I watch it "live" and pick-up a total of about 60 bits of data, give or take some for bit stuffing, I could possibly decipher a frame?

You could. Then you will find out that this frame is from a brake light, discard, repeat capture, find out this one is from TPM, discard, etc.

But, you're saying that the data I'm looking at might be from different modules sending different data?  I know that with CAN, only one module is allowed to send a message due to the arbitration rules, but I guess that doesn't mean other modules aren't trying to send their data as well?

Exactly, everything is trying to send at almost the same time, they obviously only get access to the bus after arbitration. But that does not help you.

[BenKenobi]

As somebody that is into this 'stuff' and also a 'noob' I figured I needed a scope like yourself but I did a mountain of research before settling on a storage scope that has at least rudimentary logic abilities - a DSO running at 100MHz - a better option would have been an MSO since this come with both digital and 'analogue' type probe capabilities. A logic analyser just wasn't a broad enough brush, I needed something more specific.

Unfortunately without the ability to first see the packets of data and then to analyse them. Without a logic analyser or a storage scope you're wasting your time, even then a storage scope that doesn't store enough will make life miserable, you then need to be able to zoom and move around what you captured, decoding automatically with scopes comes at a high price if you're prepared to pay it but protocol decode is logic analyser territory really.

I ended up spending twice what I originally budgeted but it was the correct decision.

There are all kinds of ways that Canbus devices can mess you up, for one some devices require an 'authentication' - such as immobilisers / ABS / Airbags - if your device doesn't authenticate properly then they won't talk to your device or if they do they will seriously limit what you can access. Many manufacturers need specific cables, the car knows if they aren't correct and although some Chinese clones 'appear' to work I wouldn't recommend their use. If the OEM ones aren't talking then this is likely a version issue, I had to replace a couple of my cables recently because anything newer than 2015 wouldn't talk to me.

[David Hess]

So, basic question 1)  Oscilloscopes only work with frequencies, right?  So, 500,000 bits per seconds is the same thing as 500 kHz when talking scopes?

Instead of thinking in terms of bandwidth, think in terms of rise and fall time.  Your 10 MHz oscilloscope has a rise and fall time of 0.35/BW or 35 nanoseconds.  500,000 bits per second is 1 bit per 2 microseconds which is more than 50 times longer than the rise and fall time of the oscilloscope.

The scope I want to use is just handheld because my home scope is obviously too balky to take with you inside a vehicle all the time.  It's rated at 10Mhz with a realtime sampling rate of 40 mega samples per second, which I have no idea what that even means? lol  Why the word "mega"?  It also says AD Resolution is 8 Bits?  Not sure what that means either?

40 mega samples per second means exactly that.  The oscilloscope can acquire 40 million samples in 1 second or 1 sample every 25 nanoseconds which is consistent with the 35 nanosecond rise and fall time from the 10 MHz bandwidth.  That is plenty for a CAN bus producing a bit every 2 microseconds.

An oscilloscope is more useful for checking that the signal levels and timing are correct but some include protocol decoding.  A dedicated CAN bus protocol decoder would be more useful.

It should be noted that you can forget about analog scopes, here they are useless. [/me hides from all analog scope fansboys]

It can be done and I have done it before but digital storage oscilloscopes make it much easier.

In the past the preferred method was to use any type of oscilloscope to verify the signal levels, timing, and fidelity and then a protocol decoder to read the message traffic.  Now all of this can be done with many DSOs.

[Brumby]

It also says AD Resolution is 8 Bits?  Not sure what that means either?

That is for a digital scope and refers to the number of values that you can have in the "Y" (vertical)axis.  8 bits gives you 2⁸ = 256 possible values.  Forget your CAN bus for the moment and just think of a 1KHz sine wave which is displayed at maximum height to fill the screen.  If you could zoom in super close and look at the sine wave, you would see it is not a smooth, continuous curve, but one that has discrete levels and is typically presented as a stepped line.  For 8 bits, your sine wave would have a maximum of 256 levels from the lowest point to the highest point.  Each of these points along the "X" (horizontal) axis corresponds to one sample.

If the resolution was 10 bits, you would have 1024 - which gives you more detail in the "Y" axis.

[Brumby]

I found a company that does sell logic analyzers for a decent price with can bus decoding.  But again, this is not really the goal in the sense I don't want to manually sit down and try to figure out an entire waveform.  That wouldn't be the greatest use of time. lol

While trying to understand what the CAN bus waveform looks like, it is not practical to do so for the purpose of working out one or two frames.  Frames (or messages, if you like) are continuously getting sent along the bus - and they can change all the time.  Decoding an "entire waveform" of the CAN bus is not a waste of time - if you use a device that is purpose built.

Let the device do all the hard work - and you just look through the messages it has decoded to find the ones you want.  The process of working out the timing to decode a series of 1's or 0's is well defined - and easily implemented in hardware - but it is not the sort of process we poor mortals can perform with any efficiency.

If you are just interested in tracking down specific data on the CAN bus, then make your life hundreds of times easier by investing in the right device.

[Karlo_Moharic]

The answer to your question is rather very simple , they have MEMORY buffers.

[james_s]

The problem with trying to use an oscilloscope to look at something like a CAN bus is triggering. To be useful, the scope has to have a way of identifying the start of a frame and triggering a capture at that point. Most scopes trigger based on voltage level or a rising or falling edge, occasionally one might have video triggering where it can lock onto the sync pulses of analog video but that's probably largely a thing of the past. You also need to have a large enough memory depth to capture all of the data you're interested in looking at. As has been said already, even a very old, very slow scope will be way more than fast enough to see data on the CAN bus, only a DSO can capture a non-repeating waveform of that nature to allow studying it, and very few will be able to trigger on a specific frame.