oscilloscope USB vs. CRT

[james_s]

I really don't like the tablet form factor in general, I hate touchscreens and only tolerate them when there is no alternative. I have several tablets and find them to generally be an inconvenient form factor, I always have to find a way to prop it up so it doesn't slide flat on its back and the various kickstand gadgets always leave something to be desired. Having tried for several years to find a good use case for a tablet I have mostly failed and do not really understand why they're so popular. I suppose a scope in that form factor could be handy for automotive work but I certainly would not choose it over a lunchbox form factor for the stuff I most often use a scope for.

[voltsandjolts]

I don't expect serial decoders and analyzer features from any kind of oscilloscope. It's better to use dedicated signal analyzer for such functions. They have more convenient controls and more interesting features than oscilloscope. I think such function is useless for oscilloscope.

MSO scopes are quite popular, and are particularly useful when correlating between analog and digital signals. Correlating between separate instruments is of course a PITA.

Just watched some videos and I almost sure that PicoScope just apply decimation to the signal with no integration for the pixels intensity

Not decimation per se, which loses information, but aggregation.
Min/max values are calculated for each block, either in hardware or software depending on the model.

Intensity grading on the Picoscopes is not great but that's something I'm very happy to trade for the huge versatility they provide.

[Fungus]

I really don't like the tablet form factor in general, I hate touchscreens and only tolerate them when there is no alternative. I have several tablets and find them to generally be an inconvenient form factor, I always have to find a way to prop it up so it doesn't slide flat on its back and the various kickstand gadgets always leave something to be desired.

Micsigs have a really good built-in stand. And knobs, if you don't want to touch the screen.

You can even use a mouse if you want. It's not as fast as the touchscreen but it's still way faster than using the knobs. You can also put the mouse in your working area to avoid reaching over to the 'scope.

[egonotto]

Hello,

......
So this is the answer how it works on USB 2, it just didn't show a true picture and show you aliased picture after decimation.
For comparison, a cheap Siglent SDS1102X shows 14 million points on the screen.

That's the difference with USB PicoScope. USB PicoScope shows 800 points, and dedicated Siglent shows 14 million points

really with a screen of 800 x 480?

If someone give me a complex waveform, that I can load in my Siglent SDG6022X, than I can show the pictures with several USB scopes.

Best regards
egonotto

[radiolistener]

Not decimation per se, which loses information, but aggregation.
Min/max values are calculated for each block, either in hardware or software depending on the model.

This is fake waveform. Actually this is min/max chart, but not waveform. You can't see waveform details between min and max value on such min/max chart. Such mode is named Peak Detect and was used in old digital oscilloscope as a workaround to avoid aliasing due to low memory depth limitation.

really with a screen of 800 x 480?

yes

If someone give me a complex waveform, that I can load in my Siglent SDG6022X, than I can show the pictures with several USB scopes.

you can try the following simple sanity test for oscilloscope. Use AM modulation with 10 MHz ladder waveform as a carrier and 10 kHz square or triangle wave as a message. Modulation depth 100%.

You should get something like that (see pictures). The line count inside a filled area of the waveform should be equals to the ladder step count - 1.

If your scope shows these lines with proper count, then it shows waveform properly. If you don't see these lines, then your scope show you fake waveform. If you can see proper wave envelope without lines, then your scope use Peak Detect mode, it's better than nothing. If you don't see envelope at all and see some garbage, then your scope showing you incorrect waveform.

In my case I was used ladder waveform with 5 steps, so you can see 5 regions separated with 4 lines. Amplitude of the carrier is 4 Vpp with no termination on oscilloscope side, cable length 1 meter.

[voltsandjolts]

Not decimation per se, which loses information, but aggregation.
Min/max values are calculated for each block, either in hardware or software depending on the model.

This is fake waveform. Actually this is min/max chart, but not waveform. You can't see waveform details between min and max value on such min/max chart. Such mode is named Peak Detect and was used in old digital oscilloscope as a workaround to avoid aliasing due to low memory depth limitation.

