Infrared Communications for Atmel Mega644/1284 microcontrollers

| |


Infrared (IR) can be used for line-of-sight communications over low to moderate range. IR is nice because of the lack of interference (except for sun and compact fluroscent lights) and freedom from FCC regulation. The transmitter drive uses a clever method to modulate and invert the serial output from the USART transmitter. The circuit is shown below. In my version, MCU timer 2 is used standalone to generate a 56 KHz square wave on pin D7. A lower resistor gives more range, but of course draws more current. The TSAL6400 can take 100 mA forward current, but the maximum current rating for any port pin of the MCU is 40 mA. You should probably limit the current to 30 mA. At 30 mA, the forward voltage drop of the diode is about 1.25 volts, so the the resistor needs to be
(2.5 volt)/(0.03 amp)> 83 ohms.

I improved Remin's protocol by setting up the link software so that timing constraints on the IR receiver AGC were guaranteed to be met. It turns out that there are several types of IR reciever, some of which are better at short data bursts, while others are better for sustained data. I chose a Vishay TSOP34156 for its good sustained data characteristics, minimal burst timing requirements, and reasonable data rate. The system I build works solidly at 4800 baud over IR with 5 characters of overhead/packet (start token, transmitter number, 2 char checksum , end token). It works with increasing packet loss up to 9000 baud. The receiver circuit is shown to the left. The RC circuit acts a low-pass filter on the power to surpress spike noise and improve receiver performance. The RC circuit should be close to the receiver. The range with a 100 ohm resistor is at least 3 meters with the transmitter roughly pointing at the receiver, and a packet loss of less then 0.1 percent. To manage burst length limitations there is a short pause between characters, and only 7-bit characters are sent, with two stop bits. The 7-bit limit means that you can send all of the printing characters on the US keyboard, but no extended ASCII. All data is therefore sent as printable strings, NOT as raw hexidecimal.

Programs (These programs were written for the atmega644, but also work on the atmega1284)

The loopback test program works in full duplex mode to send a message to itself. The program assumes that the transmitter and receiver are connected as shown above, and that in D3 is connected to the line which sends data to the PC. You need to point the LEDs at the receiver, or put them side-by-side and use a reflector to bounce light back. The transmit and receive tasks are running at different rates. The transmit task just formats a string and sends it. The receive task gets a packet, then either prints it (if the return code indicates good data), or for testing, prints the nonzero return code and the corrupted packet. The hardware USART is used for the IR link, so I wrote a software UART for communication with the human at the PC. Note that on the atmega1284 this software UART is not necessary, because the 1284 has two USARTs. The software UART routines aux_getchar and aux_putchar allow use of fprintf and fscanf functions, but are blocking and should only be used for testing or when MCU load is light. The timer 0 interrupt service routine manages the full duplex IR link. At 4800 baud, this program puts about 430 characters/second across the IR link. Bigger packets are more efficient in a low noise environment. You could expect a maximum transmit rate of about 20 packets/sec with about 20 characters/packet.

A two-processor link was built with one processor running a version of the loopback code, but transmitting on ID=1 and receiving on ID=2. The other processor is running an echo code, receiving on ID=1, and if the data is valid, echoing the packet back out on channel ID=2. Using this code, it is necessary to put an IR barrier (electrical tape or metal) between the LED emitter and reciever on each processor. I think this is because the light scattering from nearby LEDs sets the AGC of the receiver too high to receive the remote LED output. In the image below, you can see the IR shield around the reciever, the two LEDs at the left, and the 100 ohm resistor in series with the LEDs.

With both transmit resistors set to 1Kohm (implying current=(2.5 volt)/(1000 ohm)=2.5 mA), and a range of 1 meter, the packet lose is about 1/1000.
With both transmit resistors set to 390 ohm (implying current=(2.5 volt)/(390 ohm)=6 mA), and a range of 3 meters, the packet lose is about 1/10 and is very dependent on scattering and reflections from the full duplex base transmitter to the base receiver, both of which are active at the same time. Room illumination was bright, indirect sunlight, plus 60 Hz fluroscent lighting.
With the base station resistor set to 390 ohms and the echo station resistor set to 100 ohms, the packet lose is about 1/1000 at 3 meters range.

