User Reference:Timing - Revision history

Mellinger: /* Timing Display */

2026-06-29T13:01:48Z

Timing Display

← Older revision		Revision as of 13:01, 29 June 2026
Line 33:		Line 33:
	*real-time operation -- roundtrip time should stay below theoretical sample block length;		*real-time operation -- roundtrip time should stay below theoretical sample block length;
	*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves;		*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves;
	*stimulus trigger time and stimulus display -- each yellow dot represents a triggered stimulus, each green dot represents a stimulus display;		*stimulus trigger time and stimulus display -- each yellow dot represents a triggered stimulus, each green dot represents a visual stimulus display;
	*audio playback -- each violet dot represents the transition from a zero audio buffer to a nonzero one, relative to a preceding yellow dot (stimulus trigger).		*audio playback -- each violet dot represents the transition from a zero audio buffer to a nonzero one, relative to a preceding yellow dot (stimulus trigger).

Mellinger: /* Timing Display */

2024-04-08T16:16:11Z

Timing Display

← Older revision		Revision as of 16:16, 8 April 2024
Line 33:		Line 33:
	*real-time operation -- roundtrip time should stay below theoretical sample block length;		*real-time operation -- roundtrip time should stay below theoretical sample block length;
	*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves;		*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves;
	*stimulus ~~triggering~~ and display -- each yellow dot represents a triggered stimulus, each green dot represents a stimulus display;		*stimulus trigger time and stimulus display -- each yellow dot represents a triggered stimulus, each green dot represents a stimulus display;
	*audio playback -- each violet dot represents the transition from a zero audio buffer to a nonzero one.		*audio playback -- each violet dot represents the transition from a zero audio buffer to a nonzero one, relative to a preceding yellow dot (stimulus trigger).

	==Timing Evaluation==		==Timing Evaluation==

Mellinger: /* Timing Display */

2024-04-08T16:14:06Z

Timing Display

← Older revision		Revision as of 16:14, 8 April 2024
Line 32:		Line 32:
	*regularity of data acquisition -- the block duration curve should be a straight line;		*regularity of data acquisition -- the block duration curve should be a straight line;
	*real-time operation -- roundtrip time should stay below theoretical sample block length;		*real-time operation -- roundtrip time should stay below theoretical sample block length;
	*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves.		*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves;
			*stimulus triggering and display -- each yellow dot represents a triggered stimulus, each green dot represents a stimulus display;
			*audio playback -- each violet dot represents the transition from a zero audio buffer to a nonzero one.

	==Timing Evaluation==		==Timing Evaluation==

Mellinger: /* Timing Evaluation */

2012-01-30T14:35:00Z

Timing Evaluation

← Older revision		Revision as of 14:35, 30 January 2012
Line 37:		Line 37:
	During a run, BCI2000 continously monitors roundtrip time to ensure proper timing, and issues warnings when roundtrip time approaches more than 75% of a sample block duration. Once roundtrip time consistently exceeds sample block duration, the current run is aborted with an error message.		During a run, BCI2000 continously monitors roundtrip time to ensure proper timing, and issues warnings when roundtrip time approaches more than 75% of a sample block duration. Once roundtrip time consistently exceeds sample block duration, the current run is aborted with an error message.

	There are situations in which this behavior is undesired, such as when debugging or profiling BCI2000 modules. To handle these cases, the SignalGenerator and ~~FileReplay~~ source modules provide a command line switch that disables timing evaluation.		There are situations in which this behavior is undesired, such as when debugging or profiling BCI2000 modules. To handle these cases, the SignalGenerator and FilePlayback source modules provide a command line switch that disables timing evaluation.
	*Make sure that you are starting up BCI2000 from a batch file rather than [[User Reference:BCI2000Launcher\|BCI2000Launcher]].		*Make sure that you are starting up BCI2000 from a batch file rather than [[User Reference:BCI2000Launcher\|BCI2000Launcher]].
	*Edit the batch file, and add <tt>--EvaluateTiming=0</tt> to the command line that starts up the source module.		*Edit the batch file, and add <tt>--EvaluateTiming=0</tt> to the command line that starts up the source module.

Mellinger: /* Timing Display */

2012-01-23T13:34:48Z

Timing Display

