psychopy.org | Reference | Downloads | Github

Basic Bits# setup problem

I’m trying to get a Bits# box working in Psychopy (1.85.2) on a Mac running 10.11. I followed the installation instructions in the Bits# manual, including editing the Bits# config file to turn off USB-MSD and turn on USB-CDC, and I can communicate with the Bits# box using terminal and screen (it behaves as I expect for a simple case: when I put it in mono++ mode the screen goes black&white).

However, when I try to open a window, connect to the Bits#, put it in mono++ mode, it hangs on the CRS test screen and when I manage to get back to the psychopy window I get the error message (pasted below) suggesting I’m missing a config file in psychopy for the Bits# and that I have no identity LUT.

How do I create the config file (is there an example somewhere?) and will the config file solve my identity LUT problem? Are there other setup steps I need to take?

Thanks!!


8.8124 WARNING no config file yet for <psychopy.hardware.crs.bits.BitsSharp object at 0x10f3a74d0>
Checking ‘0-65535’ LUT:mean err = 42.591 per LUT entry
Checking ‘1-65536’ LUT:mean err = 0.137 per LUT entry
Checking ‘intel’ LUT:mean err = 6.430 per LUT entry
Checking ‘0-255’ LUT:mean err = 0.137 per LUT entry
Best was ‘1-65536’ LUT (mean err = 0.137). Optimising that…
0.137 0.039 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.008 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 failed to converge on a successful identity LUT. This is BAD!
{‘SerialNumber’: ‘$SerialNumber;72126112’, ‘FirmwareDate’: ‘$FirmwareDate;24/07/2017 19:01’, ‘ProductType’: ‘$ProductType;Bits Sharp’}

What’s this all about?

The issue here is that the graphics card lookup table has to be set to the “identity” for the bits box to be accurately giving exactly the values you expect (e.g. in order to send the T-Lock codes). If the graphics lookup table is changing any of the 8bit values (trying to perform some gamma correction in the system settings) then the values might not be the exact values being output. It turns out that the values coming out of the lookup table on the mac were often not exactly what we requested for a variety of reasons.

With the previous (Bits++) box we just had to set a lookup table that seemed sensible to give the “identity” and hope that then what we asked for was what we got. With Bits# we get to ask it info (we can request the values back from the box and see what they actually say), and that’s what you’re seeing. PsychoPy is testing some expected values against the actual values reported by the Bits# and then tweaking the LUT and trying again, trying to home in on the ideal LUT.

What you’re seeing is basically, that procedure of trying to home in on the true identity LUT is not working.

What might cause this?

That part is harder to know, and we’d like to get to the bottom of it.

  • On some systems I’ve seen the error value doesn’t change at all, which indicates that we aren’t managing to change the gamma (e.g. I’ve seen this on Mac Mini devices where one of the monitor outputs appears not to obey the gamma settings but the other one does!)
  • It could be that the temporal dithering of the mac is the problem (but in the tests that I’ve done a while ago this didn’t seem to be a problem, but I haven’t tested on recent versions of OSX so maybe it is now)
  • it could be that the values being reported back from the bits# aren’t being correctly decoded (we’re now using 64bit Python whereas I wrote that code on 32bit - maybe that’s broken something?)
  • it could be that we’re jumping back and forth and consistently missing the true value and we need to tweak the optimization allgorithm?
  • something else?

What to do next?

It’s interesting that the error is extremely small - it homes in most of the way to a true identity but then misses. I wonder what the erroneous value is in the sequence, and whether it’s the same on every update, or if it’s moving around. Would be great if we could home in better and get this right!

The key code doing the searching/testing is psychopy/hardware/crs/bits.py where there’s a class called Config with a method findIdentityLUT(). At the top of that file there’s also a variable called plotResultsthat might help if True.

While you try and get this working you might want to mirror your screen with another monitor so that you can see what’s actually going on (hidden by the Bits# config screen when it goes into the mode to read the pixels it puts the setup screen on)

Alternatively

You can turn off the config testing of the Bits# with
bits = crs.BitsSharp(win, mode = 'mono++', checkConfigLevel=0)
and see if this small error is actually causing you probs. It might not be if you’ve got fairly close to the right LUT. The question is whether you can actually control the TLock settings

Thanks for all the info!! I noticed at some point that the reported refresh rate in the Bits# status mode was unstable (changing from ~60Hz to 0Hz and then back), so I got the idea to try a different computer. Two older computers worked (were able to pass the checkConfig section), so I suspect there is a problem with my original computer. That original machine is running OS 10.12.6, not 10.11 as I erroneously wrote in my initial post. Is Sierra known to be a problem?

So, it’s running in that I can display stimulus, and I can put it in/out of mono++ mode, but I can’t seem to get a linear contrast response. I tried just drawing rectangles of various colors or presenting square wave gratingStim at various contrast levels, but they are always non-linear when I measure the resulting Michelson contrast, so I must still be missing something. Setting the gammaCorrectFile has no effect, nor does running a calibration in Monitor Center.

For future Bits# newbies, I needed to create the gamma correction LUT as described in chapter 7 of the Bits# manual! Now I’m getting linear contrast!