A two processor link (base code, echo code)was built with the following characteristics:
The base processor sends a time and packet number unless a button is pressed. If the button is pressed it sends 'zz'.
If valid, data received is sent to the puTTY window on the PC, and has an error code prepended if invalid.
The echo processor sends back the packet it receives. If the packet is 'zz', then the echo processor zeros it's own time counter.
If no packet is received (before receive timeout expires) then the current time counter is sent back to the base formated at "RemoteTime=xxxx", where xxxx is in milliseconds. The error rate seems to be <1/1000 packets at 3 meters with same resistors as above (condition 3, example 2). With sunlight shining directly (through heat-film covered window) onto the base receiver lens, between half and 90% of the packets are lost with 3 meter range, and 100 ohms on the echo transmitter LED. Shading the receiver my hand restores low error rate.

Packet Format

A packet consists of :
A start character, which defaults to '#', but can be changed with a define directive. No other character in the packet is allowed to match the start character.
A one-character transmitter id number which the receiver will check against a number it expects. The transmitter id should be in the ASCII character range '0' to 'z'.
An arbitrary length, printable string, which of course, must fit into the size of the defined transmit/receive buffers.
A one character checksum, which is calculated as the bitwise XOR of all the characters in the packet (transmitter id, and payload). The checksum is actually transmitted as two 4-bit values in the low 4 bits, ORed with 0x10 to form two 7-bit characters. This seemingly roundabout encoding was necessary to avoid burst length problems.
An end character, which defaults to '%', but can be changed with a define directive. No other character in the packet is allowed to match the end character.
Read More


| |


The goal of the project was to design and build a low-cost, light-weight, head-mounted eye
tracker, which will enable tracking of a subjects focus of gaze within his/her field of vision. The
head-mounted unit consists of a forward-looking camera to record the subject's field of view,
and a second camera to capture the position of the eyeball. Software running on a remote host
computes the position of the subject's gaze using the video feed from these two cameras, in
real-time. The unit is significantly cheaper than existing units available in the market.
Performance and encountered with various approaches is discussed.

Full report (pdf)


Read More


| |

Out of Violet’s electrical subsystems, the Power subsystem is the most critical because it is housed on a single board that supplies power to all other subsystems and is designed in-house. The Power System functions include using solar panels to collect energy, storing energy in batteries with appropriate protection systems, sampling components’ and subsystems’ sensors to monitor their power consumption, distributing power from solar cells and batteries, acting as a controller for the Flight Computer, and communicating with the Flight Computer through data packets. Hence, the Power microcontroller (MCU) serves as power controller and power monitor. Revision 1 of the Power Board layout was completed, and the populated board was tested in a Flat-sat setup. MCU code was written to execute the major control, monitoring, and communication functions. Correct functionality of the software functions was verified on a STK500-based testbench, which closely resembles the interfaces of the power system in the satellite. In the near future, further testing of the software will be done on a Revision 2 Power Board with a programmed MCU in order to model flight-like conditions.

Full report (pdf)

Read More


| |


This project is designed to explore the possibility of building a compact
acceleration measuring device and applying it in a typical middle/high school science
class. Such an interesting interactive device could to be used to improve the traditional
classroom environment. Students can carry the device on their bodies and see how fast
they move, and ideally, it is hoped to help them become more interested in learning
simple physics. The project’s design is based on a pair of microcontrollers.
Accelerometer’s sensors are used and data are transmitted through radio frequency and
serial communication (RS232). Readings of the accelerometer’s outputs are updated ten
times a second and data will be shown in graphical interpretation after measurement is
taken. The designed goal of this project is to provide a simple-to-use and reliable device
that can record the acceleration with good time resolution.

Read More


| |
cpu boardsRock Band 2 is a popular video game enjoyed by millions on their Xbox 360 console game systems. However, unlocking all of the available songs is a task that many players do not have time or patience for. In addition, many players wish they had talented players to achieve high scores with. We have designed a system that is able to beat Rock Band songs on any difficulty, playing up to four instruments at a time. Implemented on an FPGA, the design is capable of highly accurate, real-time results. Video is read directly from the Xbox without any external sensors mounted on the TV. Modifications were made to the Rock Band instruments that maintain their original functionality and wireless radios were used to allow users to play the game far away from the Xbox. Advanced detection algorithms allow this device to achieve near-perfect scores and compete with any human.

Full report (pdf)

Read More

Persistent of Vision Display

| |


