Products > Test Equipment
A newbie needs some help with my first DSO
nctnico:
--- Quote from: tggzzz on June 01, 2024, 05:26:40 pm ---
--- Quote from: nctnico on June 01, 2024, 03:14:39 pm ---With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
--- End quote ---
The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!
--- End quote ---
Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.
tggzzz:
--- Quote from: nctnico on June 01, 2024, 06:44:25 pm ---
--- Quote from: tggzzz on June 01, 2024, 05:26:40 pm ---
--- Quote from: nctnico on June 01, 2024, 03:14:39 pm ---With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
--- End quote ---
The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!
--- End quote ---
Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.
--- End quote ---
Those examples are little more than glorified signal integrity problems.
If you look the points I made and you snipped, you will realise that they are about more complex "higher" level specification and implementation issues.
nctnico:
No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.
tggzzz:
--- Quote from: nctnico on June 01, 2024, 08:33:59 pm ---No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.
--- End quote ---
I wrote glorified signal integrity tests, as a shorthand.
Your understanding of my test objectives.and techniques is flawed.
tautech:
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version