Thursday, June 19, 2008

Project Components

  • ATMEGA 16 microcontroller
  • ST LIS3L02 3-axis accelerometer
  • CYWM 6935 Wireless module
  • MAX 233 for serial communication
  • TC 1262 3.3 volt regulator

We are really thankful to
ST,Microchip,& Cypress for their free sample programs initiatives & help ...

Thursday, June 5, 2008

Final Board

Receiver Side:

Transmitter Side:

Final PCB:

Wednesday, June 4, 2008

Project video & Code

Getting Started


Nintendo Wii Remote uses simple 3-D mouse principle. A main feature of the Wii Remote is its motion sensing capability, which allows the user to interact with and manipulate items on screen via movement and pointing through the use of accelerometer and optical sensor technology. Apple I-PHONE gained lot of attention with its interactive keyless accelerometer based navigation.

Market has lot of play station remotes including inertial sensors for playing 3-D games. Gyration has just released their Gyromouse with simple 3-axis gyroscope as inertial sensor based on magnetic properties to sense amount of degree of rotation along any of 3-axes.Simple orientation application also gives help in GPS based navigation system.

Our idea came out there to find an alternative to mouse pad & clumsy movement based optical mouse. Accelerometer based mouse would help in many ways for screen navigation, tilt based games etc. With its small size QFN package it can even be easily inserted in mobile to interface with Bluetooth or can occupy user’s fingertip to navigate.


Human Interfacing Device is key area in modern electronics era. Gesture recognition can be well introduced in modern day computers to play 3-D games. Virtual Reality is not far away from our doorsteps. Simple inertial navigation sensor like accelerometer can be utilized in getting Dynamic or Static acceleration profile of movement to move cursor of mouse or Gyroscope to even rotate 3-D object.

We propose a technique on same principle to convert acceleration profile of accelerometer into distance with double integration. Accuracy might be issue as errors keeps on adding in double integration but with robust signal processing it would not create problems. Only limitation will be in movements that cause little acceleration which puts upper limit on sensitivity of sensor. (In mill volts per g, g= 9.8m/s2)

Measure challenge in this technique is to somehow separate out Dynamic & Static response of accelerometer to differentiate between Rotational & Static movements.

On similar basis tilt based movement can be mapped onto cursor movement of mouse. This introduces entirely different technology in navigation compared to earlier Ball mouse with optocoupler or latest optical image processing based mouse. For smooth navigation we added CYWM 6935 wireless module with 50m range.

Simple low cost, low power inertial sensor based mouse with wireless capability will provide ease of use. It can also be converted to be useful in 3-D gaming application. It can be well used in Gesture Recognition with additional gyroscope with complete 6–Degrees of freedom.

So, next time onwards while explaining PPT on projector our professors will just rotate their wrists far away from computers….?

Filtering & Noise Removal

Matlab Signal Processing:

Real time data from accelerometer consists of some stationary noise it needs to be filtered out using second order Butterworth filter. But instead we applied simple RC-filter in hardware & taken moving average of past 16 samples in Matlab. Accuracy depends on initial calibration value which sensor gives at 0G (Generally for 10 bit ADC it is 512 i.e.Vcc/2). We implemented Discrimination window of +/- 5 relative acceleration values to minimise drift errors.

3-d Mouse attempt

3-D Mouse:

We started with aim to determine 3-dimesional orientation of sensor in free space. We worked on signal processing in MATLAB to make real time data noise free by low pass filtering on windowed signal. We got good results (as shown in Fig. ) but only for slow movements. With fast movements the averaging of data was affecting magnitude of acceleration so no real movements were observed. We tried different integrations to minimise cumulative errors. This was our first attempt towards possibility of inertial sensor towards gesture recognition which got fair enough results. We tested sensor for its accuracy under different condition & found that it is more accurate for rotational motion than static as its principle of operation much favours earlier thing. That’s why it is well used in tilt based keyless PDA (Personal Digital Assistant).

Monday, June 2, 2008

Position Based Approach

square movement:

Go & Comeback To Original:

Position Based Mouse:

After signal processing for noise removal, we started giving some specific motion to observe instantaneous changes in input data along x-y plane. We found that static jerky movements are less than 300ms period. Figure shows results for square movement with clearly indicating direction & magnitude of movement (around peak value =50). This was primary focus as double integration would give absolute values as signal is well within error limits.

