Switching from bench to USB scope - bad idea?

[MrW0lf]

I wonder if you maybe have accidentally throttled the waveform capture rate in the PS6 preferences?

That's good point to be aware of but highly doubt it. It's just their design philosophy. But these old tests might have been done on slow(er) PC so I can re-check sometime later to be sure.

[MrW0lf]

1kCycles at 1kHz burst. wfm/s was counted by number of buffers collected during burst.

10us/div, Trigger is Repeat, Simple Edge, Rising

PicoScope 6404D USB3
5GSa/s, 500kSa: 32wmf/s
1.25GSa/s, 125kSa: 32wmf/s
9.766MSa/s, 977Sa: 33wmf/s

PicoScope 2408B USB2
1GSa/s, 100kSa: 34wmf/s
125MSa/s, 12.5kSa: 32wfm/s
9.615MSa/s, 962Sa: 33wfm/s

PicoScope 2205 USB2
100MSa/s, 10kSa: 34wfm/s
12.5MSa/s, 1250Sa: 33wfm/s

Analog Discovery 2 USB2
100MSa/s, 10kSa: 100wfm/s
10MSa/s, 1kSa: 100wfm/s

To be fair, 2408B and 6404D will collect 100% no prob with Rapid trigger (segmented mode), but that's besides the point.

Edit: To be even more fair looked at DPO mode also, which is also besides to point because it's more like a CRO mode (limited memory, no auto-measurements):

PicoScope 6404D
12.02MSa/s, 1.202kSa: [170, 450, 350, 490, 400] wfm/s

PicoScope 2408B
12.5MSa/s, 1.25kSa: [470, 400, 62, 370, 330] wfm/s

PicoScope 2205
12.5MSa/s, 1.25kSa: [190, 200, 190, 180, 490] wfm/s

It would be interesting if some eager person would test something along these lines with SDK. I have no time for that in near future.

[Performa01]

That's interesting. Had a little play with my old 3206B and got the following:

PicoScope 3206B USB2
 10µs/div, 500MSa/s, 50kSa: 41~44 Wfm/s
100µs/div, 500MSa/s, 500kSa: 48 Wfm/s

Decreasing the buffer length did not change anything.

Rapid trigger captured all 1000 events reliably.

DPO mode: 12.5MSa/s, 1250Sa, 680~720 Wfm/s

A cheap bench scope like the SDS1000X-E manges up to some 1280 Wfm/s for normal acquisition with history in the background and up to 6880 Wfm/s in sequence mode at 10µs/div timebase. In both modes no pulses would be lost due to blind time, yet you'd just get 392 records in the history, even though a total memory of 54.9Mpts is used. At 1GSa/s and with 14 horizontal divisions, the record length is 140kpts.

[nctnico]

Hello folks, a bit ago I started a thread where I have asked for a scope with good analytical features.
Some Lecroy devices looked really awesome first, but I now tend to get a Picoscope 5444D.
I have a hacked Rigol DS1054Z at the moment (and a crusty analog 20MHz Hameg) and plan to sell the Rigol
in order to get the Picoscope.
Is this a good Idea? The Rigol device is awesome at this price point and great for general purpose use, to probe around a prototype or when repairing a device. I think this is true in general for most bench scopes since you have great accessibility by a dedicated front panel. On the other hand it is almost limited to the internal features. Exporting data is really slow painful and ugly. This means that I am locked down to the features it offers. For the most part that's more than enough, but when doing more analytical things and statistics its basically useless.

I have used a Picoscope as a bench scope a few times but I found the operation by using a mouse very cumbersome. If the software for Picoscope has good support for touch screen operation I'd consider it a solution in combination with a PC with a touch screen. If you are only after a remote operated data acquisition unit then any Picoscope will probably do. Another option is to look for an oscilloscope with faster data transfer. The recent oscilloscopes from GW Instek (1000B and 2000E series for example) have really fast data transfer rates because they have a lot of processing power. Somewhere in an old thread various forum members compared download speeds over the network and the GW Insteks came out on top.

[MrW0lf]

Bit more toying with 2408B:

50ns/div, 1GSa/s, 500Sa:

