How to design trigger codes to obtain accurate markers

In the context of an experiment, an event typically refers to a discrete happening related to the participant. An event can be described by what happened and when. Common examples include (Figure 1A):

• the presentation of a sensory stimulus to the participant (what) after a particular baseline duration (when)
• the participant executes an action (e.g., presses a button) (what) at a specific time following a sensory stimulus (when)
• the start of an interval where participants follow a specific instruction (e.g., to maintain a resting state with eyes open) (what) after a preparation period (when)

Experimental events can be under experimenter control (e.g., stimulus presentation) or participant control (e.g., movement initiation). In the latter case, detecting events can involve various interaction devices and peripheral sensors (e.g., response buttons, motion trackers, eye trackers, accelerometers, photo sensors, microphones, force sensors, etc.).

In EEG practice, the record of all relevant events over the experiment is implemented with markers.

A marker is a representation of an event that is integrated with the EEG timeline. A typical graphical depiction of event markers on the EEG timeline is show in Figure 1B.

Figure 1: (A) Schematic of typical events of interest over the experiment timeline. (B) Graphical depiction of markers on the EEG timeline. The label ‘S 2’ describes an event (i.e., what) and its position on the EEG timeline indicates when the event occurred. Markers are recorded with multiple features in a marker file (see text).

In EEG data files with the BrainVision Core Data Format, markers are stored in a dedicated marker file (extension .vmrk). In this file, each marker has several features to describe the represented event (bottom of Figure 1B), namely:

• Marker number: The marker’s serial order in the recording relative to other markers.
• Type, Description: Labels to describe the represented event, i.e., what happened (we will discuss these two features in more detail in the following sections).
• Position (in data points): The timing of an event (when) on the EEG timeline relative to the start of the recording. The resolution of the data points is defined by the sampling rate of the EEG data.
• Size (in data points): The duration of the event, which is equal to 1 for a point event.
• Channel number:  A value of 0 indicates an event related to all channels.

By systematically creating a marker for every relevant experimental event, we obtain a record of all events on the EEG timeline.

Hardware-based trigger signals provide one of the best methods to create time-accurate markers for events as they occur during EEG data acquisition.

EEG recordings typically involve multiple devices. In one common configuration (among many) (Figure 2), experimental events are controlled and detected by one group of interconnected devices (blue cluster, Figure 2), while the participant’s EEG is recorded in parallel with a different group of devices (green cluster, Figure 2). Trigger signals serve as a bridge (red line in Figure 2) to communicate event information to the EEG recording system. The received event information is then used to create event markers integrated with the EEG timeline.

Figure 2: Schematic of common recording configuration with multiple devices (left) and their communication structure (right). Blue cluster: devices to control and detect experimental events, green cluster: devices involved in EEG recording, red line: connection path of trigger signal.

Triggering is based on digital communication protocols that are implemented in the hardware of the interacting devices (read more in our guide: Communicating with the trigger port). This hardware implementation enables rapid inter-device communication but constrains the size and format of the communicated messages. First, the messages have to be in binary format (i.e., ones and zeros). Second, the number of binary digits (i.e., bits) per message is limited, for example, eight bits.

Due to these constraints, it is useful to consider trigger-based communication as the transmission of binary coded messages from the sender (blue cluster, Figure 2) to the receiver (green cluster, Figure 2). Figure 3 is a simplified animation of this communication when there is a single sender, namely:

• Sender: When an event occurs (e.g., display of an orange square), the sender selects a binary trigger code specific to this event-type. This binary code is immediately sent as a message using a trigger signal.
• Message transmission: The trigger signal is sent only when a relevant event occurs, i.e., it is “triggered” by the event. This signal is rapidly transmitted via cables (or wirelessly) and intermediate devices (such as the TriggerBox) to a connected receiver.
• Receiver: The received binary coded message is decoded to create a marker with information about the triggering event (i.e., ‘E 11‘ for a displayed orange square).

With this protocol, markers can be created for events as they occur during the experiment. Trigger-based communication is successful if the decoded marker information corresponds to the information that the sender encoded into the message.

Figure 3: Animated schematic of communication with trigger signals for a hypothetical experiment with a single sender (trigger code are defined by 4 bits). The lower panel is a static depiction of the sequence of steps between an event and the created marker (the relative timings are not to scale).

In the BrainVision Recorder software, the Digital Port Settings define the decoding rules that decide how a received trigger code in binary format (e.g., 00001001) is converted into a marker description in alphanumeric format (e.g., ‘E  9‘).

