garv_manual(ERP7) manual page

Name

garv_manual - Garv User’s Manual (ERP manuals)

Artifact rejection in the continuous data system is performed by creating an artifact rejection parameter file, calibrating it with garv, and including it when running avg(1) . This document is on the creation, meaning, and calibration of these arf (artifact rejection function) files and the use of garv.

General Considerations Artifact rejection is a problem of signal detection. Various signal parameters are measured and then used to determine whether or not to retain the trial for averaging. These signal parameters may be associated with artifacts which one desires to reject, but this correlation need not be perfect. As an example, consider trying to reject blocking which can occur at the polygraph or another intermediate stage of data processing (recording on analog tape, transmission over cables with noise or shorts, etc.). It is not necessarily the case that blocking results in a stretch of data which numerically corresponds to the largest A/D value possible, since the blocking can occur at the polygraph or analog recorder, etc. Nor is it the case that a stretch of bona fide blocked data will even be the same numerical value because of crosstalk and low level noise injected at stages subsequent to the blocking. Clearly, rejection of blocking will be difficult, at best. Artifact rejection is most effective when the number of sums is low. This arises from the vanishing contribution of noise to a particular average when sums are large, as well as empirical studies. The conclusion: there is no substitute for good data. It is folly to believe that artifact rejection is going to transform bad data to good data; it can reject occasional artifactual trials allowing good data to be better. In other words, data that are consistently noisy or have systematic artifacts are not going to be improved by artifact rejection. It is not possible to give any hard and fast rules about what artifact rejection routines one should use, or what signal parameter values are acceptable. This is because the actual amplitude of the signals can vary depending on the gain of the polygraph, the tape recorder (if employed), and any other interposed signal processors. Furthermore, the actual morphology of the EEG is dependent on not only the subject and the subject’s state, but also the sampling rate and the setting of any filters, etc. Currently the only way to perform accurate artifact rejection is to empirically try various A.R. functions on the data and evaluate their performance by visually assessing the type of trials that they will reject. Fine tuning can be accomplished by repeatedly averaging the data with different arf files and comparing the resulting averages.

Using Artifact Rejection with avg

Artifact rejection is most effectively employed when one has a general overview of the mechanisms and algorithms involved in the procedure. The basic algorithm employed when artifact rejection is included in averaging is as follows: After each raw epoch is in memory, artifact rejection tests are applied to the data starting with the first test in the arf file. The value resulting from the specified algorithm on the specified channel between the latencies desired is compared to the threshold for that test. If the threshold is exceeded, the data fail that test, otherwise they pass. If the data pass the first test, the second is applied. This continues until the data don’t pass a test, or pass all. If all are passed, the trial is added to the accumulating sum for all bins specified in the binlist file. Application of tests terminates upon the first failure. This reduces the processing required, and simplifies rejection accounting. Counts of rejects are kept in 7 user named count variables (also termed rejection count bins). Each time a test fails, the count variable associated with that test is incremented. This self-terminating procedure has a number of ramifications. One is that the order of the specified tests influences the resulting rejection counts. This arises from the correlated nature of most A.R. functions. For example, consider an arf file containing a ppa (Peak to Peak Amplitude) and an rms (Root Mean Square) test. If the first test is ppa, epochs which would fail both ppa and rms are counted as ppa rejects, while if rms had been first, they would be counted as rms rejects. Similarly, addition of another test to the arf file will alter the distribution of counts in the various bins unless it is placed at the end of the extant functions. In other words, unless an additional test is appended to the arf file, one will not see a simple increase in rejects on the basis of the added test, since tests occurring after the new function in the arf file will not be applied to data not passing the added test.

Contents of an arf File Here is an example of a simple arf (artifact rejection function) file, as used by avg(1) and garv, with the columns labelled:

func.   desc.   chan    latlo   lathi   thresh  arcb    arg1,arg2,...
ppa     blink   0       0       950     1500    1
ptswhi  block   0       0       950     25      2       50
ptswlo  block   0       0       950     25      2       50

Above is an example of an arf file. The names above it are primarily for paedagogical purposes and should not be included in the actual file. An arf file is created using an ascii editor; the meanings of the various columns are as follows:

func.

This is the function name and must be one of those detailed below.

desc.

This is the descriptive name carried around with the data and usually indicates the type of artifact you are trying to reject. Any character string up to 8 chars can be used. A dname is associated with a particular rejection count bin - see below.

chan

This is the channel on which to perform the function. Channels start at 0. garv (and avg(1) ) will complain if the number is not between 0 and one less than the number of channels of data (inclusive).

latlo and lathi

