can you accept the bugs or problems in some low price oscilloscopes?

[nctnico]

I that respect Siglent seems to do OK. There where some issues in the early firmware of their SDG1000 series generators which they fixed later on. It gave me enough confidence to buy one of their higher end scopes.

[tautech]

This removed Rigol brand from list of suppliers of equipment for my job and my hobby purposes as well.
The bug itself is not a big issue, but the willingness of supplier to fix the bug - it is what counts.

Not a good look.

So, select a product supported by a dealer that has good contact with the manufacturer and give him feedback for ongoing product improvement so we all win.

Too often price is the driving factor for hobbyists spending their hard earned coin when one should be thinking "what if something goes wrong?"

[bwat]

I hope you realize that leaving swap enabled on a USB stick is a really BAD idea. That will exhaust the limited write endurance of the flash extremely quickly.

Found this: http://www.usenix.org/event/fast10/tech/full_papers/boboila.pdf
Now for some back of the envelope calculations.  2 days = 2*24*60*60 = 172800s. Block endurance = 10^6 cycles. So, 58 cycles per second to be expected for a new USB disk failing after 2 days. That's a lot of swapping!

Disclaimer: I read that paper very quickly.

[janoc]

I hope you realize that leaving swap enabled on a USB stick is a really BAD idea. That will exhaust the limited write endurance of the flash extremely quickly.

Found this: http://www.usenix.org/event/fast10/tech/full_papers/boboila.pdf
Now for some back of the envelope calculations.  2 days = 2*24*60*60 = 172800s. Block endurance = 10^6 cycles. So, 58 cycles per second to be expected for a new USB disk failing after 2 days. That's a lot of swapping!

Disclaimer: I read that paper very quickly.

That number is fairly reasonable considering how swap in Linux works. And if the machine was low on physical RAM and had to swap more often ...

Also, remember that the 10^6 cycles is a mean value. Your USB stick can die after 1000 cycles already. Or after 10^7 ones if you are really lucky and the device has good wear leveling. Flash going into USB sticks is also rarely the best quality available. 

[bwat]

That number is fairly reasonable considering how swap in Linux works. And if the machine was low on physical RAM and had to swap more often ...

Really? That's 58 cycles per second I calculated was for each block which will fail, not 58 cycles per second for the whole USB stick. That's either very little RAM or processes which have big working sets.

Also, remember that the 10^6 cycles is a mean value. Your USB stick can die after 1000 cycles already. Or after 10^7 ones if you are really lucky and the device has good wear leveling. Flash going into USB sticks is also rarely the best quality available.

Look at table 2 on page 5. The spread isn't that great.

Disclaimer: I've still not read that paper properly.

[SeanB]

It was an old drive, and I was not worried about it dying, just wanted to try out another OS on my EEEPC and did not want to do that to the original non replaceable SSD inside it. I did go in and add extra drives to the existing USB ports on the board so I could actually have usable storage instead of the 2G it came with. Now it runs Puppy off a SD card in the SD slot, and as that all fits in RAM it will do nicely as a holiday PC.

[Wuerstchenhund]

Consider yourself lucky. I have had several problems mostly caused by Windows even though I always use the 'software eject' provided by Windows first and then physically remove the USB drive.

How do you know the problems were caused by Windows?