In general, trigger codes are decoded by performing a binary-to-decimal conversion. Specifically, the trigger code is treated as the binary representation of a number. This binary coded number is converted into its decimal form (i.e., by performing a binary-to-decimal conversion). The resulting decimal number is used in the marker description.  However, the Digital Port Settings have additional parameters to modify how this binary-to-decimal conversion is performed and hence influence the resulting markers.

Figure 4 shows the parameters of the Digital Port Settings for the actiCHamp family of amplifiers with an 8-bit trigger input. Readers are referred to our trigger guide for full details of the various parameters. Our focus is restricted to the table with columns labelled Bit, Enabled, and Type due to their influence on the decoded marker description:

• Bit (Column 1) specifies the bit position (from 0 to 7) as related to the input pins of the hardware connector.
• Enabled (Column 2, green box) specifies whether the bit at a particular position is enabled (i.e., whether inputs to this bit should be included during decoding). A checked box ☑ indicates that the bit position on that row is enabled while an unchecked box ☐ indicates a disabled bit. This setting can be modified by the user, and its practical effects for trigger code design are discussed in the example section below.
• Type (Column 3, blue box) specifies which bits are to be decoded together and can be modified by the user. All bits with the same bit-type are decoded together to produce a type-specific marker. For example, if the user sets bits 0 to 3 to have the same bit-type Event then the resulting marker description would have the form Exxx, where E is the first letter of the type Event, and xxx are three positions reserved for the decoded decimal number (spaces are used to indicating leading zeros). This setting is valuable when trigger codes are received from multiple senders, rather than a single sender (see Note below). The practical effects of bit-types for trigger code design are discussed in the example section below.

With this background, we are now ready to address how to ensure successful trigger-based communication.

Trigger-based communication is successful when the decoded marker information corresponds to the information that the sender encoded into the message. When an experiment has many event-types, each event-type has to be encoded as a different trigger code, and these trigger codes have to be decodable in the intended manner.

Several of the criteria violations in Table 1 are deviations from the planned relationship between event-types and specific marker descriptions. Therefore, it is crucial to ensure that this planned relationship is in fact achievable. This can be achieved by preparing a one-to-one trigger plan.

For a single sender configuration, a simple template of a trigger plan is shown in Table 2. This table distinguishes the roles of the sender and the receiver on each row as follows:

• Sender-side: The first cell specifies a relevant event-type in the study. The second cell specifies the trigger code that should be sent for that event-type. This code can be described in decimal format (for human readability, and also used by some experimental software) and binary format (the actual trigger code that is to be sent).
• Receiver-side: The third cell specifies the planned marker description that should be obtained when the trigger code (specified in cell 2) is decoded. When using the BrainVision Recorder software, the rules for the trigger-to-marker decoding is specified by the Digital Port Settings (discussed above).

You can prepare a one-to-one trigger plan for your study by completing the above template table with information specific to your study, as follows:

• In column Event Type, list all event-types that require a trigger-based marker in your experiment.
• Fill in columns 2 and 3 with validated pairs of trigger codes and markers that support a one-to-one mapping between event-types and markers. How can this be done? We will show you in the next section.

When a one-to-one trigger plan has been completed:

• The validated trigger codes can be used in the control software to generate trigger signals during the experiment.
• When troubleshooting the trigger pipeline, the validated trigger codes can be ruled out as a source of errors.

We next demonstrate how to find validated trigger codes and markers.

In this section, we provide three examples (of increasing complexity) of how to find one-to-one mappings between trigger codes and markers for different configurations of the Digital Port Settings.

Our first example is for the Digital Port Settings configuration shown in Table 3. In this 8-bit configuration, all bits are enabled (Column 2) and have been modified to have the same bit-type (Column 3), namely, Event.

The binary-to-decimal decoding with this configuration is shown in Table 4 for an example trigger code 0011 0000 (decimal: 48). The resulting marker is E 48, where 48 is the outcome of binary-to-decimal conversion (shown in Table 4) and E is the first letter of the bit-type Event. The numeric value of the marker (i.e., 48) matches that of the received trigger code (i.e., 48).

Figure 5 shows all possible trigger codes (i.e., from 1 to 2⁷) and the corresponding decoded markers for the above configuration of the Digital Port Setting. This figure was created using the trigger2marker tool, which simulates the decoding behavior of the Digital Port Settings for a defined configuration.

