In my previous post, I used blinking videos on my computer to entrain my brain waves. A key question, though, was whether my computer could play those blinking videos steadily. If the blinking isn’t steady, it won’t entrain brainwaves that are easily detected. So, in this new post, I show how I hacked a photocell and my Arduino to measure the blink rate that my computer is actually producing. It’s a pretty simple (and cheap!) setup and, as you’ll see below, its data explains some of the important findings in my EEG data!
Measuring the Blink Rate From the Movies Played Back by my Computer |
Using a Photocell: My approach to measuring the video blink rate is to quickly and continuously measure the light produced by my computer screen. I chose to use a photocell, mostly because I had one that came with my very first Arduino. To learn how to use a photocell, I followed the tutorial at Adafruit. It explains what a photocell is and it explains exactly how to hook it up to an Arduino. The key is that you connect a photocell and a 10K resistor in series. Together, they form a voltage divider. Then, you connect one end to +5V and the other end to ground. In the middle, at the junction between the photocell and the 10K resistor, you connect that point to the Arduino’s analog input pin. Pretty easy!
Wiring It Up: To connect all of the bits together, I needed to solder a few things. First, I gathered my components — the photocell, some wire, and some shrink tube (to keep the soldered wires from shorting to each other).
The Components: A Super-Cheap Photocell, some Wire, and some Shrink Tube. The 10K resistor is not shown. |
Then, I soldered the wires to the legs of the photocell and insulated them with the shink tube. The photo below shows the components after this assembly. Looks decent enough.
Fully Assembled. This is the first version that I tried. Notice that the back and sides of the photocell are exposed. This turned out to be bad. |
Unfortunately, when I hooked it up to my Arduino, I found that I was not seeing any change in the light level from my computer screen. After some playing around, I found that the photocell is sensitive to light from the back and sides, in addition to being sensitive to light from the front. So, as seen in the photo below, I added another layer of shrink tube to block out the light entering from the back and sides.
Modified Assembly. I added more shrink tube to wrap around the sides back of the photocell. You have to keep out that light! |
Mounting Everything: Once I had my photocell on those long(ish) lead wires, I connected it to the Arduino as discussed on the Adafruit site. I then needed a way to hold the photocell close to the computer screen so that I could measure its blink rate. As shown in the photo below, I found that my adjustable soldering fixture (sometimes called a “3rd Hand” fixture) works really well. It works best if you position the photocell to be VERY close to the computer screen.
Position the photocell to be VERY close to the screen. |
Arduino Software: If I’m going to use my Arduino to read the photocell, I need to some software for the Arduino. My first step was to use the built-in Arduino example called “AnalogInOutSerial“. I then extended this program to report the actual resistance of the photocell under different lighting conditions (“ReadPhotocellResistance“). While either of these programs works fine to read the photocell, neither is clocked to read the values a steady pace. If the sampling isn’t steady, there’s no way to know if the video blinking istelf is steady. To fix this, you need to setup an Arduino timer. Or, you could…
Integrate with OpenBCI: The OpenBCI shield generates data packets at a very precise rate (I usually configure mine to sample at 250 Hz). It could act as the clock to drive the Arduino to sample the photocell steadily. So, I modified the OpenBCI Arduino sketch to read one of the analog input pins every time that it receives data from the OpenBCI shield. It then appends this extra data value to the OpenBCI data packet and sends it to the PC. Finally, I modified my OpenBCI GUI to receive the extra data and to include it in its log file.
Results: I used this system to record the blinking produced by the blinking movies from my previous post. Each movie was about 20 seconds long and each movie blinked at a different rate. The digitized Photocell values are shown in the figure below as raw counts from the Arduino. Clearly, this graph is a bit too zoomed out to see much of interest (though you can see the non-steady amplitude when at the fastest speed on the right). We need to zoom in to see more detail…
Zooming-In: Excerpts from three of the movies are shown below. In these plots, you can see that the light pulses recorded during the 3 Hz and 10 Hz movies look to be steadily paced, whereas the pulses in the 7 Hz movie looks much more irregular. Based on this qualitative view, I’d say that the irregularity of the 7Hz movie might cause complications when used for EEG experiments.
Measuring the Blink Rate: To better assess the steadiness of each movie, I setup a routine to quantify the blink rate on a blink-by-blink basis. I did this by, first, computing the mean sensor value for the whole recording. This is my threshold for deciding whether the screen is “white” or “black”. This threshold value is shown by the horizontal black line in the excerpts above. Then, I detected when the signal crossed this threshold. Each threshold crossing is shown as a blue dot in the figures above. To compute the blink rate, I compute the difference between the dots. The “white-to-white” blink rate is the difference between the red dots. Alternatively, the rate at which the screen merely changed (either from white-to-black or black-to-white), I measured the difference between the blue dots.
Unsteadiness: As can be seen in the plot above, the blink rate is pretty steady for the first four movies (ie, speeds of 1-4 Hz W-W). For the 5th movie (5 Hz W-W), the plot above starts to look messier, especially the blue line. This means that the system is not playing back the blinking movie smoothly. As we get into the faster movies (6-9) Hz, the blue line gets extremely messy. Clearly, the system is unable to keep a steady pace of white-to-black and black-to-white transitions (the blue line), though the white-to-white period (the red line) isn’t too as bad. Funnily, at 10 Hz, note that the white-to-white blink rate gets very stable again. It seems that at 10 Hz, the individual movie frames must be well-aligned with the natural update rate of the video system on my computer.
Relationship to EEG Data: The whole purpose of this investigation was to see if my EEG results from my previous post (copied again below, for convenience) were reflecting properties of my brain, or if they were reflecting artifacts from imperfections in my computer’s movie playback. My main question with my EEG data is why I exhibited no video-entrained EEG signals above 10 Hz. Well, looking at the graph of the computer’s blink rate (above), we see that the video blink rate becomes extremely unstable for any frequency above 10 Hz. My computer, in other words, was unable to generate steady visual stimulation above 10 Hz. Without stable stimulation, my brain had nothing to entrain with. Therefore, these limitations in my video system mean that I cannot declare either way whether my brain can entrain with visual stimuli at speeds greater than 10 Hz. With a more stable video system, maybe I could entrain with the faster blinks.