Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 2      1   2   Next
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #1 
In MonkeyLogic 2
Code like this:

toggleobject(stimuli, 'eventmarker', 20);
ontarget = eyejoytrack('holdfix', ...............)
if ~ontarget
'''
'''
'''
end
toggleobject(stimuli, 'eventmarker', 21);


I use a photodiode to record screen brightness.


While, the timestamp of stimuli on eventmarker is not equal to the true stimuli on in the screen detected by photodiode. The latency maybe 16ms, more or less, which is depended by refresh rate and other reasons.

Why the latency between event marker and the real stimuli on the screen is so big? Any way to solve this problem?

Thank you.


0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #2 
Hi Jack_23,

It seems that, with the previous flip timing setting, the graphic board updated the screen one frame later consistently. I changed the timing in the latest NIMH ML, so please download it and see if it helps with the problem. I don't have tools to measure this timing properly, so I may ask you to do some testing. Thanks.
0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #3 
Thank you.
However, I tested the latest ML2, and the problem still exists. Here, The latency between eventmarker and the real screen brightness change is unstable, sometimes 8ms(This may be the reason of LCD? The fresh rate is 100 hz), sometimes 18ms.

And in matlab, when I run "monkeylogic", a error like this "warning: while loading an object of class 'mlconfig
When constructing an instance of class mlconfig, the constructor must preserve the class of the returned object.
>In monkeylogic/loadcfg (line 2113)
>In monkeylogic/init (line 1661)
>In monkeylogic/ (line 40)
'"
While, this error doesn't affect running tasks.

Is it possible for someone to test the latency between eventmarker and the real brightness change in CRT? Then, it will help to find where the latency come from, the monkeylogic, the LCD, or both? 

I use AUSU VG248QE LCD screen. 

Thank you very much.
0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #4 
I was going to ask about your monitor. Thanks for the information.

It appears that this problem is highly dependent on the setup and the monitor. Issuing the flip command a little earlier seemed to help, so I changed the flip timing in the new package. But a safe value with one monitor does not work with another.

I will get a CRT monitor soon and be able to do more tests about this.

The warning is because I got rid of an unused variable from the config. Once you overwrite the CFG file, it will disappear.
0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #5 
Thank you very much.
I wonder whether I can send eventmarker in these codes in ML2?
'''''''
run_scene(scene3,30);
if ~wth3.Success
run_scene(endscene);
trialerror(3); % broke fixation
return
end
''''''''

Since in ML2, we can do something in each frame. For example, in the loop,  in the first frame, I send event marker.
Is it possible to do so?

Thank you very much.
0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #6 
Can you explain a little more? I don't understand what you exactly want to do.

The second argument of run_scene is the event code that is sent out after the scene starts. For example, run_scene(scene3,30) sends out the code, 30, when the first frame of scene3 is presented. You can send out a marker every frame, but I didn't make an adapter that does it yet.
0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #7 
I tested the delay of 30, 31 eventmarkers and the time when the screen brightness changes.
code like this:

run_scene(scene2, 30)
if ~wth2.success
...
...
end

run_scene(endscene, 31)


The delay between eventmarkers and screen brightness changes of one trial like this:
Screen Shot 2018-04-14 at 3.13.23 PM.png  In the left part, black vertical line represents eventmarker 30, which mean stimuli on, vertical yellow line represent the brightness change of the scene, which means the real stimuli on in the screne.
In the right part, grey vertical line represents eventmarker 31. And blue vertical line represent the real stimuli off in the screne.

The delay between black vertical line and yellow vertical line is 12ms, in some trial maybe 23ms, which is unstable. 

eventmarker 31 - eventmarker 30 is not equal to the set stimuli presenting time, maybe 10ms or 20ms more.


------------------------------------------------------------------
I wonder, since in ML2, we can do something in each frame. Then, we send eventmarker in or after the first frame, and in or after the last frame. Could this make eventmarker more close to the real screen brightness change? 
I do not know how to send eventmarker in the adaptor? Command eventmarker(30) will raise an error.

Thank you.

0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #8 
I am aware of the issue and working for a solution. LCDs have very different characteristics from monitor to monitor. I tried to find one fixed parameter that works for every LCD, but now I think it is not going to work. This has to be tested for each monitor individually. Please give me some time.

By the way, your photo detector signal is pretty stable. I am having a difficulty in getting clear on/off response due to some noise. Did you buy it somewhere? Or did you build it yourself?
0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #9 
I just bought the photodiode in the online store, which is like this.
Screen Shot 2018-04-14 at 9.23.14 PM.png 
The photodiode, a 5V battery, and a BNC connector which is connected to the data acquisition system, these three parts are series connected. By this way, the photodiode is like a switch which is controlled by the light.
I suggest trying to change the positive and negative charges of the battery when connected to see which one will produce better signal.

By the way, could you please provide a demo task to test the accuracy of refresh rate and eventmarker? For example, a stimulation which presents white picture and black picture separately frame by frame. And two eventmarker, represent stimuli on and stimuli off will be send. Using this demo, it will be easy to test both refresh rate and eventmarker accuracy using a photodiode.

Looking forward for the new version of ML2.

Thank you.

0
aboharbf

Member
Registered:
Posts: 55
Reply with quote  #10 
Quote:
Originally Posted by Jaewon
I am aware of the issue and working for a solution. LCDs have very different characteristics from monitor to monitor. I tried to find one fixed parameter that works for every LCD, but now I think it is not going to work. This has to be tested for each monitor individually. Please give me some time.

By the way, your photo detector signal is pretty stable. I am having a difficulty in getting clear on/off response due to some noise. Did you buy it somewhere? Or did you build it yourself?


Do you anticipate this problem existing in CRTs as well? I was about to do the kind of testing Jack_23 has done, and we're using CRTs.
0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #11 
Yes, I think this delay maybe exists in CRT. Please take a test. This may help to solve the problem. 
0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #12 
Here is what I found so far, as well as a solution I suggest.

Before the Apr 10, 2018 version, screen flipping was executed during the vertical blank (VB) time. Although it was a common technique in game programming that ensured the maximum performance of the software, it made the screen contents displayed consistently one frame late both in LCDs and CRTs.

In the Apr 10, 2018 version, the timing of screen flipping was moved forward by 12.5% of the frame length. This value was empirically determined from many tests with different monitors and helped with the aforementioned problem. However, one fixed value didn't seem to work with all LCD monitors. CRTs seem to require much shorter time than the time that LCDs need.

Due to the wide difference of LCD monitors' response characteristics, the flipping timing needs to be customized for each monitor. I built a tool in the Apr 16, 2018 version to do so. To use the tool, you need a working photo detector. The instructions are as below. If you don't have a photo detector, do not change the default parameter.

The default flipping timing of the Apr 16, 2018 version is 13% of a frame length ahead of VB. In case of a 60 Hz monitor, it is roughly 16 ms * 0.13 = 2 ms. So ML will present stimuli and wait for (2 ms + VB) until the screen actually changes. Since ML cannot perform any other action during this time, you may want to decrease this time for better performance by running a test, as shown below. Or you may need to increase it to compensate the response speed of your monitor. It is up to the test result.


* Instructions for tuning photodiode response

1. Assign the Photodiode signal to an analog input channel that your photo detector is connected to.

2. Select the position of the photodiode on the screen.

3. Click the "Tune" button.

phototuner.jpg 


4. Upon opening, the tool will flash a white square on the given location of the screen, to get some basic information of the pulse response of your photodiode, and show a figure like the following. The monitor spec used in this example was 1027 x 768 and 85 Hz (CRT).
phototuner2.jpg
What is important here is Threshold. Threshold can take any value between two numbers in the Scanline field ([39 806] in the above figure). Here, the current threshold is 706 as set by default (= 39 + 0.87*(806-39)). If it becomes larger, the flipping timing gets closer to the VB, which gives ML more time to work on other things, but may make the screen update pushed to the next frame. If it becomes smaller, the opposite things may occur.

[Reset]: Reset the Threshold to the initial value of when the tool started.
[Test]: Run a test to check the photodiode response with the current parameters
[Start automatic tuning]: Examine a half of the scanline range automatically from the largest scanline. After one scanline threshold is tested (by 100 times as specified in # of triggers), the threshold is decreased by the scanline interval and the test is resumed until it reaches the middle line. The result is acceptable, only when the number of failed triggers is less than Tolerance. A failed trigger is the one that evokes the photodiode response later than the shortest latency.


5. This is an example test performed with the highest threshold (=806-20, 806 is skipped because it is right before VB). Most of triggers evoked the response immediately, but one trigger did one frame late. Since Tolerance is 0, this threshold (786) won't be accepted.
phototuner3.jpg   

6. This is the result of the last iteration. The automatic test is done, once the threshold comes down below the mid line. From the last two messages, you can see that the new threshold is now scanline 766, not 706. So you lose only 5% of the frame length now ((766-39)/(806-39)=0.95), instead of 13%. The latency between the trigger and the photodiode response is 0.891 ms in that condition.
phototuner4.jpg
Since this threshold was determined with a limited number of testing (100 times), you may want to manually type a threshold even lower than 766, like 746, to further decrease the possibility of getting the screen update pushed to the next frame.


0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #13 
Sorry to the late reply. 
I have tested the Apr 16 version of ML2. However, I can't find a right threshold, either by manual set or by automatic. For most trials, the delay between eventmarker and photodiode signal is 3ms, which may be the reaction time of the LCD. However, there are always some trials, the latency is 13, 14ms, a frame time more. 
I think that  the refresh rate of this LCD is not stable may be the reason. See the below figure.
Screen Shot 2018-04-20 at 5.29.28 PM.png  The time of each frame is not always the same.


However, for the Jan-19 2018 version of ML2, the delay between eventmarker and photodiode signal is quite stable, for example, 15 ms. The variation is lease than 1ms.
For the Apr-10 and Apr-16 version, the delay between eventmarker and photodiode signal may be small. However, the variation is unstable. There are always some trials, a frame time more may happen.

So, I want to know, why this difference happens. 
Currently, I still use Jan-19 version. Because, even the latency is larger, it is quite stable, which is important for electrophysiological recording.

Can Apr-10 and Apr-16 versions make the latency stable?

Thank you very much for the improvement you have made. This debugging work always take much time. Thank you.


0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #14 
Thanks for the testing, Jack_23. Actually my finding was exactly the same as yours. If the flip command was issued earlier than VB, it decreases the frequency of delayed presentation. But, no matter how early I flipped the screen, I saw delayed presentations occur from time to time.

If you want ML to behave as it used to, it is okay. But I want to come up with a general solution that everyone can be happy with. So let me do some extended testing and decide what to do.

By the way, have you tried some extreme value for the threshold, like 100? I just want to make sure that the threshold was low enough.

0
Jack_23

Member
Registered:
Posts: 31
Reply with quote  #15 
Yes, I also tried threshold from 0 to 500, including 100. The the delay were also unstable.
0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #16 
I did some research and a little more tests. I am pretty sure that NIMH ML is precise in terms of timing of issuing flip commands. However, the actual time of stimuli showing up on the screen is still up to the graphics driver and the monitor. So, if the system is under a heavy load momentarily, it is likely that stimuli will go on the screen in the next frame, even though the driver already received the flip command. Running the flip command during VB time seems to make flips occur at consistent timing regardless of the current load of the system, but there is always a delay of one frame length in this case.

It seems that no one method or single parameter can solve this issue for all the computers, so I just decided to improve the tuning tool and let users to set their systems on their own. If you want to do screen flip during VB as Jack_23 wants, download the new NIMH ML package I just uploaded (Apr 23, 2018) and set the threshold to 0 in the photodiode tuner. If the threshold is non-zero, ML will issue the flip command before VB. I changed the default value to 10% of one frame (e.g., if the screen vertical size is 1080, the flipping will occur when the scanline is below 972). Since the value I set in the previous version (13%) does not work for all anyway, I guess there is no need to use a large value here.

The picture below is my test result in which a white squire was presented for one frame duration every 3 frames (blue line). Two eventmarkers (yellow line) were alternately sent when the square was turned on and off. To make my monitor present stimuli at the same time as the eventcode, I had to call the flip command a lot earlier (at least 2.8 ms before VB), but no single frame was presented late for several minutes, as long as I didn't run other jobs together on the computer.
   IMG_20180423_165620.jpg 



0
Geenaianni

Junior Member
Registered:
Posts: 27
Reply with quote  #17 
Hi All, 
I am running ML on a an LCD monitor (Benq, XL2411T, a gaming monitor) & noticed a large delay as described above, between my eventmarkers & photodiode signal, usually in the range of ~36 ms. The blue line is the photodiode signal, & black are eventmarkers. (as a separate issue, red lines are "reward" eventmarkers, which seem to have an even greater lag wrt the photodiode signal...)
ML_pd_1.png   
When I run the photodiode tuning function, the initial response looks like -- 
ML_pd_2.png   

When I attempt to run autotuning however, the response of the photodiode (relative to the black bar) increases significantly -- 
ML_pd_3.png   

I tried then to adjust the threshold manually. (~150 for example, to move flipping timing farther from the VB), and while this reduces the latency, the behavior becomes unstable --
One test with Threshold at 150 reduces latency to 17.7 ms, with 0 failed triggers, while a second test at 150 results in a latency of 31.8 with a majority of failed triggers.
ML_pd_4.png   

What is going on here? Is it that my LCD monitor is not responding to the flip command in a stable manner, or is there some way to fix this with ML alone?

thanks as always.
Best,
Geena

0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #18 
This latency is hidden in the graphics card and the monitor, so it is difficult to tell why it happens. Can you run some tests for me?

1. It seems that this monitor's native resolution and refresh rate are 1920 x 1080 and 144 Hz, so run the tests with those settings.

2. Try the same tests after making the subject monitor as the main (primary) display.

3. Set the threshold 0 and see if the test results are still variable.

Regarding to the reward event markers, did you stamp those markers like this?

goodmonkey(200);
eventmarker(10);

Or like this?

goodmonkey(200,'eventmarker',10);

You need to show me your code.
0
Geenaianni

Junior Member
Registered:
Posts: 27
Reply with quote  #19 
Hi Jaewon, 
we will do these tests today & get back to you. regarding the code, (attached), I am using 
goodmonkey(100, 'juiceline',1, 'numreward',1, 'pausetime',100, 'eventmarker',40);

 
Attached Files
m fixate_reward_v2 (1).m (4.52 KB, 1 views)
m fixate_reward_userloop (1).m (3.70 KB, 0 views)

0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #20 
You added idle() before goodmonkey(). That was the lag you saw. See the comments below

run_scene(endscene, 30);  % The photodiode trigger is ON here and becomes OFF right away because the duration of endscene is 0.
idle(jitter_delay);
goodmonkey(reward_dur, 'juiceline',1, 'numreward',1, 'pausetime',100, 'eventmarker',40);  % But reward (and the code 40) is delivered after 'jitter_delay', so there will a gap up to that amount of time
0
Geenaianni

Junior Member
Registered:
Posts: 27
Reply with quote  #21 

the documentation indicates "Use [Windows Display Settings] to change the resolution" -- is this meant through a button in ML or just via the computer running ML ? Bc I do not see any such settings on the ML main menu 

0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #22 
Via the computer running ML. You need to restart MATLAB after changing the screen resolution. MATLAB does not detect the screen change automatically.
0
Geenaianni

Junior Member
Registered:
Posts: 27
Reply with quote  #23 
regarding #1 above, I wasn't able to do that because I couldn't find where to switch the refresh rate in ML -- please let me know & ill try that too.

regarding #2/#2 -- 

with threshold = 0 & subject screen set as main/primary display, latency is stable at ~51 ms over 200 triggers -- 
thres0_ssMain_2.png 
with threshold = 0 & subject screen as secondary display, latency stable at ~32 ms over 700 triggers --
[just for contrast, threshold = 500 & subject screen as secondary display, did NOT result in a stable latency (17.7 - 34.7 ms over 400 triggers)]
thres0_3.png 


0
Jaewon

Administrator
Registered:
Posts: 708
Reply with quote  #24 
You should change the refresh rate via Windows as well. You can do it in the [Display adapter properties (Win10)] or the control panel of the video driver. Don't forget to restart MATLAB after changing it.

Could you repeat the same tests--primary vs secondary display--with the new refresh rate? And have you tested threshold = 500 & primary display as well?
0
Geenaianni

Junior Member
Registered:
Posts: 27
Reply with quote  #25 
I did test threshold = 500 with subject screen as primary display, which gave a latency of 34.7 ms stable over 300 triggers. 

It doesnt appear that I am able to change the refresh rate of the monitor from 60 Hz (both display adapter properties & video driver options list 59 or 60 Hz as only options). I'm guessing this could be bc of the DVI-d cable that connects the ML computer to our subject display doesn't support 144 Hz.

I will try to find a solution that allows us to change the refresh rate of the monitor, but in the meantime, what makes you think that 144 Hz is the native rate & why would that make the latency so long?
 
 
 
 
 
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.