`
`FOR USE WITH A PERSONAL COMPUTER
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001)
`
`This application is a continuation of application Ser. No. 111467,073, filed August
`
`24, 2006, which is a continuation of application Ser. No. 11/078,778, filed March 11, 2005, now
`
`expressly abandoned, which is a continuation of application Ser. No. 10/219,105, filed August
`
`15, 2002, now Pat. No. 6,895,449, which is a divisional of application Ser. No. 09/331,002, filed
`
`Jun. 14, 1999, now Pat. No. 6,470,399.
`
`FIELD OF THE INVENTION
`
`[0002)
`
`The present invention relates to the transfer of data and in particular to interface
`
`devices for communication between a computer or host device and a data transmit/receive device
`
`from which data is to be acquired or with which two-way communication is to take place.
`
`BACKGROUND OF THE INVENTION
`
`[0003)
`
`Existing data acquisition systems for computers are very limited in their areas of
`
`application. Generally such systems can be classified into two groups.
`
`[0004]
`
`In the first group host devices or computer systems are attached by means of an
`
`interface to a device whose data is to be acquired. The interfaces of this group are normally
`
`standard interfaces which, with specific driver software, can be used with a variety of host
`
`systems. An advantage of such interfaces is that they are largely independent of the host device.
`
`However, a disadvantage is that they generally require very sophisticated drivers which are prone
`
`1
`
`Apple 1067
`U.S. Pat. 8,504,746
`
`
`
`to malfunction and which limit data transfer rates between the device connected to the interface
`
`and the host device and vice versa. Further, it is often very difficult to implement such interfaces
`
`for portable systems and they offer few possibilities for adaptation with the result that such
`
`systems offer little flexibility.
`
`[0005]
`
`The devices from which data is to be acquired cover the entire electrical
`
`engineering spectrum. In a typical case, it is assumed that a customer who operates, for example,
`
`a diagnostic radiology system in a medical engineering environment reports a fault. A field
`
`service technician of the system manufacturer visits the customer and reads system log files
`
`generated by the diagnostic radiology system by means a portable computer or laptop for
`
`example. If the fault cannot be localized or if the fault is intermittent, it will be necessary for the
`
`service technician to read not only an error log file but also data from current operation. It is
`
`apparent that in this case fast data transfer and rapid data analysis are necessary.
`
`[0006]
`
`Another case requiring the use of an interface could be, for example, when an
`
`electronic measuring device, e.g. a multimeter, is attached to a computer system to transfer the
`
`data measured by the multimeter to the computer. Particularly when long-term measurements or
`
`large volumes of data are involved is it necessary for the interface to support a high data transfer
`
`rate.
`
`[0007]
`
`From these randomly chosen examples it can be seen that an interface may be put
`
`to totally different uses.
`
`It is therefore desirable that an interface be sufficiently flexible to
`
`permit attachment of very different electrical or electronic systems to a host device by means of
`
`the interface. To prevent operator error, it is also desirable that a service technician is not
`
`required to operate different interfaces in different ways for different applications but that, if
`
`2
`
`
`
`possible, a universal method of operating the interface be provided for a large number of
`
`applications.
`
`[0008]
`
`To increase the data transfer rates across an interface, the route chosen in the
`
`second group of data acquisition systems for the interface devices was to specifically match the
`
`interface very closely to individual host systems or computer systems. The advantage of this
`
`solution is that high data transfer rates are possible. However, a disadvantage is that the drivers
`
`for the interfaces of the second group are very closely matched to a single host system with the
`
`result that they generally cannot be used with other host systems or their use is very ineffective.
`
`Further, such types of interface have the disadvantage that they must be installed inside the
`
`computer casing to achieve maximum data transfer rates as they access the internal host bus
`
`system. They are therefore generally not suitable for portable host systems in the form of laptops
`
`whose minimum possible size leaves little internal space to plug in an interface card.
`
`[0009]
`
`A solution to this problem is offered by the interface devices of IOtech (business
`
`address: 25971 Cannon Road, Cleveland, Ohio 44146, USA) which are suitable for laptops such
`
`as the WaveBook/512 (registered trademark). The interface devices are connected by means of a
`
`plug-in card, approximately the size of a credit card, to the PCMCIA interface which is now a
`
`standard feature in laptops. The plug-in card converts the PCMCIA interface into an interface
`
`known in the art as IEEE 1284. The said plug-in card provides a special printer interface which
`
`is enhanced as regards the data transfer rate and delivers a data transfer rate of approximately 2
`
`MBps as compared with a rate of approx. 1 MBps for known printer interfaces. The known
`
`interface device generally consists of a driver component, a digital signal processor, a buffer and
`
`a hardware module which terminates in a connector to which the device whose data is to be
`
`acquired is attached. The driver component is attached directly to the enhanced printer interface
`
`3
`
`
`
`thus permitting the known interface device to establish a connection between a computer and the
`
`device whose data is to be acquired.
`
`[0010]
`
`In order to work with the said interface, an interface-specific driver must be
`
`installed on the host device so that the host device can communicate with the digital signal
`
`processor of the interface card. As described above, the driver must be installed on the host
`
`device. If the driver is a driver developed specifically for the host device, a high data transfer
`
`rate is achieved but the driver cannot be easily installed on a different host system. However, if
`
`the driver is a general driver which is as flexible as possible and which can be used on many host
`
`devices, compromises must be accepted with regard to the data transfer rate.
`
`[0011]
`
`Particularly in an application for multi-tasking systems in which several different
`
`tasks such as data acquisition, data display and editing are to be performed quasi-simultaneously,
`
`each task is normally assigned a certain priority by the host system. A driver supporting a
`
`special task requests the central processing system of the host device for processor resources in
`
`order to perform its task. Depending on the particular priority assignment method and on the
`
`driver implementation, a particular share of processor resources is assigned to a special task in
`
`particular time slots. Conflicts arise if one or more drivers are implemented in such a way that
`
`they have the highest priority by default, i.e. they are incompatible, as happens in practice in
`
`many applications. It may occur that both drivers are set to highest priority which, in the worst
`
`case, can result in a system crash.
`
`[0012]
`
`EP 0685799 Al discloses an interface by means of which several peripheral
`
`devices can be attached to a bus. An interface is connected between the bus of a host device and
`
`various peripheral devices. The interface comprises a finite state machine and several branches
`
`each of which is assigned to a peripheral device. Each branch comprises a data manager, cycle
`
`4
`
`
`
`control, user logic and a buffer. This known interface device provides optimal matching between
`
`a host device and a specific peripheral device.
`
`[0013]
`
`The specialist publication IBM Technical Disclosure Bulletin, Vol. 38, No. 05,
`
`page 245; "Communication Method between Devices through FDD Interface" discloses an
`
`interface which connects a host device to a peripheral device via a floppy disk drive interface.
`
`The interface consists in particular of an address generator, an MFM encoder/decoder, a
`
`serial/parallel adapter and a format signal generator. The interface makes it possible to attach not
`
`only a floppy disk drive but also a further peripheral device to the FDD host controller of a host
`
`device. The host device assumes that a floppy disk drive is always attached to its floppy disk
`
`drive controller and communication is initiated ifthe address is correct. However, this document
`
`contains no information as to how communication should be possible if the interface is
`
`connected to a multi-purpose interface instead of to a floppy disk drive controller.
`
`SUMMARY OF THE INVENTION
`
`[0014]
`
`It is the object of the present invention to provide an interface device for
`
`communication between a host device and a data transmit/receive device whose use is host
`
`device-independent and which delivers a high data transfer rate.
`
`[0015]
`
`The present invention is based on the finding that both a high data transfer rate
`
`and host device-independent use can be achieved if a driver for an input/output device customary
`
`in a host device, normally present in most commercially available host devices, is utilized.
`
`Drivers for input/output devices customary in a host device which are found in practically all
`
`host devices are, for example, drivers for hard disks, for graphics devices or for printer devices.
`
`As however the hard disk interfaces in common host devices which can be, for example, IBM
`
`5
`
`
`
`PCs, IBM-compatible PCs, Commodore PCs, Apple computers or even workstations, are the
`
`interfaces with the highest data transfer rate, the hard disk driver is utilized in the preferred
`
`embodiment of the interface device of the present invention. Drivers for other storage devices
`
`such as floppy disk drives, CD-ROM drives or tape drives could also be utilized in order to
`
`implement the interface device according to the present invention.
`
`[0016]
`
`As described in the following, the interface device according to the present
`
`invention is to be attached to a host device by means of a multi-purpose interface of the host
`
`device which can be implemented, for example, as an SCSI interface or as an enhanced printer
`
`interface. Multi-purpose interfaces comprise both an interface card and specific driver software
`
`for the interface card. The driver software can be designed so that it can replace the BIOS driver
`
`routines. Communication between the host device and the devices attached to the multi-purpose
`
`interface then essentially takes place by means of the specific driver software for the multi(cid:173)
`
`purpose interface and no longer primarily by means of BIOS routines of the host device.
`
`Recently however drivers for multi-purpose interfaces can also already be integrated in the BIOS
`
`system of the host device as, alongside classical input/output interfaces, multi-purpose interfaces
`
`are becoming increasingly common in host devices. It is of course also possible to use BIOS
`
`routines in parallel with the specific driver software for the multi-purpose interface, if this is
`
`desired.
`
`[0017]
`
`The interface device according to the present invention comprises a processor
`
`means, a memory means, a first connecting device for interfacing the host device with the
`
`interface device, and a second connecting device for interfacing the interface device with the
`
`data transmit/receive device. The interface device is configured by the processor means and the
`
`memory means in such a way that the interface device, when receiving an inquiry from the host
`
`6
`
`
`
`device via the first connecting device as to the type of a device attached to the host device, sends
`
`a signal, regardless of the type of the data transmit/receive device, to the host device via the first
`
`connecting device which signals to the host device that it is communicating with an input/output
`
`device. The interface device according to the present invention therefore simulates, both in
`
`terms of hardware and software, the way in which a conventional input/output device functions,
`
`preferably that of a hard disk drive. As support for hard disks is implemented as standard in all
`
`commercially available host systems, the simulation of a hard disk, for example, can provide
`
`host device-independent use. The interface device according to the present invention therefore
`
`no longer communicates with the host device or computer by means of a specially designed
`
`driver but by means of a program which is present in the BIOS system (Basic Input/Output
`
`System) and is normally precisely matched to the specific computer system on which it is
`
`installed, or by means of a specific program for the multi-purpose interface. Consequently, the
`
`interface device according to the present invention combines the advantages of both groups. On
`
`the one hand, communication between the computer and the interface takes place by means of a
`
`host device-specific BIOS program or by means of a driver program which is matched to the
`
`multi-purpose interface and which could be regarded as a "device-specific driver". On the other
`
`hand, the BIOS program or a corresponding multi-purpose interface program which operates one
`
`of the common input/output interfaces in host systems is therefore present in all host systems so
`
`that the interface device according to the present invention is host device-independent.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0018]
`
`In the following, preferred embodiments of the present invention will be
`
`explained in more detail with reference to the drawings enclosed, in which:
`
`7
`
`
`
`[0019]
`
`FIG. 1 shows a general block diagram of the interface device according to the
`
`present invention; and
`
`[0020]
`
`FIG. 2 shows a detailed block diagram of an interface device according to a
`
`preferred embodiment of the present invention.
`
`DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
`
`[0021]
`
`It should be understood that the title of this section of this specification, namely,
`
`"Detailed Description Of The Invention", relates to a requirement of the United States Patent
`
`Office, and does not imply, nor should be inferred to limit the subject matter disclosed herein.
`
`[0022]
`
`FIG. 1 shows a general block diagram of an interface device 10 according to the
`
`present invention. A first connecting device 12 of the interface device 1 0 can be attached to a
`
`host device (not shown) via a host line 11. The first connecting device is attached both to a
`
`digital signal processor 13 and to a memory means 14. The digital signal processor 13 and the
`
`memory means 14 are also attached to a second connecting device 15 by means of bi-directional
`
`communication lines (shown for all lines by means of two directional arrows). The second
`
`connecting device can be attached by means of an output line 16 to a data transmit/receive device
`
`which is to receive data from the host device or from which data is to be read, i.e. acquired, and
`
`transferred to the host device. The data transmit/receive device itself can also communicate
`
`actively with the host device via the first and second connecting device, as described in more
`
`detail in the following.
`
`[0023]
`
`Communication between the host system or host device and the interface device is
`
`based on known standard access commands as supported by all known operating systems (e.g.
`
`DOS, Windows, Unix). Preferably, the interface device according to the present invention
`
`8
`
`
`
`simulates a hard disk with a root directory whose entries are "virtual" files which can be created
`
`for the most varied functions. When the host device system with which the interface device
`
`according to the present invention is connected is booted and a data transmit/receive device is
`
`also attached to the interface device 10, usual BIOS routines or multi-purpose interface programs
`
`issue an instruction, known by those skilled in the art as the INQUIRY instruction, to the
`
`input/output interfaces in the host device. The digital signal processor 13 receives this inquiry
`
`instruction via the first connecting device and generates a signal which is sent to the host device
`
`(not shown) again via the first connecting device 12 and the host line 11. This signal indicates to
`
`the host device that, for example, a hard disk drive is attached at the interface to which the
`
`INQUIRY instruction was sent. Optionally, the host device can send an instruction, known by
`
`those skilled in the art as "Test Unit Ready", to the interface device to request more precise
`
`details regarding the queried device.
`
`[0024]
`
`Regardless of which data transmit/receive device at the output line 16 is attached
`
`to the second connecting device, the digital signal processor 13 informs the host device that it is
`
`communicating with a hard disk drive. If the host device receives the response that a drive is
`
`present, it then sends a request to the interface device 10 to read the boot sequence which, on
`
`actual hard disks, normally resides on the first sectors of the disk. The digital signal processor
`
`13, whose operating system in stored in the memory means 14, responds to this instruction by
`
`sending to the host device a virtual boot sequence which, in the case of actual drives, includes
`
`the drive type, the starting position and the length of the file allocation table (FAT), the number
`
`of sectors, etc., known to those skilled in the art. Once the host device has received this data, it
`
`assumes that the interface device 1 0 according to a preferred embodiment of the present
`
`invention is a hard disk drive. In reply to an instruction from the host device to display the
`
`9
`
`
`
`directory of the "virtual" hard disk drive simulated by the interface device 10 with respect to the
`
`host device, the digital signal processor can respond to the host device in exactly the same way
`
`as a conventional hard disk would, namely by reading on request the file allocation table or FAT
`
`on a sector specified in the boot sequence, normally the first writable sector, and transferring it to
`
`the host device, and subsequently by transferring the directory structure of the virtual hard disk.
`
`Further, it is possible that the FAT is not read until immediately prior to reading or storing the
`
`data of the "virtual" hard disk and not already at initialization.
`
`[0025)
`
`In a preferred embodiment of the present invention, the digital signal processor
`
`13, which need not necessarily be implemented as a digital signal processor but may be any other
`
`kind of microprocessor, comprises a first and a second command interpreter. The first command
`
`interpreter carries out the steps described above whilst the second command interpreter carries
`
`out the read/write assignment to specific functions. If the user now wishes to read data from the
`
`data transmit/receive device via the line 16, the host device sends a command, for example "read
`
`file xy", to the interface device. As described above, the interface device appears to the host
`
`device as a hard disk. The second command interpreter of the digital signal processor now
`
`interprets the read command of the host processor as a data transfer command, by decoding
`
`whether "xy" denotes, for example, a "real-time input" file, a "configuration" file or an
`
`executable file, whereby the same begins to transfer data from the data transmit/receive device
`
`via the second connecting device to the first connecting device and via the line 11 to the host
`
`device.
`
`[0026]
`
`Preferably, the volume of data to be acquired by a data transmit/receive device is
`
`specified in a configuration file described in the following by the user specifying in the said
`
`configuration file that a measurement is to last, for example, five minutes. To the host device the
`
`10
`
`
`
`"real-time input" file then appears as a file whose length corresponds to the anticipated volume
`
`of data in those five minutes. Those skilled in the art know that communication between a
`
`processor and a hard disk consists of the processor transferring to the hard disk the numbers of
`
`the blocks or clusters or sectors whose contents it wishes to read. By reference to the FAT the
`
`processor knows which information is contained in which block. In this case, communication
`
`between the host device and the interface device according to the present invention therefore
`
`consists of the very fast transfer of block numbers and preferably of block number ranges
`
`because a virtual "real-time input" file will not be fragmented. If the host device now wants to
`
`read the "real-time input" file, it transfers a range of block numbers to the interface device,
`
`whereupon data commences to be received via the second connecting device and data
`
`commences to be sent to the host device via the first connecting device.
`
`[0027]
`
`In addition to the digital signal processor instruction memory, which comprises
`
`the operating system of the digital signal processor and can be implemented as an EPROM or
`
`EEPROM, the memory means 14 can have an additional buffer for purposes of synchronizing
`
`data transfer from the data transmit/receive device to the interface device 10 and data transfer
`
`from the interface device 1 0 to the host device.
`
`[0028]
`
`buffer.
`
`[0029]
`
`Preferably, the buffer is implemented as a fast random access memory or RAM
`
`Further, from the host device the user can also create a configuration file, whose
`
`entries automatically set and control various functions of the interface device 10, on the interface
`
`device 10 which appears to the host device as a hard disk. These settings can be, for example,
`
`gain, multiplex or sampling rate settings. By creating and editing a configuration file, normally a
`
`text file which is simple to understand with little prior knowledge, users of the interface device
`
`11
`
`
`
`1 0 are able to perform essentially identical operator actions for almost any data transmit/receive
`
`devices which can be attached to the second connecting device via the line 16, thus eliminating a
`
`source of error arising from users having to know many different command codes for different
`
`applications.
`
`In the case of the interface device 1 0 according to the present invention it is
`
`necessary for users to note the conventions of the configuration file once only in order to be able
`
`to use the interface device 10 as an interface between a host device and almost any data
`
`transmit/receive device.
`
`[0030]
`
`As a result of the option of storing any files in agreed formats in the memory
`
`means 14 of the interface device 10, taking into account the maximum capacity of the memory
`
`means, any enhancements or even completely new functions of the interface device 10 can be
`
`quickly implemented. Even files executable by the host device, such as batch files or executable
`
`files (BAT or EXE files), and also help files can be implemented in the interface device, thus
`
`achieving independence of the interface device 10 from any additional software (with the
`
`exception ofthe BIOS routines) of the host device. On the one hand, this avoids licensing and/or
`
`registration problems and, on the other hand, installation of certain routines which can be
`
`frequently used, for example an FFT routine to examine acquired time-domain data in the
`
`frequency domain, is rendered unnecessary as the EXE files are already installed on the interface
`
`device 10 and appear in the virtual root directory, by means of which the host device can access
`
`all programs stored on the interface device 10.
`
`[0031]
`
`In a preferred embodiment of the present invention in which the interface device
`
`1 0 simulates a hard disk to the host device, the interface device is automatically detected and
`
`readied for operation when the host system is powered up or booted. This corresponds to the
`
`plug-and-play standard which is currently finding increasingly widespread use. The user is no
`
`12
`
`
`
`longer responsible for installing the interface device 10 on the host device by means of specific
`
`drivers which must also be loaded; instead the interface device 10 is automatically readied for
`
`operation when the host system is booted.
`
`[0032]
`
`For persons skilled in the art it is however obvious that the interface device 10 is
`
`not necessarily signed on when the computer system is powered up but that a special BIOS
`
`routine or a driver for a multi-purpose interface can also be started on the host device during
`
`current operation of the computer system in order to sign on or mount the interface device 10 as
`
`an additional hard disk. This embodiment is suitable for larger workstation systems which are
`
`essentially never powered down as they perform, e.g. mail functions or monitor processes which
`
`run continuously, for example, in multi-tasking environments.
`
`[0033]
`
`In the interface device according to the present invention an enormous advantage
`
`is to be gained, as apparent in the embodiment described in the following, in separating the
`
`actual hardware required to attach the interface device 10 to the data transmit/receive device
`
`from the communication unit, which is implemented by the digital signal processor 13, the
`
`memory means 14 and the first connecting device 12, as this allows a plurality of dissimilar
`
`device types to be operated in parallel in identical manner. Accordingly, many interface devices
`
`10 can be connected to a host device which then sees many different "virtual" hard disks. In
`
`addition, any modification of the specific hardware symbolized by the second connecting device
`
`15 can be implemented essentially without changing the operation of the interface device
`
`according to the present invention. Further, an experienced user can intervene at any time on any
`
`level of the existing second connecting device by making use of the above mentioned option of
`
`creating a configuration file or adding or storing new program sections for the second connecting
`
`device.
`
`13
`
`
`
`[0034]
`
`An important advantage of the interface device 1 0 of the present invention is that
`
`it also permits extremely high data transfer rates by using, for data interchange, the host device(cid:173)
`
`own BIOS routines which are optimized for each host device by the host device manufacturer or
`
`BIOS system manufacturer, or by using driver programs which are normally optimized and
`
`included by the manufacturers of multi-purpose interfaces. Furthermore, due to the simulation of
`
`a virtual mass storage device, the data is managed and made available in such a way that it can
`
`be transferred directly to other storage media, e.g. to an actual hard disk of the host device
`
`without, as it were, intervention of the host device processor. The only limitation to long-term
`
`data transfer at high speed is therefore imposed exclusively by the speed and the size of the mass
`
`storage device of the host device. This is the case as the digital signal processor 13 already
`
`formats the data read by the data transmit/receive device via the second connecting device 15
`
`into block sizes suitable for a hard disk of the host device, whereby the data transfer speed is
`
`limited only by the mechanical latency of the hard disk system of the host device. At this point,
`
`it should be noted that normally data flow from a host device must be formatted in blocks to
`
`permit writing to a hard disk and subsequent reading from a hard disk, as known by those skilled
`
`in the art.
`
`[0035]
`
`The said data transfer rate can be increased further by setting up a direct memory
`
`access (DMA) or RAM drive in the host system. As those skilled in the art know, the setting up
`
`of a RAM drive requires processor resources of the host device, with the result that the
`
`advantage of writing the data to a hard disk drive of the host device essentially without the need
`
`for processor resources is lost.
`
`[0036]
`
`As described above, a data buffer can be implemented in the memory means 14 to
`
`permit independence in terms of time of the data transmit/receive device attached to the second
`
`14
`
`
`
`connecting device from the host device attached to the first connecting device. This guarantees
`
`error-free operation of the interface device 10 even for time-critical applications in multi-tasking
`
`host systems.
`
`[0037]
`
`FIG. 2 shows a detailed block diagram of an interface device 10 according to the
`
`present invention.
`
`[0038]
`
`A digital signal processor (DSP) 1300 is, in a manner of speaking, the heart of the
`
`interface device 10. The DSP can be any DSP but preferably has a 20-MB on-chip random
`
`access memory (RAM). Certain instruction sets, for example, can be stored in the RAM already
`
`integrated in the DSP. An 80-MHz clock generator is attached to the DSP 1300 in order to
`
`synchronize the DSP. The DSP implements a fast Fourier transformation (FFT) in real time and
`
`also optional data compression of the data to be transferred from the data transmit/receive device
`
`to the host device in order to achieve greater efficiency and to permit interoperation with host
`
`devices which have a smaller memory.
`
`[0039]
`
`In the preferred embodiment of the interface device 1 0 shown in FIG. 2, the first
`
`connecting device 12 of FIG. 1 contains the following components: an SCSI interface 1220 and a
`
`50-pin SCSI connector 1240 for attachment to an SCSI interface present on most host devices or
`
`laptops. The SCSI (small computer system interface) interface 1220 translates the data received
`
`via the SCSI connector 1240 into data understood by the DSP 1300, as known by those skilled in
`
`the art. Further, the first connecting device 12 comprises an EPP (enhanced parallel port) with a
`
`data transfer rate of approx. 1 MBps which delivers a more moderate data transfer rate of 1
`
`MBps by comparison to the data transfer rate of 10 MBps ofthe SCSI interface. The EPP 1260
`
`is connected to a 25-pin D-shell connector 1280 to permit attachment to a printer interface of a
`
`host device for example. Optionally, the first connecting device 12 also comprises a 25-pin
`
`15
`
`
`
`connector 1282 which permits the attachment of 8 digital outputs and 8 digital inputs 1284 at a
`
`host device.
`
`[0040]
`
`Preferably, the second connecting device comprises 8 BNC inputs with the
`
`calibration relay 1505, a block 1510 with 8 device amplifiers with an overvoltage protection of
`
`.+-.75 V, this block being connected in tum to 8 sample/hold (S&H) circuits 1515. The
`
`calibration relays are relays which permit controlled changeover between a test voltage and a
`
`calibration reference voltage. Each sample/hold circuit is connected to a corresponding input of
`
`an 8-channel multiplexer 1520 which feeds its output signals via a programmable amplifier 1525
`
`into an analog/digital converter (ADC) with 12 bit and 1.25 MHz 1530 and to the DSP 1300.
`
`The ADC 1530 is controlled by means of a 20-bit timer 1535, as known by persons skilled in the
`
`art. The programmable amplifier 1525 and the 8-channel multiplexer 1520 are controlled via an
`
`amplifier channel selection circuit 1540 which is in tum controlled by the DSP 1300.
`
`[0041]
`
`The complete interface device 10 is supplied with power by an external AC/DC
`
`converter 1800 which delivers a digital supply voltage of .+-.5 V and is attached to a DC/DC
`
`converter 1810 which can deliver analog supply voltages of. +-.5 V and . +-.15 V as required for
`
`the interface device 10. Further, the DC/DC converter controls a precision voltage reference
`
`1820 which controls the 8 BNC inputs 1505 and the ADC 1530 as well as a digital/analog
`
`converter (DAC) 1830 which permits, via an output amplifier block with 4 output amplifiers
`
`1840 and a 9-pin connector 1850, analog output direct from the DSP 1300 to an output device,
`
`e.g. printer device or monitor device, which can be attached via the 9-pin connector 1850, thus
`
`providing the option of monitoring the data transferred to the host device or also, for example, of
`
`viewing an FFT to obtain rapid and comprehensive data analysis without using processor time of
`
`the host device.
`
`16
`
`
`
`[0042]
`
`In FIG. 2 the memory means 14 of FIG. 1 is implemented by an EPROM 1400
`
`which, in a preferred embodiment of the present invention, contains the operating system of the
`
`digital signal processor 1300. A random access memory with an access time of 15 ns and a size
`
`of 512 KB or optionally 1024 KB 1420 serves as a