First picture on EEVblog of the new R&S MXO4 series oscilloscope :)

[EEVblog]

Software is not easy to design. I think a lot of 'traditional' companies did and do struggle with good software design.

The amount of software in a scope like this would be massive.

[egonotto]

However, RMS is not the right measure here. Better is peak to peak or the really visible width of the noise band.

Peak to peak noise can greatly depend on the sample rate and waveform update rate. i.e. all thing being equal, a faster update rate scope will appear "noisier".
This is why RMS noise is used for comparison.

Hello,

a misunderstanding has occurred. My submission refers to a table of Rich@RohdeScopesUSA in which he relates the RMS noise to the height of the entire screen, as if the RMS noise were measuring the width of the visible noise.

Table of Rich@RohdeScopesUSA:
"
             R&S                                              LeCroy   
Scale   RMS Noise              % of Full Scale   RMS Noise   % of Full Scale
0.001   0.000104              1.0%                   0.000145     1.8%
0.002   0.000116              0.6%                   0.000145     0.9%
0.005   0.000152              0.3%                   0.00015     0.4%
0.01           0.000238              0.2%                   0.000155     0.2%
0.02           0.000436              0.2%                   0.000185     0.1%
0.05           0.00101              0.2%                   0.000275     0.1%
0.1           0.00247              0.2%                   0.0005     0.1%
0.2           0.00443              0.2%                   0.00175     0.1%
0.5           0.01013              0.2%                   0.00275     0.1%
1           0.01996              0.2%                   0.0049   0.1%

"

Best regard
egonotto

[bozidarms]

Quote from: goaty on Today at 09:16:15 am

    Software is not easy to design. I think a lot of 'traditional' companies did and do struggle with good software design.


The amount of software in a scope like this would be massive.

Are we talking here as beta testers on one unfinished (far eastern provenance) product, or we talking over one serious, expensive, industrial quality instrument?

[EEVblog]

I was able to reproduce the bug:

[EEVblog]

Are we talking here as beta testers on one unfinished (far eastern provenance) product, or we talking over one serious, expensive, industrial quality instrument?

My Keysight 3000 literally went up in flames and released the magic smoke on its launch day.
An Extech multimeter blew up in my hands.
Rigol scopes have had too many bugs to count.
The list could go on.

[nctnico]

As a rule of thumb: don't buy anything after it has just been released. This goes for about anything more complicated than a hammer and not just test equipment. Wait a year or two for the serious teething issues to be ironed out.

[Martin72]

Banana version...
But someone has to buy it before all the bugs are fixed.
First of all, to find bugs that may not be found in development or simply overlooked.
Secondly, if no one buys it and everyone would just wait, why improve something that (apparently) has no takers.

[Rich@RohdeScopesUSA]

My Keysight 3000 literally went up in flames and released the magic smoke on its launch day.

Thought I was going to lose my job on this one   Fortunately I didn't   

-Rich

[bozidarms]

Just recently, i bought a new car and then, unfortunately it turned out that the engine is not yet working as it should,
i couldn't drive it.
After further consideration fell out that the problem was in software engineering.
So after year or two, car was repaired and i was so blissful.

[EEVblog]

My Keysight 3000 literally went up in flames and released the magic smoke on its launch day.

Thought I was going to lose my job on this one   Fortunately I didn't   

I can remember sitting there thinking "They were kind enough to send me this nice scope, should I show people that it actually blew up?" a few seconds later... "Yeah, bugger it, it's hilarious!"
Keysight got way more mileage of goodwill out of the rapid response to the issue than any potential damage to their image.

[EEVblog]

As a rule of thumb: don't buy anything after it has just been released. This goes for about anything more complicated than a hammer and not just test equipment. Wait a year or two for the serious teething issues to be ironed out.

That approach doesn't work if you want or need a leading edge bit of kit.
Happens in software too. Altium and its (in)famous bugs for example. You want the new features released and you accept that there are likely to be a ton of bugs in the new upgrade.

[Fungus]

Are we talking here as beta testers on one unfinished (far eastern provenance) product, or we talking over one serious, expensive, industrial quality instrument?