← Older revision		Revision as of 13:34, 23 January 2012
Line 33:		Line 33:
	*real-time operation -- roundtrip time should stay below theoretical sample block length;		*real-time operation -- roundtrip time should stay below theoretical sample block length;
	*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves.		*module communication overhead -- this is represented by the difference between ''roundtrip'' and ''stimulus'' curves.

			==Timing Evaluation==
			During a run, BCI2000 continously monitors roundtrip time to ensure proper timing, and issues warnings when roundtrip time approaches more than 75% of a sample block duration. Once roundtrip time consistently exceeds sample block duration, the current run is aborted with an error message.

			There are situations in which this behavior is undesired, such as when debugging or profiling BCI2000 modules. To handle these cases, the SignalGenerator and FileReplay source modules provide a command line switch that disables timing evaluation.
			*Make sure that you are starting up BCI2000 from a batch file rather than [[User Reference:BCI2000Launcher\|BCI2000Launcher]].
			*Edit the batch file, and add <tt>--EvaluateTiming=0</tt> to the command line that starts up the source module.

	==See also==		==See also==

Mellinger: /* Measuring Source-to-Stimulus Delay */

2011-10-11T14:55:42Z

Measuring Source-to-Stimulus Delay

← Older revision		Revision as of 14:55, 11 October 2011
Line 18:		Line 18:

	==Measuring Source-to-Stimulus Delay==		==Measuring Source-to-Stimulus Delay==
	In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window. Modules that use the [[Programming Reference:ApplicationWindow Class\|ApplicationWindow]] class for stimulus display (as most do), don't need to call <tt>GUI::GraphDisplay::Update()</tt>, as this is taken care for by the ApplicationWindow class after all calls to <tt>GenericFilter::Process()</tt> have ~~finished~~.		In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window. Modules that use the [[Programming Reference:ApplicationWindow Class\|ApplicationWindow]] class for stimulus display (as most do), don't need to call <tt>GUI::GraphDisplay::Update()</tt>, as this is taken care for by the ApplicationWindow class after all calls to <tt>GenericFilter::Process()</tt> have returned.

	Once the stimulus time stamp has reached the source module, the [[User Reference:DataIOFilter\|DataIOFilter]] subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when BCI2000 is distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.		Once the stimulus time stamp has reached the source module, the [[User Reference:DataIOFilter\|DataIOFilter]] subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when BCI2000 is distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.

Mellinger: /* Measuring Source-to-Stimulus Delay */

2011-10-11T14:55:28Z

Measuring Source-to-Stimulus Delay

← Older revision		Revision as of 14:55, 11 October 2011
Line 18:		Line 18:

	==Measuring Source-to-Stimulus Delay==		==Measuring Source-to-Stimulus Delay==
	In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.		In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window. Modules that use the [[Programming Reference:ApplicationWindow Class\|ApplicationWindow]] class for stimulus display (as most do), don't need to call <tt>GUI::GraphDisplay::Update()</tt>, as this is taken care for by the ApplicationWindow class after all calls to <tt>GenericFilter::Process()</tt> have finished.

	~~The~~ [[User Reference:DataIOFilter\|DataIOFilter]] ~~then~~ subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when BCI2000 is distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.		Once the stimulus time stamp has reached the source module, the [[User Reference:DataIOFilter\|DataIOFilter]] subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when BCI2000 is distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.

	==Timing Display==		==Timing Display==

Mellinger: /* Measuring Source-to-Stimulus Delay */

2011-02-08T13:48:22Z

Measuring Source-to-Stimulus Delay

← Older revision		Revision as of 13:48, 8 February 2011
Line 20:		Line 20:
	In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.		In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.

	The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.		The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when BCI2000 is distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.

	==Timing Display==		==Timing Display==

Mellinger at 15:53, 11 September 2008

2008-09-11T15:53:31Z

← Older revision		Revision as of 15:53, 11 September 2008
Line 18:		Line 18:

	==Measuring Source-to-Stimulus Delay==		==Measuring Source-to-Stimulus Delay==
	In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference~~:GUI:~~:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.		In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.

	The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.		The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.

Mellinger at 18:18, 18 August 2008

2008-08-18T18:18:20Z

← Older revision		Revision as of 18:18, 18 August 2008
Line 18:		Line 18:

	==Measuring Source-to-Stimulus Delay==		==Measuring Source-to-Stimulus Delay==
	In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GUI:GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.		In the ''StimulusTime'' state, the application module stores a time stamp when the module's Process() function has finished. By this time, video memory should have been updated, given that the module enforces a display update at the end of its Process() function; generally, this is done by calling the <tt>[[Programming Reference:GUI::GraphDisplay Class#Update\|GUI::GraphDisplay::Update()]]</tt> function for the module's display window.

	The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.		The [[User Reference:DataIOFilter\|DataIOFilter]] then subtracts the source time stamp from the stimulus time stamp to compute the source-to-stimulus delay. Unlike roundtrip time, measurement of the source-to-stimulus delay requires that data acquisition and application modules share a common time base; when distributed over multiple machines in a network, source-to-stimulus delay cannot be measured.