...Me I had originally met Dave's blog when I was Googling info on the 1052E DSO. Remember the first 1052E EEVblog video? That was 4 yrs ago. Now compare his 1080 res 2013 presentation style, lab, and info galore. Well that is some sure progress!
Yup, sure it!
That was shot on a 320x240 webcam that was maybe 8 years old, propped up on a bottle of Jack Daniels (no, I don't drink it, supplier gift).
I hated that video, I really did, but I uploaded it anyway. Here is the original aus.electronics newsgroup post announcing it:
https://groups.google.com/d/msg/aus.electronics/FvwX2e93FiY/qRhoPiwzENcJ
Thank you Dave for a very informative blog. I mostly still run older equipment for my repair shop and the students where I work are still using HP54603B's which are getting a bit outdated, just how much outdated I was unaware of till watching the Rigol and the price is great. My only concern is how they might hold up to the abuse of college students so we were leaning towards the Agilent DSOX2002A since our HP-Agilent scopes have had a pretty good track record. It remains to be seen if anything new will hold up to these kids. I get lots of good ideas from your test equipment blogs that help keep me current.
Great job
Cheers
Phil
Talk to your the scope manufacturers rep, be it agilent, tek, rigol or whoever, they tend to do special deals for educational institutions.
What is necessary to do USB traffic analysis?
Do you need an $800 scope or can it be done with a Saleae logic analyzer or BusPirate?
Decoding USB on a scope would be stupid unless you are looking for a specific issue like noise or debugging a bit banging usb interface.
Your computer will very happily spew out all the raw USB protocol goodness with the right software.
As long as your computer's USB controller can understand the signal you don't need any hardware to probe it.
notsob
The Mfrs reps here in NY are not all that willing to spend much time on small institutions any more, but often I can get a piece of equipment on loan for a bit.
As far as educational deals I am a bit jaded after 23 years of being offered demos and closeouts, the most discount I have ever seen is about 10% and they only often apply that to approved educational items.
It is nice to see Daves video because it is not a sales guy pushing something.
Phil
The Mfrs reps here in NY are not all that willing to spend much time on small institutions any more, but often I can get a piece of equipment on loan for a bit.
As far as educational deals I am a bit jaded after 23 years of being offered demos and closeouts, the most discount I have ever seen is about 10% and they only often apply that to approved educational items.
A number of members here seem to have gotten their Rigol DS2000s - at a discounted price - from Tequipment.net, which is located near you. If you have any interest in the DSO - and you haven't spoken to them already - you might give them a call.
Get video, would love to see more things like this. Tear downs are good but ill be honest, I don't walk away with nearly as much learning.
I've had this debate in my mind about scopes, I have this massive tds544a at home it's a real top spec scope for its time 500mhz, 4 channels, lots of good stuff. Most of it I don't use and would rather have something small and portable. Was looking at Agilent dso2000x, Rigol and Hameg. After seeing the video I think my mind is made that rigol is a awesome scope dollar for Dollie. Agilent is good too but probably pay more for the name. Tek IMO is really just a name at this point...
The software looked interesting, but I was shocked by how long it took to transfer from the scope to the PC. It was attempting to transfer the contents of the 14Mpt sample memory(before being cancelled), right? Eight bits per sample, right? That's 14MB of data. At 100BaseT you get around 10MB/s of throughput ... so it should have been able to transfer everything in under 2 seconds.
So, is the speed a limitation of: the bloatedness of the LXI protocol? the scope? the software?
The software looked interesting, but I was shocked by how long it took to transfer from the scope to the PC. It was attempting to transfer the contents of the 14Mpt sample memory(before being cancelled), right? Eight bits per sample, right? That's 14MB of data. At 100BaseT you get around 10MB/s of throughput ... so it should have been able to transfer everything in under 2 seconds.
So, is the speed a limitation of: the bloatedness of the LXI protocol? the scope? the software?
Two things:
1) Your memory estimate is way low. Dave was working with segments - and together with the full 56MB of normal sample memory, the DSO has something in the neighborhood of 128MB of memory for segments.
2) The DSO treats each segment as if it's a single-shot sample, so when external software asks for the current contents of memory, it gets ONLY the current segment. The software then has to ask the DSO to 'play' the next segment (and wait) - and that's what takes most of the time - not the actual transferring of data.
After Rigol's experience with the DS1000 series - where you could cause major refresh glitches in the DSO by asking for data from it too quickly - they have (rightly so) made it impossible to cause any kind of glitch or slowdown to the scope's operation remotely, so external software always has low priority. Otherwise I could easily get more than 20 fps from the DSO for real-time waveform display.
Dave, I would LOVE a comparative review of hameg HMO2024 and Agilent MSOX2024 mixed signal scopes.
along with their signal decoding facilities ...
prices are almost the same (if you get a refurbished agilent ...)
are the functionnalities better in one or the other ?
I'm sure I'm not the only one that would like such a review ...
thanks.
The software looked interesting, but I was shocked by how long it took to transfer from the scope to the PC. It was attempting to transfer the contents of the 14Mpt sample memory(before being cancelled), right? Eight bits per sample, right? That's 14MB of data. At 100BaseT you get around 10MB/s of throughput ... so it should have been able to transfer everything in under 2 seconds.
So, is the speed a limitation of: the bloatedness of the LXI protocol? the scope? the software?
Two things:
1) Your memory estimate is way low. Dave was working with segments - and together with the full 56MB of normal sample memory, the DSO has something in the neighborhood of 91MB of memory for segments (it can do a maximum of 65000 segments at 1.4kB per segment).
2) The DSO treats each segment as if it's a single-shot sample, so when external software asks for the current contents of memory, it gets ONLY the current segment. The software then has to ask the DSO to 'play' the next segment (and wait) - and that's what takes most of the time - not the actual transferring of data.
After Rigol's experience with the DS1000 series - where you could cause major refresh glitches in the DSO by asking for data from it too quickly - they have (rightly so) made it impossible to cause any kind of glitch or slowdown to the scope's operation remotely, so external software always has low priority. Otherwise I could easily get more than 20 fps from the DSO for real-time waveform display.
Ahhh, I guess I didn't understand segmenting. I assumed there was a single pool of sample memory that got segmented.
In the video he captured 8128 frames of 14Ks each. That works out to about 113MB (I was only off by less than an order of magnitude
. So, it seems that the combination of the protocol and the scope (I agree the scope should put external requests at low priority) is the limiting factor. I guess that isn't anyway to 'pipeline' those requests ala HTTP/1.1
Does the 2072 use compression as well as segmentation? As a software guy working with smart-meters and the analysis/storage of massive amounts data, I would say that timeseries data on a small scale (i.e. in an oscilloscope) is no different and thus subject to some of the same efficient integer compression techniques.
Does the 2072 use compression as well as segmentation? As a software guy working with smart-meters and the analysis/storage of massive amounts data, I would say that timeseries data on a small scale (i.e. in an oscilloscope) is no different and thus subject to some of the same efficient integer compression techniques.
I don't know the answer, but I am guessing no. The great thing about compression is that you get to store more data that fits the expectations of the compressor. The bad thing about compression is that it is less predictable. On a bit of test equipment like this you should expect your expectations to be violated. With compression you would never know how many sample/frames you could store ahead of time. Is some white noise sneaking into that signal you are debugging? Suddenly you don't get as many frames (or perhaps your update rate goes down ... something will have to give).
Perhaps compression could help when transferring data to the PC, but, as has already been noted, the performance there is not limited by the data throughput.
So, it seems that the combination of the protocol and the scope (I agree the scope should put external requests at low priority) is the limiting factor. I guess that isn't anyway to 'pipeline' those requests ala HTTP/1.1
Yes, it's a pity that the DSO can't just transfer large blocks of memory with markers signifying segment start and stop points - having to display each segment on the DSO screen really slows down the process. The fastest speed I can extract segments from the Rigol is, on my desktop machine, about 1400 per minute for single channel / 1100pm for two channels. But currently my software is the only way to get segments out of the DSO (which is why I started writing it in the first place) - that is one feature that is lacking in the current firmware: the ability to save and load captured segments. It would be nice if Rigol adds it at some point.
Does the 2072 use compression as well as segmentation? As a software guy working with smart-meters and the analysis/storage of massive amounts data, I would say that timeseries data on a small scale (i.e. in an oscilloscope) is no different and thus subject to some of the same efficient integer compression techniques.
I don't know the answer, but I am guessing no. The great thing about compression is that you get to store more data that fits the expectations of the compressor. The bad thing about compression is that it is less predictable. On a bit of test equipment like this you should expect your expectations to be violated. With compression you would never know how many sample/frames you could store ahead of time. Is some white noise sneaking into that signal you are debugging? Suddenly you don't get as many frames (or perhaps your update rate goes down ... something will have to give).
Perhaps compression could help when transferring data to the PC, but, as has already been noted, the performance there is not limited by the data throughput.
Also I'm just not sure it's possible to do real-time given the tight limitations of maintaining the waveform update rate (and blind times). Each segment is exactly like a single-shot capture - and at the 20ns timebase setting - which is where the Rigol captures ~50k wfrm/s - it can capture segments at almost exactly that rate. But I don't know for sure how it stores and accesses them inside the scope - but I sure would like to
I don't know the answer, but I am guessing no. The great thing about compression is that you get to store more data that fits the expectations of the compressor. The bad thing about compression is that it is less predictable. On a bit of test equipment like this you should expect your expectations to be violated. With compression you would never know how many sample/frames you could store ahead of time. Is some white noise sneaking into that signal you are debugging? Suddenly you don't get as many frames (or perhaps your update rate goes down ... something will have to give).
On the DS7072 as I understand it, capture/analysis, storage and presentation are after all very different things though (unlike the cheaper scopes). In loss-less software algorithms (image analogy: PNG/GIF/RLE) we deal with worst case performance (big-O) and I would think it's easy to guarantee some minimum, or worst case, simply fall back to non-compressed (image analogy: BMP/RAW).
From the demonstration video by Dave, it looks like compression could potentially store several order of magnitudes more frames. That could come in handy in a scenario where you favor longer memory over higher frame capture.
From the demonstration video by Dave, it looks like compression could potentially store several order of magnitudes more frames. That could come in handy in a scenario where you favor longer memory over higher frame capture.
True, but considering that the DSO has 192MB of DDR2 acquire memory - and the current maximum amount of memory that appears to be used (based on sample size * segments) is around 114MB - would make it seem as if they're not (at least at this time) using compression.
Great video Dave.
This was a really good comparison of the DS1000 and the DS2000 series. I'd personally go with the DS2102 version.
I'l still up in the air on getting the Agilent DSOX2012 or the Rigol DS2102. I keep thinking if i go with the Agilent I might as well get the 4 channel version which is like almost doubling the cost. With Agilent you start adding options the price starts to go way up and quick.
I also keep thinking (pure speculation) that Rigol is going to come out with the mixed signal version of the DS2000 series. Anyone have inside info about this?
Great video Dave.
This was a really good comparison of the DS1000 and the DS2000 series. I'd personally go with the DS2102 version.
I was about 2 weeks shy of ordering a DS1052 but that video changed my mind. The place I would have ordered the DS2072 from says a 6 month waiting period. Oh well, I have lived without it for this long a few months more won't matter.
I also keep thinking (pure speculation) that Rigol is going to come out with the mixed signal version of the DS2000 series. Anyone have inside info about this?
From what I've heard, they are apparently working on an LA module and a waveform generator module for the DS2000 series, which will (please take the following with a huge amount of salt) be ready for sale in about 5-6 months.
From what I've heard, they are apparently working on an LA module and a waveform generator module for the DS2000 series, which will (please take the following with a huge amount of salt) be ready for sale in about 5-6 months.
If that happened, then 6 months after that you'd probably have Agilent squeezing more goodness out of the 2000X.
It's an interesting battle, and it's funny (or sad) to note that there pretty much isn't anyone else in the game that matters as much.
From what I've heard, they are apparently working on an LA module and a waveform generator module for the DS2000 series, which will (please take the following with a huge amount of salt) be ready for sale in about 5-6 months.
Are those only for new scopes??
Are they only for new scopes??
I don't know. The current DS4000 mainboards seem to have a built-in connector that might be available for add-on modules - but I don't remember seeing anything like that in Dave's teardown of the DS2000 - was there? I think we'll just have to wait and see.
I was about 2 weeks shy of ordering a DS1052 but that video changed my mind. The place I would have ordered the DS2072 from says a 6 month waiting period.
Woah, 6 months?!
Who's that?
Sorry I misread it. I says 6 weeks. Glad you brought it up.
Test Equipment.net. They are who I was going to buy the DS1052 from.
**PLEASE NOTE: Due to Overwhelming Demand, lead time is currently 6 weeks** 70 MHz Digital Oscilloscope with 2 channelshttp://www.tequipment.net/RigolPricelist.html