JabJack 12 msec TTL preceeding screen flip

1

Hi PTB community,


I am trying to sync the timing of my screen flip stimulus with TTL outputs to a Neuralynx acquisition system. I am using a 64 bit Linux system running 16.04 with a l4.13.0-45 lowlatency kernal, Neurodrebin downloaded Psychtoolbox-3 (downloaded on 6/11/18), Matlab 2017a, an NViida Quadro graphics card and a U3 LabJack to generate TTL pulses with the code generously provided by IanA. 


The script is able to open serial communication with labjack and send pulses, however, even though I have called labjack to send a pulse after the flip command, it seems like there is a 12 msec delay for when lablack sends out a TTL and the screen flips from black to white, as measured by a photodiode. The some jitter in this signal, but it is submilisecond (~0.7 msec). I just cannot figure out why it is so long. There does not seem to be a large number of frame drops, nor do I see any Timing Sync errors when running my code or opening the screen.


I have also included the code that I have been working with for troubleshooting.


Any advice will be super helpful. Thanks a bunch!

Adeeti 


  

while  ~KbCheck %&& count<numFrames

    count=count+1;

         

    % Flip the color on every frame

    if mod(count,2)

        boxcolor=params.white;

    else

        boxcolor=params.black;

    end

    

    % Draw the rect to the screen

    Screen('FillRect', params.window, boxcolor, centeredRect);

    


    % Flip to the screen

    if count==1

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window);

        record(count,1)=vbl;

        

        if mod(count,2)

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        lj.timedTTL(1,1); % TTL for eahc frame 

        else

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        end


    end


end

   


2
Hi, I currently don't have any LabJack's to test with, but 12ms is definitely not right. The send command time should be 1-2ms max. Are you sure you are measuring the correct frame. Your sample code doesn't look quite right (your flip is in a count==1 condition that only applies once). Here is a slightly modified loop that pulses a white frame every 10th frame along with the TTL only on that frame — it should make it easier to check which TTL links to which frame. Also I'm using a small trick, if you run lj.timedTTL(line,time) once it caches the raw command so if you will use the same [line,time] again you can just omit the value lj.timedTTL() should be as fast as possible.

lj.timedTTL(1,1); % makes a cached command to speed up subsequent calls;

WaitSecs(0.5);

count = 1;

[vbl(count), ~, ~, missed(count)]=Screen('Flip', params.window);

while  ~KbCheck

    % Flip to white every 10th frame

    if ~mod(count,10)

        boxcolor=params.white;

    else

        boxcolor=params.black;

    end

    % Draw the rect to the screen

    Screen('FillRect', params.window, boxcolor, centeredRect);

 

    %flip

    [vbl(count+1), ~, ~, missed(count+1)]=Screen('Flip', params.window, vbl(end) + (waitframes-0.5)*ifi);

    

    % Trigger TTL on every 10th frame

    if ~mod(count,10)           

        lj.timedTTL(); % use previous values again          

    end

    count = count + 1;

end


You could also test by just toggling a FIO line - use the lj.toggleFIO(line) command and it will switch from low to high each time it is called and this should be the fastest way to send something out on the LabJack. I haven't ever tested the LabJack under Linux, but the exodriver is the same as on macOS so I doubt there would be any difference due to the OS (well if anything Linux should be more reliable).

The other potential sources of latency are your display (is it an LCD?) and very unlikely but possibly the photodiode box if it does some kind of signal processing (I always use TLS252R LtoV photodiodes which have a 7µs rise time and output a continuous voltage signal that is easy to measure with an oscilloscope etc.)

IanA


3
Hi Adeeti,

What type of monitor did you use in your experiment? Did you use an LCD monitor?

According to our test (A consumer-grade LCD monitor for precise visual stimulation, Behavior Research Methods, Figure 3), LCD monitors have a fixed delay between the flip time in GPU and the real onset time of the stimulus on the monitors. Maybe this explains why your TTL signal occurred 12 ms before your stim onset on the monitor.

Best!
-YANG


On Thu, Jul 26, 2018 at 3:40 AM, adeeti.a@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Hi PTB community,