Software is complicated no matter what country it's written in. I'm sure there's horror stories from every single brand.

I'd even believe that the more expensive something is, the more places there are to screw up the design. Cutting edge is cutting edge.

No product manager these days is ever going to say "let's just use it internally for another six months and see if any bugs turn up".

[bozidarms]

Software is complicated no matter what country it's written in. I'm sure there's horror stories from every single brand.

I'd even believe that the more expensive something is, the more places there are to screw up the design. Cutting edge is cutting edge.

No product manager these days is ever going to say "let's just use it internally for another six months and see if any bugs turn up".

I don't quite understand the logic behind that statement, but as long as the potential buyer is willing to accept it, i have no problem with that.
I personally would never do anything like that, or when I buy a great, expensive product (car, TV set...), i expect from the beginning everything to work perfectly (drive easily, perfect picture...).
Don't see any reason why would be different with measuring equipment.

[Fungus]

when I buy a great, expensive product (car, TV set...), i expect everything to work perfectly (drive easily, perfect picture...).

Both of those frequently have 'recalls' and they both get firmware updates these days.

[tautech]

I personally would never do anything like that, or when I buy a great, expensive product (car, TV set...), i expect from the beginning everything to work perfectly (drive easily, perfect picture...).
Don't see any reason why would be different with measuring equipment.

Seems you live in some other universe. 

All brands have had problems, HW and SW.
Maybe your weren't alive when Tek had the famous TDS200 worldwide recall ?

[BU508A]

Software is complicated no matter what country it's written in. I'm sure there's horror stories from every single brand.

I'd even believe that the more expensive something is, the more places there are to screw up the design. Cutting edge is cutting edge.

No product manager these days is ever going to say "let's just use it internally for another six months and see if any bugs turn up".

I don't quite understand the logic behind that statement, but as long as the potential buyer is willing to accept it, i have no problem with that.
I personally would never do anything like that, or when I buy a great, expensive product (car, TV set...), i expect from the beginning everything to work perfectly (drive easily, perfect picture...).
Don't see any reason why would be different with measuring equipment.

May I introduce you to the theory of complexity?
In essence: the more complex a system is, the more likely is that it has errors and/or flaws in it.

It all depends on your definition of "working perfectly" and how high you are setting the level.

[bozidarms]

May I introduce you to the theory of complexity?

OK, many thanks, finally i got it - so, if I buy something complex and expensive then it is completely wrong to expect that this device should work properly, because the more complex a system is, the more likely is that it has errors and/or flaws in it.

Really interesting way of thinking and perfect excuse for work which is only partially done.
If i would think that way at my job, than i would have a lot of free time

Maybe your weren't alive when Tek had the famous TDS200 worldwide recall ?

Ha ha, I was alive at that time (guess i am your age), only not so interested in electronics.

[maxwell3e10]

Somehow people cut much more slack for software than hardware errors. Remember how much bad press Intel got for a division bug in Pentiums. But software and firmware bugs are totally accepted. I wouldn't say that software is intrinsically more complicated than designing and making a big processor. Yet hardware gets more and more powerful while software gets more and more bloated while still having mostly the same functionality.

More relevant to this thread, we need to compare oscilloscope noise spectra because rms noise does not tell the whole story. For example, Lecroy HDO has better noise RMS numbers than Rigol HDO, yet Rigol has a better spectrum:
https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg4436329/#msg4436329
Also having a low noise level at low sensitivity vertical scale (like 1V/div) is the whole point of a high-resolution scope.

[bozidarms]

 maxwell3e10,
thanks for explanation.

Could you also comment why MXO4 as a HD (12 bit and more) system has DC gain accuracy of ±1 % full scale to ±1.5 % full scale, almost as 8 bit system (LeCroy HDO has 0,5%)?

[maxwell3e10]

You would need to ask Rich. I am not sure if DC accuracy is something people focus on in an oscilloscope. It also depends on the details of the self-calibration procedure.

[luudee]

