ERROR: Error 11076: Invalid DisplayFrameThresholdStimDisplay value when running at a 200+ Hz refresh rate [30240]

This article applies to:
E-Prime 3.0
E-Prime 2.0

 
Detail
While E-Prime allows for refresh rates over 200+ Hz, a few additional settings typically need to be changed in order to avoid Runtime errors. If you bypass these Runtime errors and successfully log a completed data file when running over 200 Hz, PST recommends further verification. Users should utilize external hardware to verify their own machine’s timing. This is especially important for users hoping to run at a refresh rate over 200 Hz. Monitors advertised as being capable of running at refresh rates over 200 Hz may require the screen to be buffered first. This means stimulus presentation can only occur at least one screen refresh later than what is reported to E-Prime. While E-Prime alone is incapable of time auditing this behavior, E-Prime can help you determine if your machine’s contributing hardware can support the detected refresh rate.

NOTE: Refresh rates greater than 250 Hz are not supported in E-Prime at this time.
 
Bypassing refresh rate Runtime Errors
E-Prime typically throws the following error message when you run at a refresh rate higher than 201 Hz, either intentionally or unintentionally:
 

 
This error can be bypassed through a specific StartupInfo parameter. This parameter changes the given Display device’s DisplayFrameThresholdUpdate property value from its default of 50% to 45%:
 

 
NOTE: This example assumes you are targeting a Display Device with the default name of “Display”. If your Display device has a different name, you need to change the word before the period (i.e., in the Property Name column) to the name of your Display device (e.g., myDisplay).
 
By default, a Display device has a requested refresh rate of (unspecified) and a Maximum Acceptable Refresh Rate setting of 201 Hz. When leaving the requested refresh rate as (unspecified), E-Prime attempts to run at the highest refresh rate supported by your display adapter for any given resolution. You can determine what available refresh rates there are for your display adapter at the various supported resolutions by opening your Windows Display settings > Advanced display settings:
 

 
NOTE:Each display adapter is a combination of a single monitor, video card, and video card driver. If you have a multi-monitor setup and are possibly using multiple video cards, you want to identify which combination you intend to run E-Prime on. We recommend verifying you have the latest driver updates for your Windows Devices.
 
After having the correct monitor(s) identified and connected to the video card you intend to run E-Prime on, click on the monitor’s Display adapter properties:
 

Then, click on List All Modes and review the combinations of supported resolutions and refresh rates for your display adapter(s) of choice:
 

 
NOTE: PST has developed a test experiment that should output these listings to a text file. If you feel the need to confirm that E-Prime can see the same exact listings as are in the List All Modes section, please download the DisplayDumpModes.es3 below, open in E-Studio 3, specify your Display Device Index if you are not using Display 1, run to completion and review the contents of the generated Display-Modes.txt file.

 
If you have verified the timing for both the monitor and hardware for a data collection setup that is meant to run at over 200 Hz, you could make the two changes in a single, global StartupInfo file (STARTUPINFO EDITOR: Local and Global Values [22734]). The image below shows these changes:
 

 
Bypassing refresh rate Runtime Errors in E-Prime 2.0 / E-Prime 3.0 (3.0.3.31)
There is a known issue in E-Prime 2.0.10.353, E-Prime 2.0.10.356, and E-Prime 3.0.3.31 that does not allow you to specify your refresh rate using the Requested Refresh Rate field (BUG FIX: Specifying a RefreshRate in DisplayDevice being ignored [25863]). Therefore, E-Prime 2.0 and E-Prime 3.0.3.31 tries to run at the highest available refresh rate for the specified resolution that is supported by the underlying display adapter for the experiment’s Display device. If E-Prime attempts to run over 200 Hz, without making an additional change to the default Display Device settings, the following error occurs:
 

 
NOTE: This error can occur for a variety of other reasons. It is depicted here because the refresh rate has been detected as being outside of the bounds of the acceptable min / max refresh rate.
 
This error can be bypassed by increasing the Maximum Acceptable Refresh Rate property from the default value of 201 Hz to 301 Hz:
 

 
There is a separate known issue in E-Prime 2.0 and E-Prime 3.0.3.31 related to the issue mentioned above that prevents a non-default Maximum Acceptable Refresh Rate from being saved when the Requested Refresh Rate is (unspecified) (see BUG FIX: Minimum and/or Maximum Acceptable Refresh Rate not saved on DisplayDevice dialog [25864]). E-Prime 2.0 and 3.0.3.31 users need to identify a specific refresh rate to bypass this error.
 
