Daqarta for DOS Contents



Contact Us
Daqarta for DOS
Data AcQuisition And Real-Time Analysis
Shareware for Legacy Systems

From the Daqarta for DOS Help system:



After a previously-stored trace has been recalled from memory or loaded from a file, this menu will be shown in place of the original ADC Board menu in response to the CTRL-Board option. It reports on the data size and format, the board model name, and the time and date of the trace. This is not really a "control" menu, although there are controls for the time and date formats.

If the trace was recorded with the Virtual Source instead of an ADC board, then CTRL-Board will show the Virtual Source menu with its original parameter settings. The Trace Info menu can still be seen as an alternate menu page via the CTRL-Pg keys. This will also work during Live operation with the Virtual Source.

Trace Bits:

This shows the number of bits used to represent the data. For the Virtual Source, it is just a copy of the Bits value set by that menu, from 1 through 16. For a real ADC board, there may also be extra information regarding the data format, shown as a prefix before the bits value:

 HI 12  Indicates a 12-bit data format, where the data
        bits occupy the upper 12 bits of a 16-bit word.

 LO 12  The lower 12 bits of the 16-bit word are used.

 -      Indicates that the polarity of the data was
        inverted by the ADC board.  Daqarta traces
        always show the true polarity, so this just
        indicates that correction was required.

 +      Indicates that the data range was unipolar (all
        positive).  Since Daqarta shows waveforms with
        a bipolar Y-axis, the entire wave will appear
        above the 0-line.

The Bits value reflects the data format of the board used to collect the trace data, and is the same as the format used to store DDisk data files. OutDt files and trace memory always use 16-bit data for single waveforms and FFTs (which are stored as waves), 32-bit data for waveform averages, and 48-bit data for FFT averages.

Trace Format:

The data Format will show either 'Offset' or '2s Cmp', indicating one of the two ways that are commonly used to represent both positive and negative values using integer binary data.

Binary (base-2) numbers, which are what the CPU works with at its most basic level, are made up of only 2 different symbols: 0 and 1. These are called "bits" (BInary digiTs), analogous to the 0 through 9 digits we use with our decimal (base-10) number system. The 0 and 1 values are represented by voltages that are either off or on, respectively.

With only digits 0 through 9, the base-10 system can encode larger values by stringing digits together. Each digit column in a number is 10 times the one to its right, where 10 is the "base" of the decimal number system. Similarly, in the binary system, larger numbers are made by using more bit columns, with each bit column being 2 times the one to its right... the base of the binary number system.

But what about negative values? With the decimal system, we just use a special symbol (+ or - sign) along with the usual digits 0 through 9. However, the binary system as used by the computer doesn't have any "symbols" other than off or on. Hence, various schemes have been used to represent signed numbers.

The simplest method that first springs to mind is to just reserve an extra bit in front of the binary number to indicate its sign, such as 0 for positive and 1 for negative. But it turns out that this "sign-magnitude" system is not the most efficient when it comes to actually using the values, such as adding and subtracting them, since special handling of the sign bit is required by the CPU. Two other schemes have thus come to dominate the data acquisition field:

Offset Binary:

This just adds an "offset" value to voltages before they reach a simple unipolar ADC. If the intrinsic ADC range is 0 to 10 Volts, for instance, then all incoming voltages could have 5 Volts added to them and the overall bipolar range would become -5 to +5 Volts. For an 8-bit ADC, when the board input is -5 Volts the actual chip thus sees 0 Volts and hence produces a digital output of 0 (binary 00000000). When the board input is +5 V, the chip sees +10 V and produces its maximum output of 255 (binary 11111111). When the board input is 0, the ADC sees +5 and produces its midscale value of 128 (binary 10000000).

The astute observer may notice that 128 is not the EXACT center of the 0 to 255 range... 127.5 would be the exact center. But since the binary number system always gives an even number of values for any given number of bits, there is no way to have positive and negative symmetry about 0. By convention, the negative side is made one count larger.

For boards with more bits of resolution, the offset idea is just extended such that 0 Volts is still the midscale value of the range. On a 12-bit board, for example, the ADC can produce values from 0 to 4097, so a 0 Volt input produces a midscale value of 2048 at the output.

