new Oscilloscope choice

[technogeeky]

Oh no....OT another OS DSO thread ! 

Please take it elsewhere.

I wasn't aware of that topic (I have been gone for a while); but I specifically mean an existing manufacturer opening; not a new development. It doesn't matter.

To the OP:

Watch the whole mikeselectric video on the RTB. If money isn't a problem, the R&S scopes are awesome and the UI is amazing. I can't afford it myself.

[2N3055]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

From my Rigol:
* letting a user define an extra virtual channels they can use for math functions, offsets, etc (constants)
* adding highlight frequency in ffts
* adding the ability to anchor the trigger point left, center, or right - R&S has this
* porting over the math functions like e.g. micsig has - arbitrary functions so you can normalize waveforms, etc
* adding overrides, like adding 2.5x or 7.5x probe values so you can do tricky offsets (some other scopes have this in hardware)

I mean, whichever scope has large sales and open source will very, very quickly have the best bus decoding features out there.

Before going even more off topic, I will repeat some things said before elsewhere:

Scopes don't have unlimited memory and processing power. They rely on delicate interplay of hardware processing engine and software. Both will be limited and defined by actual chips used inside.
Large parts of rendered waveforms will be done in hardware (ASIC or FPGA) and then given to CPU to render overlays. Some traces will come from hardware some from CPU and they are mixed on same screen and scaled to look and feel like they are equal. All of that makes real, working, embedded scope, and that cannot be open sourced. It could, but would gain nothing. Nobody would do anything useful with it, because it is out of capability of heard to write something useful there. There are dozens of scopes that got reverse engineered to the point that it was known what it does and how hardware looks like.
None of them got nowhere. People managed to run Linux on it and play doom. None of them even got to the point acquire waveforms at all. None of them even got to point to even match functions that scopes got before they started "development".

What could be done would be PC scope like the Picoscope, the basic acquisition engine that does nothing than just sample data and gives it to PC for all processing. Then all of the scope functionality IS in software, and that would be closer to what could be managed. And indeed, there is a very, very clever guy Andrew Zonenberg doing just that. He is developing both acquisition hardware and software for PC. And software can (and does) work with many scopes, including effort to make it work with Siglent scopes.
Just to be clear, that is not classic scope though. It can manage few wfms/sec. As you go up the food chain, high end scopes are specialized for advanced analysis, not screen speed..

That being said, most of the stuff you enumerated here, SDS2000X+ already have, and some are visual user preferences, that might, or might not be interesting to all users.
But it is always nice to have (nice) discussion and hear clear examples and suggestions (instead of just "this bad..").
You never know, if possible and idea is good it might even get implemented..

To answer to you on RTB2000, I think it is a very confusing scope. It has some very nice features, but is limited (deliberately) in some very annoying ways. There is no search on any serial protocols except on CAN. Segmented memory is implemented as a "datasheet feature" it is not as powerful as it should be. 
It is basically an Apple of scopes: expensive,fancy and visually polished, with many good features but also limited in many ways that are not obvious at first glance.  And then you realize you could have bought Xiaomi phone with Android for much, much less money and still accomplish same things with it. Call, and SMS and read mails etc etc..

I really, really, would politely ask, if any of you want to discuss more on open source scopes, than a topic should be opened and we can discuss it there...

[Fungus]

I really, really, would politely ask, if any of you want to discuss more on open source scopes, than a topic should be opened and we can discuss it there...

There have been many threads on this already.

Short version:
a) Trying to reverse engineer then write for an existing 'scope is insanity, plus they might stop manufacturing them at any time.
b) Making usable open-source 'scope hardware is difficult.

Here's the previous thread:

https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/

[tautech]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

From my Rigol:
* letting a user define an extra virtual channels they can use for math functions, offsets, etc (constants)
* adding highlight frequency in ffts
* adding the ability to anchor the trigger point left, center, or right - R&S has this
* porting over the math functions like e.g. micsig has - arbitrary functions so you can normalize waveforms, etc
* adding overrides, like adding 2.5x or 7.5x probe values so you can do tricky offsets (some other scopes have this in hardware)

I mean, whichever scope has large sales and open source will very, very quickly have the best bus decoding features out there.