The purpose of this project is to design and to create a persistence of vision (POV) display. This display will allow users to upload an image to be displayed through wireless communication. A persistence of vision (POV) refers to the phenomenon of the human eye in which an afterimage exists for a brief time (10 ms). A POV display exploits this phenomena by spinning a one dimensional row of LED's through a two dimensional space at such a high frequency that a two dimensional display is visible. In our case, we created a cylindrical display by spinning a column of LED's around a central motor shaft (Figure 1). The rotational speed of the LED's is fast enough such that the human eye perceives a two dimensional image.
System Diagram
Figure 1. Hardware setup of POV display.
The overall design of this project can be grouped in the following three categories: electrical design, mechanical design, and software design. The most labor intensive portion of this project was the mechanical design. While the electrical schematics and software design appear trivial, integrating the hardware with an adept firmware proved to the biggest challenge of all. Mounting the electrical components onto the mechanical structure - i.e. the spinning arm - was also quite a challenge. As one can foresee, the nature of our mechanical design introduced various safety issues that we also had to take into consideration.

High Level Design   

The logic behind our project is very straightforward. Our software must calculate the rotations per minute (RPM) and the release and deadline times which set the time duration to display each "pixel" of the display (explained in software section). From a high level design, we simply measure the period of each rotation, divide time the cantilever takes to rotate through that section by the number pixels we want to display and then calculate the amount of time each pixel occupies during the rotation. By turning on a light emitting diode (LED) for just that duration of time, we can then display the pixel. Thus, we've mapped the entire display area to a 14 by 90 matrix where each element in the matrix represents a pixel that can have any red, green, and blue (RGB) value.
The nature of our design allows the software and hardware design to be independent of each other in terms of tradeoffs. The more robust our hardware becomes (i.e. tying down wires and securing boards), the safer our project becomes. The more robust we make our software (i.e. robust state machine and LED mapping), the more optimized and error free our project becomes. The only case where our decisions about which hardware we used affected software decisions was when we ran into memory issues in RAM when the resolution of our display grew too large. On our microcontroller, the ATmega644, in order to increase the resolution of the display (i.e. to store a larger matrix which contained the pixel information), we would need additional memory modules to provide this functionality. We decided against this due to time and space constraints on the arm itself.
Our project uses two standards, serial peripheral interface (SPI) and IEEE 802.11 for our wireless radio communication. The standard for SPI consists of a 4-wire serial bus that allows a master/slave communication mode. The wires are the following:
  • SCLK: serial clock (output from master)
  • MOSI: master output, slave input (output from master)
  • MISO: master input, slave output (output from slave)
  • SS: slave select (output from master)


Electrical Design

The electrical components used are:
Figure 2. Onboard ATmega644 microcontroller.
  • On-board ATmega644 microcontroller (on development board)
  • Stationary ATmega644 microcontroller (on development board)
  • 5 MAX 6966 controller chips
  • 14 RGB LEDs
  • 1 9V battery
  • 1 pair of IR transmitter and receiver
  • 2 WI.232FHSS-25-R radio transceivers from Radiotronix
  • 2 WI.232FHSS-25-FCC-R break out boards from Radiotronix
  • LP2951 Linear Regulator
  • LM340-15 Linear Regulator
  • Various Resistors and capacitors
  • Various wires and header pins
There are two main electrical designs to this project, the onboard (attached to spinning arm) system and the stationary system. The primary purpose of the onboard is to actually turn on and off the LED's based on a two dimensional matrix (further described in the software section). The onboard circuit consists of an ATmega644 (Figure 2) microcontroller which is powered by a 9V battery (also onboard). In order to turn on the LEDs, the microcontroller will act as an SPI master and the MAX 6966 will act as SPI slaves. The master, the microcontroller, will communicate to the slave chips via the SPI bus. It will send serial commands to write the registers on the MAX6966 chips. On the slave end, the target MAX 6966 chip will receive an 4-bit value that it will correspond to a PWM duty cycle outputting on specific port connected to a target LED. The onboard circuit schematic shows all five MAX 6966 chips controlling 14 RGB (red, blue, and green) LED's. The max chips are powered by a 3V3 regulator from the 5V rail from the microcontroller and the LED's will be powered from that rail as well. Also, the onboard microcontroller will be calculating the RPM (Rotations per Minute) at every rotation to adjust the display depending on how fast the arm is spinning. Lastly, the onboard microcontroller will communicate with the stationary microcontroller via radio units.
MAX chips
Figure 3. Onboard MAX 6966 chips that control the LEDs. 