It was clear that we can differentiate between tilt & motion based acceleration. Tilt can be assumed to be either only slowly varying or if changing more quickly to change steadily to a new value without oscillation. Thus all oscillations occurring on short timescales (less than about 300ms) can be assumed to be caused by movements, i.e., accelerations followed by retardations. This separation is achieved by a least-square fit procedure with a window of 64 sample points. It is worth noting change in X- axis value when Y-axis is direction of motion.


Algorithm shows calculation of distance from acceleration profile. Calibration routine is essential as dynamic properties of sensor are not steady & keeps on changing which introduces drift errors in calculation. We calculated distance without any floating point calculation only with shift operations. Sampling time was considered to be constant say 10 ms with 100 samples per second.

Figure shows results of simple Go & Comeback to Original Position movement with velocity & distance results (Axis values are scaled) along x-y plane. The expected results & observed differs because of initial calibration value which is subtracted from 10 bit result of ADC to get relative magnitude of acceleration. This error keeps on increasing if accelerometer is not kept steady to settle down for some period after movement. Thus accuracy was main constraint in actual position based mouse with integration.


  • Sampling Frequency= 62.5 KHz
  • Sampling Time= 213┬Ás
  • Sampling Rate = 200 samples per second
  • 10 bit ADC, 0g=512, +1g=800, -1g=380 count
  • Steady state Drift Error= +/- 20 count
  • Sensitivity = ((+1g) – (-1g))/2 = (740--360)/2 = 190 count per g (As per datasheet sensitivity= Vcc/5 = 660 mv/g =210 count)
  • Zero g Offset = ((+1g)+ (-1g))/2 = (740+360)/2 = 550 count at 0g

Tilt Based Approach

For more accuracy we finally decided to implement VB based tilt mouse. Tilt based properties of accelerometer are really accurate, slow varying & proportional to static, large in magnitudes.

Figure shows variation in data in 1-complete rotation along x-y plane. Relative peak magnitude is +/- 200 counts. Mapping this data onto computer screen for movement of cursor was quite simple in VB. It gave enough accuracy. Different gesture recognitions were also possible with template matching. But we restricted ourselves to make it wireless on CYWM 6935(2.4 GHz- 2.4803 GHz) USB Module with range of 50 meters using Direct Sequence Spread Spectrum technique.

This tilt information was then mapped on to computer screen in Visual Basic to move cursor in X or Y direction. Averaging 4 samples in microcontroller gives stable results with around 100 samples per second scanning rate.

Wireless Accelerometer Based Mouse

we are using CYWM6935 Wireless integrated module with antennas using DSSS technique over 2.4 GHz ISM band. It can work as ‘TRANSCEIVER’ at same time. With BLUETOOTH STACK it can be made to communicate with any Bluetooth enabled Mobile Phone. Below are the features of wireless radio module.

CYPRESS Wireless Radio module: Features

  • The CYWM6935 LR 2.4-GHz DSSS Radio SoC Module includes radio (CYWUSB6935) , antenna, and all external components
  • Operates in the unlicensed Industrial, Scientific, Medical (ISM) band (2.4 GHz–2.483 GHz).
  • -95-dBm receive sensitivity.
  • Up to 0dBm output power.
  • Complete Radio Module with Dual PCB Trace Antennas.
  • Range of up to 50 meters or more.
  • Data throughput of up to 62.5 Kbits/sec.
  • SPI microcontroller interface (up to 2 MHz data rate)
  • Operating voltage from 2.7V to 3.6V.
  • Dual DSSS reconfigurable baseband correlators
  • 13-MHz input clock operation
  • Low standby current
  • Integrated 30-bit Manufacturing ID

Functional Description:

The CYWM6935 Wireless USB LRTM Radio Module offers a complete radio module solution for integration into existing or new 2.4-GHz products.
The CYWUSB6935 transceiver is a single-chip 2.4-GHz Direct Sequence Spread Spectrum (DSSS) Gaussian Frequency Shift Keying (GFSK) base band modem radio that connects directly to a microcontroller via a simple serial peripheral interface (SPI).
  • It supports up to 78 channels of 1MHz each with 49 Golden Codes in each channel with Direct Sequence Spread Spectrum a theoretical capacity of 3822 channels.
  • Thus it can be used for both Point to Point & Multipoint communication.
  • Normal or double data rate with 32chips / 2 bit.
  • There are 64 Configurable Registers for various Settings & Adjustments.
  • No. of chips per bit can be selected as 32 chips/bit or 64 chips/bit by REG_DATA_RATE Register.
  • Power levels can be set from 0 to 30 DBm with REG_PA Register.
  • Dual base band correlate Receiver with data registers as REG_RX_DATA_A & REG_RX_DATA_B Registers.
  • EOF, Overflow & Underflow indication of received data for reliable communication.

Serial Peripheral Interface:
The SPI allows high-speed synchronous data transfer between the Microcontroller and peripheral devices. The SPI consists of four different signal lines. These lines are the shift clock (SCK), the Master Out Slave In line (MOSI), the Master In Slave Out line (MISO) and the active low Slave Select line (SS). When the SPI is enabled, the data direction of the MOSI, MISO, SCK and SS pins are overridden according to the following table.
The SS pin in slave mode is always an input pin. A low level activates the SPI of the device while a high level causes its deactivation. The master is the active part in this system and has to provide the clock signal a serial data transmission is based on. The slave is not capable of generating the clock signal and thus can not get active on its own. The slave just sends and receives data if the master generates the necessary clock signal. The master however generates the clock signal only while sending data. That means that the master has to send data to the slave to read data from the slave.
The system is single buffered in the transmit direction and double buffered in the receive direction. This influences the data handling in the following ways:
  1. New bytes to be sent can not be written to the data register (SPDR) / shift register before the entire shift cycle is completed.
  2. Received bytes are written to the Receive Buffer immediately after the transmission is completed.
  3. The Receive Buffer has to be read before the next transmission is completed or data will be lost.
  4. Reading the SPDR will return the data of the Receive Buffer.
The ability to connect several devices to the same SPI-bus is based on the fact that only one master and only one slave is active at the same time. The MISO, MOSI and SCK lines of all the other slaves are tristated (configured as input pins of high impedance with no pull-up resistors enabled). A false implementation (e.g. if two slaves are activated at the same time) can cause a driver contention which can lead to a CMOS latch up state and must be avoided. Resistances of 1 to 10 k ohms in series with the pins of the SPI can be used to prevent the system from latching up. However this affects the maximum usable data rate, depending on the loading capacitance on the SPI pins.
A write collision occurs if the SPDR is written while a transfer is in progress. Since this register is just single buffered in the transmit direction, writing to SPDR causes data to be written directly into the SPI shift register. Because this write operation would corrupt the data of the current transfer, a write-collision error in generated by setting the WCOL bit in the SPSR. The write operation will not be executed in this case and the transfer continues undisturbed.
A write collision is generally a slave error because a slave has no control over when a master will initiate a transfer. A master, however, knows when a transfer is in progress. Thus a master should not generate write collision errors, although the SPI logic can detect these errors in a master as well as in a slave mode.

As stated in previous part, data received to wireless radio module is send on serial port of PC. This is done using ATMEGA AVR controller. In PC VB-program accepts data on serial port as input for processing.

VB commands for handling Serial Port:
Inserting the object:
For serial communication we have to add MsComm object. The image of this object looks like this:
Sets and returns the state of the communications port (open or closed).
object.PortOpen [ = value ]
Setting the PortOpen property to True opens the port. Setting it to False closes the port and clears the receive and transmit buffers. The MSComm control automatically closes the serial port when your application is terminated.
Sets and returns the baud rate, parity, data bit, and stop bit parameters.
object.Settings [ = value ]
If value is not valid when the port is opened, the MSComm control generates error 380 (Invalid property value).
Value is composed of four settings and has the following format:
Where BBBB is the baud rate, P is the parity, D is the number of data bits, and S is the number of stop bits. The default value of value is:
To get data on port to program following command is used:
Data = object.Input
OutbufferCount, Inbuffercount:
Returns the number of characters waiting in the transmit buffer. You can also use it to clear the transmit buffer. This property is not available at design time.
object.OutBufferCount [ = value ]