An assortment of screenshots covering most of those ^.
All X-E models can do some of these tricks while 5kX and 2kX Plus have the Math on Math and generally better virtual keyboards.
No signals were molested in these screenshots.

[kcbrown]

I really, really, would politely ask, if any of you want to discuss more on open source scopes, than a topic should be opened and we can discuss it there...

There have been many threads on this already.

Short version:
a) Trying to reverse engineer then write for an existing 'scope is insanity, plus they might stop manufacturing them at any time.
b) Making usable open-source 'scope hardware is difficult.

Here's the previous thread:

https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/

Right.  And what's being asked for here is neither.  He's asking for a manufacturer to open source its firmware.  Which means that the manufacturer will already have done all of the heavy lifting.  The hardware design will already have been done (they're building a scope, after all) and the difficulties of making the firmware fast with respect to captures will also have already been done.

Is there a thread that covers the case that technogeeky is specifically talking about?

[kcbrown]

In the absence of a better alternative thread for this (if you've got a good one in mind, please share the link to it and I'll happily move this message there), I thought I'd add a little fuel to the fire of the memory management question.   

So, you who support the automagic "use all the memory available" approach think it's more intuitive, eh?  Well, then explain this:

https://youtu.be/UTsbYqhZiSg?t=2937

There, @mikeselectricstuff told the UART trigger to fire when it detects an FF byte, something that is present at the beginning of the 8k length packets he's capturing.  He seems (but see below) surprised that when he zooms in, it will start to fire in the middle of his 8k packet as well.

Did you spot the problem?  I did.  The packet's time duration is about 41ms.  When zoomed in, the scope is sampling at 1.25Gs/s.  And he's in "automatic" memory management mode.  That yields a required memory length to capture the entire packet of 51.25 million samples.   The scope has at most 20 million samples worth of memory.   The trigger is re-arming and firing again in the middle of the packet because the end of the memory space is reached before the end of the packet is reached, the trigger is re-arming, and the re-arm time is fast enough that it's seeing an FF packet in the remaining data in the packet.

With the Siglent and an understanding of the simple fact that what you see is all you get, the reason for this behavior would be obvious on its face.  This is so because you would know that all it's capturing is what's on the screen and nothing more.  But with a "use all the memory for a single capture" approach, it isn't obvious at all until you do the math.  You won't get any visual indication at all of the problem because the scope will be using all of its available memory at 1.25GS/s, so it won't show you the capture size relative to the size of the packet because it doesn't know that it should, or even how.

Like I said, the Siglent's approach has the advantage of obviousness.  The lack of obviousness in the approach that some here (nctnico, Fungus) prefer is exactly why @mikeselectricstuff didn't seem to immediately realize why his scope was firing the trigger in the middle of the packet.


EDIT: upon re-watching that section of the video, the real problem he seems to be concerned about is that he thinks that it's triggering off of data that differs from what he told it to trigger off of.   But interestingly, the signal he shows it triggering against matches both what he told it to trigger against and what the decoder claims it to be.  I still wonder, though, if he was surprised that it was triggering in the middle of the packet.  I can't tell anymore after having viewed this again.

The obviousness argument still holds nonetheless.  Sorry, @mikeselectricstuff, if I mischaracterized your understanding of the problem.

[Fungus]

Right.  And what's being asked for here is neither.  He's asking for a manufacturer to open source its firmware.

Oh, right.

That's not gonna happen. It just isn't.

(which is maybe why I missed the point - it's completely unthinkable)

Manufacturers need to keep control of exactly what every model in the lineup can do. eg. They don't want 2000-series features being hacked into to their 1000-series devices, it's bad for profits.

[kcbrown]

Oh, right.

That's not gonna happen. It just isn't.

(which is maybe why I missed the point - it's completely unthinkable)

Manufacturers need to keep control of exactly what every model in the lineup can do. eg. They don't want 2000-series features being hacked into to their 1000-series devices, it's bad for profits.

There's certainly some validity to that.  But keep in mind that lower end scopes also have lower end hardware, and hardware capabilities make a substantial difference in what can be done in firmware.  So it's not like a manufacturer that did this wouldn't have the ability to differentiate their higher level offerings from their lower level ones, even if they were to open source their firmware.

Honestly, I think it's not going to happen because of all of the proprietary techniques that would be revealed by doing so, ones that could easily give them an edge in the marketplace, most especially in the FPGA(s) (which is really where the deep magic lives).

[2N3055]

I really, really, would politely ask, if any of you want to discuss more on open source scopes, than a topic should be opened and we can discuss it there...

There have been many threads on this already.

Short version:
a) Trying to reverse engineer then write for an existing 'scope is insanity, plus they might stop manufacturing them at any time.
b) Making usable open-source 'scope hardware is difficult.

Here's the previous thread:

https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/

Right.  And what's being asked for here is neither.  He's asking for a manufacturer to open source its firmware.  Which means that the manufacturer will already have done all of the heavy lifting.  The hardware design will already have been done (they're building a scope, after all) and the difficulties of making the firmware fast with respect to captures will also have already been done.

Is there a thread that covers the case that technogeeky is specifically talking about?

That exact question arises every now and then. And answer is what I said: You cannot decouple hardware and software development. So hardware manufacturer would need to make all the steps like they would to create full scope, design hardware according to expected specs and capabilities, and then practically  abandon project two thirds of the way, and then document hardware in detail so someone can write their own software, and maybe also develop API and open source that too..  And then sell only scope hardware for nominal manufacturing cost + some small percentage.
Why would anybody do that? Manufacturers are not social services...

Like I said before, Linux came to existence over 25+ years. That was possible because it was made to run on Intel PC compatible platform, that existed and kept it's binary compatibility for all that time. And that was because Microsoft created reference platform and drove compatibility effort for 25 years....
Linux rept benefits on the fact that whole (professional) PC industry of the world created single platform for them to exploit. And that was possible only because it was a huge market and it was good business. And also, millions of general purpose programmers writing general purpose code were available, so some were willing to contribute.
If Linux survival depended on "Linux reference computing platform" to run it it would be stillborn.

Scopes are different, in hardware, target market, application specific code with heavy DSP and advanced math.
And few years in, hardware is obsolete...And there is no industry wide effort to make  new one that keeps all previous effort....

I hope you understand better now. I'm not against it. It's simply not going to happen. No company will spend millions to develop something they would give for free for "privilege" to sell cheap, low profit hardware that, by the way, would be copied in short time by many making cheap knockoff copies that would drive price point and quality into the ground...

[kcbrown]

Scopes are different, in hardware, target market, application specific code with heavy DSP and advanced math.
And few years in, hardware is obsolete...And there is no industry wide effort to make  new one that keeps all previous effort....

I hope you understand better now. I'm not against it. It's simply not going to happen. No company will spend millions to develop something they would give for free for "privilege" to sell cheap, low profit hardware that, by the way, would be copied in short time by many making cheap knockoff copies that would drive price point and quality into the ground...

I agree, it's not going to happen.  With respect to the efforts of making new ones that keep the previous efforts, the manufacturers already do that, since it's horribly uneconomical to throw away previous efforts without good reason.  You get new hardware architectures and all that, but there are development techniques that can be brought to bear to minimize the amount of work you have to do to port your prior efforts to a new hardware platform.  I fully expect that manufacturers make extensive use of those techniques because the cost of developing everything needed to make the scope's hardware do what it does is very, very high.

It's actually really remarkable just how inexpensive we're getting scopes for these days, given the sheer amount of man-hours that must have gone into their development.  I can't see how they can possibly get them as inexpensive as they have without leveraging an enormous amount of prior development on previous generation scopes.

[Fungus]

... document hardware in detail so someone can write their own software, and maybe also develop API and open source that too..  And then sell only scope hardware for nominal manufacturing cost + some small percentage.
Why would anybody do that? Manufacturers are not social services...

That, too^

They'd have to provide a whole lot of documentation, pass it through a legal department to make sure they aren't publishing something that might accidentally be patented, do a complete code review to make sure there's no rude comments, a whole bunch of expensive stuff.

Would it let them make a lot more more money? I doubt it. The way to sell lots of hardware is to make it cheap (better bang:buck), not to do a whole bunch of extra stuff that will cause them headaches and only a small minority is interested in.

[tv84]

John, to make things (un)clearer for you: the RTB is as "doctorable" as the SDS.

Really?
I thought some had started and dumped the firmware, but no real progress had been made, as most RTB users got a full-spec bundle at one of the sales.

I've got the COM4 bundle too so it's "too late" for me, but could you link to the thread where they've cracked that nut?

AFAIK there is no thread in this forum. But the thread you mention is a nice start. So, that was precisely what I was trying to convey: there are plenty of A-brand "nut cracking" that isn't visible.

[2N3055]

John, to make things (un)clearer for you: the RTB is as "doctorable" as the SDS.

Really?
I thought some had started and dumped the firmware, but no real progress had been made, as most RTB users got a full-spec bundle at one of the sales.

I've got the COM4 bundle too so it's "too late" for me, but could you link to the thread where they've cracked that nut?

AFAIK there is no thread in this forum. But the thread you mention is a nice start. So, that was precisely what I was trying to convey: there are plenty of A-brand "nut cracking" that isn't visible.

[kcbrown]

That exact question arises every now and then. And answer is what I said: You cannot decouple hardware and software development. So hardware manufacturer would need to make all the steps like they would to create full scope, design hardware according to expected specs and capabilities, and then practically  abandon project two thirds of the way, and then document hardware in detail so someone can write their own software, and maybe also develop API and open source that too..  And then sell only scope hardware for nominal manufacturing cost + some small percentage.
Why would anybody do that? Manufacturers are not social services...

Well, it's actually worse, or better, depending on your point of view.

What's being asked for here is for the manufacturer to open source the firmware.  That, of course, could happen at any time, including after the manufacturer has released the scope along with completed firmware.

But it's hard to see what incentive the manufacturer would have to do so since doing so simply increases the chance of his older scope offering being more competitive with his new offering.  His new offering would need to have a substantial hardware improvement to make it worth buying as a replacement for the older offering.

The other issue is with respect to specialized techniques that the manufacturer may have developed in order to implement certain things in the firmware.  By open sourcing his firmware, he'd be essentially releasing those techniques to the public.

There are ways around these things, though.  For instance, the manufacturer could include a binary bundle that contains the sensitive bits that he doesn't want disclosed, along with a very restrictive license for it.   And the rest of the code could also have a restrictive license for it, e.g. it could be released with terms that stipulate that it is to be used only with the scope models that he has released, and distributed only to other individuals who possess such scopes themselves.

If the goal is to get the users involved in the development efforts so as to minimize the amount of time that bugs remain in the firmware, then there are ways to do that without open sourcing the firmware, and distribution of it could be limited strictly to people who own the hardware in question.  But that would also require some effort and might not be worth it.  The number of people who would simultaneously be interested in improving the firmware and would be capable of doing so is likely very small.  In the end, these are special-purpose devices, and their market size is highly limited compared with other mass produced devices.

One last thing to consider: someone who winds up with the source for the firmware and puts a substantial amount of development time into it will almost certainly be dissuaded from buying a later offering from that manufacturer, precisely because of his investment into the current scope that is far above and beyond what it would be if he were merely a purchaser of it.  That obviously works against the manufacturer's interests.

I'm repeating myself here, but quite frankly, I'm astonished that these scopes are as inexpensive as they are, considering the overall market size for them and the incredible amount of R&D that has gone into them.

[technogeeky]

Before going even more off topic, I will repeat some things said before elsewhere:

Scopes don't have unlimited memory and processing power. They rely on delicate interplay of hardware processing engine and software. Both will be limited and defined by actual chips used inside.

Yes, and the software which runs on them...

Large parts of rendered waveforms will be done in hardware (ASIC or FPGA) and then given to CPU to render overlays. Some traces will come from hardware some from CPU and they are mixed on same screen and scaled to look and feel like they are equal. All of that makes real, working, embedded scope, and that cannot be open sourced.

On what basis do you assert this?

It could, but would gain nothing.

On what basis...

Nobody would do anything useful with it, because it is out of capability of heard to write something useful there.

On what basis!!?

There are dozens of scopes that got reverse engineered to the point that it was known what it does and how hardware looks like.
None of them got nowhere. People managed to run Linux on it and play doom. None of them even got to the point acquire waveforms at all.
 None of them even got to point to even match functions that scopes got before they started "development".

It's almost like without certain critical information they can't progress at all...

What could be done would be PC scope like the Picoscope, the basic acquisition engine that does nothing than just sample data and gives it to PC for all processing. Then all of the scope functionality IS in software, and that would be closer to what could be managed. And indeed, there is a very, very clever guy Andrew Zonenberg doing just that. He is developing both acquisition hardware and software for PC. And software can (and does) work with many scopes, including effort to make it work with Siglent scopes.

This is good, but not what I'm asking for and it won't fix bugs, inconsistencies, or quirks, or errors in the scopei.

Just to be clear, that is not classic scope though. It can manage few wfms/sec. As you go up the food chain, high end scopes are specialized for advanced analysis, not screen speed..

That being said, most of the stuff you enumerated here, SDS2000X+ already have, and some are visual user preferences, that might, or might not be interesting to all users.
But it is always nice to have (nice) discussion and hear clear examples and suggestions (instead of just "this bad..").
You never know, if possible and idea is good it might even get implemented..

There is plenty of space to make configurable software that lets users decide what is interesting to them. (I mean this in a compile space sense, but it may be true in a memory space sense).

To be clear I think it's more important for people to try and implement bad ideas because they are likely to be the most interesting ones! While I struggled to think of a few things that annoyed me with my current scope; but there are tons more things that I don't think would be useful for everyone but I would still want anyway.

For instance, I would love an option to disable/unload as many features on the 1054z just to speed it up a few percent or even one percent so the screen shot capture and download (to make GIFs) would be as fast as possible. Does anyone else want that? Probably not. Is there a chance for the manufacturer to implement it? Zero.

It feels like there's a bit of a failure of imagination about this. For instance, everyone who has made arguments against has had a tacit assumption in their argument that there is one master source code.

e.g. The mindset is: is this feature wanted by most oscilloscope users? It may just make it in, if you're lucky - on the next update, which will be between 6 months and 2 years from now.


It could be: Grab the list of plugins and see which one looks good. Oh, yeah, the one which draws some nice 18th century curtains over the top of my zoom window does just the trick. Oh crap, it's white fabric instead of red. Fork and change the color!

To answer to you on RTB2000, I think it is a very confusing scope. It has some very nice features, but is limited (deliberately) in some very annoying ways. There is no search on any serial protocols except on CAN. Segmented memory is implemented as a "datasheet feature" it is not as powerful as it should be. 
It is basically an Apple of scopes: expensive,fancy and visually polished, with many good features but also limited in many ways that are not obvious at first glance.  And then you realize you could have bought Xiaomi phone with Android for much, much less money and still accomplish same things with it. Call, and SMS and read mails etc etc..

I really, really, would politely ask, if any of you want to discuss more on open source scopes, than a topic should be opened and we can discuss it there...

I will do just that. I would appreciate it someone with some credibility around here might consider seriously considering the pro argument through and through (or even if you think the argument is wrong, put your debate team hat on and argue for it anyway). Maybe there are people in a position to influence at e.g. Siglent or Rigol  who are open to suggestion if not persuasion. 

[technogeeky]

That exact question arises every now and then. And answer is what I said: You cannot decouple hardware and software development. So hardware manufacturer would need to make all the steps like they would to create full scope, design hardware according to expected specs and capabilities, and then practically  abandon project two thirds of the way, and then document hardware in detail so someone can write their own software, and maybe also develop API and open source that too..  And then sell only scope hardware for nominal manufacturing cost + some small percentage.
Why would anybody do that? Manufacturers are not social services...

Well, it's actually worse, or better, depending on your point of view.

What's being asked for here is for the manufacturer to open source the firmware.  That, of course, could happen at any time, including after the manufacturer has released the scope along with completed firmware.

But it's hard to see what incentive the manufacturer would have to do so since doing so simply increases the chance of his older scope offering being more competitive with his new offering.  His new offering would need to have a substantial hardware improvement to make it worth buying as a replacement for the older offering.

The other issue is with respect to specialized techniques that the manufacturer may have developed in order to implement certain things in the firmware.  By open sourcing his firmware, he'd be essentially releasing those techniques to the public.

There are ways around these things, though.  For instance, the manufacturer could include a binary bundle that contains the sensitive bits that he doesn't want disclosed, along with a very restrictive license for it.   And the rest of the code could also have a restrictive license for it, e.g. it could be released with terms that stipulate that it is to be used only with the scope models that he has released, and distributed only to other individuals who possess such scopes themselves.

If the goal is to get the users involved in the development efforts so as to minimize the amount of time that bugs remain in the firmware, then there are ways to do that without open sourcing the firmware, and distribution of it could be limited strictly to people who own the hardware in question.  But that would also require some effort and might not be worth it.  The number of people who would simultaneously be interested in improving the firmware and would be capable of doing so is likely very small.  In the end, these are special-purpose devices, and their market size is highly limited compared with other mass produced devices.

One last thing to consider: someone who winds up with the source for the firmware and puts a substantial amount of development time into it will almost certainly be dissuaded from buying a later offering from that manufacturer, precisely because of his investment into the current scope that is far above and beyond what it would be if he were merely a purchaser of it.  That obviously works against the manufacturer's interests.

I'm repeating myself here, but quite frankly, I'm astonished that these scopes are as inexpensive as they are, considering the overall market size for them and the incredible amount of R&D that has gone into them.

I wish to reply here, but in the interest in cutting this off as has been repeatedly suggested I'll just take it elsewhere.

[kcbrown]

I wish to reply here, but in the interest in cutting this off as has been repeatedly suggested I'll just take it elsewhere.

Please supply the link to the resulting thread here once you create it.  I've a keen interest in the subject myself.

[nctnico]

Large parts of rendered waveforms will be done in hardware (ASIC or FPGA) and then given to CPU to render overlays. Some traces will come from hardware some from CPU and they are mixed on same screen and scaled to look and feel like they are equal. All of that makes real, working, embedded scope, and that cannot be open sourced.

See this thread: https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/ But as I wrote there the rendering on an open source scope needs to happen in software (or more precisely: using the GPU) so it is portable to other hardware. And this has been done before... by Lecroy. If you dig deeper into their Wavepro 7000 series you'll see that the acquisition hardware is incredibly simplistic. All the waveform rendering is GPU based, the processing is done by the CPU.

None of them got nowhere. People managed to run Linux on it and play doom. None of them even got to the point acquire waveforms at all. None of them even got to point to even match functions that scopes got before they started "development".

Wrong. https://sourceforge.net/projects/welecw2000a/files/

[2N3055]

Large parts of rendered waveforms will be done in hardware (ASIC or FPGA) and then given to CPU to render overlays. Some traces will come from hardware some from CPU and they are mixed on same screen and scaled to look and feel like they are equal. All of that makes real, working, embedded scope, and that cannot be open sourced.

See this thread: https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/ But as I wrote there the rendering on an open source scope needs to happen in software (or more precisely: using the GPU) so it is portable to other hardware. And this has been done before... by Lecroy. If you dig deeper into their Wavepro 7000 series you'll see that the acquisition hardware is incredibly simplistic. All the waveform rendering is GPU based, the processing is done by the CPU.

None of them got nowhere. People managed to run Linux on it and play doom. None of them even got to the point acquire waveforms at all. None of them even got to point to even match functions that scopes got before they started "development".

Wrong. https://sourceforge.net/projects/welecw2000a/files/

None of the cheap embedded scopes are PC based.. Unless you think some of the manufacturers of high end 20000+USD scopes would be willing to donate platform for free. OP repeated few times that he doesn't want to make OS hardware, but would like for manufacturer to "donate" ready made product so open source crowd could "make it better".

If you would want to make one, yes then that is the way, I agree. And that is what Andrew Zonenberg does...
But OP didn't want that. He would like for Siglent, Rigol, Keysight, whatever, would "donate" scope to Open Source community. And I think that is not realistic because there is no benefits for manufacturer to do so.

As for Welec (that our user Branadic was involved in) it was ONLY one that went somewhere. But that was very simple basic scope even 10 years ago. And it went nowhere when platform was discontinued. That proves my other points. I believe it was great learning experience, but didn't make significant impact.
Since then, price performance of entry level scopes is much better to the point that it makes no sense to make when you can buy very good very cheaply..

My point is that I would be ecstatic if someone would accomplish to make open source scope that would be similar to DS1000Z, not to mention better than that.

[nctnico]

Making a new DS1000Z is pointless. The bang per buck just isn't there for a low volume product. tom66 did a poll and it seems people are willing to pay way more for open source oscilloscope hardware then the price of a DS1000Z. If you want a DS1000Z then just buy one of those. And with embedded GPUs and processors being really powerfull you don't need a PC to have enough processing power.

BTW: I'm still waiting for progress on people reverse engineering the LUA API inside the GW Instek scopes. This could be mighty interesting and -if the API can do useful things- a serious entry into making third party plugins.

[2N3055]

Making a new DS1000Z is pointless. The bang per buck just isn't there for a low volume product. tom66 did a poll and it seems people are willing to pay way more for open source oscilloscope hardware then the price of a DS1000Z. If you want a DS1000Z then just buy one of those. And with embedded GPUs and processors being really powerfull you don't need a PC to have enough processing power.

BTW: I'm still waiting for progress on people reverse engineering the LUA API inside the GW Instek scopes. This could be mighty interesting and -if the API can do useful things- a serious entry into making third party plugins.

I'm not saying people should make an Open Source DS1000Z, but that even making DS1000Z would be mission almost impossible, not to mention LeCroy mid range scope. And, again, technogeeky didn't want to make hardware of any sort. He would like that some manufacturer donate platform to open source... So a better software would be made by open source community..

Which brings us to fact that that RE of Lua on GW Instek is been going on for few years now... Proving my point it's not easy to do....

[nctnico]

Which brings us to fact that that RE of Lua on GW Instek is been going on for few years now... Proving my point it's not easy to do....

That is more due to nobody really investing the time to figure it out (or someone has spend the time but hasn't published the results yet). There is root access and how to make new add-on apps is known. Figuring out which function exposed to the LUA engine does what is just grunt work. Not difficult but time consuming. But it has to start with a need for a specific feature. About a decade ago I created protocol decoding plugins for the Tektronix TLA700 series logic analysers based on some preliminary reverse engineering efforts from someone else. There was a need and thus motivation to spend the time. OTOH I woulnd't know what functionality to add to my GW Instek scope.

[hobbyelectronics]

Hi,

Going back to the original topic about deciding on a particular scope and getting away from open source for a moment (Although an interesting discussion), what views do you have on the Siglent SDS5034X.

Mainly, compared to the R&S 20004EDU with plenty of free upgrades, is the Siglent 5000x series far superior?

https://www.batronix.com/shop/oscilloscopes/Rohde-Schwarz-RTB2004EDU.html
https://www.batronix.com/shop/oscilloscopes/Siglent-SDS5034X.html


Anyone got any thoughts on the 5000X series (Or anything priced similar) that would completely put it in a league of its own over the R&S2000 series.
Also is the 5034X easily and freely upgradable.

Any thoughts good or bad, would be good to hear.

Thanks

John

[tautech]

SDS5054X owner here.
While the 5000X individual vertical controls provide for more intuitive use over SDS2000X Plus models Plus models do have a more polished front panel layout.
An additional USB outlet is welcome too in SDS5000X for powering other devices along with a mouse and USB stick.
10 MHz input too if you have time nut tendencies.
No internal AWG in 5000X so you are limited to the external 25 MHz SAG1021I single isolated channel module.
Active probe support for LeCroy, Tek (with adaptors) and Siglent active probes.
Dual 5 GSa/s ADC's each with 250 Mpts mem depth.

Otherwise it's virtually the same to use as the SDS2000X Plus.

[hobbyelectronics]

Hi tautech,

ah, ok, that's interesting and useful coming from someone who actually has one.

Although coming from old analogue scopes having individual vertical control is nice, its not essential and I suppose you get used to what you have.

At the moment I feel if I could get a RTB2004 fully loaded at a good price I may be tempted but the Siglent certainly offers better value bang for buck.

Back to having a long hard think......

Thanks