Applying the three criteria for a one-to-one mapping, we see that:

✓   Every trigger code is associated with a corresponding marker.
Why? Every non-zero trigger code (left matrix) is associated with a non-zero marker (right matrix).

✓   Every trigger code (left matrix) is associated with a unique marker (right matrix).
Why? For all 255 trigger codes, the numeric value xxx (e.g., 89) is decoded to produce a marker Exxx (i.e., E 89).

✓   Every marker (right matrix) is associated with a unique trigger code (left matrix).
Why? There are 255 unique markers, and each marker Exxx is uniquely associated with a trigger code xxx.

Thus, there is a one-to-one mapping between the full set of trigger codes and decoded markers.

Figure 5: Trigger code to marker mapping (all bits enabled, same type). This figure was generated using the trigger2marker tool. The matrix on the left lists all 255 trigger codes (in decimal format for readability). For a trigger code at row i, column j (left matrix), the corresponding decoded marker is shown at the same position in the matrix on the right (without the prefix “E”). Red circles (and text boxes) highlight selected trigger codes and their markers. This information is obtained interactively when using the trigger2marker tool, by clicking within the cell of interest. The red arrows between these trigger/marker pairs is for illustration only. The color variation between cells are for visualization.

When all trigger signals are sent by a single sender, the configuration shown in Table 3 (all bits enabled with the same type) provides high flexibility to select trigger codes for your trigger plan.

1. If your study has N event-types (where N is ≤ 255), then use the full listing in Figure 5 to select N unique non-zero trigger codes (with the associated markers).
2. Assign each selected trigger code and its marker to one event-type in the trigger plan table.
3. The completed trigger plan supports a one-to-one map between event-types and markers.

We recommend using this configuration for the Digital Port Setting, especially when all trigger signals are sent by a single device (as in Figure 2).

Certain special scenarios might require one or more bits of the Digital Port Setting to be disabled. This modification has substantial consequences for a one-to-one mapping. To illustrate these consequences, an example configuration is shown in Table 5, which is identical to Table 3 above but with one bit disabled. For illustration purposes, we have disabled bit number 3.

With this configuration, decoding the example trigger code 0011 0000 (decimal: 48) results in the marker E 24 (as shown in Table 6). This is different from the marker E 48 obtained when all bits were enabled (Table 3).

Disabling a bit does NOT mean that the disabled bit is set to zero during decoding. Instead, the positions of the enabled bits are reassigned to ignore the disabled bit, as shown schematically in Figure 6.

Figure 7 shows all the possible trigger codes (i.e., from 1 to 2⁷) and the corresponding decoded markers for the above configuration. For this full set of trigger codes, two criteria for a one-to-one mapping are violated:

x   Every trigger code is NOT associated with a marker (there are missing markers)
Why? Due to the disabled bit, certain trigger codes will not produce a corresponding marker. As shown in Figure 7, trigger code 0000 1000 (decimal: 8) has a 1 at the ignored bit position 3 and zeros at all other positions. Therefore, ignoring bit 3 during decoding would result in a trigger code with only zeros, which would not be decoded into a marker. Importantly, this missing marker is due to the logic of decoding rather than a hardware issue.

✓   Every trigger code (left matrix) is associated with a unique marker (right matrix), although only when we exclude the special case of the trigger code 8 described above.

x   Every marker (right matrix) is NOT associated with a unique trigger code (left matrix) (there is a many-to-one mapping)
Why? Different trigger codes can produce the same marker (see Figure 6). For example, the trigger codes 0110 0001 (decimal: 97) and 0110 1001 (decimal: 105) have an identical pattern of 1s and 0s (blue font) except at the disabled bit position 3. Therefore, both trigger codes are decoded to produce the same marker E 49 (see Figure 7). In fact, there are only 127 unique marker values since every marker value is obtained with two different trigger codes. This can be seen in Figure 7, where the upper and lower halves of the marker matrix are identical.

However, there IS a valid one-to-one mapping for the restricted set of 127 trigger codes/markers highlighted by the solid black frames. This restricted set of trigger codes will vary depending on how many and which bits are disabled.

Figure 7: Trigger code to marker mapping (one bit disabled, all same type). The figure was generated using the trigger2marker tool. Trigger code 8 is decoded as 0 and is not associated with a marker. The set of trigger codes/markers shown with boxes with solid black frames have a one-to-one mapping. The dotted frames indicate duplicate trigger-code/marker mappings (many-to-one).

