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 sensational performance versus cost claims, you have come across a technical fraud, think again. Because this means 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 designs 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 "
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
VERTICAL RESOLUTION: ------------------------------------------- 8/10 -- 8-bit default
VERTICAL GAIN ACCURACY: ------------------------------------------------------ 0.4%
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?
System
Block Diagram
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 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, "
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 Bench top 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”
--- a quote by James Truchard
(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". ( 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 it’s basically 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. 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 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 have bigger boxes.