Fake waveform? Eh, no, it's an aggregated waveform, which contains range information. Peak detect as you say. You can then zoom in to areas of interest to see all data points. Number of datapoints available depend on hardware memory depth etc. - something which those old digital oscilloscopes you mention did not have of course. 512MS is enough for me. Also on Picoscope, it has always-on waveform buffer / segmented memory which makes full use of this memory depth, such that you can view every detail of previous waveforms.

You prefer the 'aggregated waveform' to be presented as waveform intensity, and you are determined that is the only correct way.
For some applications that may be true, but in the varied domains I work in the Picoscope does a fine job as a general purpose scope.

Horses for courses, as they say. Or perhaps, horses for jockeys in this case

[egonotto]

Hello,

I made a try with a 10 MHZ ladder wave form and AM with 10kHz triangle.

Test with:
R&S RTA4000
PicoScope 5243A with older software (6.12.7.2687) under VISTA
Cleverscope CS328A (10 bit)
Voltcraft DSO-2074G which is a Hantek DSO3064A

Best regards
egonotto

[Fungus]

I made a try with a 10 MHZ ladder wave form and AM with 10kHz triangle.

USB's Achilles Heel revealed nicely.

[radiolistener]

You can then zoom in to areas of interest to see all data points.

No, the trick is to see details with no zoom in. It should be seen on a slow horizontal scale.

You prefer the 'aggregated waveform' to be presented as waveform intensity

I just expect to see full waveform with no simplification and no kludges and workarounds. Not min/max diagram, but a full waveform, the same as it will be shown on analog oscilloscope.

I made a try with a 10 MHZ ladder wave form and AM with 10kHz triangle.

Test with:
R&S RTA4000
PicoScope 5243A with older software (6.12.7.2687) under VISTA
Cleverscope CS328A (10 bit)
Voltcraft DSO-2074G which is a Hantek DSO3064A

R&S RTA4000  has passed the test, it shows good waveform as expected.
All other has failed. They show simplified min/max diagram instead of full waveform.

It looks that Voltcraft DSO-2074G has issue with linearity.
And Cleverscope CS328A has some strange distortion, I have no idea what is the root of cause.

I wonder why your ladder waveform is a little bit noisy? What kind of signal generator did you used?

[Fungus]

R&S RTA4000  has passed the test, it shows good waveform as expected.

I'd sure hope so at that price.

I suspect even a Rigol DS1054Z could do a decent job on that signal though.

[egonotto]

Hello,

....
I wonder why your ladder waveform is a little bit noisy? What kind of signal generator did you used?

I used a Siglent SDG6022X. In Arb function the first function is the ladder wave form.
It is not only noise as the 10MHz_Ladder_1.png shows.

Best regards
egonotto

[egonotto]

Hello,

R&S RTA4000  has passed the test, it shows good waveform as expected.

I'd sure hope so at that price.
......

In the eyes of R&S it is a cheap scope:
Mathematics: basic (math on math)
Trigger oprions: comprehensive (10 trigger types)
Mask test: elementary (tolerance mask around the signal)

Best regards
egonotto

[kcbrown]

You do not know anything about programming

Just FYI, I'm Senior Software Engineer with more than 15 years of commercial software development in a medical devices industry. Include RTOS, graphics programming, signal processing, database, network communications, client and server side applications for a known company.

As a hobby project I'm implemented my own software oscilloscope on PC. It is based on a high speed 14-bit ADC working at 100 MHz sample rate, FPGA for a stream processing and Gigabit Ethernet PHY to transfer data into PC.

Since gigabit ethernet is unable to handle 1.6 Gigabit stream from ADC directly, I capture sample into FIFO buffer and then transfer it through GMII PHY into PC at about 600-800 MBit/sec. On PC side I perform software processing of the captured data almost in the same way as a usual digital oscilloscope. I spent some time in order to investigate how digital oscilloscopes doing things in order to done it, so I know what I'm talking about.

the idea was to let the scope do the data reduction, no screen can show 28 megapoints.

You're just don't realize that data reduction which you're talking about is just memory depth limit. And when you transfer just 800 points to the PC you will get exactly the same result as you will get on a dedicated oscilloscope with memory depth limited to a 800 points.

