Daqarta for DOS Contents
For a board that doesn't have a pacer timer that can signal when each sample is ready, a slightly different method is to have a main system timer generate the interrupt signal at the required sample rate. The interrupt handler does everything as before, but in addition it must explicitly start each sample conversion, and wait until it is done to read the data. For a nominal 100 kHz board which takes 10 µsec for a conversion, we would thus need to wait those 10 µsec in addition to the interrupt overhead. Only a fast machine with low overhead could approach the board's rated 100 kHz sample rate.
A trick can be used with this type of board to restore some performance on slower systems: By using a staggered operation, each interrupt reads data from a conversion started at the end of the previous interrupt. Now the time formerly spent waiting for the conversion to finish is rolled into the time between interrupts. The data is not really from the instant in time that we "thought it was", but once the process is begun it doesn't matter.
Although interrupts are the slowest method to move data, they can still be the best or only choice when greater flexibility is needed. That's because once an interrupt handler becomes active, it can do anything at all... not just acquire data. This allows boards to acquire data and generate stimulus outputs simultaneously, without having special dedicated hardware like dual DMA access or on-board output buffers. Since the vast majority of laboratory-type boards that have DMA don't have this fancier stuff, they may still need interrupt-driven operation for stimulus generation.
Boards that support DMA will usually give the best RTime results on machines with 386 processors or higher, and on old XTs (8088 processors). Many machines with 286 processors (and maybe some early 386's as well) suffer from a design quirk wherein the DMA channel runs at HALF the CPU speed... in fact, a PC or XT at 4.77 MHz has better DMA performance than a 286 AT at 6 MHz, since the AT is really a 3 MHz machine as far as DMA is concerned. In these machines a "deep FIFO" board is best.
Some boards running in DMA mode insist upon generating an interrupt after a selectable number of samples, even when it is not required by Daqarta. You will thus need to designate an IRQ number using the I:n parameter, even though the board is using DMA transfers for acquisition. Daqarta typically sets this number of samples as high as possible (65536 for 8-bit data or 32768 for 12- or 16-bit data), so there is little time lost processing the do-nothing interrupt.
sample rate, while the program sucks old samples from the other end as needed. Typically, an interrupt is generated when the pipe is half full, signalling the program to pull those samples out as fast as possible. There may be some extra samples stuffed in during the interrupt overhead and the draining time, so by starting when the pipe is half full there is plenty of safety factor. After the samples are transferred to a system memory buffer, the program is free to do other things (like process data) until the next interrupt. As long as the AVERAGE rates of filling and draining the FIFO pipe are equal, it doesn't matter that the filling is regular and the draining is in bursts.
The FIFO system shares features with both DMA and interrupt systems. It's as though the board has its own little DMA system continuously filling the FIFO instead of system memory. The program transfers data from FIFO to system memory in interrupt-driven bursts of many samples, instead of one at a time as in interrupt-only systems. In this way the interrupt overhead is spread among many samples, reducing the average overhead and allowing faster operation than one interrupt per sample. On those 286 machines with slow DMA, this can even be faster than DMA, especially since block transfers can be used which are faster than single-sample transfers. However, this is only effective if the FIFO pipe is long ("deep") enough to bring the average overhead down substantially... not true on every board that claims FIFO operation.
Sequential operation, the time to process the data and update the display is independent of the sample rate. At high sample rates, the time to acquire the data is small so the overall cycle time between screen updates is very fast. As sample rates get slower and slower, the acquisition time tends to dominate the overall cycle, which can never be faster than the acquisition. So, for example, if you acquire 512 samples at 5 kHz (200 µsec per sample), it takes 0.1024 sec just to get the data. You will thus get just under 10 screen updates per second... still a comfortable update rate. But if you sample instead at 500 Hz, it will take over 1 second between updates, which...makes...for...an...annoyingly...slow...display.
RTime mode will have this same low update rate at low sample rates only in Triggered operation. In Free-run, however, there will just be a LOT of overlap, and the update rate will still be blazingly fast. RTime is thus definitely the way to run in FFT modes at slow sample rates.
At very high sample rates, the tables may turn. As sample rates go up, the ongoing RTime acquisition steals more frequent time slices from the update process. Eventually the screen updates become noticeably slow, as the GAP values soar... you may be sampling enough data points for hundreds of sweeps per second, but that very sampling is preventing you from getting more than a few!
This is normally only a problem if your board is using interrupt-driven sampling, since the time slices are bigger than for DMA, and more frequent than for FIFO. Stimulus generation on these boards compounds the problem because it must also transfer output samples from memory to the board, adding still more to the length of each slice.
So at high sample rates, Sequential mode may be better. However, if your experiment requires continuous background stimulus generation (an ongoing tone, for instance, instead of one tone burst per sweep), then you are stuck with RTime mode.
Sequential mode, a key that comes during acquisition causes an immediate exit of that sweep and skips the processing and screen update. This gives fast key response at all times, even if the sample rate is very slow.
In RTime mode, high sample rates that cause the overall screen update rate to slow down will cause the keyboard response to lag as well, since no action is taken on the key until the current trace is updated. Daqarta only stores one key request at a time, so at high RTime sample rates you may need to type slowly so that each key can be recognized before it is overwritten by the next.
Questions? Comments? Contact us!We respond to ALL inquiries, typically within 24 hrs.
25 Years of Innovative Instrumentation
© Copyright 1999 - 2006 by Interstellar Research