Hello, thanks for the post. The light sensors are the TEPT4400 “ambient light sensors” (datasheet: http://www.vishay.com/docs/81341/tept4400.pdf).
TL;DR we can just send you more sensors if you like, fill out the contact form with your address and we’ll send them out.
#1. Each sensor connects between the microcontroller analog input pin and +3.3v, and there is also a 10k resistor between that analog input pin and 0v. When the sensor is pointed at a black square on the screen, it has (effectively) a high internal resistance, so the 10k resistor pulls the analog input pin closer to ground. When the sensor is pointed at a white square on the screen, it has (effectively) a low internal resistance, so it pulls the analog input pin closer to VDD. Here’s the relevant part of the circuit schematic:
When you release the pushbutton during step 6 of programming (guide: http://www.wayneandlayne.com/files/blinky/images/programming_animated_gif/blinky_programming.gif) the bootloader code samples each sensor to determine the maximum voltage that corresponds to the “black” level. This is necessary due to variance of the parts involved. The measured value plus an offset (0x10, which is about 0.05 volts) is used as the threshold to determine whether the sensor is observing a “black” or “white” square.
You could directly apply a 3.3v voltage to the microcontroller input pins, as long as you kept the voltage low (near ground) up through step 6 of programming, so the auto-thresholding is “observing” a “black” voltage level. From there you could just use 0v and 3.3v to represent black and white respectively. Depending on the drive strength of whatever would be driving that signal, you might want to remove the 10k resistors and the remaining light sensor, to avoid messing up the transmitted signal.
#2. Definitely! Add ?debug to the end of the programming page URL and it will show the details in textarea fields at the bottom of the page. The textareas are only updated when you press the Go button. http://www.wayneandlayne.com/blinky_programmer/?debug
message_data is the data we want to put into the EEPROM. First byte is the number of messages included. Then comes the bytes for each message in turn. Format of messages is described on the Design page.
xmit_data is the message data after it has been packaged into records like an Intel HEX file. Each record includes the number of data bytes, the destination address, the record type, the data bytes, and a checksum byte.
xmit_raw is the bitstream to transmit. Details are on the Design page but in brief, we use a clocked data transmission scheme where the data bit is sampled each time the clock bit transitions.
If there is any issue in programming, you’ll either see LEDs 3/4 flashing back and forth (checksum error, problem with data input) or you’ll see the display just stop changing (missed clock transitions, problem with clock input).
#4. I think it’d be super cool to have a wired blinky programmer, but time is valuable too As I mentioned in the TL;DR at the top, we’re more than happy to mail you a couple of sensors for free, but I realize that probably doesn’t work with your travel, or the spirit of the challenge at hand. If you can find anyone with a PIC programmer (PIC16F1823) you could use that to edit the EEPROM bytes based on the debug output from the webpage.
Good luck, let us know how it goes!