The purpose here is display only, though.  The variable in the equation is the target display resolution.  You might need as much as the entire window's number of pixels per refresh, of course, since you're having to display the decimation of what could well be multiple trigger events which would yield overlapping pixels after decimation.

Then it's a question of the refresh rate.  I'd argue that you really only need 24 frames per second.  That's the frame rate of a motion picture.

Now, seeing how the use case here is a USB scope, I'd argue that you want to be able to resize the display window to something larger than a mere 800 pixels across.  You might set a maximum on that to, say, 2560x1440, but in reality it should probably be capped based on whatever data rate the USB connection is capable of.

What it's capable of transporting is much greater than it appears at first glance. 

Firstly, the vertical position data is actually whatever the scope's bit resolution is, or the vertical resolution of the screen, whichever is smaller.  So there's a hard upper bound on the resolution of the vertical axis.  It might be simpler to just use the scope's bit resolution to define the vertical axis of any given point. 

But secondly, and more importantly, what we're talking about here is very similar to a video stream, which is highly compressible.  A 4K (3840x2160) video needs about 20 megabits per second bandwidth in order to play seamlessly at 60 frames per second.  But that's when video is optimally compressed.  Live streaming bandwidth requirements are going to be a better indicator of the actual bandwidth you'll need, and it seems that for 4K 60 FPS, you'll need about 50 megabits per second.

Despite the vertical resolution limits, it might be simplest just to treat the waveform display as something to be streamed as a video.  Of course, you'd have to compress the data in real time on the scope, but chipsets that make that possible are now widely available from what I can tell.

50 megabits per second is easily achievable with USB 2.  And this will get you the "digital phosphor" effect, or really any effect you want for that matter.

[radiolistener]

The purpose here is display only, though.  The variable in the equation is the target display resolution.  You might need as much as the entire window's number of pixels per refresh, of course, since you're having to display the decimation of what could well be multiple trigger events which would yield overlapping pixels after decimation.

No. As shown above, with 800 points (actually 1600, because it require min and max value for every point) you will get the following picture.



With 280000 points you will get the following picture:


As you can see the difference is obvious, despite the fact that display size is about the same ~800 points width. 280000 points shows picture with detailed structure. You can see a high frequency components details on a slow time scale. The same as you can see it on analog oscilloscope.

While 800 points didn't show all these details. And this is not acceptable for a full-fledged oscilloscope.

But secondly, and more importantly, what we're talking about here is very similar to a video stream, which is highly compressible.

Yes, you can compress it. But there are two issues. First, it should be no loss compression, because some artifacts on the image is not acceptable for oscilloscope. With no loss compression you cannot obtain good compression ratio. The second issue is that compression needs additional performance and resources for both - PC and for FPGA.  Since stream is pretty fast, the realtime compression can eat significant amount of CPU time. So what is better - compressed stream or a raw stream with no compression is not obvious question. In some cases the compressed stream can allocate even more wide bandwidth than a raw stream with no compression. And you cannot use some kind of MP4 with losses and good compression here, because an artifact can be interpreted as a signal glitch which is not acceptable. Also compression needs a lot of additional resources on FPGA. So it will cost more money.

25 fps can be acceptable, but this is too low update rate to get "live effect". 60 fps will be a good choice. I tested it and can say that 75 fps for oscilloscope looks much more smooth and more "live" than 30 fps.

[kcbrown]

No. As shown above, with 800 points (actually 1600, because it require min and max value for every point) you will get the following picture.

Yes, I realize that.  I wasn't arguing for a mere 800 points worth of transmitted data.

Yes, you can compress it. But there are two issues. First, it should be no loss compression, because some artifacts on the image is not acceptable for oscilloscope.

That's fair, but that only constrains the degree or kinds of of loss that would be acceptable.

With no loss compression you cannot obtain good compression ratio.

