Issue with Photodiode Tuner in MonkeyLogic

Dear Jaweon,

The photodiode tuner in MonkeyLogic is not working properly during calibration. The attached screenshot from the Photodiode Tuner shows an unstable signal, failing both one-shot and multi-shot tests. Warnings indicate "No photodiode signal from frame start," "No signal detected," and "No stable signal > Default threshold," with the new threshold set to 0.

I have used a 120 Hz refresh rate monitor.

Could you please suggest any troubleshooting steps?

The tuner is working as I wrote. It does not support NVIDA and I programmed it to show those messages.

You are just not getting signals from the photodiode. Check if it is working properly.

Thanks for the response.

The NVIDIA issue is resolved now. Currently, I am using the HDMI connection from an Intel graphics card to two monitors.

Currently, I have an issue with the delay between the behavior code time and the onset of the photodiode pulse. I have one scene where I only show a white box graphic in the top left (though I checked all four corners of the screen), and a photodiode detects the flash. It appears for one frame with a 120 Hz monitor. However, when I measure the difference between the behavior code time of the scene and the onset of the photodiode pulse, it comes to about 47.99 ms (+/- 5 ms). As far as I understand, the event marker associated with the behavior code of a specific scene indicates the time of stimulus onset. Is this correct?

Could you please clarify the reason for the delay between the scene start time and the photodiode pulse onset? Additionally, we would appreciate your suggestions on how to resolve this issue.

Try testing with a lower resolution and a slower refresh rate, like 1024 x 768 px and 60 Hz. And is your subject screen the main display of the computer?

Thank you very much, Jaewon, for your prompt response.

I have another important question. Suppose I have a box graphic in one scene, and after recording the task, the code time for the event marker is 200 ms. Does this behavior code time accurately reflect the moment the box graphic appears on the screen? In other words, is there any delay between the behavior code time and the actual stimulus onset on the monitor? If there is a delay, is this constant across every trial?

Could you please clarify this to ensure the accuracy of our timing measurements?

I think you have the answer, not me, since you have tested with the photodiode to find it out. If what you ask about is how NIMH ML is designed, please show me your code and how you calculate the difference.

Hi Jaewon,

I have measured the lag between the photodiode onset and the behavior code time in two different configurations using the same timing script. A TTL pulse is sent in the first scene, and a photodiode is also flashed from the MonkeyLogic photodiode tunner option.

The photodiode is positioned at the upper left corner of the monitor. We are using an NI DAQ to receive the analog input from the photodiode device with a sampling rate of 1000 Hz.

Timing script:

hotkey('x', 'escape_screen(); assignin(''caller'',''continue_'',false);');

bhv_code(10,'s1');

ttl = TTLOutput(null_);
ttl.Port = 1; % TTL #1 & #2 must be assigned in the I/O menu.
ttl.Duration = 8; % The 1st pulse is 500 ms long and the 2nd pulse is 1000 ms.
scene1 = create_scene(ttl);

run_scene(scene1,10);

idle(100);


1. Delay (in ms) with 60 Hz, 1920 by 1080 display resolutiondistribution of delay figures attached)
TIMING STATISTICS
==================================================================================
Metric | Mean +/- SD | Median | Range [Min,Max] | 95% CI (Mean)
----------------------------------------------------------------------------------
pd_scene_delay | 50.87 +/- 6.20 | 52.02 | [ 40.58, 77.03] | [ 49.66, 52.09]
==================================================================================


2. Delay (in ms) with 60Hz, 1024 by 768 display resolution based on your suggestion (distirbution of delay figures attached)
TIMING STATISTICS
==================================================================================
Metric | Mean +/- SD | Median | Range [Min,Max] | 95% CI (Mean)
----------------------------------------------------------------------------------
pd_scene_delay | 50.85 +/- 9.75 | 52.41 | [ 37.09, 69.82] | [ 48.94, 52.76]




Can you suggest what to do next to minimize this latency?

Thanks
Kalpa

First of all, the photodiode tuner is the tool of which window you captured and attached in your first message. The white square presented in the corner of the subject screen is called the photodiode trigger. The trigger works whether you run the tuner or not.

What I would also like to see is your code that does the calculation (i.e., how the calculation is done). I do not need any statistics.

Can you capture the photodiode tuner and post it again, as you did in the first message?

Hi Jaewon,

I have tried something, and I think we are getting closer. The photo is attached here. In the multishot, it shows 18.2 ms. We have made some modifications to the display cable connections from the CPU. What I observed is that we can't use HDMI connections on the control screen monitor and the subject screen monitor. Then the delay becomes 37 ms on average (which you can also test if you want). I don't know the reason behind this.

Now we have both the DP port and HDMI port, with the HDMI port connected to the subject screen and the DP port connected to the control screen. Both are running at a 60 Hz refresh rate, and variable refresh rate is disabled on the monitors. The issue is that we can't use the 120 Hz monitor in this setup, even though we have it, because at 120 Hz, the photodiode does not flash on the screen. We need a 120 Hz refresh rate to achieve more precise touch positions from the pen data.

Another question is whether there is a way to measure the time lag between the frame start (or even code time) and the photodiode onset time on the oscilloscope, independent of MonkeyLogic. Currently, we measure the lag using the onset of each trial's analog photodiode data saved on MonkeyLogic and the related event code time.

Could you look into the above matters?


Thanks
Kalpa

I do not know what kind of touch detection method your device is using, but the refresh rate of the monitor has nothing to do with the precision of touch position.

The eventcodes are also sent out via the NI board, if "Behavioral Codes" is configured. You can use that output, I guess.

Hi Jaewon,

Thank you for your response.

Based on my understanding, when using the XP-PEN Artist 22R Pro 22 Inch Drawing Pen Display Graphics Monitor on a 60Hz monitor, the MonkeyLogic touch data shows repeated samples, usually 16 (16 ms), sometimes 15. When switching to 120Hz, the repeated samples decrease to 8 (8 ms). It seems that the number of repeated samples correlates with the screen refresh rate.

Could you please clarify this?

Ah, you were talking about temporal resolution. Yes, the current implementation is tied to the refresh rate, not to violate more important time constraints.

Thanks for the clarification!