These are the latencies in msec. referenced to the calculated time of event occurrence. Note that in the continuous data system, this point is presamp msec into the epoch, so to test the entire epoch, the appropriate numbers to enter would be (-presamp) to (epoch_length - presamp). Again, garv (and avg(1) ) will complain if these numbers are out of range. Sometimes a complaint will be issued when seemingly valid latencies are entered. This is due to the time quantization induced by sampling at discrete time points and inherent truncation. For example, if the data are sampled at 100 Hz, the point to point "time grain" is 10 msec. If one has specified 100 msec presampling and enters -100 msec as the starting latency, garv may complain, since the first data point (after truncation) is considered to be at -90 msec. This type of problem may be rectified in future versions of garv, but for now just diddle the latencies by a "time grain" and see if it doesn’t work.

thresh

Each function returns a value on each specified data segment. This number represents the threshold above which this function will flag the whole trial (all channels) as a reject. It is currently not possible to reject single channels; this would be of limited usefulness and incurs unbelieveable overhead in accounting.

arcb

Although it is possible to use up to 128 rejection functions, counts of rejects are kept in only 8 categories. One of these count bins is preset as a count of the number of raw trials which appeared good in the log file but could not be recovered from the raw file due to data errors. This count bin is number 0, and is named dterrs. It is employed whether or not artifact rejection is requested by the operator. Hence, only seven count bins are available to the arf file. The arcb number is the artifact rejection count bin and should be between 1 and 7. Note also that only 7 dnames are possible. The names are filled in by transferring the dname from the first test encountered which is counted in the arcb. Hence, if two names appear with the same arcb, the first is used for subsequent identification.

arg1,arg2,...

Arguments, some or all optional depending on the function, used by the particular function. See below.

Currently the following routines (functions) are implemented which may do something you want:

(function)
Routine Description

mavp This routine finds the mean absolute value of the points. No additional args required.

rms Finds rms value. No args required.

max Finds max. No args.

min Finds min. No args.

ppa Finds max-min (peak to peak amplitude). No args.

ppadif Finds max-min (peak to peak amplitude) on the algebraic difference between two channels. Useful for detecting horizontal eye movements. Arg1 specifies the second eeg channel. ptswhi First finds maximum value. Then determines the number of adjacent points which are within + or - arg1 of this maximum value. Useful for blocking. Note that the points are counted only in the neighborhood of the first maximuma in the epoch. See aptshi and aptslo for better blocking detection.

ptswlo Same as ptswhi only surrounding minimum.

lclmxs Finds number of local maxima which, in comparison to adjacent local minima, exceed arg1 in size. Maybe useful for muscle.

aptshi The maximum amplitude point of the epoch is first determined. The total number of points (whether or not they are contiguous) that are within arg1 points in the vertical direction (window of amplitude) of this maximum are counted and returned as the function value.

aptslo Similar to aptshi, except the points are counted around the minimum.

pinv Identical to the polinv test except that rejected artifacts are not considered blinks, and therefore are not passed to the blink correction routines.

polinv Useful for detecting blinks. (The name "polinv" is short for "polarity inversion", which is typically what you see on the lower eye electrode as compared with a frontal electrode when an epoch has a blink.) Note that the routine does not actually look for a polarity inversion between 2 eeg channels. Arg1 specifies a second eeg channel. First polinv calculates the mean difference between the 2 eeg channels. Then it finds the maximum difference between the 2 eeg channels, and returns the absolute difference between the maximum and the mean differences. Note that this function MUST be employed when using the -b option of avg(1) for creating a blink data file. (See documentation for avg(1) and blinkcp programs for more information regarding the blink correction procedure).

mxflat Useful for detecting blocks. Returns the length of the longest "flat" interval in an epoch. Arg1 specifies the maximum vertical distance allowable for an interval to be considered flat. Blocks can normally be detected with a very small value for arg1 (~ 6).

Using garv

Summary garv can be used without an arf file to peruse raw data. Usually, however, it is used in conjunction with an arf file to examine artifactual trials in raw data and calibrate the rejection thresholds to values appropriate for the data at hand. This is necessary since gains can vary between channels and from subject to subject (see General Considerations above). As with most EPL programs, simply typing garv without any arguments will evoke a very brief explanation on using garv. On successful invocation, garv retrieves epochs sequentially from the multiplexed continuous raw data record, displays them on the display device, and prints the values resulting from application of all the individual arf tests to the data. A vertical line is drawn on the screen at the latency of the calculated event occurrence. The record number, offset, and event numbers are also printed on the terminal to allow garv to be used as a diagnostic tool when trying to figure out, "hey, what happened here????". On end of file, EOF is printed, and garv exits. Note that garv will only run on a PC with both a monochrome monitor and an EGA or VGA monitor attached. This procedure allows one to gain a rough estimate of the necessary thresholds. It is useful to plan ahead and record explicit artifacts with event numbers to facilitate matters.

Getting Started garv is invoked thus:

    garv presampling [options]opt

