When using an oscilloscope do you find yourself trying to solve any of the types of problems listed in the poll below?
Problems I try to solve with a scope or other data acquisition equipment
When characterizing a signal such as rise time or timing budget, I care very much about a small section of my waveform. I am looking for specific issues or criteria. I don’t care very much about looking at historical signals that may have appeared on my scope while I am in real time/latest mode.
When trying to find an issue (such as victim/aggressor noise) where I have setup an analog trigger I want to know if there is a correlation to a specific event in time in the communications buses in my system causing problems. While looking at my signal in real time/latest mode I want to be able to see my analog channel at a small time scale, and be able to look at other historical transactions at a larger timescale to help me understand where I am in the flow of my systems communicating.
I am not sure what part of my system is causing the problem, but I do know that I can trigger on a signal that gets stuck which is the result of the problem. I want to capture as much data as possible so that I can search for errors in my signals to find the underlying problems, but I will do this after the capture has finished.
Other - I’ll describe in the comments below
On an oscilloscope how important (5=most important, 1=least) is it for you to be able to look at other signals in real time while also being able to look at the historical data while actively capturing data (vs looking at a capture after it has ended)?
Capture more than one event, without the need for manual restart. i.e. leave the test run overnight, next morning i have 10 captures saved, to investigate.
Capture combinations of signals, like diff A and B channel → see timing difference → see delay/phase shifts.
Easy snapshoting, for use in a report. Ideally the snapshot is a simple picture but with relevant metadata, like time of capture o.s.o., can be as simple as adding this info in the file name.
Ability to turn off CPU consuming things like contonious graph update, HLA’s and similar when not needed during the capture.
A dream feature of being able to capture data from a system in the form of SPI/SCI/… output, alongside analog captures. like the ADC values seen by my device alongside the analog signal. Or some of the values used in the calculation of the PWM signal, captured alongside the resulting output from my DAC, and many other usecases.
Sorry have to repeat this in a separate reply as it would be a game-changer for me.
A dream feature of a scope is being able to capture data from a system in the form of SPI/SCI/… output, alongside analog captures, with the SPI/SCI/… values converted to an analog-like trace.
like the ADC values seen by my device alongside the analog signal it is converting.
Some of the values used in the calculation of my PWM signal, captured alongside the resulting output after the analog filter (DAC like), the resulting currents created in the HW that I am controlling a.s.o.
I’ve got a comment added for you in the existing feature request post below for this. This is an idea we are currently tracking.
Currently, we don’t have a native software-based solution for screenshots. You’ll need to use the OS’s screenshot tool. However, we could see how a native-based screenshot solution could be useful to add custom information automatically. We unfortunately just can’t prioritize this right now. Having said that, here is where we are tracking the feature request below, and I’ve added a comment for you.
In case it helps with using screenshots for reports, we do have a light theme available. More info on this can be found below:
This is being tracked in the feature request post below. I’ve added a comment for you as well.
Our software does have the ability to record both analog and digital waveforms simultaneously. Was there anything specific missing with our current Logic analyzers that would help in this particular use case?
Yes but it lacks the conversion.
The simple example - Looking at the results from the ADC in my deice: Channel 1: The analog signal going into my device, captured directly by Saleae/scope. Channel 2: The values from my device ADC conversions, shown as an analog trace on the screen.
The data for channel 2, comes from some sort of digital communication like SPI, and is provided by my device, as close to real-time as my device is able to deliver, then converted to an analog trace on the scope.
This gives an easy to comprehend visualization of internal data, but provided in near real-time with actual captured data, providing a goldmine of data when building SW that controls some physical device.
We do have a in-house build device that provides similar functionality, but based on a simple external DAC, and using a traditional analogue scope*, but that puts all the effort of scaling and similar on the user and/or the device under test. And we use this quite a lot, i can provide you with more details on this setup but not here in a public forum.
*–> When I say “analogue scope” I am not talking about a really old fully analog scope, but a scope that is build purely for analyzing analogue signals, inside the scope it is still using digital technology.
As a final note, the main requirement is the ability to provide a virtual analogue trace based on some digital value stream, but extra features such as changing scale/adding delay (including negative delay) directly in the GUI when looking at the traces would be welcome too.