Tektronix MDO3000 Series Scope - Page 1
Forum section: electronics / testgear

author: tekman11
author_rank: Contributor
timestamp: September 19, 2014, 05:34:58 am
content: Hi all,Has any one here used the this series of scope?Is it competitive with the Agilent 3000 msox series?thanks

author: don
author_rank: Regular Contributor
timestamp: September 19, 2014, 09:59:36 pm
content: I've used mdo4000, and think other than time correlated SA / time domain, screen size and memory they are very similar. Mdo3000 does not come with mso by default ($1500 I think) but a promotion now includes 3GHz SA ($2500 option) and a protocol decode ($1100). SA is cool because it has a 3GHz capture bw vs a swept input. Agilent has a good deal now where you can get all options for ~$800. The tek is nice because it inherets a lot of scope behavior from the higher end tek scopes if you have grown accustomed to using them. I have not used msox though. Is this for general debug? For my useage the tek has the edge but may vary for you.

author: luis garcia
author_rank: Regular Contributor
timestamp: September 19, 2014, 11:31:35 pm
content: Tek MDO's have a nice feature of being "bandwidth upgradable" by software!You may purchase the 100Mhz version and upgrade it to 300Mhz. Of course purchasing the license from Tektronix!. For upgrades beyond 500Mhz you need to send the unit to Tektronix.The waveform generator, meter, logic analyzer and SA are also software upgrades. For the LA you would need the logic probe though.

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 19, 2014, 11:36:12 pm
content: You have probably seen these links.https://www.eevblog.com/forum/blog/eevblog-587-tektronix-mdo3000-mixed-domain-oscilloscope-teardown/msg507818/#msg507818https://www.eevblog.com/forum/testgear/new-6-in-1-scope-from-tektronix/https://www.flickr.com/photos/eevblog/sets/72157641979331094/Agilent MSOX3000 is different from Tek MDO3000. It just depends what you prefer. MSOX3000 has unmatched 1000 000 waveforms per second while MDO3000 has longer memory and many useful features.

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 19, 2014, 11:40:09 pm
content: I do not like that MDO3000 has uncovered power supply. If a capacitor blows, it will damage the whole digital circuitry. While at MSOX3000, the PSU is hidden behind a metal wall.Check the competitive fact sheetmade by Tektronix guys.Also see MSOX3000 internals. It is built like a tank. I like it.https://www.flickr.com/photos/eevblog/sets/72157626755861230/

author: nctnico
author_rank: Super Contributor
timestamp: September 19, 2014, 11:49:02 pm
content: Quote from: Hydrawerk on September 19, 2014, 11:40:09 pmThat is a very far fetched non argument. I've never seen a capacitor blow in a power supply like this.

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 19, 2014, 11:54:33 pm
content: Here is another competitive comparisonin pdf. This time made byAgilent (oh, Keysight) guys.They say that Tek MDO3000 does not have a segmented memory. You can check it in a datasheet from Tektronix web.On the other hand, the MDO3000 looks nice.

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 19, 2014, 11:56:37 pm
content: Quote from: nctnico on September 19, 2014, 11:49:02 pmI believe you but many scopes have some kind of a hidden power supply.

author: nctnico
author_rank: Super Contributor
timestamp: September 20, 2014, 12:16:39 am
content: Quote from: Hydrawerk on September 19, 2014, 11:56:37 pmHidden? You probably mean shielded. I guess the input circuitry or the PSU is so good in terms of susceptibility or radiation it doesn't need shielding.

