Data AcQuisition And Real-Time Analysis
Scope - Spectrum - Spectrogram - Signal Generator
Software for Windows
Science with your Sound Card!
The following is from the Daqarta Help system:



Spectrum Analyzer

Signal Generator

(Absolutely FREE!)


Pitch Tracker


DaqMusiq Generator
(Free Music... Forever!)

Engine Simulator

LCR Meter

Remote Operation

DC Measurements

True RMS Voltmeter

Sound Level Meter

Frequency Counter
    Spectral Event

    MHz Frequencies

Data Logger

Waveform Averager


Post-Stimulus Time
Histogram (PSTH)

THD Meter

IMD Meter

Precision Phase Meter

Pulse Meter

Macro System

Multi-Trace Arrays

Trigger Controls


Spectral Peak Track

Spectrum Limit Testing

Direct-to-Disk Recording



Frequency response

Distortion measurement

Speech and music

Microphone calibration

Loudspeaker test

Auditory phenomena

Musical instrument tuning

Animal sound

Evoked potentials

Rotating machinery


Product test

Contact us about
your application!

Data Logging


The LogTxt macro can be used together with a simple timer macro in a loop, or with a timed task in a multitasking setup, to produce a data log that consists of a timed series of data samples. Each line in the file can be anything you want, typically a time-stamp (including date, if desired) plus one or more values recorded at that time. The interval between samples can typically be from less than a tenth of a second, up to hours or days... or even longer.

LogTxt can use string variables, so you can record values that don't otherwise appear on a Daqarta trace, such as Freq to read the Frequency Counter, Volts for the Voltmeter, or SPL for the Sound Level Meter.

You can use DeltY to read the Delta difference or Sigma energy between two cursors.

In Spectrum Peak Track mode you can use Curs to read the frequency of the largest peak, and CursY to read its magnitude.

Normal Daqarta control variables (like ToneFreq or TrigLevel), as well as macro variables (fixed-point Var0-Z or floating-point A-Z), are automatically converted to string variables by the LogTxt command, using the number format you specify.

The basic approach is to first create a macro that waits for a specified interval or time using WaitSecs, WaitTime, or WaitCyclic, after which it uses LogTxt to send a line of data to the log file. Then, you invoke that macro in a loop set for the desired number of samples.

For example, let's say you want to record Frequency Counter readings every second. You'd first use the Macro New button to open the Macro Edit dialog, and define a macro called (say) _ReadFreq that waits one second, then gives a LogTxt command that includes a new line (n) plus the frequency (Freq), padding to column 20 (p20), and the time (t):

    WaitSecs=1                 ;Wait 1 second
    LogTxt=n + Freq + p20 + t  ;Record Freq, plus time at col 20

Then if you want to record for (say) one hour, you can call this in a loop with:


The WaitSecs timer is fine for this application, because the LogTxt command is very fast. But suppose instead you want each entry to be the Sigma energy in a certain frequency region at the end of a long Spectrum Average. You want to take readings every minute, but the average may take up a significant fraction of that minute.

Since WaitSecs is just a delay, setting WaitSecs=1 would mean the actual time between readings would be 1 second plus the time needed for the average. Instead, use WaitTime=@H:M:00 to specify every minute, on the minute. Alternatively, you could use WaitCyclic0=1:00 to specify once per minute, starting from whenever the command is received.

Often, you may not know the total time you want the recording to run. In that case, set the loop count to a really large value; setting @_ReadFreq=5G in the above example will limit to 2^32 - 1 loops, which at 1 second each will run for more than 136 years.

Then just hit Cancel in the Macro Dialog whenever you want to end the recording. If you are using Remote Control to run the loop, hit the Cancel button in DqaDlg, or send a Cancel message (0x100) from your own custom program.

Note that Freq (Frequency Counter), SPL (Sound Level Meter), and Volts (Voltmeter) readouts are never updated faster than once per 100 msec.

The Frequency Counter update rate may be further slowed by the Slow setting of the counter and the Frequency Counter Slow Interval in the Edit - Run Preferences dialog.

Similarly, the Sound Level Meter readings are affected by the Response Time and Peak TC settings, while the Voltmeter is likewise affected by its Time Constant (TC) setting.

However, the cursor readouts are updated much faster (depending on the Trace Update Interval), so you may want to look at equivalents to the above if higher speed is required. You can use Spectrum Cursor Track along with Peak mode to get a good estimate of a changing frequency. (It won't be as accurate as the Frequency Counter for a stable or slowly-changing frequency.) You would use the Curs string variable to monitor the tracked frequency.

To get faster SPL readings, set the solid and dotted cursors to opposite ends of the spectrum and select the Sigma readout mode instead of the default Delta. Use the Spectrum Curves Dialog to set the desired weighting curve, which is the same dialog invoked by the Weighting Curve button in the Sound Level Meter. For accurate SPL readings, you will need all the same calibration steps as discussed for the Sound Level Meter. Then use the DeltY string variable to monitor SPL.

For faster RMS Volts readings than the Voltmeter, you can also use DeltY with Sigma in the waveform display mode, again with cursors at opposite ends of the waveform.

See the Custom Frequency Counter Mini-App to get started with a multitasking setup that displays multiple computed values (present, high, low, and average) and can easily be modified to log these or other values.

Remote Control Tips:

You may want your remote program to continuously monitor current data values. One way to do this is to have the remote program do the timing, and then issue the desired LogTxt command at the proper time. When the "success" notification for the command arrives, you can read the file to get the latest data.

The most recent values will be at the end of the file. To determine where to start reading, your program can keep track of the previous file end pointer.

Alternatively, if the timing is done from within Daqarta as discussed above, there will be no "success" notification since the macro doesn't end after the LogTxt write, but goes back to wait for the next update.

Daqarta enables file sharing for reading the log file, so in principle the remote program could just read it whenever it wants an update, asynchronously with the LogTxt. If the program keeps track of the file end, it will know whether there is new data at the time it looks for an update.

But you can easily add synchronization by having the data logger send a message with the value of a fixed-point Var0-Z macro variable after every LogTxt update. For example, VarA=>> will send a WM_USER message with 'VarA' in wParam as an identifier, and the integer portion of VarA in lParam. (VarA=>* sends the fractional part, with 'varA' in wParam.)

Your program can ignore the actual value, and just use the receipt of the message to indicate that a LogTxt update has been sent. But the macro can just as easily increment the value each time, so the remote program can use it as a sample counter.

See also Macro Overview


Questions? Comments? Contact us!

We respond to ALL inquiries, typically within 24 hrs.
Over 30 Years of Innovative Instrumentation
© Copyright 2007 - 2017 by Interstellar Research
All rights reserved