I’m using v3.0.2 standalone and I want to start an eyetracker from psychopy. On the Psychopy API website, there is no entry for the eyetracker yet (http://www.psychopy.org/api/iohub/device/eyetracker.html), so the issue might be with my PsychoPy code but also, external to PsychoPy, with the way I organize the SMI soft- or hardware. Any help narrowing down the error is greatly appreciated!
Initially, I received the warning: msgpack_numpy could not be imported. I have now installed msg_numpy as an external package (Add Costum Modules)
I no longer get the message, about msg_numpy, but I still cannot start an iohub connection. The following code is based on the Builder demo for eyetracking with iohub.
from psychopy.iohub.client import ioHubConnection, yload, yLoader
# Create an ioHubConnection instance, which starts the ioHubProcess, and informs it of the requested devices and their configurations.
But the iohubConnection throws an error:
ioHub Server Process Completed With Code: 1
Traceback (most recent call last):
File "C:\User1\Experiment_MSVR\startrecording_eyetracker.py", line 17, in <module>
File "C:\Program Files (x86)\PsychoPy3\lib\site-packages\psychopy\iohub\client\__init__.py", line 290, in __init__
raise RuntimeError('Error starting ioHub server')
RuntimeError: Error starting ioHub server
Does anyone have input on this issue? Unfortunately, I am still stuck.
Unfortunately that’s an extremely uninformative error. Based on my own experiences with iohub, it could be something about the YAML file, or it could be a new issue in PsychoPy3 (which I have not attempted to use with my eye-tracker yet). Could you share your YAML file?
Thank you so much for replying!
Is there a way to tell whether the error is a result of values supplied by the yaml file?
I couldn’t upload a yaml file, so I’ll just copy the content of the file here:
# specifies what devices to monitor
# SMI iView Config (cf. http://www.isolver-solutions.com/iohubdocs/iohub/api_and_manual/device_details/eyetracker_interface/SMI_Implementation_Notes.html)
# *If* the ioHubDataStore is enabled for the experiment, then
# indicate if events for this device should be saved to the
# data_collection/keyboard event group in the hdf5 event file.
# streamEvents: Indicate if events from this device should be made available
# during experiment runtime to the PsychoPy Process.
# True = Send events for this device to the PsychoPy Process in real-time.
# False = Do *not* send events for this device to the PsychoPy Process in real-time.
# Port being used by iView X SDK for sending data to iView X
# IP address of local computer
# For Win10: Systemsteuerung\Netzwerk und Internet\Netzwerk- und Freigabecenter
# Set IPv4 of the ethernet connection to the ip specified here
# port being used by iView X SDK for receiving data from iView X
# type: How many points should be used for the calibration sequence.
# Valid inputs are THREE_POINTS, FIVE_POINTS, NINE_POINTS
# pacing_speed: How long a calibration point should
# be displayed before moving onto the next point when auto_pace
# is set to true. iViewX supports two values for this field: FAST and SLOW
# If auto_pace is False, pacing_speed is ignored.
# model_name: The model_name setting allows the definition of the eye tracker model being used.
# For the iViewX implementation, valid values are:
# RED, REDm, HiSpeed, MRI, HED, ETG, or Custom
I have the same problem. It might be that the available demos are not compatible with the eyetracker you use. Which one do you use?
Someone suggested to me to downgrade the used python and, if that doesn’t work, downgrade to psychopy 2 wich definatly works with the eyetribe eyetracker.
It is very likely that many of the iohub eye tracker devices do not work with Python 3. Currently the best option would be to use Python 2 and possibly PsychoPy2.
For the SMI interface to work, you also have to installed their C runtime API and have it in your environment path so python is able to find the SMI DLL.
Is it still so with latest psychopy in 2020?
If so, you mean I have to implement communication with the tracker with good ol’ way of UDP sockets?
What is SMI
C API? Where can I find it? I thought there is no such thing for SMI trackers cause they are using a universal platform and OS-independent approach of networking APIs.
Gazepoint, SR Research, and Tobii trackers are still supported. SMI trackers are no longer supported by iohub because the company no longer exists and I no longer have access to any SMI equipment to do testing with.
I thought there is no such thing for SMI trackers cause they are using a universal platform and OS-independent approach of networking APIs.
SMI officially stopped supporting their UDP protocol years ago in favour of a C API / DLL approach. The company was very insistent that I use the C API when doing the iohub interface otherwise they would not help with any issues I ran into. This was 6 or 7 years ago now. In hindsight that was a bad decision because it has made maintaining the interface impossible now that the the hardware is no longer supported.
C API allow for communication with SMI hardware via LAN?
I still have SMI eyetrackers at the lab, and I cannot see any reason to abandon the HiSpeed 1250. Pretty serviceable, too. Not sure about the licensing in case I replace some of the hardware in case something degrades, though. Will the software comply or not?
There is a module called
SMITE by Nystrom. Gonna have a look.
I know this thread is very old, and hopefully things worked out for you Lukas. I just wanted to write for others who might stumble into this thread that the issue (causing errors related to the
getPixelResolution method) might in some cases be a lot simpler than it seems. In my case, this was the problem:
This actually means that you’re telling ioHub to your second monitor connected to the computer. The reason is that ioHub used 0-indexing/counting, where 0 is the first monitor, 1 is the second monitor, and so on. I only realized this after comparing my YAML file to the ones of the ioHub demo experiments. @sol Maybe the exception/error message could be updated, so that it suggests that device numbering might be the issue when
Improving how and what iohub errors are reported will be an important part of the iohub refactor I’ll be working on over the next several months. Thanks very much for the feedback.