I am trying to sync the timing of my screen flip stimulus with TTL outputs to a Neuralynx acquisition system. I am using a 64 bit Linux system running 16.04 with a l4.13.0-45 lowlatency kernal, Neurodrebin downloaded Psychtoolbox-3 (downloaded on 6/11/18), Matlab 2017a, an NViida Quadro graphics card and a U3 LabJack to generate TTL pulses with the code generously provided by IanA.


The script is able to open serial communication with labjack and send pulses, however, even though I have called labjack to send a pulse after the flip command, it seems like there is a 12 msec delay for when lablack sends out a TTL and the screen flips from black to white, as measured by a photodiode. The some jitter in this signal, but it is submilisecond (~0.7 msec). I just cannot figure out why it is so long. There does not seem to be a large number of frame drops, nor do I see any Timing Sync errors when running my code or opening the screen.


I have also included the code that I have been working with for troubleshooting.


Any advice will be super helpful. Thanks a bunch!

Adeeti


while ~KbCheck %&& count<numFrames

count=count+1;

% Flip the color on every frame

if mod(count,2)

boxcolor=params.white;

else

boxcolor=params.black;

end

% Draw the rect to the screen

Screen('FillRect', params.window, boxcolor, centeredRect);


% Flip to the screen

if count==1

[vbl, ~, ~, missed(count)]=Screen('Flip', params.window);

record(count,1)=vbl;

if mod(count,2)

[vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

record(count,1)=vbl;

lj.timedTTL(1,1); % TTL for eahc frame

else

[vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

record(count,1)=vbl;

end


end


end





--

Yang Zhang
------------------------------------------------
Department of Psychology
Soochow University
Dushu Lake Campus
No.1 Wenjin Street, Industrial park
Suzhou, Jiangsu, 215123, China

Or: yangzhangpsy@163.com
------------------------------------------------
4
Hi Adeeti,

What type of monitor did you use in your experiment? Did you use an LCD monitor? 

According to our test (A consumer-grade LCD monitor for precise visual stimulation, Behavior Research Methods, Figure 3), LCD monitors have a fixed delay between the flip time in GPU and the real onset time of the stimulus on the monitors. Maybe this explains why your TTL signal occurred 12 ms before your stim onset on the monitor.

Best!
-YANG




在 2018年7月26日，上午3:40，adeeti.a@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> 写道：


Hi PTB community,


I am trying to sync the timing of my screen flip stimulus with TTL outputs to a Neuralynx acquisition system. I am using a 64 bit Linux system running 16.04 with a l4.13.0-45 lowlatency kernal, Neurodrebin downloaded Psychtoolbox-3 (downloaded on 6/11/18), Matlab 2017a, an NViida Quadro graphics card and a U3 LabJack to generate TTL pulses with the code generously provided by IanA. 


The script is able to open serial communication with labjack and send pulses, however, even though I have called labjack to send a pulse after the flip command, it seems like there is a 12 msec delay for when lablack sends out a TTL and the screen flips from black to white, as measured by a photodiode. The some jitter in this signal, but it is submilisecond (~0.7 msec). I just cannot figure out why it is so long. There does not seem to be a large number of frame drops, nor do I see any Timing Sync errors when running my code or opening the screen.


I have also included the code that I have been working with for troubleshooting.


Any advice will be super helpful. Thanks a bunch!

Adeeti 


  

while  ~KbCheck %&& count<numFrames

    count=count+1;

         

    % Flip the color on every frame

    if mod(count,2)

        boxcolor=params.white;

    else

        boxcolor=params.black;

    end

    

    % Draw the rect to the screen

    Screen('FillRect', params.window, boxcolor, centeredRect);

    


    % Flip to the screen

    if count==1

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window);

        record(count,1)=vbl;

        

        if mod(count,2)

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        lj.timedTTL(1,1); % TTL for eahc frame 

        else

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        end


    end


end

   




5

Well, some LCD's have a fixed delay, in a addition to a more or less highly variable delay that is dependent on the specific visual stimulus and monitor and monitor settings.

I agree that all this looks like problems with the used display, probably a LCD or projector?
If PTB doesn't give any warnings or errors wrt. timing and this is a single-display setup or a multi-display setup with the visual stimulation window on a separate X-Screen from the GUI, then the timing of the signal leaving the graphics card should be very accurate wrt. the trigger. Even more certainty is afforded if you are using the open-source nouveau display driver, instead of NVidia's proprietary blob, but even then it should be fine.

Posting PTB's full output here from running our tests, like PerceptualVBLSyncTest as most basic verification, would help to double-check your results.

Generally, if you use a digital display instead of a CRT monitor, you always want to run the display at its native video mode -- the maximum supported native resolution and video refresh rate. Other resolutions/refresh rates may cause additional signal processing inside the displays controller, with usually bad consequences for deterministic timing.

-mario

---In PSYCHTOOLBOX@yahoogroups.com, <zhangyang873@...> wrote :

Hi Adeeti,

What type of monitor did you use in your experiment? Did you use an LCD monitor? 

According to our test (A consumer-grade LCD monitor for precise visual stimulation, Behavior Research Methods, Figure 3), LCD monitors have a fixed delay between the flip time in GPU and the real onset time of the stimulus on the monitors. Maybe this explains why your TTL signal occurred 12 ms before your stim onset on the monitor.

Best!
-YANG


On Thu, Jul 26, 2018 at 3:40 AM, adeeti.a@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Hi PTB community,


I am trying to sync the timing of my screen flip stimulus with TTL outputs to a Neuralynx acquisition system. I am using a 64 bit Linux system running 16.04 with a l4.13.0-45 lowlatency kernal, Neurodrebin downloaded Psychtoolbox-3 (downloaded on 6/11/18), Matlab 2017a, an NViida Quadro graphics card and a U3 LabJack to generate TTL pulses with the code generously provided by IanA. 


The script is able to open serial communication with labjack and send pulses, however, even though I have called labjack to send a pulse after the flip command, it seems like there is a 12 msec delay for when lablack sends out a TTL and the screen flips from black to white, as measured by a photodiode. The some jitter in this signal, but it is submilisecond (~0.7 msec). I just cannot figure out why it is so long. There does not seem to be a large number of frame drops, nor do I see any Timing Sync errors when running my code or opening the screen.


I have also included the code that I have been working with for troubleshooting.


Any advice will be super helpful. Thanks a bunch!

Adeeti 


  

while  ~KbCheck %&& count<numFrames

    count=count+1;

         

    % Flip the color on every frame

    if mod(count,2)

        boxcolor=params.white;

    else

        boxcolor=params.black;

    end

    

    % Draw the rect to the screen

    Screen('FillRect', params.window, boxcolor, centeredRect);

    


    % Flip to the screen

    if count==1

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window);

        record(count,1)=vbl;

        

        if mod(count,2)

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        lj.timedTTL(1,1); % TTL for eahc frame 

        else

        [vbl, ~, ~, missed(count)]=Screen('Flip', params.window, vbl + (waitframes-0.5)*ifi);

        record(count,1)=vbl;

        end


    end


end

   





--

Yang Zhang
------------------------------------------------
Department of Psychology
Soochow University
Dushu Lake Campus
No.1 Wenjin Street, Industrial park
Suzhou, Jiangsu, 215123, China

     Or: zhangyang873@...
     Or: yangzhangpsy@163.com
------------------------------------------------
6
Thank you all for your input!

IanA, you are absolutely correct, my code missed an else and therefore was wonky. I did try the code that you provided in your response and I am still getting the same delay. I really don't think the delay can be coming from my photo-diode since I am using a patch clamp amplifier to convert the signal from current to voltage (definitely hitting a fly with a machete but it works).

I am using a commercial grade LCD monitor (Dell, U2414H). While I am using the proprietary drivers for NVIDA, I agree that I do not think they are causing the issue. The PerceptualVBLSyncTest did not cause any non-homogeneous patterns that I could see. Moreover, VBLSyncTest seemed to miss 1 out of 600 stim presentations which from what I understand is within measurement error. The full output I have included below.

Given that many of you have concurred that this is probably coming from the LCD monitor, I am a little bit confused on what to try next. I can hook up a permanent photo-diode in the corner of my screen to get accurate timings and post hoc align them with a log from psychtoolbox. I unfortunately do not have enough money to put into a BitsSharp, VPixx or CRT monitor. Are there any other solutions that you would recommend?