Offset binary is the standard data format for 8-bit .WAV files, and is used by all 8-bit sound cards. It is also fairly common among 12-bit and even 16-bit laboratory-type boards.

Two's Complement:

Compared to the above Offset data format, this might be thought of as "Rolled". Imagine that we take the range of binary numbers from 0 (00000000) to 255 (11111111) and put them on a big drum, viewing them one at a time through a readout window. If we roll the drum one way we see higher values, and if we roll it the other way we see lower values. Now suppose we roll it past 0: We would see the highest value of 255, and as we continued to roll that way the values would count down from there.

               ...                         ...
          3           .               3           .
       2                .          2                .
      1                  .        1                  .
 -->  0         .        .   ==   0         .        .
      255                .        -1                 .
       254              .          -2               .
         253          .              -3           .
               ...                         ...

The Two's Complement system thus uses 255 to represent -1, 254 for -2, and so on down to 128 for -128. In the positive direction, the numbers run normally from 1 to 127. It turns out that this is the native system used by the CPU, and is very efficient for computations.

If the ADC can produce values with this format, they require no conversion before the CPU can handle them. Values in the Offset Binary system, on the other hand, must have the offset value added to them before use. The Two's Complement format is thus preferable, and is the standard format for 16-bit .WAV files and all 16-bit sound cards. Many laboratory-style boards use the Offset Binary system, however, even for 16-bit models.

Note that Daqarta DDisk files nominally use the .WAV format, but they retain the native data format of the ADC board in order to avoid the speed penalty of converting formats on-the-fly. Thus, if you record with a laboratory-type board and try to view the file with a standard .WAV file viewer, you may get very strange results!

Daqarta files created with OutDt use the Two's Complement format, but only instantaneous (non-averaged) files will have 16-bit data... averaged files use 32 bits or more. Even though these large data widths fully adhere to the standard .WAV file format, most other viewers expect only the 8- or 16-bit data from sound cards and thus aren't prepared to handle these.

Board Model:

This is the model of ADC board that collected the trace, as determined by the ADC driver. Your actual board model may be somewhat different, especially if it is a "clone" of a popular model, or a minor variant that does not affect how Daqarta interacts with it.

Trace Date:

This is the date the original trace was collected. Two date formats are supported, and you may toggle between them at any time:

    US-style:       Month-Day-Year  (M-D-Y)
    Euro-Style:     Day-Month-Year  (D-M-Y)

The format selected here is also used for EdSav log file entries. There will be no indication in the entry as to which format is used, so it's probably wise to standardize on one and set it from an auto-initialization Key Macro.

Although only the last 2 digits of the year are shown in both the Trace Info menu and the log file entry, the Daqarta system will keep track of the correct date until the year 2099... please try to have your most important work done before then.

Trace Time:

The time the original trace was collected. You may toggle between 24 hour and 12 hour formats at any time. If you select 12 hour, an AM or PM notation will appear on the Time line.

The format selected here is also used for EdSav log file entries. For 12 hour format, the AM/PM is indicated by a lower-case 'a' or 'p' after the normal log file time entry, as in:

    11:22:33a  08-09-97

If the Virtual Source is Live, each time you bring up the Trace Info menu (via CTRL-Pg from the Virtual Source menu), the Time and Date displays will be updated. They will not continue to "keep time" if you leave this menu displayed, but you could use CTRL-Pg as a crude time check.

Daqarta disables the normal system timer to prevent its interrupts from interfering with critical data acquisition tasks. So Daqarta uses the CMOS Real-Time Clock to obtain the trace time and to update the system time before writing files or Quitting. On an old PC/XT system, or a newer system with a defective Real-Time Clock (due to a bad battery, for example), Daqarta will instead add one minute to the previous time, advancing the date as needed. This insures that you can at least tell the order of acquisition, in case it's not obvious from the file name sequence.

Note that although DOS only stores file times in even seconds, (and usually only displays file times to the nearest minute), Daqarta file and trace times are maintained to 1-second accuracy (the limit of the Real-Time Clock). This information is stored in the Daqarta file header for display here, and may thus differ from the apparent DOS time.


Questions? Comments? Contact us!

We respond to ALL inquiries, typically within 24 hrs.
25 Years of Innovative Instrumentation
© Copyright 1999 - 2006 by Interstellar Research