That depends on the amount of difference between frames.  If the amount of frame-to-frame difference is consistently substantial (like it would be when you're looking at random noise) then you won't get good compression, but at 24 frames per second or higher, the end result will be so much of a mess that accurate representation won't matter anymore anyway.  The entire point of being lossless is so that you can see transients easily and so that you'll have correct gradients when the display is reasonably stable.  Both of those situations are ones for which compression will be high.

So I expect that the amount of compression is actually likely to be very high, even if you make it lossless.

Remember, too, that the vertical resolution is constrained by the sample resolution.  If you're talking about 10 bits of resolution then at most you're talking about 1024 values worth of vertical resolution.  Oh, and the values themselves are not RGB values.  They're just intensity values.

The worst possible case here is a very wide window (e.g., 3840 pixels) being used to display noise that fills all of the vertical values.  But for a 10 bit sample resolution, that's 3840 x 1024 x 8 bits per frame, or 31 megabits per frame, uncompressed.  At 24 frames per second that's 754 megabits per second.  If you could cut that in half somehow then you could just squeak it under the USB 2 bandwidth limit.  Or you could drop to 12 frames per second for random noise, or something.

The second issue is that compression needs additional performance and resources for both - PC and for FPGA. 

Of course.  But as I said, the chipsets for this type of work are readily available and, as far as I know, relatively inexpensive (though I haven't done the research on that, and in any case, what we're talking about might well be a custom implementation anyway).

Since stream is pretty fast, the realtime compression can eat significant amount of CPU time. So what is better - compressed stream or a raw stream with no compression is not obvious question.

You either pay for it with a higher bandwidth link or you pay for it with compression hardware.  There ain't no such thing as a free lunch.  But remember that the original claim is that this kind of display can't be done over USB 2, and that's clearly not true.

In some cases the compressed stream can allocate even more wide bandwidth than a raw stream with no compression.

That's true, but those are pathological cases, for which you'd want to do something else anyway.

And you cannot use some kind of MP4 with losses and good compression here, because an artifact can be interpreted as a signal glitch which is not acceptable.

Perhaps.  Perhaps not.  It depends entirely on the nature of the artifacts and how they show up in the first place.  I don't know enough about how the compression works to make any kind of reasonable guess as to how well it'll work, but I fully expect that it involves frame difference encoding among other things.  I can say that in videos of people using their scopes, I've not seen anything to make me believe that it'll be a real problem.

But it should be easy enough to test this.  Take a video of your scope's screen, then compare the resulting video against what you originally saw on the scope, and see if there are any obvious artifacts that would somehow cause you to change your assessment of what the scope was telling you.

Also compression needs a lot of additional resources on FPGA. So it will cost more money.

Of course.  There ain't no such thing as a free lunch.

25 fps can be acceptable, but this is too low update rate to get "live effect".

I certainly agree that 60 FPS would be better, but if a tradeoff has to be made, a drop in FPS is the logical first step.

The real question is why you want a higher frame rate in the first place.  This is a test instrument, not a video game.  Interactive responsiveness is likely to be limited more by the other processing that happens within the scope than by the frame rate.  And one can easily argue that a lower frame rate is better for seeing transient glitches because it allows a glitch to remain on screen for longer.

[rsjsouza]

Interesting that Picoscope website shows some heat mapped waveforms which precludes applying weights to specific pixels on the frame buffer to display their relative frequency of occurence.

https://www.picotech.com/library/oscilloscopes/digital-persistence-modes

I obviously don't know Pico's implementation, but I imagine the hard work of calculating and formatting the framebuffer with the proper weights to the pixels is done in the custom hardware - especially also because of the very high waveforms per second count.

If I haven't missed any details, there's not much difference than a standalone oscilloscope, since the only difference would be the speed of transmitting all the data via the wire - USB2.0 and the newer implementations have an excellent link budget (unless perhaps if you are doing high speed transfers in the same USB chain).

[2N3055]

Maybe instead of wild speculation and funny numbers pulled out of the hat some real data might be interesting.
Unlike many, Picotech exactly documents what is being transferred and how. In their API manual.
And it's not compressed or 800 points. (why 800 points  ).

Also Pico has (Tektronix  like) two display modes, a standard and persistence mode. In persistence mode it can have classic intensity grading, or color grading with several strategies and phosphor emulation. Palette is also adjustable. You would use that for that type of work. It's not very good, because of short sample lengths used ( to maximize wfms/sec), despite persistence algorithms being excellent. It will work great for signals that don't have too heterogenous frequency content (widely scatered frequencies from low to high), because sample rate drops quickly like in Keysights in that mode..

In standard mode it has flat pixel rendering without intensity. In that mode it simply plots data points and not emulating phosphor. And won't be of much use for looking at intensity gradients of AM modulated signals. But it will calculate measurements over full 100MS buffer.... In that mode it plots on screen similar to old Teks without intensity...

So yeah,  as I said many times before, every instrument won't be brilliant at everything. 20000 USD Keysight MSOX4100 cannot capture PSU startup sequence 100 msec long at 1 GS/sec because you need 100MS for that and it has 1 or 2  or 4 based on settings.  At those high lengths it will drop sampling rate to 10 MS/sec and still keep 1 GHZ input filter and will heavy allias with anything going over 5 MHz. 
Fact that it has brilliant phosphor emulation won't help you there.

And also nice intensity plot is only a visual aid. If  you're going to inspect that signal, you will still need to zoom in and look at the signal at a carrier and modulation friendly timebases...
There are many combinations different carriers and modulation waveforms that will produce same visual effect, including artefacts from aliasing at unlucky timebase/mem depth combinations and interaction with scope refresh rates. 
If you work on a known signal and know what exactly to expect, you can just look at shapes in a manner of a signature analyser.

If you are analyzing signal, then, well you analyze it...

Fact is, you can confuse any instrument if you try. Or if you know your instrument, you can avoid problems, by knowing it's limitations.

Otoh, it's fun to see a little Siglent is shown as a reference example of a well made implementation. It is amazing how much of the useful instrument you can get these days for not much money, compared to only 10 years ago...

[Andrew_Debbie]

Everytime I look at getting a Picoscope, I end up back at a Siglent SDS-1000X-x series.

UK prices from UK distributor.  Prices include tax.

SDS1202X-E    2CH 200MHz 1GS  14Mpts,  ? A/D    £360
SDS1104X-U    4CH 100MHz 1GS  14Mpts,  1 A/D    £391.20  - reduced feature set
SDS1104X-E    4CH 100MHz 1GS   14Mpts   2 A/D   £454.8

Pico
2207B   2CH 70MHz   1GS 64Ms    £379
2208B   2CH 100MHz  1GS  128Ms   £479
2407B   4Ch 70MHz      £579

I belive the Picoscopes all have per channel A/D but I'm not certain.

It is hard to justify paying more for a Picoscope than a Siglent  SDS-1000X-x series.

[tautech]

Otoh, it's fun to see a little Siglent is shown as a reference example of a well made implementation. It is amazing how much of the useful instrument you can get these days for not much money, compared to only 10 years ago...

That little Siglent is a some years old SDS1000X model and their first compact using what is now a much further developed GUI with 8” display and 50 ohm inputs.

Later X-E and the new X-U have the more powerful Xilinx processors but otherwise owe their parentage to SDS1000X models.

[tautech]

Everytime I look at getting a Picoscope, I end up back at a Siglent SDS-1000X-x series.

UK prices from UK distributer.  Prices include tax.

SDS1204X-E    2CH 200MHz 1GS  14Mpts,  ? A/D    £360
SDS1104X-U    4CH 100MHz 1GS  14Mpts,  1 A/D    £391.20  - reduced feature set
SDS1104X-E    4CH 100MHz 1GS   14Mpts   2 A/D   £454.8

Pico
2207B   2CH 70MHz   1GS 64Ms    £379
2208B   2CH 100MHz  1GS  128Ms   £479
2407B   4Ch 70MHz      £579

I belive the Picoscopes all have per channel A/D but I'm not certain.

It is hard to justify paying more for a Picoscope than a Siglent  SDS-1000X series.

To be completely fair, I can get a modest discount on Picotech.    Makes the 70Mhz Pico the same price as a 200Mhz Siglent.

4ch X-E are the pick of that bunch if you’re looking for the fullest featured scope.