I am interfacing PTB3 with arduino uno to perform behavioural experiments in animals. I am currently using the arduino to control the apparatus of the experiment (water delivery, linear actuator, etc) and using MATLAB to deliver visual stimulation whenever necessary (it achieves this by reading serial info from arduino and triggering PTB3).
I tried to measure the latency between the trigger from the arduino (to the data acquisition box) and the photodiode that was attached to the monitor. I am seeing ~60ms lag between the trigger and the visual stimulation, which is problematic.
I am using a Windows 10 machine with Intel HD620 graphics card. MATLAB2020b, updated PTB3 to the newest settings. Machine passes VBLSyncTest without an issue.
I am wondering whether this 60ms lag could be the time lag between the communication delay between the arduino and MATLAB, or whether it may be PTB3 related. Any thoughts?
Edit: As I was trying to look for the solution, I decided to look at how fast the Screen(‘Flip’) command takes. I did this by taking the difference between FlipTimeStamp and the vbl of the flip. I get a value of -1 on average. Does this mean that I get 1ms of lag every single time flip occurs? This might explain my 60ms lag because I am showing a drifting grating for 1s on a 60Hz monitor (and thus ‘flipping’ 60 times).
Are you aware that PTB3 also works on the RaspberryPi2/3/4/400 with Raspbian Linux + Octave? That one would allow reliably timed visual stimulation and digital I/O etc. on one relatively chip microcomputer if your stimuli are not too demanding, and could simplify your setup.
Modern Intel HD graphics on Windows10/11 has severely broken visual timing in my experience, it is the most fragile solution under Windows, so i’m surprised if timing works at all. All I ever got throughout the last years on Win10/11 were sync failures at startup or timing error messages at runtime. A 50 msecs lag or timing error range would be possible with undetected timing errors. A slowly responding monitor or photo diode placement not at top-left corner could also up the latency significantly. The best way to get solid and trustworthy timing with Intel graphics is to upgrade to Linux.
The timestamps you reported wrt. vbl and FlipTimestamp make no sense to me, you’d need to show the code you’re using, but the unit of reported time is seconds, not msecs.
For any further advice from myself → help PsychPaidSupportAndServices for a paid support membership.
How are you controlling the Arduino from MATLAB? My experience with the current MATLAB hardware package is the timing is awful (I timed a minimal command-response time of ~30ms). In addition it is annoying as hell to set up and installs hundreds of megabytes of unnecessary dependencies…
What I ended up doing was switching to the older Mathworks legacy hardware interface, which uses the serial port and much much faster. I ended up rewriting the code to use PTB’s IOPort and the command-response time dropped orders of magnitude, you can see some comparisons here: Serial port interface code -- a performance comparison – I also rewrote the controller, so that variable length TTL’s do not block the main PTB loop. This means I can get very fast (submillisecond) command-response control from PTB.
Are you sure your arduino code itself is not doing something that can also introduce the delay? And how are you polling the arduino to “trigger” PTB’s screen flips?
I have definitely considered raspberry pi as an option… might be a time to switch since my stimuli is also very simple.
I’ve also tried the same with nvidia GPUs (Quadro P1000) and the problem still persists. May be an issue with the code. Also, I wasn’t aware about the photodiode placement - I read something similar in the forums. Does the screen update first from the top-left corner? My photodiode was either in the middle or the bottom right corner of the screen - I will have to retest it by changing the location.
I have a bit of a janky set up which will definitely need altering but I’m essentially sending a signal from arduino to matlab (a character or a byte) and matlab is picking that up using the new serial() command combined with readline to trigger the PTB3 stimuli.
I can consider triggering the pins directly from MATLAB as well, but I figured interfacing it this way may give me a better latency (but maybe not?).
I’m more or less confident it’s not the arduino code itself but not confident that the polling of arduino from MATLAB is fast enough. If you have any other ideas on how to do this (instead of how I’ve been doing it - listening on the serial port with MATLAB and then triggering PTB stimuli when a byte appears or something), it would be super great.
I think an alternative is to move onto raspberry pi or a more integrated system like mario has mentioned on top. Will have to test everything again by moving the photodiode to the top-left corner of the screen…
The “new” serial function in MATLAB is serialport(), not serial(), but as I mentioned both are slower than PTB’s IOPort().
Anyway if the Arduino is running at full speed then its latency should be very low. I’m not convinced by your intuition that triggering PTB from the Arduino is better, so the question remains why are you using the Arduino to control PTB drawing? You could just use the Arduino to initiate a more precise sequence in which PTB is in charge of timing directly, or is this some sort of precise closed loop design?
Though not directly related to triggering-in-loop but more response measurement, these papers including one by Xiangrui Li and Mario Kleiner on their custom response box give some idea about expected latencies between PC and serial linked USB devices:
As an aside I also have to mention that I have had latency problems with cheap Chinese made arduino uno clone boards (they were also less reliable!), which went away moving to “genuine” boards and also the super small and fast Seeduino Xiao which is arduino compatible…
Sorry yes you are correct. I meant serialport() instead of serial().
It’s not a closed loop setting. It’s a simple visual task - animal sees the visual cue and then responds (which then the response is picked up by the arduino). The computations of the trial structure and the triggering of the solenoids etc is done by the arduino. This is probably a poor hardware/software implementation (and maybe verything can be done more cleanly if I port everything into raspberry pi) but our lab has never done any visual experiments so I’m trying things out.
To give you a bit more information on how arduino triggers PTB3, after calculating the trial structure (whether it’s a S+ or S-, type of visual stimuli, etc), this information is sent to MATLAB. I pick this information up with MATLAB and then it triggers the corresponding visual stimuli. My one other guess is this information processing by MATLAB after receiving this information from arduino is also adding additional lags (I am using serialport()'s readline function).
The digital trigger that I’m comparing the photodiode to is sent directly from the arduino pins to a data acquisition box (more specifically it’s an ephys acquisition board).
The reason I am using this arduino - MATLAB system was because in prior experiments, we were using a different cue (olfactory cue for example), and we did not require MATLAB to function in parallel with arduino. And of course, because everything was previously running off arduino, we did not have any issues with latency.
I can also try doing this. It seems an easy enough change to my current setup to try it out…