Somehow people cut much more slack for software than hardware errors. Remember how much bad press Intel got for a division bug in Pentiums. But software and firmware bugs are totally accepted. I wouldn't say that software is intrinsically more complicated than designing and making a big processor. Yet hardware gets more and more powerful while software gets more and more bloated while still having mostly the same functionality.
...

Traditionally, a lot more testing and verification has been put in to hardware. I have been doing ASIC design
for over 30 years. I have also done some software development (C/C++).

To manufacture an ASIC, the NRE is anywhere between $1Mil USD, 20 years ago, 180nm node, to about
$10Mil USD, Samsung 8nm node, 4 years ago. Because of the high cost, a lot more effort is being put in to
making HW to be correct the first time. Everything from functional verification, to toggle coverage to various
timing analysis had to be 100%. 

Since FPGAs have taken over a lot of the low-volume market, HW/chip designers have lost the art of making
hardware that works the first time around. We now see "firmware" upgrades that not only include software but
also hardware fixes in FPGA bit streams.

I bet the "freeze" Dave found in the MXO4 is from some FPGA ... the GUI appears to work just fine.

Overall, I believe it has become much less critical to properly verify and test hardware and software, since it
has become so easy to provide and install updates. I still vividly remember the times, when a software update
meant for a vendor to ship two 27xxx EEPROMS which you had to physically replace on a device motherboard.

As such, I believe all equipment we will see in this day and age will suffer from incomplete/faulty HW and SW.
It has become so cheap and convenient to issue a fix at  a later date, that I bet many of these vendors purposely
leave out features and function for a later date. Time-to-Market has become the driving force.

Comparing today's "equipment" to what was manufactured 20 years ago, I believe, the designs were much more
mature, complete and though through 20 years ago that they are today.


luudee

[mawyatt]

Somehow people cut much more slack for software than hardware errors. Remember how much bad press Intel got for a division bug in Pentiums. But software and firmware bugs are totally accepted. I wouldn't say that software is intrinsically more complicated than designing and making a big processor. Yet hardware gets more and more powerful while software gets more and more bloated while still having mostly the same functionality.
...

Traditionally, a lot more testing and verification has been put in to hardware. I have been doing ASIC design
for over 30 years. I have also done some software development (C/C++).

To manufacture an ASIC, the NRE is anywhere between $1Mil USD, 20 years ago, 180nm node, to about
$10Mil USD, Samsung 8nm node, 4 years ago. Because of the high cost, a lot more effort is being put in to
making HW to be correct the first time. Everything from functional verification, to toggle coverage to various
timing analysis had to be 100%. 

Since FPGAs have taken over a lot of the low-volume market, HW/chip designers have lost the art of making
hardware that works the first time around. We now see "firmware" upgrades that not only include software but
also hardware fixes in FPGA bit streams.

I bet the "freeze" Dave found in the MXO4 is from some FPGA ... the GUI appears to work just fine.

Overall, I believe it has become much less critical to properly verify and test hardware and software, since it
has become so easy to provide and install updates. I still vividly remember the times, when a software update
meant for a vendor to ship two 27xxx EEPROMS which you had to physically replace on a device motherboard.

As such, I believe all equipment we will see in this day and age will suffer from incomplete/faulty HW and SW.
It has become so cheap and convenient to issue a fix at  a later date, that I bet many of these vendors purposely
leave out features and function for a later date. Time-to-Market has become the driving force.

Comparing today's "equipment" to what was manufactured 20 years ago, I believe, the designs were much more
mature, complete and though through 20 years ago that they are today.


luudee

That is so true regarding the ASIC NRE, maybe even on the low side. Our over decade old CLASS ASIC for DARPA was ~$50M and worked the first time, with only ~1B transistors (massive Systolic Array). Recall Intel spending $100s of Millions on processor chip development long ago and Apple spent ~$1B on the initial M1 chip set development.

With those kind of numbers and the huge wafer mask set costs for SOTA Digital CMOS processes (reruns), one better get the design right the first time, as errors are quickly career limiting