Each MAX6966 chip (Figure 3) has 10 output pins and an SPI input bus. Since each LED is controlled by 3 pins, each MAX6966 chip can control 3 LED's. The SPI control bus comes from the microcontroller (master) and chooses which MAX 6966 chip (slave) to talk with and control pin outputs. Each pin on the MAX6966 chip can be chosen to turn on or off a color for a specific LED. Since we have 14 LED's (needing 42 driver pins), we decided to use 5 MAX6966 chips (corresponding to 50 outputs), each with its own chip select.
To collect the RPM data needed for our timing calculations, we have the microcontroller connected to an infrared (IR) circuit board. This circuit consists of an IR transmitter and receiver which face downwards. Each time the circuit board passes by the white piece of paper, it will send a signal to the microcontroller to trigger an interrupt to calculate the rotation period.
The wireless transceivers used to send images are connected to their respective microcontroller boards using the UART TX and RX pins. The RX and TX pins on the wireless transceiver are connected to their counterparts TX and RX, respectively, on the microcontroller.

Figure 4. Stationary transmitter connected to computer. 

All of the power needed by the electrical components (not including the microcontroller) is from the VCC from the microcontroller. In order to allow the microcontroller to provide enough current to power all 14 LEDs, 5 MAX 6966 chips, IR circuit, and wireless transceiver, we have a high current (1A) LM340-15 linear regulator on the microcontroller to limit the 9V from the battery to 5V. Furthermore, since the MAX 6966 chips take 3.3V, we have an LP2951 linear regulator to limit the 5V VCC output from the microcontroller to 3.3V.

The primary function of the stationary circuit is to act as the user interface so that the user can upload whatever image to be displayed (Figure 4). Another function of the stationary circuit is to select different functions for the onboard board to perform such as animations, clearing the display, etc.
Since our motor is an AC motor that spins at 1,600 RPM as soon as it is plugged into the wall socket, this is too fast for our application. Thus, to reduce the speed and to prevent the motor from going from 0 to 1,600 RPM instantly, we are using a variable AC adapter. It is actually a light dimmer from Lutron Electronics, but it is essentially a variable AC, and it has a dial for choosing how much amplitude we want to give to the motor. This allowed us to perform safer tests, without worrying about pieces flying off of the spinning arm.

Hardware Design

  • Bodine Electric Company AC motor
  • Base support plate
  • Vertical support plate
  • Plexiglas support arm
  • Plastic arm (for LED)
  • Several 3M dual locks
  • Electrical tape
  • Hot glue
  • Various size screws
The main components of our hardware design is an AC motor, a mounting bracket for the motor, and the spinning arm which is comprised of a Plexiglas piece and a plastic piece. The Plexiglas acts as the main support for the arm and is connected to the spinning shaft of the motor, while the plastic piece has for the 90 degree bend at one end to provide a platform for mounting the LED's.
Our AC motor does not have any self-supporting component to stand upright. Thus, we have built a mounting bracket that will hold to make sure the motor is standing upright. The bracket consists of the base piece and the vertical support piece. Both pieces are approximately � of an inch thick. The vertical support piece is connected to the base piece at a 90 degree angle with two size 8-32 screws. Next, the motor is attached to the vertical support piece with four size 10-32 screws in a square orientation. The four tapped screw sockets on the motor was initially already there, so we had to just drill four holes in the vertical support that are lined up with the provided sockets on the motor. This mounting bracket provides great stability while the motor is spinning at high rates. Load balancing of the spinning cantilever is the main reason for the stability during spinning. As an addition precaution , the user should clamped the bracket to a table during the spinning.

spin arm
Figure 5. Spinning arm attatched to rotor. 

For the spinning arm, a piece of Plexiglas 1/4 of an inch wide and 1/2 foot long is attached to the spinning shaft of the motor. This shaft is approximately a size N hole with a small flat edge. In order to secure the Plexiglas firmly to the shaft without it sliding along the shaft in any way, we drilled a hole size that is just a bit smaller than size N (to make it a very tight fit), and drilled a small hole on the side to insert a set screw that will push against the flat edge. We decided to use Plexiglas because it is a strong yet light material. Lastly, a thin plastic piece was bent at 90 degrees near one end and attached to the Plexiglas. We are using this plastic piece mostly because it is easily bendable while also light.
In order to make sure we don't get too much wobbling when spinning at high rates, we positioned the electrical components on the spinning arm to provide good counterbalance on both sides (Figure 5).

