Arduino Phototransistor Signal Protocol

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.

About engineerzero

Once and future engineer.
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

2 Responses to Arduino Phototransistor Signal Protocol

  1. Weeezes says:


    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.

    • engineerzero says:

      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!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s