Serial buses are ubiquitous in today's electronic world.
The one that you may be most familiar with is USB.
To pass data and control information from one device or subsystem to another,
signals in the form of digital bits are transmitted and received serially.
That means one bit at a time, sequentially.
High-speed systems, including many PCs,
can transmit and receive billions of bits per second.
There are many different protocols which you can think of
as the data structure.
Are bits transmitted most-significant bit first
or least-significant bit first?
How are the bits grouped?
How are they encoded?
How fast are bits transmitted and received?
You can think of it as an agreed-upon language
between two or more interconnected devices.
If you speak to me in Chinese,
I'm not going to understand too much beyond "ni hao,"
because I have English receivers.
The most common protocols that you may encounter
while studying engineering,
especially during your capstone project,
are I²C, which stands for inter-integrated circuit,
SPI, which stands for serial peripheral interface
and is sometimes pronounced "spy,"
UART, which stands for universal asynchronous receiver-transmitter,
and CAN, which stands for controller area network.
Hi, I'm Johnnie Hancock, Product Manager for Keysight's InfiniiVision oscilloscopes.
In this lesson, we only have time to do a brief overview
of just one of these protocols,
but the basic concept of transmitting and receiving serial data is the same,
regardless of the specific protocol.
We'll be looking at an example of the CAN bus protocol.
CAN is used in a broad range of applications,
including control of industrial equipment,
automotive applications,
and robotics, which is where you may use this bus
while in engineering school.
Let's get started and take a look at some CAN electrical signals
on an oscilloscope.
This is a CAN bus signal.
It happens to be one of the built-in education training signals
of this oscilloscope.
The CAN bus is a differential bus,
should use a differential probe.
It's differential because often,
the signals have to be transmitted over a long distance
and the differential bus is better for noise immunity.
Let's go ahead and set up the scope and take a closer look at these signals.
You set the scope up, initially, just like we've done before.
I'm going to rescale the vertical.
Now, set the trigger level.
Set it about the center of the waveform.
Rescale the horizontal.
The first thing you notice is that all this digital information
is coming out in bursts or packets.
In CAN vernacular, they call them frames.
Each of these bursts is a frame of information,
or a message.
Let's press Stop.
Now, let's take a closer look at one of these packets
or one of these frames.
This particular CAN bus is running at 125 Kbps.
Some people call that the baud rate.
The CAN bus itself can run up to 1 Mbps.
I'm going to zoom in on this particular packet here.
I'm going to set the timebase or the horizontal
at exactly 16 μs per division.
The reason I set it at 16 μs per division is,
125 Kbps means each bit is 8 μs.
Now, at 16 μs, I've set it up for each division to be 2 b,
because what I want to show you right now
is how many engineers would decode something like this
many years ago,
before automatic decoding was available on oscilloscopes.
I call it the brute-force method.
This is the beginning of a packet.
Remember, each division is 2 b, so we have a 00 00 1 0 1111 01 000 100.
Then, I'd have to slide over and do the next set of bits
and slide over and do the next set of bits.
This is a very painful process to decode this into 1s and 0s.
Let's have the scope do it for us.
I'm going to press Run again.
Let's get one frame on screen.
Some scopes have a button on the front panel.
It might say Bus.
It might say Serial.
On this one, it's in the Analyze menu,
so I'll select Analyze,
and then turn on Serial.
Next, I have to select the serial mode or the serial protocol.
This scope supports I²C, LIN, SPI, UART,
and the one up here at the top is CAN.
This is a CAN bus signal.
I have to tell the scope what language we're talking,
which protocol.
This is the CAN bus.
Now you can see, below the signal, it is automatically decoding this frame here,
or these frames that are occurring over and over hexadecimally,
but it's jumping all over the place, and we can't see it.
I could stop it and you could see the decode there.
Do a single shot, another frame, another frame.
The problem is, why is it jumping around like that?
It's because we're not triggering on anything specific yet.
The scope is still triggering on its default trigger mode,
which is any edge of the signal.
We can have it trigger on something specific to CAN.
I'm going to go into the Trigger menu,
select Trigger Type.
You can see it says Edge.
We talked about some of these other trigger modes
in the last lesson.
Let's go down here and select the bottom.
It says Serial CAN.
Now, it's locked in on what's called start of frame
or start of any packet.
There are other specific conditions you can trigger on.
You'll probably have to do some homework and studying
to fully understand the CAN bus.
The one I'm going to select is Data Frame ID.
It's like an address.
Then, I'm going to say trigger on a specific address,
and right now, it's triggering--
and it's not address, it's called ID or identifier--
it's triggering on the hex identifier of 000.
The CAN bus, as well as other protocols,
breaks everything up into fields.
The first field, the first 11 b, is called the identifier field.
That's where we have 000.
The next field is a status field.
Right now, it tells us DLC = 4.
That's an indicator of how many data bits are going to follow.
That is the body of this packet or frame, the data bits.
To give you an idea, what do these fields do?
The identifier might be,
if you had a robotics project in your capstone project,
and maybe one particular arm of your robot or robotics machine
had an ID, might be 000.
The data fields, these four data bytes,
right now, I press Stop.
It says 35, 4D, 3C, 85.
That's four bytes, those are hexadecimal codes.
Those four bytes might indicate an X, or an X, a Y, and a Z position
of your robotics arm.
Let's go ahead and press Run again.
A different ID might position some other--
I don't know how many arms your robot has,
but it might do a different positioning of your robotics arm.
Let's get more of these packets on screen.
As I get more packets on screen,
you can see the decoded field below each of these packets or frames
got squished, we can't read it anymore.
There's another method of reading this.
If I go back into the Serial menu, select Lister,
now we can see a tabular format,
and it shows us what each of these frames is
on a line in this table.
One thing you might notice.
See this red floating through here?
What's happening is the scope is detecting errors
on this particular bus.
We could set the scope up to trigger on specific errors.
We're not going to do that right now.
But we can see, things aren't working right.
Perhaps your robotics arm is not positioning
where you think it should be positioning.
What is the cause of that?
Maybe you programmed it incorrectly.
That data field, maybe that was the wrong data.
You need to go back in and correct the software.
Or perhaps this error is picking up a signal integrity problem
with the actual electrical signals.
Maybe there's too much noise on the bus.
We can see that with the oscilloscope.
Perhaps some of the bits slid into the next bit field.
The timing of the bits isn't right.
Again, you could see that.
You could also connect up another channel of the oscilloscope
and maybe probe the actual analog signals
that are moving the robotic arm and get a time correlation.
When you send a command out to reposition a robotic arm,
you can see the analog signal of the repositioning.
During this lesson,
I tried to give you a rough idea of what a serial bus is
and how to decode it using an oscilloscope.
Unfortunately, we didn't have time to cover this topic in detail.
In our next lesson, we'll be talking about Lissajous curves.
Remember: You can download additional technical information about oscilloscopes
at the URL listed on your screen.
Go, Cal Poly Mustangs!