Triggering

Sending event signals to synchronise systems

After initialising the device, event signals can be sent via the output port. These are then recorded by the recording system. By using event signals of differing lengths, multiple different event signals can be sent over a single output channel.

Events can be specified using simple, pre-specified events or more flexibility can be added by defining user-specified events.

Event types

Here, we implement four event types: a start signal to indicate the start of a trial, an end signal to indicate the end of a trial and event1 and event2 signals to indicate two event types during trials.

Each signal type has a different duration:

Event type	Duration (ms)
Start	50
End	100
Event 1	150
Event 2	200

Each signal type is generated using simple commands from within the task script. Recovering the discrete event timings is discussed in the analysis section.

Start signal

The start signal is intended to indicate the beginning of a new trial. It is produced by using the SyncMaster object.

source

SyncMaster.start

 SyncMaster.start ()

Send start signal

Incorporating this into the task script sends a 50ms pulse over the output channel every time this command is executed.

# Send start signal
device.start()

An example output for a start signal recorded with an oscilloscope is shown below.

End signal

The end signal is intended to indicate the end of a trial. It is produced by using the SyncMaster object.

source

SyncMaster.end

 SyncMaster.end ()

Send end signal

Incorporating this into the task script sends a 100ms pulse over the output channel every time this command is executed.

# Send end signal
device.end()

An example output for a end signal recorded with an oscilloscope is shown below.

Event 1 signal

The event1 signal is intended to indicate the occurence of an arbitrary event within a trial. It is produced by using the SyncMaster object.

source

SyncMaster.event1

 SyncMaster.event1 ()

Send event 1 signal

Incorporating this into the task script sends a 150ms pulse over the output channel every time this command is executed.

# Send event 1 signal
device.event1()

An example output for a event1 signal recorded with an oscilloscope is shown below.

Event 2 signal

The event2 signal is intended to indicate the occurence of an arbitrary event within a trial. This allows for two different arbitrary events to be encoded in addition to start and end signals. It is produced by using the SyncMaster object.

source

SyncMaster.event2

 SyncMaster.event2 ()

Send event 2 signal

Incorporating this into the task script sends a 200ms pulse over the output channel every time this command is executed.

# Send event 2 signal
device.event2()

An example output for a event2 signal recorded with an oscilloscope is shown below.

User-specified events

For complex task designs, simple triggers such as start, end and two unique event markers may not be sufficient.

For these cases, user-defined event IDs can be defined. Triggers can then be sent via the device to identify each of these events on the output channel.

# Define event IDs
END = 1
EVENT1 = 2
EVENT2 = 3
CONDITION1 = 4
CONDITION2 = 5

Each event ID is assigned a single unique identifier.

source

SyncMaster.event

 SyncMaster.event (eventID)

Create event marker

The event command allows for triggers corresponding to user-defined event IDs to be sent. Each event type should have a single, unique ID, defined as an integer. Up to 100 unique event types can be defined using this approach. This offers great flexibility regarding marking multiple conditions and events in complex task designs.

''' Run simple trial using user-specified events '''
# Start trial with specified condition
device.event(CONDITION1) 

''' Run behavioural task '''

# Trigger specific event
device.event(EVENT1)

''' Continue behavioural task '''

# Send end trigger
device.event(END)

This approach offers significantly more flexibility than using the simple, pre-defined event triggers.

This comes at the cost of requiring event IDs to be carefully tracked to ensure that all events have unique IDs.

Further, the trigger duration for each trial type is ten times the event ID, measured in milliseconds (i.e. the trigger for event 3 is 30ms in length). As a consequence, events with high event IDs result in relatively longer triggers. This should be kept in mind for situations where multiple triggers occur in rapid succession. For this reason, a limit of 100 event types is in place to limit the maximum trigger duration to one second.