I’ve designed a signal protocol for the Arduino to convert phototransistor readings from the laptop screen into bytes of data. Here’s what I came up with today:
In the illustration, the white boxes in the black strip are light pulses on the screen which are shown as spread out across a time line. (Note that units of time have yet to be assigned.)
When the phototransistor signal goes high, it triggers (starts) the byte-reading cycle. By definition here, the start of the trigger pulse is t = 0. Thus the time line shown here is just for reading a single byte. (I’ll work on reading multiple bytes once I master reading a single byte.)
At time t = 1.5, the phototransistor voltage is read at Arduino pin A0. If the value is LOW, then the bit has a value of 0. If it is HIGH, you guessed it, the bit has a value of 1.
At time t = 2.5, the phototransistor is sampled again. If it is LOW, then the bit has a value of 0. If it is HIGH, now we’re assigning a value of 2.
And so on. After t = 7.5, all the bit values are added up to give a byte value from 0 to 127. And that tells me what my control code is.
After the last bit value is read, there is a delay of a quarter second, and then the trigger for the next byte can be sent. The reason for the delay is that I want each byte-reading to be started by a “clean” trigger because I don’t want to mess up the bit-reading frames, which I fear could rapidly get out of synch otherwise.
I’ve been having trouble with the Arduino IDE serial monitor (or maybe, it’s been having trouble with me), but I hope to test this protocol tomorrow.
I know this post is a bit old and this may come too late, but why not consider differential manchester encoding for your optical data transferring? It’s not so sensitive to the noise in the signal, so it should be great on an application like this.
Here’s a few good links on the subject:
I found the latter one easier to understand with implementation in mind.
For now I’m still thinking of a straight implementation of the data/clock protocol. If the noise problem continues, then Manchester encoding looks like something I should investigate. Thanks!