We'll pick up where we left off during the last demonstration
and do some further analysis on this CANbus signal.
Looking at these particular bits here, this is a frame called "Brake torque,"
that's the name of the message.
Notice at the end of the frame, there's a pulse that goes to a lower or a more dominant level.
This is because after the node that generates brake torque,
all other nodes will pull on the acknowledgement bit if it sees a valid frame,
It pulls more current and takes it to a lower low level.
It makes it easy to see if each frame is acknowledged.
Look over here at the beginning of the frame.
Something similar is happening.
Let's zoom in on that a little bit closer,
and you'll see, again, it appears to be randomly jumping to a more dominant level.
This is evidence of arbitration.
Multiple nodes are beginning to transmit frames at nearly the same time,
and they have different levels of priority.
Let's do some analysis on this particular frame.
First of all, let's use Segmented Memory and just see how often does this frame occur.
I'll go into the acquisition menu.
Let's select "Segmented Memory,"
and let's capture 100 consecutive occurrences of this particular frame.
There, you can see in the Lister, every acquisition that it captured
was the message called "Brake torque."
Over here, on the Segmented table, we can see how often this frame is occurring
which is called the cycle time.
We can see that it's occurring every 20 ns.
In this case, we captured 100 consecutive occurrences for approximately 2 seconds.
Let's turn off Segmented Memory, press "Run,"
and now, let's set up the scope to trigger not only on brake torque
but trigger on brake torque only when arbitration occurs.
For that, we can use "Zone Trigger."
Now, it's only acquiring frames when arbitration occurs.
Let's go back to Segmented Memory and let's capture 100 consecutive occurrences of this
and see how often arbitration occurs.
Here, we can see the first two segments, they were 20 ms apart, which is the cycle time.
The second one was 80 ms later, then 20 ms, 80 ms, and so on.
There's a repeating pattern here,
and that's because I'm using an arbitrary waveform generator
to produce this waveform, and it's repeating.
In reality, if you're monitoring live traffic from an automobile,
it's going to be relatively random.
Let's now go back, turn off Segmented Memory, turn off Zone Trigger.
Remember, when we capture multiple frames here consecutively,
we can see occasionally the red hopping in here.
These are errors that the scope is capturing.
Let's uniquely trigger now on errors.
I'll go into the Trigger menu, select "Trigger on all errors."
Let's scale it to about 30 μs per division.
Now, it's capturing multiple errors.
Let's go into the Segmented Memory menu and let's capture 100 consecutive occurrences of errors.
Here, you can see how often errors are occurring.
Over here in the Lister you can see the different type of errors.
This particular frame has a stuff-bit error.
This particular frame has a CRC error and an acknowledge error.
We could further filter down on specific errors, so let's do that.
Let's turn off Segmented Memory.
Go back into the Trigger menu, and then rather than triggering on all errors,
let's trigger uniquely only on stuff-bit errors.
Let me rescale the time base here.
We'll go back into the acquisition menu, select "Segmented,"
and let's capture 100 consecutive occurrences of frames that have stuff-bit errors.
Here, we can see stuff-bit errors are occurring every 100 ms.
Again, we have a repeating pattern because it's from the arbitrary waveform generator.
Stuff-bit errors occur only in a particular frame called transG or something like that.
Here, you've been able to see how you can use Zone Trigger to uniquely trigger on arbitration
as well as Segmented Memory to capture multiple occurrences of particular events
over a long timespan.