Why the lack of open source scopes?

[AndyC_772]

So you are limited to only 1 computer per household?
You would swap magic black box Oscilloscope for a PC dedicated to being Oscilloscope.

Not progress...!

My scope has a LAN port and is on my network. It contains a web server which incorporates a very nicely done, fully graphical representation of the front panel that I can view in a web browser, and use to control the scope as well as viewing waveforms.

It's about as nice an implementation of a 'PC scope' as I've seen anywhere - and I NEVER use it, because it's a much worse way to operate the instrument than the conventional front panel controls. In terms of usability, ergonomics, the speed at which I can work and the rate at which the display is updated, the conventional front panel is so much better it's not even funny.

I use the network interface to capture and save screens so I can include them in reports or email them to customers, and that's it.

I think you've got your market and price points a bit confused. $1000 is what you'd have to pay for serial decoding on the better quality bench scopes, not the Owons of this world. You're getting a very polished, fast, responsive and reliable UI on that level of scope, which you'll struggle to match on a PC. The limitations you describe really only apply to the very bottom tier.

[dannyf]

If you want to accomplish something, then you should identify the core problem you're trying to solve and focus on that.

Totally agree.

The whole thread sounds like a child's dream to me, rather than a well-thought out engineering endeavor: define your problems, define your target niche, define roles / responsibilities and plan out the general framework of how things / modules will eventually work. and then figure out their feasibility - why do you think you can make those individual things happen and why do you think you can make them work together.

Otherwise, it is just a bunch of guys drinking their beers while talking about things they have no clue about.

[Rasz]

Sure, the SoC has fast interfaces. How do you access this without hacking the tablet?

hacking = opening the case, unplugging the camera, plugging own cable.

Hacking the tablet is going to be particular to one type of tablets, and cheap tablets tend to come and go, so it's hard to standardize on one type unless you pick an expensive type like a Samsung/Apple product. Are you also proposing to build your own tablet?

It needs to be done once per device, not the biggest hurdle. USB 3.0 enabled tablets will be here in a year.

All of that is front end. Community build a family of frontends, starting with cheap ass 2x20MHz and see what software people can do with it.

Many SDRs don't even have 20 MHz bandwidth, let alone dual channels. Most SDRs use USB 2.0, which can't sustain 2x20 MHz on a single port. So what components would scopes and SDRs have in common?

dsp, software components are already build and tested in open source SDR applications (some even GPU accelerated).
Its pretty obvious I wasnt talking about reusing SDR hardware.

You already can. Any DSO sold today can interface with a computer over USB and/or LAN. Often with a well-documented SCPI protocol if you buy a decent brand.

Yes, they let you download small sample window, or preprocessed data, or like AndyC_772 says crappy web interface with laggy javascript net 2.0 joke of a UI.

Few people use this for general purpose use (as opposed to logging or automated setups) because it's a pain compared to the stand-alone scope and software availability is poor. Is either of that going to change when an open-source scope comes along? Look at the Sigrok project: none of their GUI's offer a decent interface for a logic analyzer yet. None of the GUI's for the open-source SUMP/OLS logic analyzer is that great either. And the GUI for a LA is much simpler than for a scope.

scope has broader usage scenario than logic analyzer so there is a chance more people would work on it. Look at gnuradio or Gqrx for example, difference between fixed function hi-end ham radio and even cheap SDR + open source software is like night and day. It doesnt have to be like sigrok or Gimp

So how about taking that decent hardware that you're not going to exceed in either performance or price in an open-source design and replace that shitty software?

You would still have to pay for 2/3 of the box (fpga/soc/lcd) that you never use in case of using frontend/adc and connecting to a tablet/pc. Reusing whole thing is too difficult (as mentioned before in the thread), reverse engineering custom design would limit brain power to few determined hackers versus people who know dsp and can program pc.

In general it seems that you guys are looking to increase the number of challenges, as if reaching your core target is not hard enough. Summarizing your and Marco's post together it seems that you guys want to build an analog front-end, an active probe, the ADC + digital hardware, build/hack a tablet and write software better than that by Owon/Hantek/Atten/Rigol. Each of which alone could easily take an experienced engineer a few months of work, depending on how high you're aiming. If you want to accomplish something, then you should identify the core problem you're trying to solve and focus on that.

Best case scenario would be reusing/copying whole frontend up to ADC, and building only PC interface.
Lets face it, writing better software than Owon/Hantek is a given, you cant go worse than that

I think you've got your market and price points a bit confused. $1000 is what you'd have to pay for serial decoding on the better quality bench scopes, not the Owons of this world.

Yes, owons of this world usually dont even offer most of the interesting decoders, or responsive UI for that matter

You're getting a very polished, fast, responsive and reliable UI on that level of scope, which you'll struggle to match on a PC. The limitations you describe really only apply to the very bottom tier.

Highend scoper _are_ x86 PCs.

[senso]

Not all cameras are the same, I dont believe that every manufacturer and camera uses the exact same pin-out in the connector..
Some tablets might be risky to open(example: iPads, need to lift the glued screen)..

Yeah, your scope "app" will be run in a sandbox inside a virtual machine, running interpreted code in the host that then makes the calls to the hardware, it might be a bit laggy..

[AndyC_772]

