Oscilloscope and logic analyser notes: Difference between revisions

From Helpful
Jump to navigation Jump to search
 
(13 intermediate revisions by the same user not shown)
Line 49: Line 49:
'''How much do you need?'''
'''How much do you need?'''


Consider e.g. retrocomputing repair and most DIY and most microcontrollers.
Consider e.g. retrocomputing repair, and most DIY and most microcontrollers.


Even if things run at dozenz of MHz internally,  
Even if things run at dozenz of MHz internally,
most digital signals that come out will rarely be above a MHz or two.
most digital signals that come out will rarely be above a MHz or two,
 
and most slower than that.
Consider an Arduino.
Aside from the main crystal, the fastest thing you'll see happen on pins is probably 1MHz.


In this regard, if you can find a EUR100 scope but it's limited to maybe 5MHz bandwidth,
In this regard, if you can find a EUR100 scope but it's limited to maybe 5MHz bandwidth,
that would already solve cover a lot of needs.
that would already solve cover a lot of needs.


And you can get a decent 25MHz scopes for EUR200.
And you can get a decent ''new'' 25MHz scopes for EUR200.




Line 68: Line 66:
There is a very real difference between sampling rate and bandwidth.
There is a very real difference between sampling rate and bandwidth.


'''Bandwidth''' is largely about whether an analog signal can make it from your device to the oscilloscope's ADC without being changed - can the probes pick it up, can the frontend handle it without distorting it?
'''Bandwidth''' is largely about whether an analog signal can make it through all the parts,
from your device, through the oscilloscope frontend and to the oscilloscope's ADC, without being changed or distorted.


Distortion is a relative measure, though.  
Distortion is not an on-off thing - systems will slowly not be able to meet their specs, which for bandwidth
often means the inability to carry a frequency / speed.