And you're aware that just clicking on 'eject' isn't enough but you have to wait until drive access stops (i.e. the stick's LED stops blinking) and Windows actually tells you that it's now safe to remove the device? Because when clicking 'eject' Windows flushes the OS write cache for that drive and closes all open connections so that it can be dismounted orderly. This can take several seconds, and if you pull the stick out while it is doing that you're very likely to cause filesystem corruption.

I use USB flash drives a lot, and the only time I have seen problems is when sticks were ripped out before Windows did complete its sync process before dismounting it, when they were at the end of their lifetime (some of my very first 1GB and smaller memory sticks are beginning to fail, but many of them are now 10 years old), or when someone bought or got a cheap-ass China fake which either was built using recycled memory (yes, they really do build memory sticks with reclaimed memory!) or which lied about its capacity (i.e. could merely hold 1GB instead of 8GB, the typical China fake). I also had a few instances with FAT file system errors when a large stick (>2GB) was used with my Siglent SDG1020 AWG (but that was only with early firmware so I guess Siglent has fixed that in later versions).

There are many reasons why USB memory sticks can fail, aside from the things I mentioned like user error or used memory/fakes there are many others. So how do you know it was caused by Windows? Or are you just asuming because you couldn't figure out what the real problem was? Unless of course we talk about Windows95 here.

[nctnico]

Consider yourself lucky. I have had several problems mostly caused by Windows even though I always use the 'software eject' provided by Windows first and then physically remove the USB drive.

How do you know the problems were caused by Windows?

Because it is Windows 

And you're aware that just clicking on 'eject' isn't enough but you have to wait until drive access stops (i.e. the stick's LED stops blinking) and Windows actually tells you that it's now safe to remove the device?

I do know that  O0

[Wuerstchenhund]

How do you know the problems were caused by Windows?

Because it is Windows 

So in short it's the usual Windows bashing then.   

[adam1213]

What confidence should one have in a piece of test equipment that crashes as it wasn't tested properly?

[nctnico]

How do you know the problems were caused by Windows?

Because it is Windows 

So in short it's the usual Windows bashing then.   

No. It's just an observation that my Linux system runs with much less hick-ups than my Windows system. If something goes wrong unexpectedly Windows just crashes where Linux gracefully recovers. It's all about the quality of coding under the hood.
Recently my Windows machine wouldn't recognize USB sticks at all. Connecting a USB hub made the system almost crash (needed a reboot to fix). I've never seen similar behaviour from Linux.

I have one piece of equipment which runs Windows but it only runs just Windows and the software which comes with the test equipment. No other applications at all!

[Wuerstchenhund]

No. It's just an observation that my Linux system runs with much less hick-ups than my Windows system. If something goes wrong unexpectedly Windows just crashes where Linux gracefully recovers. It's all about the quality of coding under the hood.

I'm sorry but the thing about "quality" is nonsense. Like any modern OS, Linux does have it's fair share of flaws, and there are things in it that are outright stupid. And I can assure you that Linux (like any other OS) can fail miserably in some situations.

In addition, just because an OS seems to have 'recovered' on the surface (i.e. to the user it looks like everything is normal) this doesn't mean that there isn't some shit going on somewhere down below running havoc or shredding your file system. Believe it or not but sometimes it's actually an advantage if the OS stops execution when a severe problem occurs. Especially in areas where the data is actually worth something.

Recently my Windows machine wouldn't recognize USB sticks at all. Connecting a USB hub made the system almost crash (needed a reboot to fix). I've never seen similar behaviour from Linux.

Ever considered that maybe something with the hardware or some drivers might be the issue? For example, Windows since Vista relies on a correct ACPI table in the BIOS, which wasn't always the case in many standard mainboards. Linux contains some workarounds for some of them, and often falls back to ancient PnP. The advantage of course is that this mitigates to some extend for the crappy BIOS whith bugs that shouldn't be in there in the first place. On the other side ACPI allows Windows much better control over hardware, i.e. power management capabilities.

Of course often it's difficult finding the cause of a problem, but it's silly to believe that the reason for your USB problems is with Windows, an OS that runs of millions of PCs (aside from serving as the backend platform for most large enterprises around the world), and is used with probably the largest range of USB accessories day in and day out.

[nctnico]

Hint: VHS versus the technically superior Video2000. The best system isn't always the most popular. McDonalds probably serves more food than a 4 star restaurant but does that make the food in the 4 star restaurant crap?

[PlainName]

And you're aware that just clicking on 'eject' isn't enough but you have to wait until drive access stops (i.e. the stick's LED stops blinking) and Windows actually tells you that it's now safe to remove the device?

I'm not sure that's true for USB sticks. Windows recognises two types of external storage: cached and uncached (basically, it is whether write-through is enabled or not). A cached device requires proper ejecting so that the cache can be written (if it's dirty). That applies to external hard drives and the like.

However, I think USB sticks are treated - by default - as write-througgh devices, so the write operation doesn't return until the data is actually on the stick. This is because Windows expects the user to whip the stick out without thinking about proper eject sequences, and for the user it means that as soon as that file copy says done it really is done.

You can change this setting to allow caching, and then the stick will appear to be much faster. But then you have to use the eject method to prevent data loss.

[Gribo]

Back OT, Test equipment should be reliable.  If there are bugs in the device's software, how can I trust its readings? One example I encountered in the past was a bug in the Ethernet port of   the Agilent's N9320A ( made in China..). It rendered the port unusable.

[Wuerstchenhund]

Hint: VHS versus the technically superior Video2000. The best system isn't always the most popular.

Oh yes, I remember Video 2000 quite well. It was certainly a nice VCR system at its time (I had several Grundig and Philips V2000 VCRs back then).

Was it technically superior than VHS and Beta? Yes.

Was it better? No, not really.

One reason why it wasn't more popular was because it suffered from lots of flaws. For example, Philips was stupid enough to violate their own standard with their first recorders (Grundig used U loading while Philips used M loading, and the first Philips V2000 recorders had their Audio/Sync head mounted on the wrong spot so that tapes recorded with a Grundig recorder had a roughly 0.5s delay in audio). Both Grundig and Philips recorders (as their rebadges sold by by Nordmende, Siemens, Loewe and others) have generally been very unreliable (the Philips VR2000 Series suffered from mechanical issues because of the wire system in its M loading mechanism, and the older Grundig 2x4 recorders failed because of crappy connectors, overheating controllers and bad ESD protection), only the later Grundig 2x4 and 2x8 recorders were more reliable, but at that time Video2000 had already lost. The tapes also suffered from low reliability, mainly because of the complex cassette housing and because of the uneven wear caused by V2000 only using half of the tape width.

Another reason V2000 failed was because essentially it was a product of only two companies (Grundig and Philips) which were reluctant to offering licenses as they both wanted to be sole OEMs for the platform. VHS on the other side was widely licensed at low costs, and even Sony offered licenses for its Betamax system (non-Sony VCRs could only call themselves 'Beta', though).

V2000's only real advantage was its playtime (2x4hrs per tape at SP, later 2x8hrs per tape at LP), but VHS quickly catched up with 4 head LP recorders which offered much lower per hour media costs than Video 2000. The same is true for other features (i.e. ATF).

"Technically superior" does not necessarily mean "better". Video2000 was an over-engineered insular solution which took forever to sort out its many issues and was priced way out of the market. VHS on the other hand was kept simple, and the cheap licensing meant that it was offered by many manufacturers who all could compete in price and features. The picture quality was also good enough, and subsequent improvements (i.e. Stereo and later Hifi, LP, auto tracking, index search, S-VHS etc) were quickly introduced.

Sorry but in the eyes of consumers world wide VHS clearly was the better system.

McDonalds probably serves more food than a 4 star restaurant but does that make the food in the 4 star restaurant crap?

Not sure what this has to do with the discussion, but I get the feeling you somehow seem to believe that Linux is written by elven coders in unicorn land where thanks to pixie dust everything is bug free and highly optimized. I'm sorry to disappoint you but this isn't the case. Linux used to be hacked together mostly by volunteers of which many had no clue about conceptual code design or proper software development, and nowadays it's mostly maintained by experienced developers similar to those working on Windows or OS X. That doesn't mean there still isn't a lot of shit code in Linux or other FOSS programs (which there is), though.

So if you want to suggest that Windows is the McDonalds food and Linux the 4 star restaurant then sorry but this comparison is nonsense.

[nctnico]

Back OT, Test equipment should be reliable.  If there are bugs in the device's software, how can I trust its readings? One example I encountered in the past was a bug in the Ethernet port of   the Agilent's N9320A ( made in China..). It rendered the port unusable.

You should always have an idea what the reading should be. Just blindly relying on what a piece of equipment reads is useless to begin with. After all you could have the probes connected wrong.

[nuno]

Hey guys, these OT messages are ruining a very interesting topic, will you please open a new one and move them there? Thanks.

Personally I have very low tolerance for bugs.

I'm 100% with don on this, my personal tolerance for bugs is very low. The same is true for stupid UI designs btw.

  

I'm just waiting a bit for the new firmware version for my DS1104Z-S to fix the UI issues with the font size, if it doesn't get to a reasonable point, I'm returning it, and if more people did the same they would take more care with (stupid) bugs. As a programmer by profession it deeply frustrates me to see sw bugs, specially the "stupid" ones (and annoying), to ruin an otherwise good instrument. If we tolerate them, they'll keep coming.

I wish Rigol and other manufacturers released hw interface specs for older models, even if no software at all.

[microe]

For my own experience, these low price oscilloscopes are not such untolerable. Most times, it tests quite well, maybe not perfectly though.
There is just some area such as high-tech research that needs oscilloscopes cost thousands dollars. For popular uses, I think the low price oscilloscopes are good. At least they meet for our hobbies.

[DanielS]

Back OT, Test equipment should be reliable.  If there are bugs in the device's software, how can I trust its readings?

That depends on the bug's nature. Many of them have one or more work-around but the operator still needs to recognize a potential glitch when he notices one and how to double-check it. If you see weird things in a slow time base, you can zoom in to determine if it was an intensity grading glitch or a real signal but you do need to be aware of the glitch to know how to confirm it.

Same goes with any instrument: if you are not aware of potential traps, you are likely to fall straight into them and waste tons of time chasing the wrong or nonexistent issue.

[Wuerstchenhund]

Hey guys, these OT messages are ruining a very interesting topic, will you please open a new one and move them there? Thanks.

Sorry, seems I got carried away a bit.

I'm just waiting a bit for the new firmware version for my DS1104Z-S to fix the UI issues with the font size, if it doesn't get to a reasonable point, I'm returning it, and if more people did the same they would take more care with (stupid) bugs.

It shouldn't really that difficult to allow selectable font sizes, but then that would require that the UI is flexible enough to accomodate it. I'm frankly disappointed by the UI of many modern test instruments.

As a programmer by profession it deeply frustrates me to see sw bugs, specially the "stupid" ones (and annoying), to ruin an otherwise good instrument. If we tolerate them, they'll keep coming.

Indeed. But to be fair, at least for UI issues it's not really their fault as every manufacturer should have some Human Factors guy who knows about proper UI design. In my experience most people that are good in software development (i.e. programming) are usually bad UI designers and vice versa.

[rollatorwieltje]

USB sticks are disposable memory, not something you keep anything valuable on.

First of all, that's an opinion, not a fact.  Based on one set of experiences.  I have many USB sticks with valuable content on them.  Of course, it's never my only copy.  But then, nothing I have that's important is ever my only copy, for very long.

I've lost count on the number of failed sticks.

I'm sorry to hear that.  It would certainly explain your negative POV.  OTOH, I've had many, many of them.  And only 1 that ever failed completely.  And a couple others that developed sporadic, distributed errors, that I decommissioned (aka, threw away ).

The company I work for uses USB keys in a product for service purposes. It's rare when a key lasts for more than a year. Those are Kingston sticks, not some generic garbage. All kinds of failure modes, often a corrupted partition table (not even counting the broken connectors). I suspect these USB keys don't have any sort of data integrity checks built in, just a piece of flash and a dumb memory interface. These sticks are basically only used a a license dongle and occasional software updates. That's why I don't trust them at all.

[Wuerstchenhund]

The company I work for uses USB keys in a product for service purposes. It's rare when a key lasts for more than a year. Those are Kingston sticks, not some generic garbage. All kinds of failure modes, often a corrupted partition table (not even counting the broken connectors). I suspect these USB keys don't have any sort of data integrity checks built in, just a piece of flash and a dumb memory interface. These sticks are basically only used a a license dongle and occasional software updates. That's why I don't trust them at all.

It really does get more difficult to find a good USB memory stick. The reason for that is that USB drives nowadays are garbage products. Most brand name sticks come from the same source as no-name sticks, and use the same crappy memory (often rejects or even reclaimed), with very little over-provisioning. Back in the old days, when USB sticks were a bit more expensive, brand name sticks were usually pretty well built. Not anymore. Especially the ultra compact sticks seem to have a shelf life of fresh milk.

I have a ton of memory sticks, which all lasted much longer than a year (and some of them have seen quite a large amount of write cycles). Many of the older ones are HP, made for their servers (ProLiant) and workstations (so not the cheap consumer stuff), of which many are older than 5 years and still work fine as boot drive for VMWare vSphere and Citrix XenServer. I also have some newer Samsung sticks which seem to be pretty reliable.

I recently bought some rubberized Kingston USB 3.0 sticks (can't remember the model), lets see how long they last.

[andrewwong2000]

I've been reading the Siglent and Rigol DSO and MSO threads with some amusement.

Having gone that way, assessing the pros and cons of the Chinese equipment and gone back to proven brands..

I wonder what Keysight or Tek could achieve if they produced a "crowd tested and developed" product. Great hardware platform.. SVN firmware.

Some people here have so much time on their hands to mess with half finished products - as a company I would imagine it's like a team of somewhat highly skilled beta testers for free.




Sent from my iPhone using Tapatalk

[Mr Carlsons Lab]

Re: can you accept the bugs or problems in some low price oscilloscopes?

No! Do the job right, then sell your product. This crap is all to common these days. Seems like many companies are putting their products on the market before proper testing. "Oh, we'll send you a firm ware update to fix the bugs."
Can you imagine if us guys that design circuit boards sent our products out, faulty right from the get go..... "Oh sorry, we'll have to send you that flip flop that we forgot to populate in the board, by mail."

In all reality, they know what's going on, its just about getting it out the door faster, (so they get their money) then making you wait for the fix while the guys at the factory are writing the proper firmware. (and in some cases not)

Times sure have changed.