Thanks again for all of the help- I really appreciate it!
Adeeti






PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.14 - Build date: Apr  6 2018).
PTB-INFO: Support status on this operating system release: Linux 4.13.0-45-lowlatency Supported.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: NVIDIA Corporation - G84GL [Quadro FX 570] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia G84GL [Quadro FX 570] GPU of NV-050 family with 2 display heads.


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: Quadro FX 570/PCIe/SSE2 :: 3.3.0 NVIDIA 340.104
PTB-INFO: VBL startline = 1080 , VBL Endline = 1124
PTB-INFO: Measured monitor refresh interval from beamposition = 16.666879 ms [59.999234 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.666842 ms [59.999371 Hz]. (50 valid samples taken, stddev=0.000999 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.                                                                                                                              
 
7
Hi Adeeti, it is not entirely clear to me from your first post which of the two signals is actually the delayed one, the TTL or the photodiode signal. First I was assuming it was the TTL signal, because a delayed photodiode signal would be much less of a surprise. Your LCD runs at 60Hz (=1/16.67ms), so if you measure close to the bottom of the screen, you will easily observe such a delay, even if the LCD works perfectly fine. The value also depends on which point of the photodiode signal you take as reference, given that the rise and fall times of LCDs can be several milliseconds So without having more detailed information it is hard to tell whether there is a problem at all.
8
I think from the side of PTB and the graphics card everything seems to be optimal and it is only the monitor that causes this - also dependent on the exact pixel color/intensity values you are using.

TFT-Central did a full test of your monitor, so there's lots about timing and color reproduction esp. wrt. fast changing stims:


So for a photo-diode placed at the top-left corner of the display, which is what correponds to the timestamps returned by 'Flip' / your trigger, a 11-12 msecs lag would be expected. You can see the histograms there that give you an idea how the timing changes depending on grayscale/color values of your pixels.

Btw. your gaphics card is old enough that the open-source default nouveau driver would do a good enough job, likely no need for the proprietary driver, and the FOSS driver gives extra convenience of setup and peace of mind wrt. timing checks. But that just for future reference.

-mario

---In PSYCHTOOLBOX@yahoogroups.com, <adeeti.a@...> wrote :

Thank you all for your input!

IanA, you are absolutely correct, my code missed an else and therefore was wonky. I did try the code that you provided in your response and I am still getting the same delay. I really don't think the delay can be coming from my photo-diode since I am using a patch clamp amplifier to convert the signal from current to voltage (definitely hitting a fly with a machete but it works).

I am using a commercial grade LCD monitor (Dell, U2414H). While I am using the proprietary drivers for NVIDA, I agree that I do not think they are causing the issue. The PerceptualVBLSyncTest did not cause any non-homogeneous patterns that I could see. Moreover, VBLSyncTest seemed to miss 1 out of 600 stim presentations which from what I understand is within measurement error. The full output I have included below.

Given that many of you have concurred that this is probably coming from the LCD monitor, I am a little bit confused on what to try next. I can hook up a permanent photo-diode in the corner of my screen to get accurate timings and post hoc align them with a log from psychtoolbox. I unfortunately do not have enough money to put into a BitsSharp, VPixx or CRT monitor. Are there any other solutions that you would recommend?

Thanks again for all of the help- I really appreciate it!
Adeeti






PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.14 - Build date: Apr  6 2018).
PTB-INFO: Support status on this operating system release: Linux 4.13.0-45-lowlatency Supported.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: NVIDIA Corporation - G84GL [Quadro FX 570] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia G84GL [Quadro FX 570] GPU of NV-050 family with 2 display heads.


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: Quadro FX 570/PCIe/SSE2 :: 3.3.0 NVIDIA 340.104
PTB-INFO: VBL startline = 1080 , VBL Endline = 1124
PTB-INFO: Measured monitor refresh interval from beamposition = 16.666879 ms [59.999234 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.666842 ms [59.999371 Hz]. (50 valid samples taken, stddev=0.000999 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.                                                                                                                              
 
9
Thank you all for the input and for the article! I guess I will have to find a different monitor to get this working.