Yes, they let you download small sample window, or preprocessed data, or like AndyC_772 says crappy web interface with laggy javascript net 2.0 joke of a UI.

I said my scope has "about as nice an implementation of a 'PC scope' as I've seen anywhere" 

The problem isn't the implementation, it's the use of a PC screen and mouse at all. Putting a lot of work into making it faster and more responsive won't change the fundamental fact that clicking buttons on a screen is nothing like as intuitive, easy or comfortable to use as a real front panel.

Highend scoper _are_ x86 PCs.

That's the worst thing about them. Whilst I don't doubt that having the resources of a PC available makes good sense for post-capture analysis, compliance testing and the like, that's a completely different type of usage model compared to how most - or at least, many - general purpose bench scopes are used.

If that's the market you're aiming at then fair enough, a PC plus an acquisition 'engine' probably isn't a bad fit at all. Something that can set up a well-defined test case, capture data in a controlled and predictable way and then analyse the results is certainly a useful tool and well worth investigating.

It's not a replacement for a general purpose scope, though.

[Marco]

Few people use this for general purpose use (as opposed to logging or automated setups) because it's a pain compared to the stand-alone scope and software availability is poor.

Some do though and it can make good sense.

[nctnico]

If the GUI is portable you could use a small Linux box (many available) to run the user interface. If the FPGA in the scope does all the heavy lifting the user interface only has to draw the dots. In that case you can do a lot with USB2.0 even at 12Mbit.

[Rasz]

I said my scope has "about as nice an implementation of a 'PC scope' as I've seen anywhere" 

yes, but it is still crap, right? All it does is remote desktop into scope, with noticeable delay.

The problem isn't the implementation, it's the use of a PC screen and mouse at all. Putting a lot of work into making it faster and more responsive won't change the fundamental fact that clicking buttons on a screen is nothing like as intuitive, easy or comfortable to use as a real front panel.

Thats the beauty of open design - its trivial to add stuff. USB optical encoded knobs are not rocket science. How many knobs do you have on a scope now? Dave always complains about them not being clicky, or many functions piled on one knob. With open design you could add as many knobs as you like, and dedicated custom buttons. Just think how many times you wished something had dedicated button/slider/knob, but instead was hidden under 3 layer menu.

That's the worst thing about them. Whilst I don't doubt that having the resources of a PC available makes good sense for post-capture analysis, compliance testing and the like, that's a completely different type of usage model compared to how most - or at least, many - general purpose bench scopes are used.

PC based scope doesnt have to equal touch screen.

[AndyC_772]

Can I offer a suggestion? See if you can borrow a high quality, general purpose bench oscilloscope from somewhere, and spend a while learning your way around it. It'll take time to get really familiar, but it's well worthwhile doing because only then do the strengths and weaknesses become apparent.

Around the beginning of this year, I was fortunate enough to acquire two new scopes: one Agilent 3000X, and one Rigol DS4000 series. Both were unfamiliar to me at first, but since then I've spent enough time with them to get to know them both reasonably well.

They have similar capabilities, and both UIs are similar enough to the Tektronix scopes I've grown up with that neither has ever felt oddly unfamiliar or off-putting for that reason.

Given the choice, though, unless I strictly needed the Rigol's deep memory, I'd pick the Agilent for a given job every single time. The reason is simple - the controls are beautifully judged in terms of weight, responsiveness and precision, which makes it a pleasure to use. There are precious few things it can do that the Rigol actually can't, but I can set it up and make a measurement in half the time. It's all down to the quality and refinement of the UI, and by that I specifically mean the real, physical knobs and buttons on the unit and the way they interact with the display.

If you made me drive the Agilent via its remote UI, it would easily be the other way round.

[hlavac]

All we need is enough processing power on the hardware to do the actual processing of the samples, leave the display and controls to the PC...

I would be more worried about how to get the data in the PC at a decent rate, if you don't want to be one of those PC-based scopes with way too slow update rates. USB 2.0 is ubiquitous, but slow.

You don't need to transfer all the samples to the PC in real time. Process the samples locally. You can then transfer essentially a processed frame buffer to the PC. Easy enough, every webcam does it!

[alm]

But then you can't do the DSP in a PC. Which was the premise of this thread. You'd need an FPGA, DSP hardware or a really beefy micro to do that at decent speeds.

[dannyf]

But then you can't do the DSP in a PC.

Why?

[alm]

You don't need to transfer all the samples to the PC in real time. Process the samples locally. You can then transfer essentially a processed frame buffer to the PC. Easy enough, every webcam does it!

[Alphatronique]

if someone was willing to design analog front-end / attenuator and software
i may handle all the digital and pcb whit assemby

i just spend my last 5 year working on kind of high speed scope design for my work

that quite easy whit some trick to avoid controlled impedance and similar stuff for keep cost down  , but honestly i sure it not possible to make lower cost that rigol or else


p.s.

just think a bit more about that and this was my suggestion

use sparten6 for glue ADC to DDR (1 DDR Chip / Chanel) and handel other small thing
like touch screen interface and Front panel ,etc etc 
then route a bus from fpga to raspberry pi CSI/DSI connector   
so use raspberry for GUI / LAN / USB   (HDMI permit to use nice display and start firmware development right now ..

so need some one for analog front end / attenuator and trigger circuit
and bunch of software developper