The way we often bandwidth ''basically'' means there is a -3dB attenuation at the specced bandwidth,
The way we bandwidth is frequently specced ''basically'' comes down to that being the point at which its limitations mean there is already -3dB attenuation of signal at that specced bandwidth, meaning the amplitude is at only ~70% of what it should really be (this is why you see reviews use frequency generators. It's useful to check that the waveform look right ''but also'', independently, to check when that attenuation happens, e.g. "I know this is a 1V 50MHz signal and yet it measures 0.7V" then you have a good idea what the limit is.
meaning the amplitude is at only ~70% of what it should really be (this is why you see reviews use frequency generator, not only for 'does the waveform look right' but also when that attenuation happens, e.g. "I know this is a 1V signal and around 50MHz it measures 0.7V" then you have a good idea what the limit is.


You don't have to think about this much before you get near your specced bandwidth (at 1/10th it's maybe 2%)
"so is this a gradual falloff?"


Yes, but mostly not one your need to worry about.
At 1/10th of the bandwidth the falloff is maybe 2%,
so in everyday use, you don't have to think about bandwidth until you actually get somewhere near it, or care about very precise measurements (in which case you need to think about better devices for it).




Line 82: Line 84:


'''Sampling rate''' is about whether you sample often enough to see that waveform.
'''Sampling rate''' is about whether you sample often enough to see that waveform.
: Nyquist says ''at least'' a factor two more than the bandwidth you have
: Nyquist says you need to sample ''at least'' a factor two more than the frequency you like to see -- so if this isn't twice faster than the bandwidth, you can't really use that bandwidth (not that it's bad to not get near that bandwidth - you could argue it's a good frontend for this scope).


...yet ''at'' that double rate you can only tell that there ''is'' a signal at that rate, not what shape it has, or even say much about its amplitude.  
...yet ''at'' that double rate you can only tell that there ''is'' a signal at that rate, not what shape it has, or even say much about its amplitude.  
Line 141: Line 143:


===Memory - at all===
===Memory - at all===
<!--
<!--


Oldschool analog scopes had no memory.  
Oldschool analog scopes had no memory at all.  


They show what is happen continuously.
They show what is happen continuously.
For any regular signal, this is plenty.
For any regular-ish signal, this is plenty.




Line 154: Line 155:
There are various models of CRTs that ''do'' do digital storage, and can play that back on the CRT.
There are various models of CRTs that ''do'' do digital storage, and can play that back on the CRT.


https://www.youtube.com/watch?v=mG3enGpGyNA




Line 160: Line 160:
: ...yet if you're looking for second hand, this may still matter.
: ...yet if you're looking for second hand, this may still matter.


https://www.youtube.com/watch?v=mG3enGpGyNA


-->
-->


===Memory depth (how much)===
===Memory depth (how much)===
Line 208: Line 210:
-->
-->


===Triggering===
===Triggering, trigger modes===
<!--
<!--


The most basic triggering is seeing edges on the channels you're sampling.  
A classical scope's vertical behaviour may be obvious enough (voltage = position on screen),
but what about the horizontal, time one?
 
 
If, while actively showing data, the waveform looks stable,
this is an illusion based on the signal being both very regular,
and the sample somehow being at the same part when the scope starts drawing the next line.
 
{{comment|You can consider this a bug (you miss a lot of things) or a feature (often you care about what is consistently happening).}}
 
We would like to make such a stable-looking thing happen by design, rather than accident,
so often, you want ''some'' control over when to start sampling (and and showing).
 
 
 
 
'''Triggering''' refers to synchronizing capture with ''something''.
 
Why? Well.
 
 
It is fundamental to "we show you what is happening live" that, the more time detail you want to show,
the more that becomes too much, and goes by too quickly.
 
 
As a side effect, 'things that are consistently there' is a lot easier to show - given some further assumptions.
'''Historically, triggering''':
* assumes that the thing you want to see happens continuously in basically the same way
and
* prefers that it has a fairly well defined start
and
* prefers that there is a time within which we wouldn't need/want to trigger again
 
 
 
The more that those assumptions are true {{comment|(E.g. a bunch of digital communication matches that ''fairly'' well, and e.g. most music does ''not'')}},
the easier it is to get a useful thing you want on screen,
and in the same position, because aside from aligning at the start of what we call it event,
we are also ignoring some of what is happening on our input.
 
 
Note that part of this that came from restrictions of early scopes not having any memory - so the easiest way to visualize well was to wait to do a sweep, entirely live with what is on the input, until a certain event.
 
 
---
 
Given that introduction, '''Trigger modes''' become a little easier to grasp:
 
'''Normal''' - update only when the trigger condition is met, and nothing otherwise
: where that condition is often "has gone above a voltage threshold"
: e.g. useful
:: for relatively rare events, if you can get it to trigger only on each event
:: or even as a "update only while I hold the probe to something happening" (though this is more fragile in that you might see the bit where you made poorrt contact just before lifting contact)
:: sometimes to see the ''last'' trigger (e.g. a crude "what happened when I powered off" sort of use - somewhat fragile as there may be other messy things going on that trigger it again)
: while e.g. for a squarewave this functions essentially the same as auto.
 
 
'''Auto'''
: sort of a normal-with-timeout: "whenever there is no real thing triggering" then trigger after a certain time
: the amount of time to wati depends on the currently set timescale
: note that this fallback does ''not'' kick in whenever you are triggering faster than that
: more practically:
:: while not actively triggered, it is unlikely to synchronize with ''anything'' (even e.g. a very regular sine wave), so looks messy,
:: but e.g. useful to see where the waveform is, and move in a trigger level and then get that thing to show more stably
:: (older scopes might put threshold and auto on the same knob - then you don't get a threshold during auto, only during normal mode)
 
 
'''Single''' - after the next trigger, sample a bit, show, and then pause everything (regardless of what the signal does after)
: press run to get it back to continuous sampling
: can only be done on memory scopes (but all modern scopes are)
 
 
 
 
---
 
 
 
 
 
A separate trigger channel is cheaper to implement than a 'real' ADC channel (and it can be easier to make it respond ''quickly''),
but also, it can be useful to not occupy one of those fancy waveform-sampling channels ''just'' for triggering.


Also, triggering based on sampling may vary slightly on when it triggers,
so when doing live sampling, the waveform may seem less stable than it actually is,
than it would look with more stable triggering.


A separate trigger channel is cheaper to implement than a 'real' ADC channel,
and in some setups frees one such channel for waveform sampling, so most scopes have a trigger channel.


(trigger channels will still have trigger voltage levels via a comparator)
This and other reasons mean scopes old and new often have a separate channel that you can ''only'' use for triggering.




The most basic triggering is seeing edges on the channels you're sampling.
(trigger channels will still have trigger voltage levels - via a comparator, rather than data sampling)


{{comment|(A separate trigger channel was also interesting in early memory scopes,  
{{comment|(A separate trigger channel was also interesting in early memory scopes,  
Line 225: Line 312:
These days that's mostly irrelevant.)}}
These days that's mostly irrelevant.)}}
   
   
and it's still nice in that you can trigger some things without occupying a real (ADC) channel.




Analog triggering (depending a little on implementation) may also vary slightly on when it triggers, so when showing many traces overlaid the waveform may seem less stable than it is.




Line 239: Line 324:


If this is a setting, preferably an exposed one, this can help dial into some specific signals.
If this is a setting, preferably an exposed one, this can help dial into some specific signals.
There may be some further trigger-related parameters, like
* '''Delay''' - after the condition is met, wait some time to actually trigger
:: e.g. useful if the interesting part happens some time after the triggering part
: on a memory scope you can set this ''negative'', amounts to mean "look back some time before the trigger"
:: e.g. useful if you are specifically interested in seeing all of what triggered it
* '''Holdoff''' - only trigger if the last trigger was at least some time ago (holds off to rearm the trigger)
: in analog scopes some of this was just necessary, e.g. while and after the beam back while blanked, and you could extend that time.
: not useful for very regular signals, but e.g. consider trying to look for the start of a pulse train repeated with some interval
* ignoring high and/or low frequencies in triggering.
* '''Trigger type'''
Edge - makes more sense on block waves, digital communication
Positive slope - makes more sense on e.g. sine
Normal mode displays a waveform when the trigger conditions are met, otherwise the oscilloscope does not trigger and the display is not updated. Auto mode is the same as Normal mode, except it forces the oscilloscope to trigger if the trigger conditions are not met.
-->
<!--
A zoom and history mode isn't necessarily the same thing.
That is, 'history' may mean something like "I kept the all the last triggered captures" (which may be a mess e.g. in auto mode),
whereas zoom is "I look around one long acquisition"




Line 276: Line 408:
One of the simplest oscilloscopes, one you already have, is a sound card.
One of the simplest oscilloscopes, one you already have, is a sound card.


This will give you a 2 channel, 16-bit ADC, 44100 or 48000 sample/sec
This will give you a 2 channel, 16-bit ADC often 48000 sample/sec, and assume at most 15kHz bandwidth.
and sound cards now tend to have a pretty low noise floor.
 
Too slow for many fancier things things,
but it's pretty nice to be able to measure some slow baseband signals for almost-free -- a few cents worth of resistors for some protection.
 
Sound cards now tend to have a pretty low noise floor.
 




Line 285: Line 422:
because all sound cards have lowpass filters on their input, meaning you should assume content above ~15kHz is attenuated and above ~20kHz is gone.
because all sound cards have lowpass filters on their input, meaning you should assume content above ~15kHz is attenuated and above ~20kHz is gone.


Still, there are a bunch of slow baseband signals that this deals with ''perfectly'' well.
{{comment|(You sometimes find faster ADCs around PC hardware, such as a 448kHz (not a typo) ADC in bt878-based TV cards, with ~360KHz usable bandwidth{{verify}}, though it takes more work to make this into something usable.)}}
 
 
 
You sometimes find faster ADCs in PC hardware, such as a 448kHz (not a typo) ADC in bt878-based TV cards, with ~360KHz usable bandwidth{{verify}},
though it takes more work to make this into something usable.
(what about a lowpass?{{verify}} possibly not, if it's meant to be able to sample 8 channels?)
 
 




'''Voltage'''
'''Voltage'''


Since audio assumes it'll rarely go above ~0.5V,  
Since consumer audio assumes it'll rarely go above ~0.5V,  
and most things you want to measure is higher-voltage,
and most things you want to measure is higher-voltage,
you'll at least want to make a factor-20ish voltage divider.
you'll at least want to make a factor-20ish voltage divider.
Line 350: Line 479:




One of the first, and simplest to get started with, was https://github.com/konsumer/arduinoscope (GUI for win, lin, osx), which is fed with ASCII lines of values - not very efficient, but it's an easy way to visualize what's happening on a pin, and with just a few lines of Arduino code.
One of the first, and simplest to get started with, was https://github.com/konsumer/arduinoscope (GUI for win, lin, osx), which is fed with ASCII lines of values - not very efficient, but it's an easy way to visualize what's happening on a pin, and with just a few lines of Arduino-side code.


The arduino IDE itself has basically adopted that same approach since version 1.6.6 (2015), with its "Serial Plotter" (see the tools menu),  
The arduino IDE itself has basically adopted that same approach since version 1.6.6 (2015), with its "Serial Plotter" (see the tools menu),  
Line 651: Line 780:
-->
-->


==On (not) damaging up your oscilloscope==
==On (not) damaging your oscilloscope==
<!--
<!--


Line 780: Line 909:


=Practical use notes=
=Practical use notes=
==Trigger mode==
<!--
Triggering is synchronizing capture with some event, which is great to put events of interest on the screen.
The most typical thing to trigger on is a rising (or falling) edge.
Single - after the next trigger, sample a bit, show, and then pause everything (regardless of what the signal does after)
: press run to get it back to continuous sampling
Normal - update only when the condition is met
: e.g. useful
:: for rare events, if you can get it to trigger only on each event
:: see the ''last'' trigger (e.g. a crude "what happened when I powered off" sort of use)
:: or even as a "update only while I hold the probe to something happening" (though this is more fragile in that you might see the bit where you made poorrt contact just before lifting contact)
: while e.g. for a squarewave this functions essentially the same as auto.
Auto - basically means trigger continuously (regardless of the condition set)
: how quickly depends on the timescale, which is better than nothing, but is unlikely to synchronize with anything, so looks messy
: still useful to see where the waveform is, e.g. to move in the trigger level
There may be some further options, like
* Delay - after the condition is met, wait some time to actually trigger
: on a memory scope you can set this ''negative'', amounts to mean "look back some more"
* Holdoff - only trigger if the last trigger was at least some time ago (holds off to rearm the trigger)
: in analog scopes some of this was just necessary, e.g. while and after the beam back while blanked, and you could extend that time.
: not useful for very regular signals, but e.g. consider trying to look for the start of a pulse train repeated with some interval
* ignoring high and/or low frequencies in triggering.
Trigger type
Edge - makes more sense on block waves, digital communication
Positive slope - makes more sense on e.g. sine
Normal mode displays a waveform when the trigger conditions are met, otherwise the oscilloscope does not trigger and the display is not updated. Auto mode is the same as Normal mode, except it forces the oscilloscope to trigger if the trigger conditions are not met.
-->
<!--
A zoom and history mode isn't necessarily the same thing.
That is, 'history' may mean something like "I kept the all the last triggered captures" (which may be a mess e.g. in auto mode),
whereas zoom is "I look around one long acquisition"
-->

Latest revision as of 17:01, 15 May 2024

📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.


See also the nice aggregation at http://opencircuits.com/Oscilloscope



The things below are roughly ordered from cheaper to more expensive

What do you need?

Sampling rate and bandwidth

Rise time

UI

Memory - at all

Memory depth (how much)

Triggering, trigger modes

Math features

Decoding

Poor man's oscilloscopes

PC sound card

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

One of the simplest oscilloscopes, one you already have, is a sound card.

This will give you a 2 channel, 16-bit ADC often 48000 sample/sec, and assume at most 15kHz bandwidth.

Too slow for many fancier things things, but it's pretty nice to be able to measure some slow baseband signals for almost-free -- a few cents worth of resistors for some protection.

Sound cards now tend to have a pretty low noise floor.


Bandwidth

Note that running your sound card 96 or 192kHz does nothing to increase your bandwidth, because all sound cards have lowpass filters on their input, meaning you should assume content above ~15kHz is attenuated and above ~20kHz is gone.

(You sometimes find faster ADCs around PC hardware, such as a 448kHz (not a typo) ADC in bt878-based TV cards, with ~360KHz usable bandwidth(verify), though it takes more work to make this into something usable.)


Voltage

Since consumer audio assumes it'll rarely go above ~0.5V, and most things you want to measure is higher-voltage, you'll at least want to make a factor-20ish voltage divider.

A few more components can provide more protection and/or convenience - consider (e.g. switchable division or potmeter voltage divider, buffering, protection diodes, decoupling)

See pages like http://xoscope.sourceforge.net/hardware/hardware.html



See also:

Microcontrollers

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

...such as the Arduino's Atmega chip, the PICs, and others.


If they have an ADC, you can use it as a lowish-speed scope. Consider e.g.

Arduinoscope (AVR based software scope)

...but note that performance is on the same order as a sound card.


Even without an ADC, they can be a (somewhat faster) logic analyser. Consider e.g.

Bus pirate (PIC based logic analyser)


Arduinoscope

It's not going to have the precision, regularity, or memory depth, or interface features of even a relatively cheap DSO, but it can be a pretty good debugging tool, given it's software for something you already have.


One of the first, and simplest to get started with, was https://github.com/konsumer/arduinoscope (GUI for win, lin, osx), which is fed with ASCII lines of values - not very efficient, but it's an easy way to visualize what's happening on a pin, and with just a few lines of Arduino-side code.

The arduino IDE itself has basically adopted that same approach since version 1.6.6 (2015), with its "Serial Plotter" (see the tools menu), that reads numbers written as text on the serial port.



There are various other projects that tried to be a little fancier than that, in particular getting a little more speed.

AVR-wise, the 9.6ksamples/sec that libraries default to is for compatibility with more arduino variants, and most AVRs can easily be run at ~77ksamples/sec.

Higher is possible, but using/moving the data fast enough becomes an issue, and above ~77ksamples/sec the resolution loss starts becoming noticeable.

It seems the combination FTDI UART and AVR USART (both also run at higher bitrates than typical in Arduino), and AVR code needing some time, will in practice probably transfer no faster than ~1.5mbits/s. If you are willing to give up bit depth for speed, you can get on the order of maybe 150k or 300ksamples/sec.



Toy-like DSOs that fit certain purposes

Somewhat better

USB / mini oscilloscopes

USB logic analysers

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
  • Logicport one
  • ZeroPlus Logic Cube
  • Bus Pirate
  • USBee


USB scopes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

'DSO' is a description -'Digital Storage Oscilloscope', not a brand or type. You see the term on toys as well as professional gear.



Many cannot use all their sample memory at the top speed(verify)



DSO Nano

  • One probe (so no probe-based triggering, but there's level and edge triggering).
  • 12bits ADC at 1Msamples/sec. Don't count on seeing unaliased / detailed signals faster than 200kHz.
  • Can store waveform to SD storage
  • USB connection can be used to charge battery, read stored waveform (from SD storage), upgrade firmware
  • USD ~100


DSO Quad - basically an improvement over the DSO Nano

Desktop memory scopes

On probes

On (not) damaging your oscilloscope

See also


Practical use notes

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Oscilloscope_and_logic_analyser_notes&oldid=96562"