Oscilloscope and logic analyser notes: Difference between revisions
m (→PC sound card) |
|||
(5 intermediate revisions by the same user not shown) | |||
Line 210: | Line 210: | ||
--> | --> | ||
===Triggering=== | ===Triggering, trigger modes=== | ||
<!-- | <!-- | ||
A classical scope's vertical behaviour may be obvious enough (voltage = position on screen), | |||
but what about the horizontal, time one? | |||
The most | |||
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. | |||
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 228: | Line 312: | ||
These days that's mostly irrelevant.)}} | These days that's mostly irrelevant.)}} | ||
Line 242: | 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 279: | 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 often 48000 sample/sec, | This will give you a 2 channel, 16-bit ADC often 48000 sample/sec, and assume at most 15kHz bandwidth. | ||
but | 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. | Sound cards now tend to have a pretty low noise floor. | ||
Line 292: | Line 420: | ||
Note that running your sound card 96 or 192kHz does nothing to increase your ''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 ~ | because all sound cards have lowpass filters on their input, meaning you should assume content above ~20kHz is attenuated to gone. | ||
Attenuation may start a little lower, though that effect often comes from microphones more than audio interfaces. | |||
though | |||
{{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.)}} | |||
Line 787: | Line 912: | ||
=Practical use notes= | =Practical use notes= | ||
Latest revision as of 11:13, 21 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
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 ~20kHz is attenuated to gone.
Attenuation may start a little lower, though that effect often comes from microphones more than audio interfaces.
(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:
- Software:
- http://xoscope.sourceforge.net/ (linux) (no cost)
- http://www.zeitnitz.de/Christian/scope (no cost)
- www.multi-instrument.com (paid)
Microcontrollers
...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
- Logicport one
- ZeroPlus Logic Cube
- Bus Pirate
- USBee
USB scopes
- http://www.pctestinstruments.com/
- http://www.google.com/search?q=parallax%20usb%20oscilloscope
- http://www.google.com/search?q=propscope
- DSO-2090, DSO-2250 (apparently made in china, and appears with many brand stickers and varying prices)
- Poscope
- PCSU1000
- PicoScope 2104, 2105
- ...and more
'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