Star Trek Tricorder 200
This was originally a paper for a Contest, sponsored by Xilinx, HandspringTM, and Portable Design Magazine. --- If you are familiar with design and complexity of modern DSOs and you think, after reading the performance specs. and other claims, you have come across a technical fraud, think again. Because this would mean you discovered the first such incident from the R&D departments of Bell Laboratories, perpetrated at substantial expense and the granting of U.S. Patent #4,217,524 --- It's not likely!
This paper describes a development in progress for a portable, Palm computer based, Digital Sampling Oscilloscope, DSO, with a bandwidth-performance equal to the "top-of-the-line" handheld scopes on the market; the 200MHz Fluke 199 ScopeMeter and the 200MHz Tektronix THS730A. The design objective is for a "cost-breakthrough" in the oscilloscope market, which will put the most vital tool for electronic engineering into the reach of the budget of most engineering students and the smallest of start-ups. It will not only be a great service to our profession, but also widen the market substantially by making high-performance DSOs affordable to a very much larger group of customers. (Which then also benefits the manufacturer.) Several new concepts are incorporated to make the above objective possible. First, the basic concept of "Software-Defined-Instruments" is implemented, and the "DragonBall" processor of the Palm computer is also used to perform all post-acquisition scope functions. Further, its USB link is utilized to connect the Palm-DSO to EDA programs running on a PC Workstation. (See "Instrument-Peripherals for your Workstation -".) Second, the DSO uses a new digitizing method called D2IS which allows for a design road-map exceeding a bandwidth of 50 GHz, while still remaining inside the power constrains of the PCMCIA format.
The particular design described here is actually the lowest performance version of this DSO, because it is the one that meets the 300 mW power limitation of the Visor Palm computer and has a "bill of materials" of less than $50. Which means that, at the customary price of four time's component cost for PC-peripherals, the DSO could be marketed for $200. With the basic Handspring selling for $149, total cost to customers could therefore be as low as $349 compared to $2500 for the Fluke scope or $3400 for the Tek scope. For a size comparison, look at: "Handheld-really?"
An apparently Incomprehensible Market Concept
The total Oscilloscope market is about $1.5 billion today and growing at a 10.5% annual rate. Market researchers divide the market into two segments, the "low-end" high volume market and the high-end market above $5000, with both segments at half the total dollar volume. If we plot the scopes on the market today for Bandwidth versus Cost the result is stunning! The correlation is so strong that one could assume it is a law of nature or at least as valid as "Moore's Law". This is comparable to the relationship that existed for the MIPS ratings of the old minicomputers versus Cost. If we had a "Time-machine" to go back to the 70's and added a Giga-Hertz Pentium PC to such a minicomputer chart, it would look similar to the Oscilloscope chart below with the new Palm-Scope added.
The manifestation of such cost-breakthrough products in "existing markets" has been researched by Harvard Professor Christensen and named <Disruptive Technology>. Likely "market consequences" should be obvious after the minicomputer demise, but the management of established T&M Firms does not recognize this.
Features
Oscilloscopes are very mature products, which have been around for more years than I have. Performance characteristics and controls are well established. A person who learned how to operate a car or an oscilloscope sixty years ago can still use that knowledge today. Any new scope deviating from this established operating standard would have a very hard time on the market. The Palm-scope design therefor has identical characteristics compared to "standard" scopes. Compared to the scopes from Fluke and Tek, there is one difference. The present Palm-DSO works in real-time only in the first third of the time-base range, the upper two thirds are in equivalent time; but faster than random sampling. This has been the standard for high bandwidth scopes for several decades, but the major T&M firms are now going to all-realtime in their drive for "up-market" products, which generate higher profits. It will take a few years until the disruptive technology of "Software Defined Instruments" can also provide this feature.
And while Fluke and Tek scopes have PC connectivity, via slow RS232, for waveform downloading as costly option ($390 and $319 respectively), the Palm-DSO uses its native high-speed USB link to become a fully functional peripheral to a PC Workstation. In this "mode", the PDA relinquishes all DSO controls to the Workstation and serves only as a secondary display. Other features, which Fluke and Tek scopes don't have, are the 10 bit vertical resolution directly from the D2IS digitizer and a time and amplitude controlled calibration pulse-train to provides a TDR function. And lastly, the "compute centric" nature of the scope architecture makes it possible to provide "auto-calibration" for time and amplitude accuracy. [This "Self-calibration and Correction" is important, because engineers and their scopes stay together for a long time, but both are aging! --- Believe me, I know!]
Specifications: Palm-DSO 262b PCMCIA Card Type 2
ANALOG BANDWIDTH: -------------------------------------------------------------- 200 MHz
MAX. SAMPLE RATE, EQUIV. TIME: ------------------------------ 5 Giga Samples/sec.
SINGLE-SHOT: ------------------------------------------- 100 Kilo Samples/sec. (20 KHz)
--------------- (Second Generation design with 10 bit ADCs, 20 Mega Samples/sec.)
NUMBER CHANNELS: -------------------------------------------- 2 (+ 1 Trigger Channel)
NUMBER OF HORIZ. SAMPLES: -(PDA version) ------------------------- 160 to 240
VERT. SENSITIVITY RANGE: --------------------------- (2mV*) 20mV/div. to 5V/div.
VERTICAL RESOLUTION: ------------------------------------------- 8/10 -- 8-bit default
VERTICAL GAIN ACCURACY: ------------------------------------------------------ 0.4%
TIME-BASE RANGE: ----------------------------------------------------- 2ns/div. - 5s/div.
TIME-BASE ACCURACY: ------------------------------------------------------------- 0.1%
MAX. TRIGGER FREQUENCY: ------------------------------------------------- 200 MHz
TRIGGER CONTROLS: ------- Channel A, External, Level, +/- Slope, Hold-off
POST TRIG. DELAY, (for WINDOWING): ------------------------- 0 to 90 Divisions
SPECIAL FEATURES: Time-Base Zoom Expansion (Dual Time-Base Windowing)
------------------------------ Anti-Aliasing Feature, (Incremental 10x Over-sampling),
--- Auto Calibration, Auto Setup, TDR function, Auto probe (switch/type) sensing.
POWER: PC-card-DSO 262a --------- 3V DC 100mA from Host or 2 AAA batteries
OPTIONAL ACCESSORY: --------- 1 MegOhm FET active-probe $50, *2mV/DIV
SOFTWARE: Standard: IVI foundation: - Palm computer software included.
Optional: Instrument driver DLL for G, C, C++, Visual Basic LabVIEW, VirtualBench
How about "The Other" PC-Card-DSO on the market?
The system architecture in the block diagram has been stable for a long time, but the previously considered large Xilinx chip became unnecessary. The micro-controller is now an 80-pin QFP Motorola MC68C912B32, which can also provide the parallel Springboard interface, as shown on the PCMCIA type 2 board, below the diagram. All components (larger than a 0.1uF capacitor) are on the topside, but an "actual" board might need some components placed on the reverse sides. Sub-blocks on the diagram and the components on the board are grouped in the same way. (Compare the block-diagram with the article on advanced Mixed-Signal design.)
The Motorola controller's native SPI link (250/500Kbytes/s) has also ample speed to update the display of a Palm computer (160x160) or a QVGA display at 30 traces a second. A more modern embedded processor chip, providing a native USB interface, would be ideal for nearly all-computing devices on the market, including all modern Notebook computers. (24 million units sold last year, growing at a 30% annual rate.)
For the programming I am using FORTH, because it's the only language I know sufficiently. Fortunately, "Forth" is available for the Palm OS, http://www.quartus.net/ and for the Motorola HC12 from http://www.newmicros.com/ and others. The majority of code is for the "user-control" and graphic display. User-controls are not high speed, but the high MIPS rating of the DragonBall in the Palm computer is needed for the display.
The following figure shows what the controls of the Palm-scope might look like if implemented on a conventional bench-top instrument. This will give some idea for the amount of programming involved.
Controls of the "Palm DSO", - implemented on a bench-top scope
Handheld DSOs by Fluke and Tek implement these controls with a keyboard of about 25 keys, but many engineers don't like it. The Palm-DSO can use its "Touch-Screen", operated with the stylus, with a Virtual-front-panel, transparent to waveforms.
Virtual Control Panel on the Palm Touch Screen simulates old fashion Benchtop scope.
The "Stylus" replaces the mouse of a Windows system, and touching a time or amplitude number makes a selection. The selected parameter then turns to bold lettering or reverses in color. While the Front panel graphics will temporary obscure the lower waveform (Channel B), changes on this waveform caused by changes in control can still be observed. Two of the four Palm's push buttons are assigned to toggle these "Channel Amplitude" and "Time and Trigger" control displays on and off, and the other two buttons are assigned for miscellaneous function displays. (Cursor movement, FFT etc., etc.) When the DSO program is turned off, assignment of the buttons reverses back to their original settings (PDA functions)
(The following is a sketch for the DSO controls only to illustrate the concept.)
Software Flow Description
Primary data flow in a DSO consists of blocks of (8 bit) numbers representing the amplitude of a waveform being digitized. In case of the Palm-DSO, the blocks would be 160 bytes long, or 320 for both channels. For the D2IS method, some memory for these blocks must also be available to the embedded micro-controller on the PC-Card, because a fast machine language algorithm is part of the digitizing process. Transmission of these blocks is the primary data-flow of the system. Flows of much less frequency consist of the command-strings from the Palm computer to the PC-Card. Because Engineers want "instant response" from their scopes, these command-strings have a maximum latency requirement. And while commands are only transmitted between data blocks (60 times a second), they still interrupt the D2IS digitizing process. Circuits and algorithm, however, are designed to handle this. A third type of transmission, even less frequent, are reports from the DSO controller back to the Palm computer relating the control-settings. This will only come into play for the automatic modes, or when probes are changed, or no trigger can be found and for the checkout procedures. The design for this part of the software is simple.
The Software is the Instrument
(Or how I ended up with a Software Defined Instrument, just to save hardware cost)
Most engineers I talked to believe that this line from James Truchard, CEO and Founder of National Instruments, is just a metaphor. --- Surprise, it's not! The novel architecture of this DSO has evolved by transforming more and more of the functions of a DSO into software. Originally to save hardware cost, which, of course, is a well-known concept of embedded system designs, but then something else happened. The architecture became extremely flexible, because the functioning of the system blocks was now predominantly "software-defined". (See: Equivalency for Hardware/Software)
Initially, my incentives were all the peripheral circuits included by Motorola into their HC11/12 type processor chips. E.g., like other chips, the HC11/12 has 8 channels for A/D conversion, but I had use for only two --- the low frequency real-time digitizers. Working on an early breadboard, I discovered that I could rapidly get a stable trigger by hanging a voltmeter on the output of the trigger circuit and adjusting the input-level for a symmetric output-swing. Here was a use for another two A/D channels detecting amplitude and approximate trigger frequency.
To get the necessary range of input attenuation for this DSO, the scope probes must have a 1 to 10 switch. If the "program" is not being told the switch setting, the V/Div display will be wrong. Remembering how the cheap game-controllers (joystick) for PCs work, I am now using a second resistor and switch contact in the probe and an A/D channel to get the indication. But the PC game-controllers are using "one" 8 bit A/D to sense up to 32 various switches --- and oscilloscopes can use many different probes. You might get the drift; the "program" can now distinguish between a dozen different probes. (Current probes, high-voltage, FET probes, optical probes, etc.) Trivial? Yes, but if we don't count the cost of the resistor, it's for free, and the "other" scope manufacturers either don't provide this, or charge you a mint. This kind of "serendipity" repeated itself in other parts of the system. When I added a D/A converter to the time-base for the Zoom feature (a ten-time expansion of the trace at a cursor point, see picture on first page.), I found that the same circuit could now also do the "Anti Aliasing" feature --- the time-base was truly "software defined"!
The real interesting part of this "Software Defined" design started when I began to use a software algorithm for the digitizing process itself and for the time-base operation. (With the ancient HC11/12, I needed to drop into machine code, but still could use more speed.) The flexibility that this design-step provides is incredible! I still have not yet discovered all advantages and uses of it. Any kind of digitizing algorithm can be implemented; the time-base can go forwards, backwards or sideways. It can jump over areas or zero-in on them with high-resolution sampling.
For a long time, for instance, I was "stuck", believing that the concept of D2IS needed a byte of RAM for every sample displayed on the scope screen. Then it came to me that I could do long traces for PC type computers with less Ram by dividing these into two or more groups; such as odd and even, with only minor change in the time-base algorithm. I had been <thinking-inside-the-box> all these years, but with the concept of "Software-Defined" design the box became much wider. Will we ever get outside the box? No, we will just be thinking in bigger boxes. ------ Back to Index