Software Design

The software design of this project is relatively simple. We are running three tasks; task1 to record and calculate the current RPM at every revolution, task2 to write the appropriate data (based on matrix) to the respective MAX6966 chip port via SPI, and task3 to run the animations. The frequency of task2 being executed depends on the measured RPM values by setting the release and deadline to the amount of time per "segment" (each column in our matrix). Each "pixel" of the image is represented by one element in the matrix. Currently, we have a 14x90 matrix displaying only on half of a circle, but it is possible to expand the resolution in the future. Furthermore, each element in the matrix is a 16 bit number where the first 4 bits are for the red value, the next 4 are for the green value, and the last 4 bits are for the blue value of an LED. These 4 bit values are mapped to 8 bit values to actually set the intensity level of the LED's. The main difficulty of the software was to setup the SPI communication between the microcontroller and the MAX6966 chips.
The MAX6966 has 10 I/O ports, each capable of outputting an 8-bit PWM signal. Each port is controlled by registers onboard the chip. The SPI bus is used to communicate with the MAX6966 and set both the explicit registers which control the ports and the implicit registers which control the state of the chip (power up sequences, shutdown mode, run modes, etc). The MAX6966 is a current sync which means to turn on an LED, we short the Port pin to ground completing the circuit and turning on the common anode RGB LED. To program the chip, we send commands to the register to allow maximum current draw through each pin (20ma) and set every port high (LED's are wired low logic). We put the chip in run mode and then we are ready to set the outputs of every pin and control three RGB LED's (per MAX6966 chip).

In order to display anything, a transmitter must send pixels to the onboard receiver which will then populate the display matrix in the microcontroller with the sent pixels. Thus, there are two components: the transmitter code and the receiver code. The transmitter code is very straightforward; we transmit each pixel at a time as a packet. Before we send each packet, we must send a SYNC byte and then an ADDR byte. The SYNC byte will sync the transmitter and the receiver, and the ADDR byte will let the receiver receive data only from a transmitter with that expected ADDR byte. After these 2 bytes are sent, we send the column and row byte. Next, we break the 16 bit data into 3 bytes that contain the first 3 nibbles of the 16 bit data and send them across. Lastly, we send an antisync byte to let the receiver know that it has finished sending data.
The code for the receiver is a bit more complicated. It involves a state machine with states WAIT_SYNC, WAIT_ADDR, and WAIT_DATA. State WAIT_SYNC waits for the SYNC byte from the transmitter and once it sees that, it goes to the WAIT_ADDR state. State WAIT_ADDR waits for the ADDR byte and when it sees it, it goes to the WAIT_DATA state. Otherwise, it goes back to WAIT_SYNC state. In WAIT_DATA state, the processor waits to get data for the column and row byte and then the data bytes. After all the data bytes and the antisync byte are received, the state machine will proceed to recompile the individual bytes back to a 16 bit data and put it in the matrix element at the received row and column.
We have also added animations to our project. This specific animation was hardcoded to move the 'S' in "SEXY" back and forth repeatedly. We did this by turning off the LED's in the previous location of 'S' and then turn on the LED's in the next location of 'S'. As of now, our animation code remains to be hardcoded and a possible extension for this project can be a more user-interactive animation.


Hardware Testing

The structural components of the design were very straightforward; we needed a design that would allow the motor to stand upright instead of lying down. Thus, we eventually came up with the L shaped mounting structure. The actually machining process for this piece took time since neither my partner nor I have had much machining practice. However, it was just a matter of drilling two holes through the vertical plate which lined up with the two holes in the base plate. The important step was to tap the base plate, but use a body drill for the vertical plate for the same hole size. This allows the screw to push the vertical plate against the base plate tightly. Our original efforts had both holes in the vertical and base plate tapped, causing the joint to be very weakly attached. After the holes on the vertical plate were drilled with the body drill, the joint became very strong.
After attaching the spinning arm (the last structural component), we tested spinning the motor. The first test proved that it was necessary to clamp the mount to the table while spinning. This was because since the motor was just an AC motor with the power outlet as the power source, the motor settings were either off or on at maximum speed. Even with the mount clamped down, when the motor was turned on, the motor would shake the entire bench. This was clearly too dangerous to actually test with any electrical devices attached to the arm. To allow a variable speed for the motor, we used a light dimmer that is basically just a variable AC controller. This allows us to adjust the speed of the motor progressively, allowing us to test with much lower RPM's.
Next, the electrical components were added to the arm. The electrical components that we used in our initial light test consisted of a 9V battery, the target board, the IR sensor, a through-hole board with one MAX6966 chip, and another through-hole board with three LED's. Aside from the target board, all the other components were attached on one end of the arm. This was the only viable option because the spinning arm was connected to the shaft at just one end of the arm, so there was no space to add counterweights. Thus, when we started spinning at a slow 200 RPM's, the system became very unstable and started to shake the table. At this slow speed, however, it was enough to show a proof of concept because we can still discern the image. Once this was done successfully, we began to expand our design to include 14 LED's and to improve load balancing.
With the 14 LED design, we were also able to move the bottom Plexiglas piece more to the other side to allow space to put the microcontroller and the battery. This design allows us to spin the arm at near maximum speed of the motor without any signs of structural instability. The only main issue that we had left was to figure out the wiring of all the electrical components. Since we were using 14 LED's, that means we needed five MAX 6966 chips, mounted on two through-hole boards. Once everything was connected, insulated, and tested, it was turn to test the software.

Software Testing

The first piece of code that was written and tested was the SPI code. Once this was tested and working successfully, we were able to write the code based on TRT operating system.
Next, we added the code to measure the RPM of the system. Amazingly, our code worked without any major bugs with the three LED's. Our biggest concern was that TRT could possibly jump to another task while in the middle of writing SPI to one of the chips. However, this proved to not be a problem after testing. One issue that was not considered at this point was displaying all three colors for each LED. For the sake of quick testing, our matrix consisted only of either on or off for each LED, where on is just max intensity in red color. Our next expansion design includes the use of all the colors for each pixel.
A major problem in the updated code for 14 LED's was a problem with having enough memory. Creating an uint32_t matrix with size 14 by 180 causes us to use four times the amount of memory that we have. Thus, we proceeded to reducing the number of column pixels to 90 while keeping the resolution the same. This just meant cutting our display to just half the circle instead of the entire circle. Also, instead of using uint32_t, which is 32 bits, we used uint16_t and use 4 bits for intensity for each LED color. These 4 bits will then be logarithmic scaled to an 8 bit number.
Another major problem we encountered was intermittent receiver failure. However, resetting power on both the receiver and the transmitter would fix the problem. Other bugs such as turning off the transmitter while it's in the middle of sending data to the receiver would also cause the receiver to freeze (the LED's still displayed the image right before it froze since the MAX chips control the LED's, thus, hard to debug). We were able to narrow the problem down to our receiver's state machine, since it had several holes that could cause the onboard microcontroller to freeze. For example, turning off the transmitter in the middle of transmitting could leave the receiver stuck in the WAIT_DATA state since it never got the antisync byte. Another problem was that we did not check to see if row and col were within our useable limits. Thus, if we were to receive mixed up data and set col to a number greater than 89, then our code would crash because it would try to access an index that's out of bounds (we have 90 columns).


Our project met all of our requirements laid out in our proposal. We were successfully able to spin a one dimensional array of LED's through a two dimensional space (a cylinder) at a high enough frequency such that a full 14x90 pixel RGB display can be seen. We can successfully communicate wirelessly to the spinning onboard microcontroller to update the display and change any of the pixels at any time.
Our onboard system was spun around 500 rpm. This was definitely fast enough for the human eye to retain the information displayed, but it did present a definite flicker to the eye. The refresh rate (of spinning the LED's) is obvious. However, by turning out the lights, or displaying in a darkened room, we can help reduce the flicker and increase the intensity of the display.
Safety was a concern for our project. Spinning essentially a blade at 500rpm is dangerous enough, and we were mounting several PCB boards, a 9V battery, a transceiver and a row of LED's to our spinning blade. We began by mounting each of the components on the cantilever with electrical tape. This unfortunately did not let us have easy access to the hardware for testing and debugging purposes and we could not remove the hardware easily for upgrades, modifications or repairs. Removing the tape could produce voltage spikes as high as 5000V across our circuits so at the risk of blowing out chips and damaging the hardware, we carefully removed the tape and abandoned this method of attaching our hardware to the cantilever. We used Dual Lock, a 3M product similar to Velcro, which has a high coefficient of friction and would allow us to detach our boards for repairs and modifications as well has hold them on while the intense g forces threaten to hurl them off the spinning cantilever. As a precaution, we wore safety glasses to protect our eyes should anything happen. Before each time we turned on our motor, we checked each board to ensure it was securely fastened. We also used variable AC speed controller to slowly ramp up the speed. This helped reduce the severe acceleration (both from spinning and quickly increasing the speed).
We did use the radio transceivers identical to those several groups in the lab. We prevented interference from other radio communication by adding a fixed address in the beginning of the packet structure. Both the receiver and the transmitter had this fixed address hardcoded and checked each packet to ensure they contained it. If the packet had this address, we could be confident that this was our packet we received, if a different address was read, we could be sure it was someone else's packet we have accidently received.
In terms of a user interface, the method for sending pixels at this point in time must be done manually. Commands must be sent to every pixel detailing exactly what color to display. The transmitter also needs to be programmed each time a new packet or group of packets needs to be transmitted. This leads a cumbersome user interface, since the user must be familiar with programming the microcontroller and familiar with our code. In the future, we would like to connect the UART (instead of using the UART to send the data to the transceiver) to the computer, and connect the transmitter to a manually written UART on a separate I/O pin. This would allow serial communication between the computer and the microcontroller, opening the possibility for all sorts of user interfaces to be built. One idea for future exploration would the writing a program which parses a *.bmp or *.jpg and sends those across the UART to the microcontroller to be then transmitted via radio to the onboard microcontroller and displayed on the LED's.


While we met all the specifications detailed in our proposal and pleased with the performance we achieved, we have many plans for building on the initial foundation and continuing with additional refinement of the project. We succeeded in building a proof of concept, on the test bench, a rugged design; however, our project is only a foundation on while many other interesting projects could be built.
Improvements and areas of future exploration include upgrading to a faster motor to eliminate the "refresh" or blinking of the display. This would involve some major modifications to the design including figuring a better way to fix the PCB boards and battery to the spinning cantilever. Perhaps, it would be better to just design our own PCB in which all the components would be surface mounted. This would eliminate much of the heavy wires and extra PCB board contributing to the weight of the arm as well as drastically reducing the space (since every component would be surface mount) needed to contain all the components. Reducing size and weight would also make it easier to spin the cantilever faster.
The RGB LED's have done a great job, however I would like to either get defused LED's (we used a clear LED casing) or LED's in which each color diode in the LED housing was closer together. Sometimes, depending on the viewing angle, it can be difficult to tell that two different color diodes in the same LED aren't two side by side LED's.
In conclusion, this project really demonstrated competence combining a difficult integration of the mechanical and electrical systems to build a persistence of vision display. We built a general standalone system which can receive input from any device wirelessly to print out a display based on the pixel information received. We demonstrated this by connecting with the alphabet character recognition system. The onboard system is a fully contained system, capable of outputting the display at varying RPM speeds and not carrying about what system interfaces with it as long it follows a standardized wireless protocol developed by us. This project also has so much room to explore further exciting developments and additions to the many devices with which it could interface.


MAX6966 Board Schematic

MAX6966 Board Schematic
Schematic of the MAX6966 board connected to the LEDs.

Microcontroller and RF Schematic

MicroBoard Schematic
Schematic of the microcontroller with RF and radio transceiver circuits.

Source Code

Download the main source code here
Download the transmitter source code here

Budget List

Description Vendor Number Ordered Unit Price ($) Total Price ($)
-- -- -- Total Expenditures 70.39
100 RGB LEDs Parts Express 0.14 19.99 2.79
Motor Scrounged 1 Free 0.00
Transceiver Lab 2 Free 0.00
MAX6966 MAXIM 5 Free Samples 0.00
Target Board Lab 2 15.00 30.00
2" Through-hole Board Lab 4 1.00 4.00
Female PIN headers Lab 282 0.05 14.10
0.1" Headers Lab 20 0.05 1.00
9V Cable Lab 1 Free 0.00
Jumper Cables Lab 8 1.00 8.00
6" Through-hole Board Lab 1 1.00 1.00
Dual Lock Campus Store 0.50 15.00 7.50
Metal Mounting Bracket Scrounged 1 Free 0.00
Wires Lab Many Free 0.00
Electrical Tape Lab Many Free 0.00
Ribbon Cable Lab 15 Free 0.00
Plastic Cantilever Lab 2 Free 0.00
Resistors/Capacitors Lab Many Free 0.00
LM340-15 Lab 1 Free 0.00
LP2951 Lab 1 Free 0.00
Jumpers Lab 2 1.00 2.00
Read More


| |

Face detection and tracking has been an important and active research field because it offers many applications, especially in video surveillance, biometrics, or video coding. The goal of this project was to implement a real-time system on an FPGA board to detect and track a human’s face. The face detection algorithm involved color-based skin segmentation and image filtering. The face location was determined by calculating the centroid of the detected region. A software version of the algorithm was independently implemented and tested on still pictures in MATLAB. Although the transition from MATLAB to Verilog was not as smooth as expected, experimental results proved the accuracy and effectiveness of the real-time system, even under varying conditions of lights, facial poses and skin colors. All calculation of the hardware implementation was done in real time with minimal computational effort, thus suitable for power-limited applications.
 lab setup

Full report (pdf)

Read More

Samsung Galaxy S4 specifications

| |

Here comes the complete tech specs of the new flagship phone "Samsung Galaxy S4"

keep hooked to see the new features and specs right after the break .....


Read More

Samsung Galaxy S4

| |
finally the smartphone manufacture Samsung Electronics announced the much awaited s series fourth generation GALAXY S 4 smatphone which features a  5-inch Full HD Super AMOLED display with a resolution of 1920 x 1080 pixels at 441 ppi. 

It weighs 130g and is 7.9 mm thick. The phone will be powered by a 1.9 GHz Quad-Core Processor or a 1.6 GHz Octa-Core processor.Running Android 4.2.2 OS, the Galaxy S4 has a 13 megapixel auto focus camera with flash and zero shutter lag.
It also uses the corning gorilla glass 3 technology which makes it a perfect companion for life.

Its features like Samsung optical reader(it will recognize text,bar codes etc and then use them for call,sms,translation and much more) and Samsung watch on(it will serve as a optical remote for large number of in house devices like tv,dvd plyers ,ac etc) make our life much more simple by providing more utilities

The new "s health" software from samsung will provide you details about your health and regular preventions and cure about various body diseases.

so keep your pockets lose to get your hands on this new flagship phone from Samsung shortly :):)
Read More