author: DanielS
author_rank: Frequent Contributor
timestamp: September 20, 2014, 12:25:49 am
content: Quote from: nctnico on September 19, 2014, 11:49:02 pmI have seen some power supplies with blown caps - one of them in a computer my older sister wanted me to fix. That cap was in the gate driver circuit so no real damage was done to the rest of the computer. If one of the output caps blow up though, the amount of junk on the affected power rail(s) may very well fry most of the electronics on them (like Dave's LeCroy scope with weird trigger issues until the 3.3V rail failed and killed the memory controller chips) and moot the mechanical protection argument.Here is one example of a capacitor failing inside a PSU - blew its top off and all that is left of it on the PCB is bits of paper. Cause or consequence? With the amount of damage all around, I have no idea how to figure that out.

author: GreyWoolfe
author_rank: Unknown
timestamp: September 20, 2014, 12:53:57 am
content: I have see just the base left inside failed ELO touchscreen monitors that were supposedly refurbished. Small capacitors (don't remember values) but big mess.

author: EEVblog
author_rank: Unknown
timestamp: September 20, 2014, 01:59:36 am
content: Quote from: luis garcia on September 19, 2014, 11:31:35 pmThe Agilent scopes work exactly the same way.

author: EEVblog
author_rank: Unknown
timestamp: September 20, 2014, 02:05:38 am
content: The MDO3000 represents great value with the now free spectrum analyser included. Shame it's not time correlated like the MDO4000, but hey, you get it for free.The biggest difference between the two machine is in terms of UI speed and usability.The MDO is as slow as a wet week. Turn on the spectrum analyser and it practically locks up the front panel at low RBW's.In the defense of the Tek it's slow because it searches and computes based on the entire sample memory, not just display memory.But ultimately it's it's old architecture that makes it slow.If you want a super fast response scope for stress free everyday use, the Agilent is the winner.If you want more bang-per-buck the Tek is a good option.

author: tekman11
author_rank: Contributor
timestamp: September 20, 2014, 03:57:00 am
content: Hi Dave,The MDO4000 spectrum analyzer looked impression on you tube.how does the MD03000 spectrum analyzer compare to the MDO4000, Is the noise floor similar?How did you like the protocol analyzer(spi/i2c).thanks tekman

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 20, 2014, 03:30:33 pm
content: Quote from: nctnico on September 20, 2014, 12:16:39 amYes, I meant shielded.

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 20, 2014, 03:32:29 pm
content: Quote from: EEVblog on September 20, 2014, 02:05:38 amBut the MDO3000 has no competitor in its category.

author: jahonen
author_rank: Super Contributor
timestamp: September 20, 2014, 04:08:12 pm
content: Quote from: EEVblog on September 20, 2014, 02:05:38 amEven if it uses the whole memory for the computation and it takes time, that is ok, but it is absolutely inexcusable to lock up the UI meanwhile the computation is being done. UI should not be ever locked up that way even if some lengthy computation is being done in the background. Multithreaded programming, anyone?Regards,Janne

author: luis garcia
author_rank: Regular Contributor
timestamp: September 20, 2014, 04:20:05 pm
content: MDO's have Linux inside. Unless they have set the SA thread priority to something like real time, it is no usual the GUI gets locked. However it is acceptable to do so if you have a long task to finish and want to present results as soon as possible. When do you perform a SA sweep what do you prefer, wait while you play with the GUI or have the results ASAP ?.To me the real MDO's are the 4000 series. MDS3000 is a cheap version of the real machine.

author: don
author_rank: Regular Contributor
timestamp: September 20, 2014, 07:25:58 pm
content: Quote from: Hydrawerk on September 20, 2014, 03:32:29 pmMDO is not normally slow and really only at low resolution as Dave highlighted. Running SA with 30Hz resolution BW is pretty extreme and obviously not possible on other oscilloscopes. A traditional swept SA can take minutes to sweep at 30Hz resolution bw depending on span (and do not have 3GHz capture BW which is awesome for tracking EMI problems). Doesn't justify laggy UI but realistically all SA's are unusable at low resolution BW until capture is complete. And i think MDO might beat other SA's in total time to capture (at least on one test I saw). Normal scope usage is fast. Laggy UI is rare. Pan/zoom at 10M is fast on MDO. Measurements can be gated with cursor, screen, or entire waveform. This impacts computation time. Scope is still useble (not locked up) while measurements are being computed if you choose to compute based on entire waveform with 10M memory, at least from measurements I've used. . Protocol decode is fast. Also it works how you would expect. You can capture a waveform in normal yt or roll mode and enable decode. It will compute decode and display. Same with cursors / zoom. Turn them on and they work on any mode and consistent across all modes. The cost might be computation time in some cases so choose what's important to you (consistent usage in all modes, waveform computation) or fast response from HW based system but more limited usage .

author: kilohercas
author_rank: Regular Contributor
timestamp: September 21, 2014, 06:54:41 pm
content: MDO3000 is very nice scope, as i start to say, i only need solder iron and power supply on my bench for normal work.AFG is very limited , but useful, i was able to lock femtosecond laser to AFG as reference, because laser photo-diode output had some problems with PLL, so that was quite fun debugging.if some one want to trade MDO3054 (all modules, SA,MSO,AFG) to MSOX3000 series scope, please contact me

author: MarkL
author_rank: Unknown
timestamp: September 21, 2014, 07:02:11 pm
content: Quote from: don on September 20, 2014, 07:25:58 pmWhen I tested the MDO4104 two years ago, it took 50 (correct: fifty) seconds to decode a single 20Mpt capture of I2C data. Two streams took 100 seconds, and so on. During decode time the UI was utterly unresponsive and unusable. Plain SA mode locked up several times and required power cycling. Feature-wise the spec sheet for the scope reads great, but we sent the eval back along with a list of about 35 other issues and UI bugs.Have you done any specific protocol testing on the MDO3000 that you can share to support your "it's fast" statements? Has Tek made any improvements since the MDO4000? My understanding is that it's essentially the same software as the MDO4000, but I'd like to learn otherwise.

author: kilohercas
author_rank: Regular Contributor
timestamp: September 21, 2014, 07:46:21 pm
content: Quote from: MarkL on September 21, 2014, 07:02:11 pmFor 1000 to 1M decoding looks like real time, but longer sampling size will reduce performance even when MDO3000 use hardware decoding ( it does looks so)

author: don
author_rank: Regular Contributor
timestamp: September 21, 2014, 08:44:13 pm
content: Quote from: MarkL on September 21, 2014, 07:02:11 pmI have not yet used MDO3000, but use the MDO4000 regularly. My understanding is the MDO3000 is faster than MDO4000 (at least original MDO4000). I have never encountered anything near 50s to decode a 20Mpt I2C record. I can't give you a number because I never measured, but seems like an order of magnitude faster than what you were seeing. Did you have have several full waveform measurements on? Rough idea of how many I2C transactions? I would guess I usually have under 100 transactions. I'll pay attention next time I'm doing some decoding.My "fast" statement is subjective. To put it another way, I'm going to spend A LOT more time parsing through 100 I2C transaction that I will to capture. Or I'll spend more time waiting for the trigger to occur. Once data is captured and decoded you can zoom and pan and jump from transaction to transaction in real time. To me, this is critical. Once I capture something, I want to be able to do what I want with captured signal. I'll wait up front a bit, but I can't deal with capturing a signal only to find I can't zoom or decode after it's captured. This is where I think the tek scopes excel. Even a simple thing like being in zoom and having cursors way at the other end of record. You can probably find a button "click to center" on all scopes, but the tek scope accelerates the scrolling when off screen and in zoom so it's still only a few turns of the knobs to bring it on screen. Little things like this make it fast in my opinion.35 issues and bugs? That's a lot. Something must be different about how people use scopes. I tried a siglent SDS2000 and Rigol DS4000 (with the intent of purchase) and found them unusable for my needs. I find the Tek scopes (including MDO4000 to work without issue. Maybe even the same firmware you found 35 issues on. Go figure, right? Good thing lots of scopes to choose from.

author: Omicron
author_rank: Regular Contributor
timestamp: September 21, 2014, 11:16:07 pm
content: For those using an MDO4000 or MDO4000B: be sure to grab the latest firmware from the Tek web site. It brings you all the goodies of the MDO3000 (apart from the AWG obviously), including the new UI look. Most notably it gives you the newFastAcqmode and so upgrades the max. wave form capture rate from 50.000 wfps to 250.000 wfps. It also adds the nice color graded display modes. Well worth the small trouble of doing the upgrade! This also shows that there is nothing "faster" about the MDO3000 compared to the MDO4000, it's all just software optimisation that has been done.A lot of the the early reports about the UI locking up are known issues with the initial versions of the firmware. There have been several updates since then that, as far as I can tell, remedy these types of things. At least I've never had mine lock up (been using it for about a year). Some operations do take time if you have the full capture memory enabled, there is no denying that. That fact that it always uses the full capture memory for measurements however, does mean it can do things an MSOX simply can't. E.g. try measuring the rise time and width of a pulse at the same time on an MSOX. You have to optimise the display for either one or the other, but you can't do both with optimal accuracy. That's the downside of the approach Agilent uses. On the Tek you just select your memory depth so it's running at full sample rate and all measurements you do are at best possible accuracy.

author: EEVblog
author_rank: Unknown
timestamp: September 21, 2014, 11:24:14 pm
content: Quote from: Hydrawerk on September 20, 2014, 03:32:29 pmTrue, and have said so in my videos.That still doesn't make it the best choice for an everyday use scope.YMMV.

author: Omicron
author_rank: Regular Contributor
timestamp: September 22, 2014, 12:14:19 am
content: Quote from: EEVblog on September 21, 2014, 11:24:14 pmI'm fortunate in that I have access to both an MDO4000 and an MSOX3000. To appreciate the difference between the Agilent and Tek approaches you really need to sit down and play with them both. My own experience I could summarise as follows:- The Agilent gives you a carefree experience. It won't lie to you (aliasing if it does happen is pretty obvious) and is extremely fast. It's the ideal scope for general troubleshooting and tinkering about when the emphasis is on qualitative observation. I'd describe it as very "Apple" like: you turn it on and you don't really have to worry much about it: it simply works.- The Tek you really need to know how to drive because it will not protect you from your mistakes. However, if you take the time to learn, it can be a much better measurement device than the Agilent. I find it excels at single capture type use due to its sophisticated navigation and search features. I really love that aspect of its UI. It also has a much better assortment of probes.What your best everyday use scope is depends a lot on what type of work you do. I mostly do embedded work. If I would have to make a guess I'd say that about 80% of the time I'm using my scope in single capture mode combined with protocol decoding. That gives the Tek the edge for me. I could (reluctantly) let go of the Agilent, but the Tek they would have to pry out of my cold dead hands

author: w2aew
author_rank: Super Contributor
timestamp: September 22, 2014, 03:37:00 am
content: Quote from: Omicron on September 22, 2014, 12:14:19 amYou have to be careful aboutthatstatement. If you try to make the measurement you described earlier (rise time and width of a pulse at the same time), it might give you misleading results if the rising edge is very fast and not adequately sampled in the decimated display data that is used for the measurement.On the Tek, you'll get a "low resolution" message if the waveform sample rate is too low for the measurement, at which time you can then increase the waveform memory to give you a higher sample rate at the same timebase setting. Like you said, the more you know about how to drive, the better the unit is.

author: Omicron
author_rank: Regular Contributor
timestamp: September 22, 2014, 09:54:55 am
content: Quote from: w2aew on September 22, 2014, 03:37:00 amYes, absolutely. I was referring only to the waveform display and in particular to the way the Agilent handles aliasing, which I think is much better suited to casual users and beginners (or professionals burning the midnight oil).One detail I love about the Tek is its ability to save screen captures directly to a network drive. Just press the save button and be done with it. I use that all the time. I don't like fiddling around with USB drives, they always manage to end up somewhere were I can't find themI haven't yet found a similar feature on the Agilent. You can use the web interface to grab images, but then that's only practical if your PC is also on your bench. True, it's a minor feature but once you get used to it...

author: MarkL
author_rank: Unknown
timestamp: September 22, 2014, 04:40:10 pm
content: Quote from: don on September 21, 2014, 08:44:13 pmIt was roughly 8500 I2C transactions (START conditions), with 1 or 2 bytes of data each. In total, the MDO4000 had to decode about 19k (addr + data) bytes. The SDA and SCL lines were also being displayed on 2 of the analog channels, but nothing else. The decode time was fairly linear to the number of bytes, as I recall.Better tools for such a job? Certainly. But my main point is there's no excuse for the UI to roll over as a result. And 19k bytes should not be such a Herculean effort to decode.But even with a modest amount of decoding on the screen, I found the UI still lagged by a few seconds, which continued to cause issues. The A/B knobs are encoders with no detentes and you are solely reliant on the visual feedback to know what you are selecting. The lag would surface at unexpected times, and you would often get ahead of yourself with the A/B selections and have to wait until the UI caught up, or more often, overshoot and end up selecting the wrong thing by accident. Really, really, frustrating.Quote35 *is* a lot, but other vendors we evaluated at the time had similarly sized lists. Being a long-time Tek fan, the poor software quality in a flagship product was a big surprise.It was version 2.52, which by now is old, but I've continued to scan the release notes from newer versions as they appear. Nothing we reported has been noted as fixed, but I concede there's probably plenty of problems that are fixed without publicly documenting them.I'd still like to consider an MDO3000 or MDO4000, but was looking for any evidence that the UI and decode issues have been addressed.(Edit: Fixed minor typo.)

author: W7NGA
author_rank: Regular Contributor
timestamp: September 22, 2014, 05:18:14 pm
content: I simplywouldcould not use a scope that couldn't be switched into fine-resolution (and back) by the push of a detented control.One other data point. I've owned my Agilent MSO7000 series oscilloscope for five years and it hasnevercrashed, locked, or exhibited any errant behavior.daniel W7NGA

author: Mark_O
author_rank: Frequent Contributor
timestamp: September 22, 2014, 08:34:24 pm
content: Quote from: MarkL on September 22, 2014, 04:40:10 pm20Mpt of I2C data is actually 40Mpt, since there's SDA and SCL to process. So it was running 800k points/sec processing. That doesn't seem too terrible to me, for software-based decoding. (The fact that >98% of that was bus idle is somewhat irrelevant... it still had to be scanned.) If the data was so sparse that you couldn't simply back off on the sample rate, then segmented-capture mode would have made more sense. But I don't know if the MDO4000 supports that mode, and I believe I read that the MDO3000 doesn't (no mention in its data-sheet)?Though I would structure things differently, so that a) the UI wasn't preempted, and b) you quickly got a screenful of data displayed, while processing of the unseen part continued in the background. I.e., I'd autozoom to something meaningful, quickly. Rather than process the whole acquisition in one batch (displaying no progress), then display the whole enchilada (too densely to be very useful). [Gee, maybe I should patent that.] I.e., nobody is going to be looking at 20kB of decoded data on a single screen anyway, even if all the bus idle gaps were removed.It sounds like the Tek UI violates two important principles: never lock the user out (control), and never leave the user in the dark (feedback).

author: Hydrawerk
author_rank: Super Contributor
timestamp: September 22, 2014, 10:38:43 pm
content: Quote from: W7NGA on September 22, 2014, 05:18:14 pmI have my DSOX2002A for 1.5 years now and once i saw this error message.But the scope was not locked. It only rebooted.Quote from: Hydrawerk on August 20, 2013, 11:23:45 pmhttps://www.eevblog.com/forum/reviews/my-new-toy-)-agilent-dsox2002a-sex-on-a-stick!/msg279789/#msg279789

author: don
author_rank: Regular Contributor
timestamp: September 22, 2014, 10:39:46 pm
content: Actually the UI does give feed back - there is a little rotating square graphic to indicate its calculating. And I don't remember UI ever being locked up (I'm sure it can, but I have not encountered). Though I can't think of a use case where I need to press buttons while its decoding so maybe that's why . Run/stop will abort and free up resources. Out of curiosity, can anyone think of scope settings you need to adjust during a capture?So we are talking about 8500 transactions...with that in mind, 50 or 100s may be in the noise when adding in the the time to analyze (enjoy the break!).In any event, I've used decode on mdo4000 and it never struck me as slow. I'll see how mdo3000 is at some point. Hopefully same or faster.

author: MarkL
author_rank: Unknown
timestamp: September 22, 2014, 11:59:27 pm
content: Quote from: don on September 22, 2014, 10:39:46 pmProbably not much to do while a capture is happening. All the problems I encountered was when it was done capturing.Perhaps it's specific to the version, but once it was stopped and done decoding there were a number of actions that kicked off the decode again on the exact same stream. One of the ones I documented was turning on a bus or waveform display, even if it wasn't related to the decoded stream. There were others that I didn't write down because it was happening so often while routinely taking measurements and zooming in and out. Clearly the decode result was not being cached, and that magnified the response problems in the UI.And the little animated icon that shows it's busy calculating? It didn't animate on Bus2, just on Bus1. I thought the scope had crashed.I think you're right that if you only have 100 bytes or so you'd never notice any of this. But Tek should have done the testing to the limits and should have known.

author: tekman11
author_rank: Contributor
timestamp: September 23, 2014, 05:15:35 am
content: Hi all,At the lowest vertical sensitivity which scope has the least amount of noise?The Agilent spec's the crosstalk between channel as 100:1,Tektronix is spec at 40:1. Would this be a issue under normal usage?tekman