Typical usage scenarios do not require bits to be disabled. When it is unavoidable, the trigger plan can be completed by a careful selection of trigger codes, as follows:

1. Identify the set of valid trigger codes for your specific Digital Port Settings by using the trigger2marker tool. If the number of event-types (N) is less than the available number of trigger codes, then
   1. Select N unique trigger codes from the values highlighted by solid black frames.
   2. Assign each selected trigger code and its marker to one event-type in the trigger plan table.
   3. The completed trigger plan supports a one-to-one map between event-types and markers.
2. However, if there are more event-types than available trigger codes, consider alternative strategies to ensure a one-to-one mapping. For example,
   • Can the disabling of bits in the Digital Port Setting be avoided or reduced?
   • Can markers for certain event-types be created during analysis rather than with trigger signals during data acquisition?

Trigger signals can be received from multiple independent devices. In these scenarios, it can be useful to assign different types to individual bits depending on their device origin. An example configuration is shown in Table 7, where 4 bits are assigned to the type Stimulus and 4 bits are assigned to the type Response.

With this configuration, decoding the example trigger code 00110000 (decimal: 48) results in the marker R 3 (see Table 8). As shown in Table 8, bit positions are reassigned separately for each type

Figure 8 shows all the possible trigger codes (i.e., from 1 to 2⁷) and the corresponding decoded markers for the above configuration. For this full set of trigger codes, two criteria for a one-to-one mapping are violated:

✓   Every trigger code is associated with a marker.
Why?  Since all bits are enabled, every non-zero trigger code will result in at least one marker.

x   Every trigger code (left matrix) is NOT associated with a unique marker (right matrix)(i.e., there is a one-to-many mapping).
Why?  For example, for trigger code 0011 1001 (decimal: 57), the bits assigned to the Stimulus type (orange) and the Response type (blue) are not all zeros. Therefore, both groups of bits are decoded to produce valid markers, namely, S 9 and R 3. Only a narrow range of trigger codes produce a single marker (either Sxxx or Rxxx) as highlighted by the solid black frames.

x   Every marker (right matrix) is NOT associated with a unique trigger code (left matrix) (i.e., there is a many-to-one mapping).
Why?  For example, the trigger codes 0011 0000 (decimal: 48) and 0011 1001 (decimal: 57) are identical for the bits positions of Response type (blue). Therefore, both trigger codes would produce the same marker R 3. Due to these symmetries, every marker value (e.g., R 3) is associated with 15 distinct trigger codes. As shown in Figure 8, each row of the Stimulus marker matrix has identical values, and each column of the Response marker matrix has identical values.

However, there IS a one-to-one mapping for the restricted set of 30 trigger codes/marker highlighted by solid black frames in Figure 8. This set of suitable trigger codes can differ depending on the number of types, the number of bits assigned to each type and their specific positions.

Figure 8: Trigger code to marker mapping (all bits enabled but with different types). The figure was generated using the trigger2marker tool. The display conventions are the same as in Figure 5. The set of trigger codes/markers shown with solid black frames have a one-to-one mapping.

Remember that bit-types do not refer to event-types (see Note box above). Using multiple bit-types is not required when all trigger signals are sent by a single sender. When there are multiple senders, the trigger plan can be completed by a careful selection of trigger codes. To complete your trigger plan:

1. Identify the set of valid trigger codes for your specific Digital Port Settings by using the trigger2marker tool. If the number of event-types (N) is less than the available number of trigger codes, then
   1. Select N unique trigger codes from the available trigger codes.
   2. Assign each selected trigger code and its marker to one event-type in the trigger plan table.
   3. The completed trigger plan supports a one-to-one map between event-types and markers.
2. If there are more event-types than available trigger codes, consider alternative strategies to ensure a one-to-one mapping. For example,
   • Is the use of different bit types necessary?
   • Can the number of bits assigned to each type be changed?
   • Can markers for certain event-types be created during analysis rather than with trigger signals during data acquisition?

Designing a one-to-one trigger plan is a simple yet systematic “paper and pencil” strategy that can be performed before data acquisition. It can provide you with usable trigger codes as well as help you make strategic decisions about the trigger pipeline and how to configure the Digital Port Settings for your data acquisition. Be sure to check out our Support & Resources and Solutions pages for further information and ideas on designing effective trigger pipelines.