EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: forrestc on January 01, 2017, 11:13:53 pm
-
I'm needing a 4 channel DSO to use in automated test. For this application, I'm looking for 4 channels and mask testing. Any modern DSO should be fast enough (50Mhz is fine, 100Mhz is plenty and then some).
The obvious goto for this is of course a Rigol DS1000Z series, which seems to fit the bill perfectly, except for one thing: Because this is automated test, I need to be able to save and restore the mask via whatever programming interface the unit has (in this case LXI). The idea being to be able to restore the instrument state completely from the test computer. Amazingly, this capability seems to be missing from the DS1000Z series, although I'm in the process of trying to get a definitive answer out of Rigol as to whether this is really missing, or just an oversight in the manual.
My budget is around $1000, or less. Hopefully much less. At $1000 I'd probably just pull the raw captured waveform into the host PC and write code to do the mask testing there. There are lots of reasons to have this on the oscilloscope hardware though....
So far, I've looked at the following <$1000 4 channel scopes:
Apparently won't work:
Rigol 1000Z - see above.
OWON Scopes - I think I looked at all of the 4 channel ones. The programming datasheets are skimpy but no mention of masks.
GDS-1000B series - No mask testing.
May work:
Siglent SDS1000CFL series - This seems to be the frontrunner so far... has most/all of the features I need.
Looked, kinda:
Other Rigol scopes.
USB Scopes of various manufacturers.
Have I missed any, and has anyone worked with the mask functionality with the Siglent?
Thanks.
-
Have I missed any, and has anyone worked with the mask functionality with the Siglent?
rf-loop does Mask Pass-Fail tests on any of the scopes that come across his bench and there's numerous screenshots of those that he's posted, some going back years.
I quickly found 17 hits using the Search button with "mask test" and rf-loop in the User box so no need to put up the links, you can find them easy.
-
GW Instek calls mask testing a 'go-nogo function' and you need to install it as an extra application (software module) on the oscilloscope. It is fully documented in the user and programming manual.
-
The obvious goto for this is of course a Rigol DS1000Z series, which seems to fit the bill perfectly, except for one thing: Because this is automated test, I need to be able to save and restore the mask via whatever programming interface the unit has (in this case LXI). The idea being to be able to restore the instrument state completely from the test computer. Amazingly, this capability seems to be missing from the DS1000Z series, although I'm in the process of trying to get a definitive answer out of Rigol as to whether this is really missing, or just an oversight in the manual.
Have you read the Programming Manual?
http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf)
I have no idea what the MASK commands actually do but there is one called CREATE.
-
I'm needing a 4 channel DSO to use in automated test. For this application, I'm looking for 4 channels and mask testing. Any modern DSO should be fast enough (50Mhz is fine, 100Mhz is plenty and then some).
The obvious goto for this is of course a Rigol DS1000Z series, which seems to fit the bill perfectly, except for one thing: Because this is automated test, I need to be able to save and restore the mask via whatever programming interface the unit has (in this case LXI). The idea being to be able to restore the instrument state completely from the test computer. Amazingly, this capability seems to be missing from the DS1000Z series, although I'm in the process of trying to get a definitive answer out of Rigol as to whether this is really missing, or just an oversight in the manual.
With time to do a little more digging I found this post that you need study:
https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156 (https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156)
-
...Rigol DS1000Z series, which seems to fit the bill perfectly, except for one thing: Because this is automated test, I need to be able to save and restore the mask via whatever programming interface the unit has (in this case LXI). The idea being to be able to restore the instrument state completely from the test computer. Amazingly, this capability seems to be missing from the DS1000Z series, although I'm in the process of trying to get a definitive answer out of Rigol as to whether this is really missing, or just an oversight in the manual...
My bet is the documentation is wrong, because I just sent a :MASK:DATA? to my Rigol DS1054Z (upgraded), firmware 00.04.04.SP1, and it responded by returning 1217 bytes.
In the latest programming guide I have for the DS1000Z, there is no SCPI command for ":MASK:DATA?". I found this command looking in the programming guide for Rigol DS4000 series. In the DS4000 programming guide, there is also a ":MASK:DATA <data>" command that sends the mask from the PC to the scope, but I didn't tested it on my DS1054Z yet.
Still, you might want to ask Rigol if DS1000Z officially supports ":MASK:DATA" commands. Please post here the answer.
-
Have you read the Programming Manual?
http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf)
I have no idea what the MASK commands actually do but there is one called CREATE.
Yep. Doesn't do what I needed from what I can tell.
If you have a reference trace on the screen you can set the x and y tolerances using one set of commands, then issue that create command, and you'll have a mask. Which is all and good until you really just want to store a reference waveform and/or mask for later. The interface on the device will do this (save and load mask), it just seems that you can't via the SCPI command interface.
I also didn't see any way to load waveform data back into the scope via SCPI, since it seems like you could load a waveform into trace memory, then use the create command to create your mask. A bit indirect but it's ok. But that still isn't an option, unless I missed something. (I read the whole thing, but skimmed over some parts).
-
unless I missed something.
My Rigol DS1000Z can send/receive a mask via LXI.
-
My Rigol DS1000Z can send/receive a mask via LXI.
Which tool are you using to do this? Is this something you wrote, or is it the Rigol Software (ultrascope?)?
-
With time to do a little more digging I found this post that you need study:
https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156 (https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156)
Ewww... Ick.... (in relation to the Rigol).
Hmm... now the question is... how does the SDS1000CFL compare.... time to do some more digging.
-
Which tool are you using to do this? Is this something you wrote, or is it the Rigol Software (ultrascope?)?
Neither. I sent the command manually, using NetCat (nc).
Will you ask Rigol?
-
With time to do a little more digging I found this post that you need study:
https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156 (https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156)
Ewww... Ick.... (in relation to the Rigol).
Hmm... now the question is... how does the SDS1000CFL compare.... time to do some more digging.
You've said you're looking for a 4 ch DSO for Pass/Fail testing but what I'm unsure of and can't find in manuals is if a Pass/Fail mask can be built for more that 1 channel. :-//
The 1kCFL units all have 2Gsa/s and that's probably a good thing for Pass/Fail accuracy.
The Pass/Fail UI is described in the SDS1000CFL manual on P94 but only shows/describes it being used with 1 channel.
http://www.siglentamerica.com/Uploadfile/file/20140925/SDS1000CFL_UserManual_UM01012-E05A.pdf (http://www.siglentamerica.com/Uploadfile/file/20140925/SDS1000CFL_UserManual_UM01012-E05A.pdf)
I haven't even got another 1000**L unit in stock to try this for you sorry....all sold out. :)
I can have a try with my 2304X but it's an entirely different UI and much more powerful beast......
Had a fiddle and you can setup a mask (2304X) for any channel and change the signal source to any other channel to check for compliance.....all done manually. An automation script should be able to switch between the channels and hopefully there'd be no violations while it does.
SDS2304X screenshot
(https://www.eevblog.com/forum/testgear/4-channel-dso-with-mask-testing-and-programmability-(lxi-usb-etc-)/?action=dlattach;attach=282417)
Here we have a mask that's been built for Ch 2 but Ch 1 is selected as Source for Pass/Fail. Ch 2 Horizontal position has been moved outside the mask to show there's no violations showing for it and only Ch 1 (normally yellow) is now red. Selection of the Operation > starts the test and if the DSO's sound is not disabled a string of beeps are heard.
Changing the Source to any channel in this setup ^^ will trigger violations
-
All my Agilent scopes do mask testing well, but only one channel at a time.
I am not aware of any modern scope that could do mask testing on more than one channel at a time.
-
My Rigol DS1000Z can send/receive a mask via LXI.
Which tool are you using to do this? Is this something you wrote, or is it the Rigol Software (ultrascope?)?
Note: Ultrascope is very generic software and it's missing a lot of specific things that the DS1054Z can do.
-
I am not aware of any modern scope that could do mask testing on more than one channel at a time.
Weirdly limited modern scopes are... :-//
But I have me hands on secret future tech yet again:
(https://www.eevblog.com/forum/testgear/4-channel-dso-with-mask-testing-and-programmability-(lxi-usb-etc-)/?action=dlattach;attach=282436)
It also has extensive SDK but I do not use it so dunno about automated mask testing. Screenshot was made w/o scope using demo mode. Anyone can download software and try it w/o buying.
If signals are not phase-locked would have to use logic triggers to lock onto some correlation point. But in demo I cannot get this to work. Demo signal gen is probably a hack and some stuff is not accounted for. With real signals logic triggers work no prob when hysteresis etc is fiddled correctly.
-
I'm needing a 4 channel DSO to use in automated test.
I'm curious, why do you need an automated test for hobby use?
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
-
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
Well scope capable of 4 analog ch mask is made in UK...
But on the other hand I had Japanese car once that floored the throttle when cruise control was enabled in certain conditions. Car was capable of spinning wheels on 3th gear so it was no joke. Could kill no problem with such a bug. But it still sneaked thru testing... So it comes down to specific engineer doing the job. No formal procedure can fully compensate...
-
I wanted to propose the pico too, but i recall they advertise mask testing in the 3k series and up but not for the 2k series, i think maybe they put a limitation to the feature? Still, the 3k series should be within budget
-
I wanted to propose the pico too, but i recall they advertise mask testing in the 3k series and up but not for the 2k series, i think maybe they put a limitation to the feature? Still, the 3k series should be within budget
My 2013my 2205 MSO does mask just like in demo. So guess even 95€ 2204A will do 2ch mask.
-
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
I don't know about others, but I don't select stuff because it's Chinese or not. I try to buy what's the most suitable, whether for business or personal. For example, I was looking for a scope with easy-to-access long one-shot acquisition memory (for business purposes). I haven't really found anything suitable so I decided to wait, but DS1054Z was the best candidate.
-
I'm needing a 4 channel DSO to use in automated test.
I'm curious, why do you need an automated test for hobby use?
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
It depends entirely on how big the production runs are. Using a $5k scope can be not worth it and a cheap Rigol is easy enough to replace without losing much money or (worse) going through piles of bureaucracy to have a large expense approved.
-
With time to do a little more digging I found this post that you need study:
https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156 (https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg830156/#msg830156)
Ewww... Ick.... (in relation to the Rigol).
Hmm... now the question is... how does the SDS1000CFL compare.... time to do some more digging.
And that old message applies to the newest firmware? I don't know the answer but I do know that there have been quite a few fixes over the last year or so. Still, I wouldn't take a chance, buy something else. Perhaps the Siglent does a better job although from that thread, I couldn't really tell. At $1000, you are seriously limited in your choice of scopes.
Actually, pulling the waveform and analyzing it in software is probably the easiest way to get where you want to go.
For about $3.5k, you can get a Keysight 3000T <something or other> scope and the Mask app as an $1100 option.
-
Rigol is easy enough to replace without losing much money or (worse)
Well you do lose "worse". Namely actual data you were trying to record:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208)
So being cheap is indeed big plus when you find that out :-+
-
I'm needing a 4 channel DSO to use in automated test.
I'm curious, why do you need an automated test for hobby use?
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
It depends entirely on how big the production runs are. Using a $5k scope can be not worth it and a cheap Rigol is easy enough to replace without losing much money or (worse) going through piles of bureaucracy to have a large expense approved.
Oddly, this is actually an important consideration. A $400 scope would be expensed, a $1000+ scope will probably be capitalized. Some companies go easy on approving expense items because it's one-and-done. No depreciation schedules, no bookeeping, etc. Other companies watch expense like a hawk but have gobs of money for capital items because it is an investment. I have worked in both types of companies.
-
All my Agilent scopes do mask testing well, but only one channel at a time.
I am not aware of any modern scope that could do mask testing on more than one channel at a time.
The Agilent/Keysight MSO/DSO-X3000A can do mask testing against all active channels by turning on the "Test All" option. So, it can do up to four channels.
However...
The problem with this feature is that there is no way to automatically create a mask that is suitable for more than one channel since "Automask" only works against one channel. So, you're stuck manually creating a mask, or you could create single channel masks one at a time, download them to a computer, and process them into a single mask with the right "cutouts" for all four channels.
Not simple, but it could be done. The mask format is detailed in the user manual.
Why they included a multi-channel mask test option without the ability to auto-create a multi-channel mask is a mystery to me. Maybe some other models fix this omission.
EDIT: Added example screen shot of a two channel mask, created as described above with Automask and external editing. Could be up to four channels, but you get the idea.
-
Rigol is easy enough to replace without losing much money or (worse)
Well you do lose "worse". Namely actual data you were trying to record:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208)
So being cheap is indeed big plus when you find that out :-+
VERY old referenced thread. There have been several iterations of firmware in the last 2 years. Is it still a problem? I don't know because I took one look at the date and classified the thread as irrelevant. That Epic rant re: the DS1054Z is another thread that should be relegated to an archive somewhere. Any comment re: firmware prior to Nov 2016 is irrelevant except for the Pluses misspelling. That 'bug' is still with us!
Note to all: You need to be real careful about these dinosaur threads. A lot of work has been done in the past year and many of these problems MAY have been corrected. Or not... The test needs to be redone with latest firmware. If the test isn't current with Nov 2016 firmware (Rigol DS1000 series), it is certainly questionable. It might be a fundamental electronics issue which can not be corrected in firmware or it might just be a firmware issue which will eventually be corrected.
Considering that TEquipment seems to be moving about 1000 DS1054Zs per WEEK (based on tracking inventory levels on the web site) leads me to believe Rigol wants to OWN that market segment. I rather expect they will continue to improve the firmware.
-
Rigol is easy enough to replace without losing much money or (worse)
Well you do lose "worse". Namely actual data you were trying to record:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208)
So being cheap is indeed big plus when you find that out :-+
VERY old referenced thread. There have been several iterations of firmware in the last 2 years. Is it still a problem? I don't know because I took one look at the date and classified the thread as irrelevant. That Epic rant re: the DS1054Z is another thread that should be relegated to an archive somewhere. Any comment re: firmware prior to Nov 2016 is irrelevant.
I wouldn't dismiss an old thread like this because you can't tell whether it is fixed or not. That is the main problem with Rigol and Siglent scopes: at some point you just lose track off what has been fixed and/or broken (again) because the firmware is nowhere near finished when the product is released and you never know when something gets fixed. If it just was 'unexpected' behaviour due to design limits (=the way it works) things would have been way more manageble.
-
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
I don't know about others, but I don't select stuff because it's Chinese or not. I try to buy what's the most suitable, whether for business or personal. For example, I was looking for a scope with easy-to-access long one-shot acquisition memory (for business purposes). I haven't really found anything suitable so I decided to wait, but DS1054Z was the best candidate.
around that price (not hacked of course) picoscope would have 5 times the memory and be much better at doing almost everything
besides the fact that (for me at least) the way rigol works is unbearable, when it takes me at least twice to do anything more complicated than setting edge trigger and glancing at the waveform.
this may not apply to you but spending 2x now to save on future headaches or dead times is important for me
-
around that price (not hacked of course) picoscope would have 5 times the memory and be much better at doing almost everything
besides the fact that (for me at least) the way rigol works is unbearable, when it takes me at least twice to do anything more complicated than setting edge trigger and glancing at the waveform.
this may not apply to you but spending 2x now to save on future headaches or dead times is important for me
It might be better at memory and transfer speed, but I strongly prefer Ethernet over USB. But Pico doesn't even have a screen. And it's not exactly around the same price as DS1054Z. A comparable 50 MHz Pico 3000 is $900, while 100 MHz Pico 3000 is $1,600.
-
was thinking of the 2000 series, as they still have mask test (but don't know if they have limitations and what they are. i don't really use it much.. but today i glanced at it again and with a 2000 i can set up and import masks. trigger on fail)
2408B is 949€+VAT, 100 MHz, 1GS/s, 128 MS with also segmented memory, decoding on full window, current and past acquisition (like having a GB or two of acquisitions, can have them all decoded at once with search and whatnot). don't know if all of this is relevant to you though.
To be honest, if i had to get a new scope i wouldn't care too much about the bandwidth, if i can upgrade it later.. but instead focus on a better product. half-baked features may as well be gave away for free (oh, wait. they are.) for i find them useless to do any kind of real work. This is what i think about this segment of products
not having a screen is not really a problem for me, the work i do and for how my workbench is arranged. there are situations where i prefer to have a bench scope but if this means resorting to compromizes like spending some minutes to get the trigger i need because of combination of limited hardware, limited software and slow ui that can't almost keep up with displaying four traces...
Of course, being able to drop some K on a keysight/lecroy would be nice.
-
Rigol is easy enough to replace without losing much money or (worse)
Well you do lose "worse". Namely actual data you were trying to record:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208)
So being cheap is indeed big plus when you find that out :-+
VERY old referenced thread. There have been several iterations of firmware in the last 2 years. Is it still a problem? I don't know because I took one look at the date and classified the thread as irrelevant. That Epic rant re: the DS1054Z is another thread that should be relegated to an archive somewhere. Any comment re: firmware prior to Nov 2016 is irrelevant.
I wouldn't dismiss an old thread like this because you can't tell whether it is fixed or not. That is the main problem with Rigol and Siglent scopes: at some point you just lose track off what has been fixed and/or broken (again) because the firmware is nowhere near finished when the product is released and you never know when something gets fixed. If it just was 'unexpected' behaviour due to design limits (=the way it works) things would have been way more manageble.
Then the old threads should be cited with a caveat: I don't know if this has changed over the last 2 years! To cite it as the gospel really isn't correct, or fair.
-
I'm curious, why do you need an automated test for hobby use?
(Please, don't say you want to use chinese hobbyist stuff in a professional production environment...)
I want (and do) use Chinese hobbyist stuff in a professional production environment....
There are a lot of us out there who run very low volume assembly lines. Picking a figure out of the air, if you manufacture and ship 5000 units total of a mix of various items per year, spending say $10K on test equipment every year increases your per-unit cost by $2. If a typical product is $100, then that's 2% of cost.
Today things are functionally tested, by hand. I.E. power it up, verify it works, look at some key functional parameters, etc. This is human-error-prone but somehow works amazingly well. There is very little test equipment needed for this method, so there isn't much. I think the only thing one would consider test equipment which is currently used for product test is an old TDS210 2 channel mono oscilloscope which is used to look at waveforms on one product type to verify that it is producing at least what superficially looks like the right pulse shape is being generated.
Our budget for improving this process has to come from the financial benefits of reduced employee cost and improved product quality. Seeing as we have very few shipped-defective units and we don't expect automated test to actually save much time (since feeding the machine is going to take about the same amount of time as the functional test), there isn't really a lot of budget here. BUT, I'd really like to do a more complete job of testing.
There is something to be said for buying something which is "good enough". Sure I could run out and spend $10K on a scope which would do this without question. But that's overkill. All I need to do is look at some relatively slow signals, and verify that they match a reference waveform. And do this via software, not by human. This seems like something a sub-$1K "hobby scope" should be perfect for.
And before anyone mentions it: I'm also a big fan of buying "the right tool for the job", which sometimes is the way-too-expensive oscilloscope. There's a reason why I have a $10K oscilloscope on my bench. And there's a reason why I'm not buying an identical one for the manufacturing line.
-
Well, a $10k scope doesn't really cost $10k after taxes. It will cost $1k per year for 10 years (expected life). One can, of course, argue about cash flow. The other solution is to lease the thing. The one thing that doesn't work is to try to expense, in one year, a piece of capital equipment valued at $10k.
Were it me, I would look at leasing. It will cost quite a bit more than buying but it can be expensed over several years (as the payments run) so the added cost per widget is lower than purchasing.
But then, there is the issue of debt...
-
In relation to the PicoScope:
It also has extensive SDK but I do not use it so dunno about automated mask testing. Screenshot was made w/o scope using demo mode. Anyone can download software and try it w/o buying.
The first scope from PicoScope which mentions mask testing in the API is the 9000 series... which is $10K.
Oddly, there doesn't seem to be an API for the picoscope software itself, just to directly control the instrument. (Someone correct me if I missed something). As a result, you can get the raw data from the scope but not control the picoscope software which seems to be where the mask testing is implemented.
This doesn't seem much better than using an off the shelf scope and grabbing the raw data.
-
BUT, I'd really like to do a more complete job of testing.
IMHO this is very important to realise. Some things are easy to test manually but if you need to test a lot of inputs or combinations then you need some kind of automated testing. Whatever you ship untested doesn't work because when it comes to circuit board assembly there is a failure rate of around 1%.
-
BUT, I'd really like to do a more complete job of testing.
IMHO this is very important to realise. Some things are easy to test manually but if you need to test a lot of inputs or combinations then you need some kind of automated testing. Whatever you ship untested doesn't work because when it comes to circuit board assembly there is a failure rate of around 1%.
Part of the reason why we've been so successful is that most of the gear tests itself with the help of an external harness of some sort. Our functional tests are designed to look at almost everything either through inbuilt software or with human inspection. It's really the human inspection part we need to dispense with, because we've discovered that humans make errors ;) . As we're working though process improvement, we've reached the point where this has landed near the top of the pile as far as where the process can be improved.
Part of what is driving this is that the testing and products are getting more complex. For instance, we have devices with over 250 I/O pins. All it takes is one assembly failure combined with one testing failure on the circuit for a single pin to make a defective product which makes it into the wild. But... the challenge here is that our current process is really effective at catching these errors. We've just seen a bit of an uptick over the last couple of years as products get more complex - usually the root cause is eventually determined to be something which was supposed to be human-verified and somehow was missed. (When you're looking at 20-30 different parameters per product, it is easy to miss one).
But... if I was to bundle up all of the cost of all of the failures, we're still probably only talking a couple thousand dollars a year. Not a lot of room to work with, but something which still needs to be done. I just need to do it as inexpensively as possible.
-
Well, a $10k scope doesn't really cost $10k after taxes. It will cost $1k per year for 10 years (expected life). One can, of course, argue about cash flow. The other solution is to lease the thing. The one thing that doesn't work is to try to expense, in one year, a piece of capital equipment valued at $10k.
Were it me, I would look at leasing. It will cost quite a bit more than buying but it can be expensed over several years (as the payments run) so the added cost per widget is lower than purchasing.
But then, there is the issue of debt...
All of this is very true. If this was just about the scope, I'd just throw the 10K at it, either through a lease or maybe just purchase it outright. Unfortunately the scope and a few other bits are getting the shaft here because of the cost of everything else which is going into this test system.
-
I see!
to do this at work we use a national instruments i/o thingy, programmed in lab view to do all the tests we need, sending multiple signals and reading back.
Also, having a ridiculous amount of slower analog and digital I/O means we can test 2/4/8 at a time, depending on the board l
I also reprogrammed one of our products to make a "testbench" for a product with more particular digital peripherals that can be controlled via UART so connect the harness and launch the script.
Now saying the 1054 can't do that, but i'm throwing another player into the field
-
I see!
to do this at work we use a national instruments i/o thingy, programmed in lab view to do all the tests we need, sending multiple signals and reading back. I also reprogrammed one of our products to make a "testbench" for a product with more particular digital peripherals that can be controlled via UART so connect the harness and launch the script.
Now saying the 1054 can't do that, but i'm throwing another player into the field
Now or Not ?
You did not read:
https://www.eevblog.com/forum/testgear/4-channel-dso-with-mask-testing-and-programmability-(lxi-usb-etc-)/msg1104199/#msg1104199 (https://www.eevblog.com/forum/testgear/4-channel-dso-with-mask-testing-and-programmability-(lxi-usb-etc-)/msg1104199/#msg1104199)
-
Huh?
-
Then the old threads should be cited with a caveat: I don't know if this has changed over the last 2 years! To cite it as the gospel really isn't correct, or fair.
I bought the thing. I tested the crap out of it. In absolutely no situation I could observe raw data, only heavily manipulated or digital artefacts. It is not built in the way it could display raw data because that would probably reveal quite funny stuff about realities of analog frontend. I have published a lot of test data and it is not challanged so far as incorrect. Same with rf-loop tests. And btw, only way to challenge test data is provide new one or prove it metrologically invalid.
Just look at this wonderful difference in normalized frequency response in various vertical ranges:
(https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/?action=dlattach;attach=280272) (https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/?action=dlattach;attach=280275)
But I can understand fans. I actually like the Rigol. Great body with many knobs poking out so to speak. You will forgive a lot for that :P However as soon as it comes down to doing important stuff. Like doing measurements for something that has scientific value or involve substantial finances... well... :scared:
-
As I wrote before: an oscilloscope isn't accurate to measure signal amplitudes especially at frequencies over 1/10 bandwidth (remember RC circuit frequency response!) so anybody who knows about oscilloscopes is not going to be surprised by this graph. It has been known for a long time and you can produce similar results for every oscilloscope! Sometimes it is even in the specifications.
-
As I wrote before: an oscilloscope isn't accurate to measure signal amplitudes especially at frequencies over 1/10 bandwidth (remember RC circuit frequency response!) so anybody who knows about oscilloscopes is not going to be surprised by this graph. It has been known for a long time and you can produce similar results for every oscilloscope! Sometimes it is even in the specifications.
I'm not talking about absolute amplitudes dropping with growing frequency. Im talking about vast difference in normalized response. And especially trying to look as much higher bw scope in >=500mV/range via "overboosted" Sinc function. Its like two entirely different scopes in one box. Pretty ok in <=200mV range and weird hack-o-booster in >=500mV.
-
That is what I wrote: the displayed amplitude can depend on the V/div setting. Nothing new here.
-
That is what I wrote: the displayed amplitude can depend on the V/div setting. Nothing new here.
I guess it's not first crap design then :-DD
Also... when reading the datasheet:
Bandwidth (-3dB):
MSO/DS 1104Z/1104Z-S: DC to 100 MHz
DS1054Z: DC to 50 MHz
Test was done with high quality sine. It's not a step response.
Only a blind man or one willingly playing a fool will not notice that 500mV/div graph is at artificial angle with "hump" in the middle which implies heavy processing.
-
As I wrote before:
It's Wolfie. :horse: :horse: :horse: :horse:
you can produce similar results for every oscilloscope! Sometimes it is even in the specifications.
And this is the point he's completely missed. Everything in the world has a specification/tolerance, even a simple resistor. The only problem he's discovered with the DS1054Z is with his personal expectations (from a $400 'scope no less - imagine his horror if he's paid more!).
-
specification/tolerance
Good point, how 500mV graph computes with -3dB at 100MHz specified? Or even better. How it can report 2080mV with Sinc=OFF and 3640mV with Sinc=ON in same range with same sampling rate (https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/?action=dlattach;attach=280275). 5dB difference - thats insane. Unless you are priest in the Chruch of Z of course ::)
-
specification/tolerance
Good point, how 500mV graph computes with -3dB at 100MHz specified?
I'm not sure what the point of that graph is. To show that there's a tiny difference in frequency response on different voltage ranges?
That's not surprising at all, the signals get routed through different physical components on the different ranges, either with transistors or mechanical relays (there's actually an audible click on some of the ranges when the relay switches). It would only be surprising if there wasn't a difference. :-//
Endlessly pointing the finger at the DS1054Z for the tiniest deviation from the ideal oscilloscope that only exists in your head is silly at best.
-
tiniest deviation from the ideal oscilloscope
5dB diff with Sinc=ON|OFF is tiny while all other stuff = const? Back to school Fungie :palm:
-
BUT, I'd really like to do a more complete job of testing.
IMHO this is very important to realise. Some things are easy to test manually but if you need to test a lot of inputs or combinations then you need some kind of automated testing. Whatever you ship untested doesn't work because when it comes to circuit board assembly there is a failure rate of around 1%.
Part of the reason why we've been so successful is that most of the gear tests itself with the help of an external harness of some sort. Our functional tests are designed to look at almost everything either through inbuilt software or with human inspection. It's really the human inspection part we need to dispense with, because we've discovered that humans make errors ;) . As we're working though process improvement, we've reached the point where this has landed near the top of the pile as far as where the process can be improved.
Part of what is driving this is that the testing and products are getting more complex. For instance, we have devices with over 250 I/O pins. All it takes is one assembly failure combined with one testing failure on the circuit for a single pin to make a defective product which makes it into the wild. But... the challenge here is that our current process is really effective at catching these errors. We've just seen a bit of an uptick over the last couple of years as products get more complex - usually the root cause is eventually determined to be something which was supposed to be human-verified and somehow was missed. (When you're looking at 20-30 different parameters per product, it is easy to miss one).
But... if I was to bundle up all of the cost of all of the failures, we're still probably only talking a couple thousand dollars a year. Not a lot of room to work with, but something which still needs to be done. I just need to do it as inexpensively as possible.
Re-reading everything again, this is becoming interesting. First of all erase everything i typed before because i didn't have a clear image of the problem.
Let me tell you how we handle testing:
we also do small runs of products (in the 5-10k€ per product line order). However, even though they have more relaxed requirement on IO count (more complex products goes up to 24 IOs) the output formula isn't always simple and depends on many variables.
We also handle slow signals, and i mean in the 1-3KHz bandwidth at most for analog signals. Using a scope just for this would be a waste of money, just to reconfigure the mask and move the probes! We resorted to a national instruments DAQ defice. These things have a fair number of ADCs and DACs with more than the necessary bandwidth and sample rate. Plus a number of digital lines. Some of their tools also mount a FPGA where you can load cores or custom HDL code to excecute (I'd use it to simulate digital peripherals for example).
So we have a NI DAQ, an harness from DAQ to 1 or multiple products and the test setup in labview. Signals are generated and go to the DUT, data is read back and compared to an "acceptable" mask. over or under signals an error.
Since i found this to be a nice solution i ask: why do you think a scope would be better instead?
--for digital communication, for now i'm using a repurposed product. via uart outputs can be set and inputs can be read back. again the calculation and mask can be done entirely in labview. in the future i may write the code to simulate the peripherals inside the FPGA so we can test more units at a time--
-
The Agilent/Keysight MSO/DSO-X3000A can do mask testing against all active channels by turning on the "Test All" option. So, it can do up to four channels.
Thank you for that information, I was not aware of it.
In the past I had only tried "Auto-Mask" and it always only works on 1 Channel
I will look in to this great feature.
Hopefully Keysight will implement an Auto-Mask for multiple channels in a future FW update.
-
How it can report 2080mV with Sinc=OFF and 3640mV with Sinc=ON in same range with same sampling rate (https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/?action=dlattach;attach=280275). 5dB difference - thats insane.
There is more things wrong with Rigol Z, false Sinc function.
Just compare straight lines without Sinc (turn persistence on) and after then using Sinc. As you can see it do not draw at all via true sample points, if even these are true. (and more fun, this same joke they start when they launch old DS1000E series and never repaired). They have never find how Sinc need work. They use it just as for draw "nice art image", not like it need be in T&M equipment. But it draw "nice image" and thousands of peoples like. If they do it right, it do not cost any cent more.
But first they need know what a heck is Sin(x)/x. I can help Rigol worker , it have nothing to do with mahjong.
-
Re-reading everything again, this is becoming interesting. First of all erase everything i typed before because i didn't have a clear image of the problem.
Let me tell you how we handle testing:
we also do small runs of products (in the 5-10k€ per product line order). However, even though they have more relaxed requirement on IO count (more complex products goes up to 24 IOs) the output formula isn't always simple and depends on many variables.
We also handle slow signals, and i mean in the 1-3KHz bandwidth at most for analog signals. Using a scope just for this would be a waste of money, just to reconfigure the mask and move the probes! We resorted to a national instruments DAQ defice. These things have a fair number of ADCs and DACs with more than the necessary bandwidth and sample rate. Plus a number of digital lines. Some of their tools also mount a FPGA where you can load cores or custom HDL code to excecute (I'd use it to simulate digital peripherals for example).
So we have a NI DAQ, an harness from DAQ to 1 or multiple products and the test setup in labview. Signals are generated and go to the DUT, data is read back and compared to an "acceptable" mask. over or under signals an error.
Since i found this to be a nice solution i ask: why do you think a scope would be better instead?
--for digital communication, for now i'm using a repurposed product. via uart outputs can be set and inputs can be read back. again the calculation and mask can be done entirely in labview. in the future i may write the code to simulate the peripherals inside the FPGA so we can test more units at a time--
In regards to the NI DAQ:
We're in the range where we really need a relatively high sampling rate. One of the pulses we're looking at is only ~120uS long, so a slow DAQ isn't going to cut it. Which puts me into something like a PXI-5105 or a PXI-5114, which even used is easily 5x the cost of the scopes we're talking about, if not more.
We do have a couple of instruments in the PXI and/or VXI chassis here along with the relay matrix. We also have a couple of external instruments as well, for instance the Keithley DMM we use as a transfer standard. We actually drive the instruments with a C# program mainly because I find it easier (even with learning C# as I go) than dealing with LabView for this type of work, and it seems that everything is available with a windows library which C# does well. In any case, the test process is being abstracted out to a config file for each test, so unless a new product needs a new type of test, it becomes just writing a config file with a list of steps which need to be completed in order. I.E. do a wiremap on these pins. Then apply power. Then verify voltages at certain pins. Verify signals against known mask, etc.. So far, it seems to be going much quicker than I had thought and future tests will be even faster to write. But, we're still missing a couple of instruments we need.
-
The cheap Keysight DSO1014A family scopes will give you 4 channels with mask testing on any one channel, and you can programmatically save & load masks to internal memory or USB drive. They are controllable over USB. This may be enough? They appear from time to time as used or 'Certiprime' on the Keysight eBay store http://stores.ebay.com/Keysight/All-Used-Equipment-/_i.html?_fsub=874615011&_sid=869664151&_trksid=p4634.m322 (http://stores.ebay.com/Keysight/All-Used-Equipment-/_i.html?_fsub=874615011&_sid=869664151&_trksid=p4634.m322), though they are still closed for the holidays just now.
-
Isn't the Keysight DSO1014A made by Rigol?
-
Isn't the Keysight DSO1014A made by Rigol?
Yes it is: but it's QA'ed and warranted by Keysight
-
We do have a couple of instruments in the PXI and/or VXI chassis here along with the relay matrix. We also have a couple of external instruments as well, for instance the Keithley DMM we use as a transfer standard. We actually drive the instruments with a C# program mainly because I find it easier (even with learning C# as I go) than dealing with LabView for this type of work, and it seems that everything is available with a windows library which C# does well. In any case, the test process is being abstracted out to a config file for each test, so unless a new product needs a new type of test, it becomes just writing a config file with a list of steps which need to be completed in order. I.E. do a wiremap on these pins. Then apply power. Then verify voltages at certain pins. Verify signals against known mask, etc.. So far, it seems to be going much quicker than I had thought and future tests will be even faster to write. But, we're still missing a couple of instruments we need.
Despite your apparent aversion to Labview is it not a viable option for what you want to achieve considering dedicated Labview drivers are available for many DSO's. :-//
AFAICT it has pass/fail mask testing as part of its package. Multi channel, well I haven't got that far yet.
http://sine.ni.com/psp/app/doc/p/id/psp-357 (http://sine.ni.com/psp/app/doc/p/id/psp-357)