Hi, I’ve been thinking about the issue of trying to work around the inherent timing problems of HID devices, and also of synchronizing to internal displays. I’m focusing on my Macbook Pros, but I think that this idea applies to any computer with a modern video interface that supports dual displays and DDC2.
The idea is basically to create a response box that communicates over the DDC2/I2C bus in the video connector. This is the portion of the video interface that exists primarily to allow “plug and play” configuration of external displays, but it is implemented using the bidirectional I2C interface standard.
The DDC2 standard supports a +5, 300ma output, as well as a standard I2C clock and data line. Furthermore, the Mac kernel has at least the vestiges of support for multi-device I2C buses, using the video port. I’m not sure what Windows provides, but I am under the impression that its interface is actually more fleshed out than the Mac one.
If the video configuration reported via EDID using the DDC2 protocol is identical to that of the internal display, then the system display can be run in “mirror” mode so that the format and timing of the external display would be identical to that of the internal one. However, there would be no actual video device connected, just the I2C response device.
Here’s what this device could do. First, since the connection would be via I2C, there would not be the kind of lag that is seen in the system-heavy HID/USB connections. A bit would be readable on one end of the cable a few nanoseconds after it is set on the other end of the cable. This in and of itself would be a big improvement.
Second, the device would receive vsync and hsync signals from the video interface, and therefore be capable of synchronizing its time measurements precisely to the video display. Obviously, it would also need its own millisecond clock as well, but the ability to sync to the raw video signal would be a tremendous improvement. For example, it could respond to commands like “after the next vsync start looking for a response for up to 4000 ms on inputs 2, 4, and 5”.
Third, it could do everything that any of the other RB-series or the SV-1 could do, including use the XID protocol, but it would be connected to, and receive power from, the external video connector instead of to a USB-serial conversion cable.
Fourth, there would be an additional option, which would be to install the device into an actual video monitor, and to use that monitor either in mirror mode or in dual-display mode to present stimuli to subjects: a “smart” standard display for video stimuli. You could get fancy with this: known, constant video timing, colors, brightness, size, aspect, etc., plus connectors for buttons, headphones, microphones, etc. The advantage over using the internal display is that experiments would be identical across different systems, PCs, Macs, laptops, desktop, etc.
Finally (and here I’m getting into even murkier waters), other, standard I2C lab equipment could be controlled on the same bus, so for example, it might be possible to use this method to control external stimulus devices, etc. For this to work, the response box would need a connecter to an external I2C bus.
I haven’t done any testing and I’m not certain about the details of any of this, but it just seemed to me that the approach might resolve some of the issues around using Superlab. If the idea is really stupid, then please excuse it.
Greg Shenaut