Samsung Galaxy S4 features

| |

finally the time has come when the smartphone giant Samsung premiered its latest flagship phone, The Galaxy S4, which supports a bigger display and amazing features such as gesture controls. TO add to core world of processors It comes with 1.9 GHz quad-core processor and 1.6 GHz Octa-core processor depending on regions, supporting 3G network as well as the 4G LTE. 

Here's a look at the great amazing features that the new flagship S4 packs in it:


The new 'Smart Pause' feature would enable users to control the screen by where they look. When users are watching a video, the video pauses if they look away, then it re-starts right up again when they look back.


The 'Smart Scroll' function would allow users to scroll the browser or emails up and down without touching the screen. It recognizes users' face looking at the screen and movement of their wrist and then scrolls the pages up or down accordingly.

A 'dual camera' function, which had a 13 megapixel rear camera and a 2 megapixel front camera, would allow users to select eight different ways to combine the two photos taken by both it the coming era the 8 mp has upgraded to 13mp and pushed the limits of smart photo shoot


Also When a video is playing, for instance, the stream will automatically pause if the person glances away and it will restart when the eyes refocus on the screen.


The latest phone also has a sensor that lets users move their hands to the left or right to scroll between different websites they have opened or through songs or photos in an album without having to touch the phone.

 Another feature includes the option to automatically put a copy of details from a photograph of a business card into the phone's contacts database or call a number in the business card. Samsung is also promising an instant translation between 10 different languages for certain applications, as well as a separate translation application on the device.


so get yourself ready to buy this new phone which has touched the new heights of technology giving a strong competition to its rivals:):)

Read More

top 10 five star hotels in world

| |
finally here it comes ....the top 10 hotels of the world which surpasses the the luxury element in them when compared to the others due to their finest services offered to the guests to make them experiance lure the bliss of heavens at their land in the nature bliss
so to start off with The Phoenix Resort grabs the first spot

1.The Phoenix Resort

2. The Peninsula

3. Star Wood Hotels

4.The Upper House

5. The Oberoi Udaivilas

6.Onyria Marinha Edition Hotel & Thalasso

7.Alchymist Nosticova Palace

8. The Chedi Club Tanah Gajah a GHM Hotel

9. Shangri-La Hotel, Tokyo; Chiyoda, Japan

10.Hotel Imperial Vienna; Vienna, Austria

Read More