Products > Test Equipment
PicoScope 2000
MrW0lf:
Due to something that probably has to do with sample counts fft(derivative(x)) and some other math tends to work only on Sinc'ed data. Also need custom derivative like (A[0.000000002]-A)/0.000000002) where number is sample interval. Since Sinc is by default applicable on max 2000Sa record one is limited to very low resolution FFT on complex math. Picture below is however with 1M bins. ;)
Another annoyance is buffers limited to max 10k. Now 64k.
And of course biggest annoyance of all - measurements stats on max 1k wfms. Now 100M (max tested ~300k).
Default mode: No Sinc, limited resolution on measurements, RT measurement does not work, stats limited to 1k:
Hacked: All above fixed:
Nothing exotic, just fiddled with config file a little :-/O All this of course purely educational & experimental & at your own risk etc. New Sinc limit of 100k seemed optimal on my PC, more gets slow.
C:\Users\%user%\AppData\Local\Pico Technology\%hash%\preferences.xml
--- Code: ---...
<category name="resampleActive">
<preference name="resampleActive" value="True" />
</category>
...
<category name="waveformbuffer">
<preference name="maxcount" value="65534" />
</category>
<category name="measurementstorebuffer">
<preference name="maximumBufferSize" value="100000000" />
</category>
...
<category name="resampleSizeBuffer">
<preference name="reSampleSize" value="100010" />
</category>
...
--- End code ---
MrW0lf:
Someone did point out that "hacked" measurements may go into overflow with large readings number and especially on high bit scope. In fact I did run long term test to find this out and presumed count would either stop or software would crash. As seen buffers did go into overflow at 65534 which is almost 2^16 eg 65536. Measurements count continued and I stopped test at 275319. It took about 4h to get there if remember correctly and frame rate had indeed dropped so physical limit might have been in sight. 100M value in config was just largest value I tried that did not lead to crash at startup. So if someone needs that feature it makes sense to do functional test first over desired time period.
Meanwhile I had idea to try out PicoScope 5 software that I've never used, but which supports my oldest 2205. It turns out sometimes one must indeed go back in time to go forward...
Measurements count limit max 10k vs 1k in PS6.
FFT limit in PS5 is official bw * 2 (50MHz) instead of official bw (25MHz) in PS6. In fact even bw * 2 is limited because scope can to 200MSa/s. But... why would anyone want FFT on more than official bw, surely confusing because of amplitude drop?! Hmm... aliasing perhaps? :popcorn:
PS5: First lets determine what the analog bw is:
PS5: Now lets look at 40MHz signal. Very predictable and useful, can get correct amplitude value from analog bw graph.
PS6: Nice trap for young players, eh?
Edit: Of course there is workaround, but very non-obvious for young player - create Spectrum viewport in Scope mode instead, there they cannot cut you out of full sample rate because it would cripple the scope. This helps very much with alias, but everything above 25MHz is still not processed / visible:
And that's just the start of it, PS5 had many more useful differences which will cover sometime later.
MrW0lf:
It turns out that PS5 had persistence (DPO and color grading) in regular Scope mode. PS6 has only dedicated Persistence mode with hardware support which was probably supposed to replace old options, because regular Scope mode is now lacking these features. So did it turn out well?
To find out good case would be something complex and slow with random errors. There is main wfm with distinct discrete steps and very poor "triggerability". Some very seldom occurring errors (spikes) induced. To have good look - best find some triggerable part and browse around with zoom. Errors can be distinguished from main wfm by spike width, so need enough sample rate for that (good time resolution).
PS5: 100us/div, 12.5MSa/s, 12.5kSa, 10x zoom, color graded persistence. As can see no problem spotting the errors collecting over time.
PS6: 100us/div, 781.3kSa/s, 781Sa, 5x zoom, color graded persistence. It looks like gates of hell have opened :scared:. Hardware supported DPO is limited to about 1kSa and despite having higher wfm/s rate completely useless for such tasks. Max 5x zoom, no math, no measurements. It cant trigger properly because of insufficient sample rate and all visual detail lost.
PS6: 100us/div, 12.5MSa/s, 12.5kSa, 10x zoom, as workaround math function peak() used to provide pseudo-persistence mode. Can only choose single color for peak() but somewhat works. No DPO or color grading. Suppose quite non-obvious way to achieve (sort of) persistence for many users.
So replacing, not complementing Scope mode persistence with weird Persistence mode that can be used only for high speed stuff seems no the best idea.
MrW0lf:
However if move from old 2205 back to 2408B then there is at least very neat trick. After collecting buffers one can apply one of buffered math functions: min, max, average, peak. For pseudo-persistence can use min, max, peak. So now if combine with Rapid trigger (~1Mwfm/s capability) can achieve this:
Theoretical maximum trigger rate for given wfm is ~763Hz. When configure Rapid trigger to 10k buffers it will display result after 14 seconds. To collect at maximum possible rate would take ~13.1s. So can assume that indeed there was 0% of trigger misses + some time do download result from scope memory.
Initially it will display just one wfm with no indication that something useful is still going on, but after ~20 seconds (until PC crunches through 10k wfms) this is displayed:
Sadly it will not process buffers on subject of auto-measurements. One would need DeepMeasure for that (USB3 scopes). Also some indication that processing is ongoing would be very helpful. Another shortcoming is that despite all spikes shown, one has still no idea in which exact buffer of 10k total given spike appeared.
Collecting same amount of data with Repeat trigger took 284s, which converts to 35wfm/s eg ~95% of trigger misses.
Edit: Forgot to mention drawback of Rapid trigger mode: Buffers are not time-stamped, they get single timestamp of the final download - so no idea when something occurred. There is ongoing discussion on this here:
https://www.picotech.com/support/topic17321.html?&start=15#p140390
_Wim_:
--- Quote from: MrW0lf on November 06, 2018, 12:20:05 pm ---Meanwhile I had idea to try out PicoScope 5 software that I've never used, but which supports my oldest 2205. It turns out sometimes one must indeed go back in time to go forward...
--- End quote ---
Were you able to install both PS5 and PS6 on 1 pc?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version