RoadTest: Tektronix MSO2024B Oscilloscope
Author: shabaz
Creation date:
Evaluation Type: Independent Products
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Agilent products and Pico Technology PC test tools in the same price range
What were the biggest problems encountered?: -1 point for some supporting PC software issues; -1 point for the remainder supporting PC software which functioned but, could be improved
Detailed Review:
(December 2013 - updated with some more screenshots)
Oscilloscopes have been around for over a hundred years, and traditionally they served a role similar sounding to their name; they were used for observing oscillations which by their nature tended to be repetitive. Cathode rays were first reported by the British scientist Sir William Crookes in 1878 but it took almost twenty years until the first Cathode Ray Oscillograph (CRO) as it was known at the time was constructed in France at the University of Strasbourg by the German physicist Ferdinand Braun. The early oscilloscopes (in use around the early 1920’s) actually didn’t really have a linear time base; they relied on the fact that a sine wave is approximately a straight line at a few degrees about zero; it was resolved around 1924 most likely by an R. Anson’s linear time base invention (there is not a lot of information about him).
Unsurprisingly oscilloscopes have advanced since then but many textbooks often omit an explanation of some of the additions of functionality that are present in modern oscilloscopes.
As an example: How useful were the early oscilloscopes at capturing single events? Apparently, with appropriate phosphor it was possible to see a single spot traveling at 225mph so not very fast at all (slightly slower than a peregrine falcon). With expensive, complex photography of the scope trace, a far more impressive 2 million mph was recordable; yet this equates to 0.3% of the speed of light. This is fascinating stuff (and there are some links to more information in the reference section), but the rest of this post covers a more recent model - which is a Tektronix MSO2024B (Incidentally [just to complete the digression] modern oscilloscopes like the MSO allow captures of around 20 million mph to be traced at low cost) – reviewed for the past two weeks due to a late delivery from a courier and so after a very brief ‘look-and-feel’ section below , this review will primarily focus on use-cases (topics listed below) and how the oscilloscope performed for these tasks.
Looking back on the past two weeks, the oscilloscope has performed well for all the scenarios attempted, and offered up some good and some superb features to help with these tasks:
(Most of the review can be read in any order, although some of it benefits from being read in sequence. Or, just go straight to the Summary):
The MSO2024B oscilloscope visually is fairly big; a large 7-inch screen with soft keys and two soft-knobs takes up almost half of the front, and the remainder has well-spaced, mostly dedicated, buttons, digital knobs and a pan/zoom rotary control for looking deeper inside captures. The entire case looks to be hefty >3mm thick non-creaky plastic; it will be no surprise if the product lasts 20 years. Despite looking through the manual for several hours before finally turning the device on, it will still seemed daunting – oscilloscopes have got to the point where they are extremely feature-rich and a lot of functionality can be buried inside menus.
The user interface is (90% of the time – not always due to extreme feature-richness) intuitive for many tasks; follow the menus and use the soft-keys. You will soon get used to looking out for small orange circles in the menus which indicate when to use a soft-knob to adjust a value.
User input handling is good; if you make any scale or position change, it is reflected instantaneously in the marker, but it may take close to half a second for the trace to move to the correct position and for the old trace location to digitally fade out. I have no issue with this; it is instantly possible to know where the trace will end up because you can see the marker move, and the trace will be displayed in that position in approximately 0.5 seconds. The behaviour is different to my older model oscilloscopes but it appears to be an implementation or design decision, and one that a user could certainly accept.
The colorful display can illustrate persistence (like an analog oscilloscope), averaging and also the presence of high frequency components (such as noise) in a faint glow on the normal (time domain) trace. The screenshot here shows an example signal from a DDS synthesiser with rapidly ramping frequency, settling on each of four frequencies briefly. Those four frequencies correspond to the brightest traces.
The frequency spectrum can be displayed through built-in numerical processing of the captured data. Digital data can be displayed either as separate signal traces or busses with numerical values or further decoded (for certain serial busses). The usual cursors are present; and it is possible to stack up multiple measurements that you wish to perform (three measurements are shown in the screenshot here). Notice the purple trace has a very faint glow to the left, indicating that the two signals were not locked in phase.
The display quality is good; the color dimension allows a lot of detail to be introduced and overlaid. It is bright and doesn’t dim much from any angle unless the oscilloscope was placed above head height. The default graticule is too bright but can be dimmed via the menu.
Often as Engineers we have had to contrive signals or delays in order to capture events of interest because we knew that an oscilloscope trigger circuit would typically work by looking at a voltage level exceeding a threshold, and that may not actually be closely related to the event we want to capture. This is no longer the case; modern oscilloscopes offer a vast array of possibilities that now match real life scenarios. Worried a pulse may be too narrow or too long? The trigger can be defined based on that. Want to trigger if the rise time is too long or too short? Or when data setup or hold time does not meet your criteria? All this is possible too. These capabilities raise triggering several notches up from traditional (old) oscilloscopes. The MSO excels and pushes the envelope here. It takes it further by offering additional trigger options such as runt pulse triggering (where the pulse amplitude is lower than expected). Each option has tuneable attributes. The trigger menu is so rich, it would actually be a pleasure going through it and determining your ideal trigger strategy for any scenario you are trying to capture.
Taking things yet further, if you want to trigger on actual content within a protocol such as I2C, or parallel data content then this is possible too; this raises the ballpark of possibilities up yet another notch.
The trigger options have a 1ns granularity, and it works very well; trigger jitter was below my measurement capabilities. As a test, it was possible to trigger on rise time for a high-speed comparator (7ns in my case), confirm that it operated to the datasheet specification, and then increase the trigger rise time value on the oscilloscope by one nanosecond and see no triggers occur (in the single shot mode) until about 400 million pulses. Increasing by another nanosecond and it dropped to zero triggers over a longer test. This would allow you to characterise the behaviour easily. (Don’t forget to take oscilloscope and probe rise time into account if you’re attempting this – information below in the reference section). In summary the trigger options, granularity and reliability were very impressive.
The MSO offers a large amount of memory for trace capture; enough for 1 million records per trace or reduced to 100k depending on user configuration. Putting things in context it is 200 times higher than some older oscilloscopes. It is interesting to see how such a volume of captured information can be viewed, searched (beyond the usual zoom/pan system which works well) and recorded.
Given that it is not possible to represent thousands of data points on an LCD, some tricks are used to provide feedback to the user that it could be worth zooming in further.
The display can represent high frequency content that is either captured but not visible at the current zoom or filter level, or high frequency content that could have been captured had a more suitable timebase setting been applied.
All test instruments can mislead if not used correctly, therefore this type of feature acts like an expert system advising of situations where the signal may have additional content worth investigating that may ordinarily not be visible with the current oscilloscope settings.
The four displays here show the feature. The first trace shows an example capture that looks like a noisy signal (it is a 100kHz sine wave with a 10MHz component added to it).
It is possible to adjust the filter to hide the high frequency content; the second trace shows the signal filtered at 5MHz.
If the Glitch Capture function is turned on, then it will display the fact that some high frequency content is being filtered out (bottom left trace).
The fourth trace shows if the time base is set to a very high value where a lot of data is being thrown out to keep the number of records to 100k or 1M then the MSO will warn you of the fact that high frequency content is being missed if you zoom in too much, by highlighting the area of uncertainty with blocks of a different color or shade (depending on if digital filtering is being used or not).
The feature is nice; it provides confidence up to the bandwidth of the scope if any data is being missed from the view, regardless of the time base and filter settings.
The high volume of data provides possibilities to post-process the captures. The data can be directly passed to software applications via USB (or Ethernet if you have a module installed) or transferred in a text file with comma separated values. The CSV file can be opened up with Excel or any text editor. There is more information about this in the software section further below.
There is an integrated search function to help locate analog - or digital (see later) - points of interest within the captured data. These can be defined exactly like trigger options. As an example it is possible to trigger based on rise time, and then search within the captured data with different thresholds or search with completely different criteria. Given the exceptional trigger possibilities, the search function is equally capable and highly impressive.
As the search parameters are adjusted, the display will dynamically provide a live indication of how many events are found. When you are ready to view them, cursor keys are used to skip back and forth.
Some experiments were done to see what the search performance was like, once the trace had been captured. When the search function is enabled and the search criteria is adjusted, a little ‘walking ants’ type of animation will display while the MSO is searching through the data.
While the animation is occurring it is still possible to continue to operate the oscilloscope (such as to adjust or modify the search criteria). The table here shows how long it would take for different levels of search complexity. It can be seen that for a more-than-reasonable number of search events (i.e. a sensible search criteria), the time taken seems to be mostly dependant on the number of records (100k or 1M) more than anything else. The 3.5 second time was considered reasonable (given that often we wait longer for a web page to appear).
The MSO can collapse up displayed digital signals into any arbitrary bus (up to two busses simultaneously). The in-built serial bus trigger capability is incredibly flexible; not only can conditions such as the start of I2C transmission be used to cause the oscilloscope to begin its acquisition but more advanced configurations can be set to inspect multiple byte address or message content to determine that the trigger condition has occurred – it is a unique level of inspection for triggering that I have not seen before. The trigger feature can capture based on wildcards too – perfect if you want to capture data that may be addressed to more than one device on the bus for instance.
The tests showed consistent reliable triggering; in my limited tests it was not possible to find any scenario where the scope would miss an event – and I tried many repeatedly including fixed values and wildcards.
It is easy to configure; select the desired number of bytes for inspection, and then select the binary or hexadecimal digit in each byte and adjust to the correct value using the soft knob.
A very useful application for the multi-byte trigger is to observe what happens to an oscillator when the frequency is changed. This is important for many applications including transmitter and receiver testing or design. The diagram here shows a phase locked loop (PLL) voltage controlled oscillator (VCO) behaviour during certain frequency changes in order to see if it was behaving well (changing frequency rapidly and settling quickly) and to see what spurious output could occur during the change for certain frequencies; it was possible to program the oscilloscope to trigger on a specific frequency change on the I2C bus to capture what occurred to the VCO control voltage. The yellow trace is the VCO voltage and purple line is the I2C bus. This is the zoomed-out view showing the change to a certain frequency, and then back to the original frequency.
Shown below is an example zoomed-in view. The I2C bus activity is automatically positioned correctly in time to match the analog trace and the address and data information can be directly read off the screen:
The serial bus trigger feature functions extremely well and the resultant display interaction here is carefully thought out and implemented; content scrolls smoothly at a good speed to view the data content when the pan knob is partially rotated. Further rotation causes a well-paced acceleration – again smoothly; very important when keeping track of where you are in a long capture.
The serial trigger is a highly useful feature that requires the ‘embedded trigger’ module. It will also be useful for Serial Peripheral Interface (SPI) busses which can run at very high throughput where it would be impractical without a multi-byte trigger capability to capture exactly at the correct time of interest.
Mixed Signal Oscilloscopes were intended to reflect the need that modern designs had both analog and digital circuits. These were designs like washing machines, car engine management, mobile phones, cameras and other bits of home electronics with analog sensors or analog outputs combined with digital circuitry including microcontrollers. Why could a separate logic analyser and a separate oscilloscope not meet needs? Surprisingly one of the issues is familiarity and usability; engineers were already familiar with using oscilloscopes, whereas logic analyzers were fairly complex tools up until recently. I remember seeing a particular model at a place of work, and no-one in the team knew how to operate it, so sadly it sat gathering dust. Moving forward, today some requirements have changed; nowadays there is often no need for a logic analyser to decode a bus into assembler code, because often the bus is not visible with integrated RAM/ROM on microcontrollers, and debugging has moved to a higher level with software tools.
However if you’re working with high-speed (likely parallel) ADC/DACs, digital video, cameras and LCD displays then digital data capture is highly desirable. Another scenario is programmable logic; you may want to probe a large quantity of signals simultaneously during debug. The data can be clocked in and the MSO can display it as individual traces per signal and/or combined with values printed in hexadecimal or binary form.
The logic analyser within the MSO is extremely well-integrated; it blends into the existing menu options so that (where it makes sense) you will see options to use logic inputs alongside options to use analog inputs. The MSO supports up to 16 dedicated digital inputs but the analog channels can be combined to total 20 logic inputs. This might seem a large number but it is easy to get through; a camera module may have a 10-bit data bus for example, not including the clock and synchronisation signals. Triggering based on parallel bus content is integrated into the trigger menu too.
The screenshot here shows individual bus signals and the collapsed view with hexadecimal decode.
Much like the MSO analog search capability, it is possible to search digital data for particular values (including wildcards) or manually traverse the data using the pan/zoom capability.
As with serial busses, it is also possible to switch to an alternate display which shows a table view of the data along with timestamps. The content can be exported to a text file.
Here is an example view of event tables for parallel bus data and for serial (I2C) bus data:
There didn’t appear to be any software to recreate the timing diagram from the text file, but a short program was written to convert it to a suitable format for the Open Bench Logic Sniffer (OLS) client; more information and the source code is in the reference section. A screenshot is shown here of the data from the earlier screenshot (“Example Parallel Bus Capture”), converted and displayed with the OLS client software. This allows you to replay the traces on your PC (Windows, Apple, Linux).
This information should have been in the ‘Investigating high volumes of data’ section, but it makes sense to list it here after the digital features have been described. Much like the analog trace search performance, it was interesting to try to see how fast the MSO could process digital data. For this test, I2C data was captured. The results show that once the data has been captured, it can take around 4 seconds for the decode to be displayed on the screen, regardless of the number of bytes that are decoded. This is very acceptable. Once the decode has occurred, subsequent searching on the data is extremely quick; searches take about 0.5 seconds to process (this was done counting fractions of Mississippi’s :-) - so not very accurate).
When dealing with logic signals often an ‘eye pattern’ is used to see the quality of the signal. It superimposes the seemingly-random signal on top of itself repeatedly. Digital logic signals contain high frequencies (even at low bit rates, the near-vertical edges contain high frequencies) that get affected when transmitted (e.g. over a wire or from one end of the circuit board to the other) because the path may filter the signal or noise may be picked up. The diagram here on the left illustrates a badly terminated signal showing another common effect; reflection from the end of a cable, causing the pulse shape to dramatically change:
The patterns are easy to do with any oscilloscope; turn on edge triggering and enable display persistence. They are valuable because you can see the voltage thresholds, distortions, mismatch, noise effects, and any jitter all from one snapshot. The diagram on the right above shows a better termination (still not perfect).
Here is a common scenario; signalling over Ethernet. The images below show a 100Mbit/sec signal over an Ethernet cable and the signal when the wire is untwisted for about 50cm.
Spectral analysis in the same test instrument would be very useful to further characterise signals. With the MSO an attempt was made to observe the frequency spectrum. The diagram here shows the result for a pseudo random binary sequence (PRBS). The MSO’s computed display is near-textbook. From the time domain view it can be seen that the logic signal has some ringing visible. The frequency domain view provides additional information; it shows that the signal has a bitrate of 32MHz (it was possible to expand the trace to see this) from the dips in the spectrum and that it is conventional (Non-Return-to-Zero) encoded from the shape of the peaks.
This information could prove useful when transmitting digital data. Note that the MSO2024B will not directly compute the FFT from a digital logic input (only from analog inputs), but it is possible to post-process on a PC of course.
Unless your oscilloscope is needed for a dedicated particular test role, nothing under 100-200MHz bandwidth should generally be considered. Remembering the sharp edges described earlier, many logic devices (microcontrollers and CPLDs) will have logic switching at frequencies high enough (it just takes a few tens of MHz) that you won’t get an adequate waveform display with any lower bandwidth oscilloscope.
The maximum advertised sample rate will be higher than twice the bandwidth but it doesn’t need to be many multiples higher these days to help reconstruct a signal. It is worth clarifying this further: traditionally oscilloscopes tended to ‘join-the-dots’ to show the sampled signal; this worked very well as long as the oscilloscope bandwidth was far lower (of the order of ten times or more) than the sample rate.
Modern oscilloscopes will post-process the sampled data to perform low-pass filtering (known as ‘sinc interpolation’; in practice a variant will get chosen); this provides a representation of the input signal up to the bandwidth of the input filter. You can have confidence that frequencies up to the advertised bandwidth will be displayed with good accuracy.
It was worth a quick experiment to confirm that signal content up to the bandwidth of the oscilloscope will be faithfully reproduced. Note that the ‘sinc’ function involved extends to infinity so would take an infinite amount of time to compute, but in practice a special shaped truncation is made. With the truncation, for a decent filter response (and thus decent waveform reproduction), the bandwidth is desired to be a quarter of the sample rate and doesn’t need to be much more. Also note that in practice the bandwidth advertised is at a -3dB point.
As a comparison, a single-shot (so no averaging) signal was recorded on the MSO (at 1Gsample/sec) and then compared with the signal connected to an older HP oscilloscope with 2Gsample/sec rate. The bandwidth of the HP oscilloscope was higher (500MHz); the same 200MHz probe was used for the comparison (compensated for each scope). This is not a fair comparison since the HP scope is an old model; nor is it remotely a perfect test (ideally it should have been repeated with different types of signals) but I picked a popular (commonly encountered) signal - just a step. Also, distortion from the photograph had to be corrected slightly.
The white trace is at 2Gsample/sec and 5ns per division; the blue trace is from the MSO at 1Gsample/sec and 4ns/div so it has been needed to be squashed horizontally when overlaid to get the timescale to match (i.e. 4 divisions from the HP scope needed to be aligned to 5 divisions from the MSO. Both traces look similar (and the source was a low-cost pulse from a comparator) so there was room for lots of experimental error. However the comparison shows that the interpolation behaves in a similar way for a step input for both oscilloscopes at these two sample rates with no anomalies such as overshoot. In summary the captured trace representation is extremely good.
Many oscilloscopes feature FFT and additional math options, and it was decided to see how useful the capability was on the MSO. It cannot replace a spectrum analyser – the MSO is not intended for significant levels of testing with RF - but it does provide some value for the scenarios that were tested and it allows the MSO to be used in areas where a conventional spectrum analyser would be overkill. Not all elements of the FFT are under your control, so some adjustment of the time base is needed to get the sample rate to a suitable value such that (a) you can resolve frequencies at the level you require and (b) that the spectrum display does not fold onto itself for any strong high frequency components expected in the input.
Frequency measurements play a big role with anything communication related, so it made sense to see if the FFT capability would be useful in this area. Many communications building blocks benefit from a frequency domain view. Many radio receivers filter out the undesired spectrum loosely, and then convert the range of interest into an intermediate frequency (IF) stage for further processing (including better filtering) – popular IF frequencies for home radios are 455 kHz and 10.7 MHz.
The example here shows a 455 kHz IF output from a radio receiver; at this ballpark the oscilloscope provides a good resolution of the order of 1kHz, which is sufficient to observe the effect of changing the IF filter on an input amplitude modulated (AM) broadcast signal. Note that it is possible to post-process the oscilloscope data using a PC to obtain a better resolution bandwidth – this test only looked at what the oscilloscope itself could compute. The video here shows the result observed with a 9.5kHz pass bandwidth filter which is uncommon (you would see 2-3 times as wide and therefore a far more detailed result for a normal AM radio) – the processing speed was fast enough to view it in real time. You can also see the shaded glitch capture rendering (as mentioned earlier) around the trace advising the user to zoom in to view high-frequency content not visible at the current zoom level.
Video signals can be difficult to trigger on without dedicated functions; the MSO supports NTSC, PAL and SECAM. Analog video is still used extensively (e.g. security cameras) so having the feature is highly desirable. NTSC was tested (I have not had a chance to try other formats). The trigger for all formats can be set to one of several options such as the start of the video frame (odd field) or even field or any desired line. The video trigger results in a completely stable trace. An example NTSC capture of the start of a video line using the trigger capability is shown here. You can see the color burst just to the left of center, and the video line content to the right of center. The grid can be set to measure in video units (not shown here).
Note that the video signal needs correct termination, usually 75 ohms for this.
Virtually all test gear needs to have network capability. Without it, it is harder to control test scenarios and process captured data and to share it. The MSO can have an Ethernet card inserted as an option; the tests here were conducted using a directly connected USB interface.
As with other devices, Oscilloscope data capture and control functions operate using a standard abstraction to software; the abstraction is known as VISA (Virtual Instrument Software Architecture).
There are custom methods, but also four off-the-shelf methods of interfacing with the MSO; eScope, OpenChoice Desktop, Tektronix Toolbars for Office and SignalExpress. With eScope a web server runs inside the MSO so that a browser based user interface can be accessed (it works on any platform) and was not tested (it requires an Ethernet card). The others were tested.
The key to much problem solving can often be as simple as sharing information with others; and nobody likes to see unannotated graphs or blurry photographs of scope traces! Therefore OpenChoice Desktop provides a simple interface for retrieving captured data and settings and for transferring oscilloscope configuration files. The captured data is automatically scaled to fit the larger PC screen and so for documentation purposes OpenChoice is absolutely ideal; the diagrams throughout this review were captured using either OpenChoice or the direct MSO screen capture. It is likely to be the primary software for day-to-day trace capture for documentation.
OpenChoice Desktop reliably started up each time the USB cable was plugged in (I have used this feature constantly over three months) and provided good quality scope traces. The raw data is captured too; suitable for exporting to a spreadsheet or other applications including custom software – more on this further below.
The toolbar software is a simple add-on for Microsoft Office – it provides the capability to capture images directly into Word or Excel (data can be captured into Excel using the toolbar too). It doesn’t have a lot of functionality but is convenient for documentation if you need to rapidly type up notes in Word and intersperse it with oscilloscope traces quickly.
National Instrument SignalExpress is available in a Tektronix Edition and a free to use ‘light’ Tektronix version is supplied and is downloadable from the Tektronix website however it didn’t work for me. It needs further investigation (it could well be my fault - a PC related issue) so I will report more on this after it has been pursued further. As an alternative option (which sadly didn’t work for me either) it is possible to download the full SignalExpress 2013 from NI’s website. NI’s downloadable full version will default to a light version after a trial period.
The Tektronix Edition is available from Farnell at a reduced price to the full SignalExpress 2013. It is worth considering.
This is not the place for a full review of it, but in summary the software allows you to capture, process and display results. It is possible to define a multi-step workflow (for example steps to acquire data, perform filtering and perform FFT) and you can bring out separate live graphical reports at all stages of interest in the workflow. The software provides full control of the MSO (the full version supports other vendor products too). With SignalExpress it rapidly becomes second nature to control the oscilloscope, capture and process data all via the PC. Once it works, I’ll provide an update.
USBTMC allows oscilloscopes to be able to send traditional GPIB-style commands in a standard manner across USB connections. It allows custom applications to control test equipment. The MSO supports USBTMC. An open source GPL license driver is kindly available from Agilent’s website and it was compiled and tested on Red Hat Linux with the MSO and confirmed to work with the supplied example code (which just retrieves and displays the product name, manufacturer and serial number).
While Microsoft Excel can be useful, it is not cross-platform and not designed for intensive data processing. If you have access to Matlab then this is another option otherwise Gnu Octave can be used for free. (Also, see here for how to automate your oscilloscope and integrate it into Octave). It is an easy task to take the CSV format files from the MSO and load them into Octave. The diagram here shows the quality of plots that are possible. This was a capture of a video signal using the MSO (see the reference section below for notes on Octave commands for this).
The MSO can capture 1 million points per acquisition, and this is very ideal for processing followed by data reduction before generating a plot. In summary there are lots of options for controlling, capturing, processing and documenting your results and all worked very well.
The MSO is a well thought out instrument; it appears constructed to a high standard and has sufficient features to provide many years of good service. The outstanding highlight is the extensive and reliable triggering (and search) capability which will greatly simplify capturing awkward or rare events. Other very good features included the high quality of traces, 16/20-bit logic analyser capability and the very large (1M record) capture buffer – perfect for further processing or for generating detailed reports. The number of digital channels makes the scope very ideal for circuits with programmable logic or any high speed logic.
The MSO design philosophy appears to have been “Perform these features, and do them well” and it looks like Tektronix engineers have faithfully met and exceeded expectations. However, it is clear that future designs will need to expand the goal to allow users to work in other ways too – such as higher waveforms/second throughput to allow less reliance on a well-defined trigger – and yet (thankfully) the MSO has what appears to be flawless and densely feature-rich triggering. The suggestion is that there can be multiple routes to achieve the same end test goal for a user, and users like flexibility. The MSO beats earlier generations of digital storage oscilloscopes (including my old HP) by an order of magnitude for such throughput, but times change.
Note that in the bigger picture (if we’re not peeling thin layers of onion any more) then the core features of trigger quality, trace quality, memory and throughput that the MSO offers far outstrip earlier model DSOs (perhaps ten-fold in almost each of the parameters) and is a wonderful upgrade. It is hard not to admire an oscilloscope that worked well for all the scenarios that were thrown at it; the above combination is a spectacular set of features that any engineer would look forward to applying to a whole range of tasks. After now having used it extensively for three months I am very happy with the features, particularly the vast triggering capabilities and the measurements which have been accurate and dependable, the simple-to-use interface and the ease at which I can export data and traces - absolutely essential to be able to share results. I have yet to get anywhere with NI SignalExpress - I will remind National Instruments.
The data export and PC display and processing options with OpenChoice Desktop and other software are very acceptable (the produced diagrams are superb for presentations, reports or textbooks) although there is room for improvement – it won’t be on every users list of priorities but I would consider it important to get SignalExpress functioning, so I will continue to pursue it – yet there are some attractive alternatives that are easy to use such as software like Octave, and it is cross-platform.
During the testing two fairly minor bugs were identified with the latest firmware; they have been reported to Tektronix.
The remainder information is useful as a reference for those who are about to purchase the product (or if you want to go deeper).
For an extraordinarily detailed in-depth examination of the history of early oscilloscopes (which is where the introduction was sourced from), see Measurements in Electrical Engineering by means of Cathode Rays by J. T. MacGregor-Morris and R. Mines, 1925.
Some information was sourced from Electronic Inventions 1745-1976 by G.W.A Dummer
Hameg has an interactive rise time PDF calculator here http://www.hameg.com/uploads/media/Oscilloscope_Risetime_Calculator_03.pdf (works with Acrobat Reader, but not with Firefox’ built-in PDF reader).
The MSO is supplied with 4 probes (all X10 devices; perhaps a preference would have been two X10 and two X100), but it is always good to keep some coax cable handy with every oscilloscope for some scenarios.
There is no in-built 50ohm input in the oscilloscope, but connecting an external 50ohm resistance closely to the scope is adequate for signals up to the MSO bandwidth – a convenient way to perform the termination is to keep a T connector and a 50-ohm BNC termination handy.
Active probes are supported for the MSO – they contain a switchable in-built 50-ohm termination, or a TekVPI adapter can be used to provide this capability.
The unit comes with a soft probe case that can be attached to the rear of the scope; I choose to store my probes in a box to protect them.
For the FFT feature, the displayed value is in dBV; if you are terminating with a 50 ohm load, then 13 needs to be added to the displayed values to get the dBm value.
A hard protective cover is available as an option (Tektronix code 200-5045-00).
Tektronix have some excellent hard transit/flight cases – I use one for transporting any electronics gear when needed.
The (very simple) source code to convert captured logic values (in CSV format) to OLS format is attached. With this code, it is possible to type:
tek2ols input.csv output.ols
Although the code works, it may need modification – it has not been overly tested. A better option would be to directly modify the OLS client software (it is open source) to be able to directly accept the Tektronix CSV files.
GNU Octave can be installed on a Linux or a Windows machine. To convert MSO traces into a format suitable for Octave, strip off the CSV file header (using any text editor). Optionally reduce the data (no point plotting 1M points if you only need a few thousand points) if you don’t need to process further. It could probably be done with ‘sed’ or ‘awk’ but a simple program to keep 1-in-N lines is attached. This example will keep 1-in-10:
reduce capture.csv 10 reduced.csv
Then, in the Octave command line, the following command will read in the file into a matrix:
x=csvread("c:\\projects\\reduced.csv");The first column contains the timestamp, and the second column contains the amplitude. This can be plotted using:
plot (x(:,1), x(:,2))
Top Comments
use one like this in school i think it is great nice review
Great review, looks like an awesome scope.