Data AcQuisition And Real-Time AnalysisScope - Spectrum - Spectrogram - Signal Generator
Software for Windows
Science with your Sound Card!
Contact us about
The LogTxt macro can be used together with a timer macro in a loop 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.
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.
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.
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 - 2013 by Interstellar Research
All rights reserved