|
Andrew Papale
|
|
|
Group: Forum Members
Posts: 66,
Visits: 233
|
Inquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process.   The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA
|
|
|
|
|
Andrew Papale
|
|
|
Group: Forum Members
Posts: 66,
Visits: 233
|
+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 105K
|
+x+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks If your trial doesn't have a /pretrialpause, it's likely that Inquisit has to delay the onset of the 1st stimulus because it has to some time for the start of the next display refresh cycle, thereby shortening the effective on-screen duration of the stimulus. Graphics card drivers with varying quality can also cause delays and/or frame slippage. (Just because the hardware has been instructed to do something at a specific time unfortunately doesn't always mean that the hardware *will* do said thing at that specific time.) To minimize timing issues: (1) Use /pretrialpause and measure again. (2) If onset delays persist, shift /stimulustimes forward by one or two refresh cycle durations. and measure again. Also, graphics card performance isn't the only factor at play here. The actual duration depends on a host of other physical characteristics of the respective display, cf. Plant, Hammond & Turner (Behavior Research Methods, 2004), Wiens et al. (Psychological Science, 2004), Plant & Turner (Behavior Research Methods, 2009), Elze & Tanner (Medical Physics, 2009), https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 and many more.
|
|
|
|
|
Andrew Papale
|
|
|
Group: Forum Members
Posts: 66,
Visits: 233
|
+x+x+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks If your trial doesn't have a /pretrialpause, it's likely that Inquisit has to delay the onset of the 1st stimulus because it has to some time for the start of the next display refresh cycle, thereby shortening the effective on-screen duration of the stimulus. Graphics card drivers with varying quality can also cause delays and/or frame slippage. (Just because the hardware has been instructed to do something at a specific time unfortunately doesn't always mean that the hardware *will* do said thing at that specific time.) To minimize timing issues: (1) Use /pretrialpause and measure again. (2) If onset delays persist, shift /stimulustimes forward by one or two refresh cycle durations. and measure again. Also, graphics card performance isn't the only factor at play here. The actual duration depends on a host of other physical characteristics of the respective display, cf. Plant, Hammond & Turner (Behavior Research Methods, 2004), Wiens et al. (Psychological Science, 2004), Plant & Turner (Behavior Research Methods, 2009), Elze & Tanner (Medical Physics, 2009), https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 and many more. Thank you Dave, I was unable to change the delay after using pretrial pause (neither an arbitrary 50ms nor a 145ms pretrialpause at 145Hz refresh rate worked) or shifting the stimulus times by 1-2 frames. I will say that I tested PsychToolBox in Matlab and observed a 50ms discrepancy under equivalent conditions so Inquisit is once again superior given an equivalent setup. I am very surprised that the higher refresh rate (145Hz vs 60Hz) did not change this delay under any conditions. I could also try re-specifying everything with the /stimulusframes property instead of the /stimulustimes and see if that helps. At this point I'm leaning towards this being a hardware timing issue. I think the parsimonious thing to do is just to add the respective times to the stimulus times in Inquisit to have them display the requested durations, and account for a 20ms delay between the start of the trial, or start of feedback (marked as precisely as possible with the TTL pulses) and the actual display updating with the respective stimuli. This will not add an appreciable length of time to our task (about 12s).
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 105K
|
+x+x+x+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks If your trial doesn't have a /pretrialpause, it's likely that Inquisit has to delay the onset of the 1st stimulus because it has to some time for the start of the next display refresh cycle, thereby shortening the effective on-screen duration of the stimulus. Graphics card drivers with varying quality can also cause delays and/or frame slippage. (Just because the hardware has been instructed to do something at a specific time unfortunately doesn't always mean that the hardware *will* do said thing at that specific time.) To minimize timing issues: (1) Use /pretrialpause and measure again. (2) If onset delays persist, shift /stimulustimes forward by one or two refresh cycle durations. and measure again. Also, graphics card performance isn't the only factor at play here. The actual duration depends on a host of other physical characteristics of the respective display, cf. Plant, Hammond & Turner (Behavior Research Methods, 2004), Wiens et al. (Psychological Science, 2004), Plant & Turner (Behavior Research Methods, 2009), Elze & Tanner (Medical Physics, 2009), https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 and many more. Thank you Dave, I was unable to change the delay after using pretrial pause (neither an arbitrary 50ms nor a 145ms pretrialpause at 145Hz refresh rate worked) or shifting the stimulus times by 1-2 frames. I will say that I tested PsychToolBox in Matlab and observed a 50ms discrepancy under equivalent conditions so Inquisit is once again superior given an equivalent setup. I am very surprised that the higher refresh rate (145Hz vs 60Hz) did not change this delay under any conditions. I could also try re-specifying everything with the /stimulusframes property instead of the /stimulustimes and see if that helps. At this point I'm leaning towards this being a hardware timing issue. I think the parsimonious thing to do is just to add the respective times to the stimulus times in Inquisit to have them display the requested durations, and account for a 20ms delay between the start of the trial, or start of feedback (marked as precisely as possible with the TTL pulses) and the actual display updating with the respective stimuli. This will not add an appreciable length of time to our task (about 12s). Just adding that with a 145Hz refresh rate, you have a 6.897 ms refresh cycle duration, which makes it impossible to achieve a stimulus onset at exactly 100ms (that'd be 14.5 display frames). That's probably part of where the discrepancy comes from. The 60Hz refresh rate / a 16.667 ms refresh cycle duration should theoretically be superior for a 100 ms stimulus onset, since that works out to 6 display frames exactly. Do take note that calculating stimulus duration based on refresh cycle durations is an imperfect approximation (albeit "good enough" for many, if not most, purposes). Actual duraton will differ depending on a host of other factors, such as display response time, pixel color transition times (which are not uniform), and delays or discrepancies can also be introduced by additional processing performed either in software (e.g. optional "enhancements" the driver performs) or hardware (many modern displays are themselves mini-computers and may perform various corrections, enhancements or signal transformations before outputting anything). Whatever analog or digital video interface is used (VGA, DVI, HDMI, etc.) may also play a role.
|
|
|
|
|
Andrew Papale
|
|
|
Group: Forum Members
Posts: 66,
Visits: 233
|
+x+x+x+x+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks If your trial doesn't have a /pretrialpause, it's likely that Inquisit has to delay the onset of the 1st stimulus because it has to some time for the start of the next display refresh cycle, thereby shortening the effective on-screen duration of the stimulus. Graphics card drivers with varying quality can also cause delays and/or frame slippage. (Just because the hardware has been instructed to do something at a specific time unfortunately doesn't always mean that the hardware *will* do said thing at that specific time.) To minimize timing issues: (1) Use /pretrialpause and measure again. (2) If onset delays persist, shift /stimulustimes forward by one or two refresh cycle durations. and measure again. Also, graphics card performance isn't the only factor at play here. The actual duration depends on a host of other physical characteristics of the respective display, cf. Plant, Hammond & Turner (Behavior Research Methods, 2004), Wiens et al. (Psychological Science, 2004), Plant & Turner (Behavior Research Methods, 2009), Elze & Tanner (Medical Physics, 2009), https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 and many more. Thank you Dave, I was unable to change the delay after using pretrial pause (neither an arbitrary 50ms nor a 145ms pretrialpause at 145Hz refresh rate worked) or shifting the stimulus times by 1-2 frames. I will say that I tested PsychToolBox in Matlab and observed a 50ms discrepancy under equivalent conditions so Inquisit is once again superior given an equivalent setup. I am very surprised that the higher refresh rate (145Hz vs 60Hz) did not change this delay under any conditions. I could also try re-specifying everything with the /stimulusframes property instead of the /stimulustimes and see if that helps. At this point I'm leaning towards this being a hardware timing issue. I think the parsimonious thing to do is just to add the respective times to the stimulus times in Inquisit to have them display the requested durations, and account for a 20ms delay between the start of the trial, or start of feedback (marked as precisely as possible with the TTL pulses) and the actual display updating with the respective stimuli. This will not add an appreciable length of time to our task (about 12s). Just adding that with a 145Hz refresh rate, you have a 6.897 ms refresh cycle duration, which makes it impossible to achieve a stimulus onset at exactly 100ms (that'd be 14.5 display frames). That's probably part of where the discrepancy comes from. The 60Hz refresh rate / a 16.667 ms refresh cycle duration should theoretically be superior for a 100 ms stimulus onset, since that works out to 6 display frames exactly. Do take note that calculating stimulus duration based on refresh cycle durations is an imperfect approximation (albeit "good enough" for many, if not most, purposes). Actual duraton will differ depending on a host of other factors, such as display response time, pixel color transition times (which are not uniform), and delays or discrepancies can also be introduced by additional processing performed either in software (e.g. optional "enhancements" the driver performs) or hardware (many modern displays are themselves mini-computers and may perform various corrections, enhancements or signal transformations before outputting anything). Whatever analog or digital video interface is used (VGA, DVI, HDMI, etc.) may also play a role. Just an update to close this thread off, we found that by reducing the threshold of the photodiode, the stimuli appeared to be longer. At 75% they were 20ms short. At 66.7% they were precisely as expected. Below 66.7% The were slightly too long. So this appeared to be the effect of the LCD screen ramping up / down luminance as in https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 105K
|
+x+x+x+x+x+xInquisit Community, We are using Inquisit 6 for an EEG task requiring millisecond precision. To test the timing of stimulus display, I have hooked up a photodiode to a virtual oscilloscope and tested the timing of stimulus onset relative to trigger times and stimulus onset relative to stimulus offset. The primary concern I have is that Inquisit 6 seems to be stopping the display of stimuli before the requested timing in the code. I have compared our oscilloscope measurements with the data audit times and they are inconsistent. I have repeated the test on two different graphics cards and observed the same problem (though on the Dell Integrated graphics, the offset was 30ms and on the NVIDIA graphics card it was 20ms before the scheduled offset). Below are two screenshots from the virtual oscilloscope. On the left, I have requested a white square be on the screen for 100ms, but observed it switching to a black square after 79ms. On the right, I have requested a white square be on the screen for 1000ms, and observe it switching to a black square after 980ms. This is with the NVIDIA graphics card, Windows 10, and Inquisit is running as a realtime process. The code to do this is very straightforward and I don't think this is a coding error on my part, but feel free to correct any errors. The relevant code is just: / stimulustimes = [0 = white_square, trigger, other stimuli;
100 = black_square, other stimuli;
]. // flash white square for 100ms, send trigger to port COM4 when white square appears Any help in understanding and/or fixing this behavior would be appreciated. On the plus side, I will say I have achieved precision with the trigger and stimulus onset on the order of +/- 500 microseconds, which is quite impressive. Sincerely, Andrew Papale University of Pittsburgh USA Some additional details about the figures. The red trace (CH0) is the photodiode. The oscilloscope is set to trigger on the photodiode. The vertical dashed lines measure the length of the photodiode onset (when the white square is on the screen). The difference in the vertical dashed lines is displayed above in the "delta" in ms. The orange trace (CH1) is the trigger from Inquisit to our EEG system and can be ignored for these purposes. Thanks If your trial doesn't have a /pretrialpause, it's likely that Inquisit has to delay the onset of the 1st stimulus because it has to some time for the start of the next display refresh cycle, thereby shortening the effective on-screen duration of the stimulus. Graphics card drivers with varying quality can also cause delays and/or frame slippage. (Just because the hardware has been instructed to do something at a specific time unfortunately doesn't always mean that the hardware *will* do said thing at that specific time.) To minimize timing issues: (1) Use /pretrialpause and measure again. (2) If onset delays persist, shift /stimulustimes forward by one or two refresh cycle durations. and measure again. Also, graphics card performance isn't the only factor at play here. The actual duration depends on a host of other physical characteristics of the respective display, cf. Plant, Hammond & Turner (Behavior Research Methods, 2004), Wiens et al. (Psychological Science, 2004), Plant & Turner (Behavior Research Methods, 2009), Elze & Tanner (Medical Physics, 2009), https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 and many more. Thank you Dave, I was unable to change the delay after using pretrial pause (neither an arbitrary 50ms nor a 145ms pretrialpause at 145Hz refresh rate worked) or shifting the stimulus times by 1-2 frames. I will say that I tested PsychToolBox in Matlab and observed a 50ms discrepancy under equivalent conditions so Inquisit is once again superior given an equivalent setup. I am very surprised that the higher refresh rate (145Hz vs 60Hz) did not change this delay under any conditions. I could also try re-specifying everything with the /stimulusframes property instead of the /stimulustimes and see if that helps. At this point I'm leaning towards this being a hardware timing issue. I think the parsimonious thing to do is just to add the respective times to the stimulus times in Inquisit to have them display the requested durations, and account for a 20ms delay between the start of the trial, or start of feedback (marked as precisely as possible with the TTL pulses) and the actual display updating with the respective stimuli. This will not add an appreciable length of time to our task (about 12s). Just adding that with a 145Hz refresh rate, you have a 6.897 ms refresh cycle duration, which makes it impossible to achieve a stimulus onset at exactly 100ms (that'd be 14.5 display frames). That's probably part of where the discrepancy comes from. The 60Hz refresh rate / a 16.667 ms refresh cycle duration should theoretically be superior for a 100 ms stimulus onset, since that works out to 6 display frames exactly. Do take note that calculating stimulus duration based on refresh cycle durations is an imperfect approximation (albeit "good enough" for many, if not most, purposes). Actual duraton will differ depending on a host of other factors, such as display response time, pixel color transition times (which are not uniform), and delays or discrepancies can also be introduced by additional processing performed either in software (e.g. optional "enhancements" the driver performs) or hardware (many modern displays are themselves mini-computers and may perform various corrections, enhancements or signal transformations before outputting anything). Whatever analog or digital video interface is used (VGA, DVI, HDMI, etc.) may also play a role. Just an update to close this thread off, we found that by reducing the threshold of the photodiode, the stimuli appeared to be longer. At 75% they were 20ms short. At 66.7% they were precisely as expected. Below 66.7% The were slightly too long. So this appeared to be the effect of the LCD screen ramping up / down luminance as in https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 Good to know! Thanks for the update.
|
|
|
|
|
seandr
|
|
|
Group: Administrators
Posts: 1.3K,
Visits: 5.6K
|
Thanks for the follow up, Andrew. Glad you were able to sort this out.
-Sean
|
|
|
|