850kHz in 10kCycle burst:

Scope (collecting buffers): 1
Rapid (collecting buffers): 10000 (100% capture) => 850 kwfm/s
Persistence/*: >1

850kHz steady signal:

Scope (collecting buffers): 34 wmf/s
Persistence/Fast: ~31 kwmf/s
Persistence/Advanced/Scatter/Frequency: ~4 kwmf/s

So that Rapid/segmented thing is quite serious business. Persistence somewhat works depending on mode. But normal mode (Scope) is clearly crippled on purpose, and quite surely on the PC software end.

[Performa01]

My results for the 3206B:

50ns/div, 500MSa/s, 250Sa:

850kHz in one 10k cycles burst

Scope (collecting buffers): 1
Rapid (collecting buffers): 10000 (100% capture) => 850 kWfm/s
Persistence/*: >0 -> rather weird…

850kHz steady signal:

Scope (collecting buffers): 35.7 Wfm/s
Persistence/Fast: ~62 kWfm/s
Persistence/Advanced/Scatter/Frequency: ~6 kWfm/s


Yes, I have figured that a PicoScope should be able to compare with (or even beat) a MegaZoom scope with regard to acquisition rate - only in sequence (rapid trigger) mode, that is.

Old 3206B again:

10ns/div, 500MSa/s, 50 (216)Sa

5MHz in one 10k cycles burst
Rapid Trigger: 10000 (100% capture) => 5 million waveforms per second!

5MHz -> 200ns period, x 10000 = 2ms total burst length.
10ns/div x 10 divisions x 10000 buffers = 1ms acquired data. => blind time = 50%
Re-arm time < 200ns.

That competes with analog scopes at similar timebase settings – sadly just for 2ms…

At even higher rates the Pico starts missing triggers, but hey, that is a pretty darn decent result.

For the true applications of sequence mode, this means we can be almost 100% sure to not miss any event, no matter how random their timing might be.

Speaking of real applications for sequence mode - if only Pico Tech would have realized after all that time that we need time stamps (with µs resolution) for that to be actually useful! 

[2N3055]

Speaking of real applications for sequence mode - if only Pico Tech would have realized after all that time that we need time stamps (with µs resolution) for that to be actually useful! 

Yes, that old chestnut...

Cast a vote here :
https://www.picotech.com/support/topic17321.html?&start=15#p140390

Maybe if more people create fuss...

I plan to have discussion with them at Electronica. I'm not holding my breath, but man has to try... :-)

Regards,
Sinisa

[MrW0lf]

@Performa01: About that 10k buffers thing. It is not listed for 2408B but for 6404D 10k is again PS6 limitation. Also total capture by method is limited to meager 100M. And you'd better insure that 3206B because seems after that they limited Rapid to ~1Mwfm/s because neither of mine will go much over that with 100% capture rate.

BTW SDK spec for 6404D it is max 2M buffers and of course ~2G memory: "something useful could be done".

@2N3055: I have dumped about 5 A4 worth of illustrated suggestions on them about true potential of Rapid trigger, DeepMeasure etc over a year ago. They said many viable and got green light. As of today - yes there have been some improvements with DM but nowhere near the potential.

As for proper timestamps they do not like them because even new version of PicoLog dumped time values rounded to seconds into CSV, which was also reported:
https://www.picotech.com/support/topic38461.html

Edit: Did poke PS6 a little on hope to eliminate speed limit but instead did manage to make it slower & more accurate:
https://www.eevblog.com/forum/testgear/picoscope-2000/msg1940467/#msg1940467

[MrW0lf]

1kCycles at 1kHz burst. wfm/s was counted by number of buffers collected during burst.

10us/div, Trigger is Repeat, Simple Edge, Rising

...

Analog Discovery 2 USB2
100MSa/s, 10kSa: 100wfm/s
10MSa/s, 1kSa: 100wfm/s

Found the setting. In Options below Time. Need to set Update as 1ms, it was on 10ms. New numbers:

100MSa/s, 10kSa: 125wfm/s
10MSa/s, 1kSa: 135wfm/s

Tried other settings, smaller memory etc but this seems to be about the top speed in any case.