Refresh rates in E-Prime 3.0 (3.0.3.60 or later)
E-Prime 3.0.3.60 or later does allow you to request a refresh rate lower than the highest available at a given resolution. For those hoping to reduce .OnsetDelay, we recommend manually specifying your Requested Refresh Rate and choosing Duration values for your visual E-Objects that are roughly divisible by the refresh rate. Specifying a Requested Refresh Rate automatically adjusts your Maximum Acceptable Refresh Rate to be one Hz higher. This allows for a typical -1/+1 Hz variance when E-Prime goes to lock in your specified refresh rate during the Display Device initialization at the start of an experiment run. If left to the default of (unspecified), E-Prime 3.0.3.60 or later attempts to run at the highest available refresh rate for the specified resolution. If you do not need to run at over 200 Hz, then specifying a lower refresh rate does not require the above workarounds.
 
Verifying the timing of your 200+ Hz using Chronos, etc.
PST cannot perform its normal battery of timing tests on every possible combination of supported machines, monitors, operating systems, video cards, drivers, etc. Therefore, we expect users verify their own data collection setup timing for verification of timing. If you have Chronos, you can run the ChronosRefreshRateAndLatencyTest in this article: TIMING: Verifying your Clock and Timing in E-Prime [34371]. Alternatively, you could design a similar test using a different external hardware verification tool, such as the Black Box Toolkit (http://www.blackboxtoolkit.com/) or an oscilloscope.
 
These tests should determine the Rise (black-to-white) and Fall (white-to-black) transition times of your monitor. These values describe the latency between when .OnsetTime is logged (at the exact millisecond .Draw is executed) and when the pixels on your monitor begin to physically change. E-Prime can log .OnsetDelay to audit how much time elapses between the original .TargetOnsetTime and when .Draw executed at Runtime. However, E-Prime alone is not capable of logging hardware latency.
 
Hardware latency must be measured by an external hardware verification tool such as Chronos or the Black Box Toolkit. This helps you determine if the screen is being buffered first (i.e., meaning stimulus presentation occurs at least one screen refresh later than what is reported to E-Prime). There is no universal standard for measuring monitor latency and response times. PST prefers to go by Rise and Fall times to help cut through common ambiguities, but every researcher has to make their own subjective call as to when “grey becomes black” and when “grey becomes white”. 

 
Verifying .OnsetDelay
Once the monitor’s advertised response time has been verified by measuring the Rise/Fall latencies, you should also pay close attention to what degree of baseline .OnsetDelay values you are getting on this setup when following best timing practices. A monitor's measured response times might verify its individual capacity to run at over 200 Hz, and E-Prime might detect a refresh rate suggesting as much, but you should still be separately verifying that the contributing hardware components, such as your graphics card, are themselves independently fast enough to handle the specified refresh rate at that resolution.

You can either go by the Stimulus.OnsetDelay values you see when running the sample experiments included with each installation - BasicRT, PictureRT, MovieRT, etc. based on the particular type of stimuli you are hoping to present, or you can follow the experiment design steps outlined in the article TIMING: Steps to reduce large OnsetDelay values [19370] to see what degrees of .OnsetDelay are reported for your experiment when following best timing practices. If you typically see positive .OnsetDelay values that are within a few refresh intervals for your specified refresh rate, or negative .OnsetDelay values within a single refresh interval, then this suggests the contributing hardware components should indeed be capable of displaying as fast as the detected refresh rate suggests. We always recommend monitoring .OnsetDelay values for all time-critical E-Objects presented.
 
NOTE: Until PST has performed sufficient testing with a suitable range of 200+ Hz refresh rate monitors, we do not recommend running at refresh rates over 200 Hz unless you are able to perform the Rise/Fall times testing and .OnsetDelay values monitoring. Unlike the concerns related to the screen buffering, there is not currently a singular test experiment uniquely designed to test for underperforming hardware.

Users are expected to monitor for large .OnsetDelay values reported for their time-critical objects and to make any necessary adjustments during the design and piloting phase of the experiment design process. To determine if any excessively large .OnsetDelay values you are seeing might be specific to your experiment design or sourced stimuli files, rather than being specific to your hardware setup, you can always compare these values to the baseline values obtained by running the E-Prime sample experiments on this same data collection setup.
 
See Also:
TIMING: Stimulus Presentation Challenges [22850]
TIMING: Stimulus Presentation Solutions [22858]
TIMING: E-Prime 2.0 Monitor Recommendations and Timing Information [18080]