where presampling is the total desired prestimulus interval (including the onset delay, or trigger to stimulus delay) Note that by default the raw file is on magtape and the magtape should be loaded and the tape drive should be on line drive prior to invoking garv. garv will work with this minimal set of arguments and display the raw data on the color monitor; most often, however, one will want to calibrate an arf file as well. This is specified as one of the possible options:

    -a arf_file    Use A.R. tests contained in arf_file.
    -c chan_prec    Select # of points per epoch as 256*chan_prec.
    -n        Don’t rewind the magtape on termination.
    -r dec_factor    Decrease the sampling rate of the data (decimate) by
            an integral factor dec_factor as they are extracted
            from the raw file.  
    -d id_filter    (This option is not available on DOS systems yet.)
            digitally filter the data using the integer digital
            filter id_filter as they are extracted from the raw
            file.

which are appended in any order to the three required arguments. Note - if one employs the -n option, garv will attempt to space to the end of the tape before exiting when an exit is requested. This can take a long time, and the occurrence of a signal during this period will leave the magtape in an unspecified state.

Running garv Once garv has been successfully invoked, it retrieves the first trial in the raw file and prints its record number, event number, and offset within the record, displays the data (all channels) on the display device with a vertical line at the putative time of stimulus occurrence, and if an arf file is in use, prints the contents of the arf file along with the values for each test after application to these data. A message is printed indicating whether or not this trial would have been rejected or accepted given the current thresholds in the arf file. If this trial would have been rejected, the channel of data that cause the rejection is highlighted. If the event was a pause or delete mark, this is noted. At this point, garv will be in command mode, and the following commands will be recognized and performed:

Command Description

+ Increase the size of the displayed data by a factor of two. The + commands are cumulative and remain in effect until - command(s) are invoked. The current record is redisplayed at the new gain.

- Decrease the size of the displayed data by a factor of two. As with + commands, the - commands are and the current raw data record is redisplayed on the display device.

nnn Advance nnn + 1 trials into the raw file, where nnn is a decimal integer. Note that a blank line (typing only a return) advances the raw file by one trial.

d c0 c1 c2 ... Instead of displaying all the channels of data on the display device, display only channels numbered c0, c1, c2, etc. Note that channels are numbered starting with 0 and cannot exceed the total number of channels minus 1. The c0, c1, c2, etc are decimal integers - any non- numeric arguments or channels out of range will be ignored. The order in which the specified channels are displayed is determined by the order in which they are specified in this command. For example: d 3 6 0 14 will display the fourth, seventh, first, and fifteenth channels on the display device for all subsequent commands. It is possible to specify that no channels be displayed if desired.

a The a command sets the mode of garv to print all A.R. tests and the values obtained from the current data trial. This is the de- fault mode.

V N Advance to the next event number N (a decimal integer). Zero is not a valid event #.

p The p command causes only the A.R. test that causes a rejection to be printed as the trials in the raw file are perused.

P The P (capital ’P’) causes a copy of the current graphics screen to be printed out on the laserjet printer.

h This h or help command causes garv to print a summary of the various command options avail- ble in the current implementation.

q Exit the program. Control d will also work, as will an interrupt (delete key) or an EOF (End of File) on the raw continuous data file.

s The s command causes garv to skip to the next trial in the raw file that would be rejected, given the current arf file. Unlike the +, -, d c0, c1, c2, ..., a, and p commands, the s command does not set a mode, but must be typed in each time to repetitively skip to rejected trial. In this sense, it is in a class with the nnn (or blank line) commands.

e Invokes a text editor with the contents of the current arf file. The default editor is ’vi’ but if the environment variable EDITOR exists, the editor it defines will be used instead. After you edit the file, (optionally) save the changes and quit the editor, garv re-reads the arf file and continues from the epoch where it left off. If some part of the arf file has an error in it, garv will allow you to either re-open the editor to fix the problem, or quit garv altogether.

l c0, c1, ... The l command takes a list of events numbered c0, c1, etc. and creates a "stop list" from them. When moving through data files, garv looks to see if the next event code is on the stop list. If it is, the epoch is skipped, and the next epoch who’s event code is not on the stop list is displayed.

After every command, the data are displayed on the screen, the raw trial and other information printed, and the A.R. tests applied to the data unless the current command or a previous command has indicated otherwise. On invocation the default mode includes ’a’ (print all A.R. tests) and display all channels on the display device. If one wishes to view or calibrate multiple raw files on a single reel of magtape, they are best processed in the order in which they were digitized, using the -n flag on each invocation of garv except the last.

Garv Errors There are, as usual, a number of possible errors that can occur when trying to use garv. These are meant to be self-explanatory, but this does not always ensure an easy solution to the problem. Many of the error messages are the same as for avg(1) , since all the continuous data and A.R. routines are common to both garv and avg(1) .

Table of Contents

Name
Description