Travis Rich -- HTMAA

week 1 Proposal
week 2 Press Fit
week 3 FabISP
week 4 3D
week 5 PCB
week 6 Casting
week 7 ATtiny
week 8 Big
week 9 Input
week 10 Epoxy
week 11 Output
week 12 Interface
week 13 Network
week 14 Machine
week 15 Final

Weeek 13 -- Networking



This week we're building devices that network - or, more simply put, a project with two or more processors. I'm dabbling with the idea of making data flashlights for my final project, so I decided to play a bit with using using visible light LEDs for communication.


I used two boards for this project: a fabduino and the light sensor board that I had made a few weeks ago. The fabduino served as the transmitting board and the phototransistor on the light sensor board made the obvious choise as the receiver board. For this week I decided to stay with a simplex system, that is - I can only transmit in one direction (i.e. it's broadcast). The fabduino didn't have a bright LED on it, so rather than making a new board, I simply hooked up an LED and 1k resistor to one of the output ports.


To transmit, I set up a software serial port on the pin tied to my LED and had the loop continuously write 'hello' to the serial port. The result is a simple on-off keying modulation of the LED. The serial port was set to 9600 baud. The receiver side performed simple serial reads to receive the message. The challenge here was running into a lot of bit errors and timing issues. Sometimes the entire message would be bit shifted leaving me with a garbled message (and non-ASCII output). I got a lot of flipped bits as well due to shadows and other slight fluctuations in light intensity. This would be a good argument against on-off keying as a modulation scheme. To work around this, I implemented a few hacky error-checks that were run before passing the data to the display interface. One check is to delay the display until the same message is received 5 times in a row. This ensures that quick bit flips don't cause the output to glitch. This doesn't solve the bit shifting issue though. To avoid this, I implemented a check that made sure the data received was in the ASCII range of A-Za-z. If the data was outside this range, I bit shift by one and check again - repeating until the data is verified to be A-Za-z.