Oscilloscope Setup - Quick Guide
NOTE FROM AUTHOR
This chapter is incomplete.
Development of this page was halted at the end of the two month "writing" phase, at the start of the "review and edit" phase.
This is intended to be a very focussed quick start guide.
I would like to complete this chapter when the project gets properly funded.
This is a quick introduction to general oscilloscope (scope) usage, and not a complete guide. How to use your scope will depend on what device you have. Like driving different cars, the pedals and steering wheel are always in the same place. The switches, levers, gauges and mirrors are not. The manufacturers can't even decide if the emergency brake is a lever to lift, a handle to pull or a foot pedal which could be released by a handle or a second depression of the pedal.
When you finally come to look at your bus on the scope, you will find that set up is quite simple. This basic set up will work with PC based scopes and analyzers, like the Saleae or PicoScope devices. You connect your scopes probes to the signals you want to see, you then enable those channels. Not all scopes are created equal. The lowest common denominator is a two channel analog scope. Four channel analog scopes are popular. Some scopes have digital only channels as well, with eight or sixteen channels that are more akin to a logic analyzers input. If you have analog and digital,then you have a Mixed Signal Oscilloscope (MSO).
Once you have connected your device to the scope, you need to start the scope running. You can then change the timebase and voltage scales so that you see the portion of the signal you are looking for, and zoom in. To get the signal reliably you will want to set up triggers, these will align successive captures on the screen. One of the best ways to learn how to use your scope is to use it. There will be times when, no matter what you do, you get completely lost. Most scopes have an auto setup button, which looks for the most obvious signal and configures to accommodate this. If you have valid activity on your bus, then this will snap it all into a sensible state. If your bus is idle, then there is a good chance the auto setup will zoom in the time and voltage to show you in great detail the noise on your idle bus lines. While sometimes not useful for quickly setting up your scope, the auto setup will at least snap all active signals to visible on screen. It's a lot easier to adjust what you are looking at when you can see it.
I know, that is a lot if you are new to this. Here is the todo list in brief
turn on scope
connect signals to scope inputs
enable channels to view
adjust voltage scale and offset so channels are visible
set trigger
set scope to run or auto
adjust time scale to fit
Digital or analog inputs?
As a software engineer you are probably most interested in the digital domain, that is the logic state of the bus lines, or the data values associated with the bus traffic. The digital inputs will be what you are most comfortable with as they are presented as square wave, with sharp transitions between low and high. If you are using an MSO or a Saleae you will have this option. If you are only using an analog scope, then you have no option, but you can always look at digital signals as if they were analog, just don't expect a textbook waveform of square edges.
There will be times when you do care about the analog view of your signals. Since this book is written as a guide for software engineers I assume that you have hardware was made by someone else, either off the shelf, or by your teams hardware engineer. If there are problems that are only visible in the analog domain, they probably are the fault of software. That said, board damage can occur after manufacture, or a manufacturing defect can be heat sensitive and therefore intermittent.
If you have the choice to use analog of digital inputs then you will want the most interesting signals to be on the analog channels. Which signal are most interesting depends on the problem you are debugging. If we assume the hardware is good, data and address lines would be on the digital inputs. Anything that is bi-directional, such as the SDA line on I2C, is a good candidate for analog analysis to look for driver conflicts.
Setting voltage scale and offset
For your analog inputs you can set the vertical scale by adjusting the voltage. This changes how tall your wave form is. There is a second adjustment for the offset, that is, how far up the screen is the zero value. Some scopes have a mechanism to help find off screen signal, and may have an offset reset.
In the world of serial protocols we have defined voltage levels. Busses like RS-485 and CAN have voltages that may be much higher than the signals output from your microcontroller. Busses like I2C will typically be at voltages closer to your MCUs GPIO levels.
If you are looking at the interface directly on your MCU then you will have 0v as the low and 5V, 3.3V or 1.8V as the high. There are newer low voltage technologies that have a logic high at 1.2V or 1V. A good starting point is to set for 2 volts per division, with the zero point on-screen, and offset from the other signals.
If you are looking at the actual wiring between two devices, then voltages may vary significantly. Some busses, such as RS485, actually use a differential signal, without the concept of a common ground. Most others you can measure relative to ground. The signal between your MCU and the line driver or transceiver will be at the logic level of your MCU, but between circuit boards the higher levels will be seen.
Bus
type
Vlow
Vhigh
RS-485
differential
-7
12
RS-232
-15 to -3
3 to 15
Setting your trigger
The setting of your trigger very much depends on what problem you are trying to debug. You can always trigger on an edge, that is a transition in signal level. You have to select what signal you want to trigger on, the select whether you want to catch falling of rising edge. The next parameter to set is the trigger level, that is, what voltage threshold will you recognize as an event. There are more parameters which define what data is captured relevant to the trigger. For example, is the trigger at the end of the capture, the middle or the start. You can also set a duration, the trigger level having to be true for a minimum time.
Some scopes allow triggering on a series of events, or the nth occurrence of an event. If you have a MSO, especially with a built in protocol analyzer, you can trigger on protocol framing or data values.
Setting the trigger level will depend on what you are looking for. For simple edge triggers, assuming that you only have a software, set the level to 50% of the range between the highest and lowest values.
If you are monitoring a recurring signal, or an active bus you will see frequent triggers when running. With long data packets your trigger may appear in the middle of a message. Changing the holdoff time can allow you to always capture the start of a packet.
You can also add a trigger delay, capturing data some time after the event. Be careful when doing this as your trigger event may not be the same time before each occurrence of what you want to observe. An example of this is where a data read happens relative to an interrupt request from a peripheral.
Setting the time scale and offset
The horizontal scaling is controlled by the timebase. It depends what you are looking for as to how you will set this. When debugging serial protocols you will often be looking at a packet of data. You will want to scale appropriately. If you are having trouble with communications starting, you may want to just focus on the address phase.
The time scaling is coupled to your sampling rate. You may find that your scope has limited control over how samples are gathered. There is a maximum sampling rate inherent in your scope, but there is also a limit to how many samples can be stored to be displayed. Sample rate may be adjustable independently of the time scale, but you will notice that the maximum record time and maximum sample rate are coupled together in the user interface.
To start capturing your serial protocol you will need to know the characteristics of the bus in question. For example, what is the data rate of your bus, and how many bytes are in a packet. You will also need to know something of the framing.
Looking at I2C, we should know the frequency of the bus. Let say we are in fast-mode, that is 400kbit/s. To capture the SCL signal which has a transition 800k times a second we would need a sample rate at least 800K per bit, but we do not know the clock as 50% duty cycle, so we may miss highs or lows if we are unlucky. The Nyquist Theorem would have us capture at twice that rate, 1.6 mega samples. A better guide would be to sample 5-10 times the highest frequency.
The duration of capture would depend on how much data you would like to capture. Again with I2C, we have 9 bit times per byte transferred. There is the overhead of the start, addressing which is two byte long in 10 bit mode. The 9 bits are not guaranteed to be an even length. The target may stretch the clocks, and you may find a byte is much longer than anticipated. Between each byte there will be turnaround time within the sender. And for a read transaction, you will also have a write of a few bytes to set the command in the target, then a restart followed by an address and read bit. You will probably want to capture at least 5 bytes to see the start of a write, and 10 bytes of time to see that start of a read. This example will give you a rough idea of how to set up pro-actively. You may find that twiddling the knobs until you get what you want is the way to go. I do that often myself, but if the signal is missing completely it is sometimes good to see that the timing is set up roughly correctly and not just zoomed out too far to be useful.
Last updated