The Digital ASIC design folks have the benefit of some very good (an expensive) CAD tools from Cadence, Synopsis and others. Analog ASIC designs folks, the CAD tools available aren't as refined, and much more emphasis and risk is placed upon the designer.

If you really want to dive into the risk pool of ASIC design, try the merging of Digital and Analog/RF like our first Microwave Systems on Chip dating back to ~2000, which hosted multiple processors, DSP, memory, DACs, ADCs and entire frequency agile Microwave Receiver/Transmitter on a single SOTA SiGe BiCMOS process chip!!

Even today with low cost PCBs available it seems that some hardware designs are just thrown together and get fixed by PCB iteration, and the Firmware/Software is just riddled with numerous bugs.

However, do think generally the "A Grade" TE OEMs do a better job with new equipment introductions, they have the people and financial resources to do a more thorough job before releasing a new product, and the cost shows such!! Some of the better "B Grade" OEMs seem to do a better job before releasing a new product than others, and seem to have found an attractive cost/bug ratio cost*bug product!!

Anyway, old seasoned ASIC designers may have a different perspective on things than folks that have never attempted a complex ASIC

Best, 

[EEVblog]

Software is complicated no matter what country it's written in. I'm sure there's horror stories from every single brand.

I'd even believe that the more expensive something is, the more places there are to screw up the design. Cutting edge is cutting edge.

No product manager these days is ever going to say "let's just use it internally for another six months and see if any bugs turn up".

I don't quite understand the logic behind that statement, but as long as the potential buyer is willing to accept it, i have no problem with that.
I personally would never do anything like that, or when I buy a great, expensive product (car, TV set...), i expect from the beginning everything to work perfectly (drive easily, perfect picture...).
Don't see any reason why would be different with measuring equipment.

Volume, target market, and technical needs are very different between a car and a high end oscilloscope.
But car are not immune, Tesla's for example are (in)famous for software bugs that not only impact the software experience but also extend to hardware functionality.

[mawyatt]

One likely reason for the relatively few hardware bugs vs. the typical large number of firmware/software bugs we are accustom too is the hardware bug may require a return and PCB replacement (high OEM cost). Whereas, the firmware/ software bugs are usually rectified by having the user download the prior bug correcting revision (low OEM cost), only to usually introduce new bugs 

So the OEM bean counters decide that spending some verification resources on the new product hardware has a better ROI than on firmware/software!!

The mentioned Intel processor computational error vs. Microsoft's bug riddled Windows OS is a great example, and somehow Mr Gates has conditioned us with continual software/firmware revisions loaded with new bugs as acceptable. Can you imagine what additional flack Intel would have gathered if they had introduced the replacement processor with one that had a new bug!!

Best,   

[2N3055]

One likely reason for the relatively few hardware bugs vs. the typical large number of firmware/software bugs we are accustom too is the hardware bug may require a return and PCB replacement (high OEM cost). Whereas, the firmware/ software bugs are usually rectified by having the user download the prior bug correcting revision (low OEM cost), only to usually introduce new bugs 

So the OEM bean counters decide that spending some verification resources on the new product hardware has a better ROI than on firmware/software!!

The mentioned Intel processor computational error vs. Microsoft's bug riddled Windows OS is a great example, and somehow Mr Gates has conditioned us with continual software/firmware revisions loaded with new bugs as acceptable. Can you imagine what additional flack Intel would have gathered if they had introduced the replacement processor with one that had a new bug!!

Best,

That Intel bug was a reason to introduce formal verification in Intel for verification of designs..
But don't worry, they still make them with bugs even today. It is just they are not as blatant as basic FP instructions..
And all Intel processor for many years, can do actual microcode updates. At boot time, a BIOS loads a a microcode patch into CPU.. So they are sort of software updatable, not much unlike FPGA. They still have to have at least part of instruction set  function properly so the can execute BIOS, but yeah software patches are reality on CPU too..
They can even load nev CPU instructions...

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html

Sad part is that software development could be formally verified and there were great developments on that in 80ies and 90ies but once business side realized they could save money by not doing any of that and by lawyering up and desensitizing users to accept "bugs are normal" philosophy, things went downhill fast...