Ben's Notes: January 2011

Monday, 31 January 2011

Parity Coding

Name: Parity Coding
Status: complete
Affiliation: 18-240 Structure and Design of Digital Systems Lab 1
Group members: Arlene
Start: 1/23/2011
End: 1/27/2011

Description: Implements parity coding, which is a safety caution that adds one bit to a code word. This extra bit allows error detection when any one bit in the code word is corrupted. In an even parity code, the parity bit is set so there is an even number of 1 bits in the code word, while in an odd parity code, the opposite occurs. An interesting fact to note is that the odd parity bit can be computed as the negation of the even parity bits. The primary limitation with parity coding is that it can be assumed to be correct IFF single-bit errors are the only possible sources of corruption.

Notable issues with parity coding:
-Does not tell you how many errors
-Does not tell you where the errors are
-Can miss errors if they are of the correct parity

What I learned:
-introduction to System Verilog
-parity coding
-assigning logic inputs and outputs to pins on the hardware (xilinx spartan 3)

Asserts 1 when code word is inconsistent. In the video, I increment the input from 0 to 63.

Monday, 17 January 2011

Sign Language to Braille Glove ( --> Simon Says)

Name: Sign Language to Braille (--> Simon Says)
Status: somewhat complete
Affiliation: Build18 (build18.org)
Group members: Justin, Kee Young
Start: 1/10/2011
End: 1/14/2011

Description: The glove began with the intention of converting sign language to braille by taking gestures as inputs and returning braille as output using an LED array. The LED array currently acts as a proof of concept because making a mechanical device that can output real braille is a substantial project in its own right.
However, we ran into some problems:
1. Didn't think about how many analog inputs we needed. Unfortunately, Arduino Duemilanove only has 6, so we weren't able to attach all of the flex sensors and an accelerometer. Unfortunately, we weren't able to get our hands on a multiplexer. Should probably consider investing in a Mega.
2. LED array didn't have the pins we wanted, as well as an outdated data sheet. We weren't 100% sure how to use it without blowing it up so we decided to use wire six individual LEDs instead and control them separately.

The lack of analog inputs prevented us from using all of our sensors, which meant we wouldn't have very accurate gesture recognition. As a result, at 8pm the day before build18 demos, we decided to rewrite our software. We kept the same hardware for the most part (removed two flex sensors, removed accelerometer).
In the end, our final product was a simon says game where a number of LEDs are lit and you have to gesture how many are lit. The sequence gets increasingly longer as you get more sequences correct.

What I learned:
1. Be prepared when ordering parts under strict timelines. Have foresight.
2. Be wary of how many digital/analog I/Os you have and how many you actually need.
3. Have backup plans for when you don't have foresight.
TBA: circuit diagram, parts list, cost, code