Lost frames using SmoothPursuit

Hello

I have a big problem of lost frames when I use the adapter SmoothPursuit(eye_)

Here is the config recognized by ML
NIMH MonkeyLogic 2.2.20 (Oct 27, 2021)
Microsoft Windows10
MATLAB (R2020b) Update 2
NIMH daqtoolbox 1.0.72 (Feb 4, 2021)
National Instruments NI-DAQmx 20.1
Intel64 Family 6 Model 158 Stepping 10, GenuineIntel
Detected 12 "AMD64" processors
Found 2 video device(s)...
Found 2 DAQ adaptor(s), 2 board(s)

Stimuli are presented on an ASUS ROG 2560*1440 60 or 85 Hz (diplay port connected).
Eye signals are acquired at 1000 Hz with an eyelink, and transfered to ML through a PCIe-6321 card.

Latency test works fine at 60 Hz and at 85 Hz. It looses frames though when testing monitor is not the main monitor. I then setted it up as the main monitor. Also, I've done each of the troubleshooting steps provided on the website. My problem does not seem to be related to the monitor or windows or even ML, but really about SmoothPursuit.

However, when I run the task pursuit (provided in the example), or when I use the SmoothPursuit(eye_) adapter in an home made task, I loose approximately half the frames. The target does not moves smoothly at all. The problem is the same at 60 and 85 Hz (even 120 Hz on another monitor).

Here are
the timing file of the home made task: [amubox.univ-amu.fr]
the condition file: [amubox.univ-amu.fr]
one bhv file: [amubox.univ-amu.fr]
and the latency test for 85hz: [amubox.univ-amu.fr]

I've tried it in a different set up and the problem is the same (even worth).
I've tested it on my laptop (windows 10, ML 2.2.17, matlab 2019b, connected on another monitor through HDMI, no PCI express, no eye signal) in simulation mode works perfectly fine.

Any help would be greatly appreciated. Could it be related to the last ML update?

Thanks
Guilhem

You had better check whether your SmoothPursuit is modified or you have a custom version in your task directory. Do you see the same in the simulation mode?

Smoothpursuit has never been modified. I've checked it's the same as the ones on other machines. Problem is similar in simulation mode.
Really not sure why it does that and how to solve this problem.

You set the size of its threshold window to 300 degrees, which is probably 30 times larger than your monitor. Reduce the threshold.

thanks, it seems that was the problem and there is no problem with the codes...

Arggh, that was that dumb... I've set it up as high so I could test it without entering simulation mode and without changing manually the inputs from the eyelink. It turns out I created the problem. Thanks for your help and sorry for the confusion...
G