Mouse Controller With Infrared Remote
Introduction
1.1 Abstract:
The objective of our project is to develop a microcontroller based system to control computer mouse with an infrared remote. To accomplish the task we have used a Sony® TV remote, an Atmega8 microcontroller, a 38 KHz IR receiver with an external circuit. For connecting the system with PC we’ve chosen USB interfacing. The program code is developed in AVR Studio. Our circuit is very simple and easy to understand. We’ve tried to make the device user friendly as much as we can. It’s compatible in almost all PC with operating system Microsoft® Windows XP, Windows Vista or Windows 7. We hope anyone will have fun using our device.
1.2 Purpose and scope:
Almost everybody today is used to operating a remote control. From the TV, to the DVD player, up to the air conditioner, there are just a few appliances left without their own remote control. Oddly, this small superfluous but essential device called remote control is not so common in the computer world. By using this device we can control some of the function of our computer like as media player volume up & down, change audio & video etc.
1.3 IR mouse overview:
IR mouse is an AVR (automatic voltage regulator) microcontrollers based USB mouse controlled by IR remote. It receives packets from remote, decodes, and (if IR code matching) sends reports to pc via USB. Reports are as in standard USB mouse (hid class device), so there is no need for additional programs/drivers on pc side, everything is done in IR mouse and system recognizes it as standard USB mouse.
1.4 Block Diagram:
Fig: – 1.1 Block Diagram
1.5 How dose it actually Work:
As from Sony remote, we send a 12-bit along digital signal modulated in 38 KHz with a starting bit. The IR receiver demodulates the received signal and sends interrupt signal to the microcontroller. We set a timer (initial value is 0) to count the time of two adjacent ‘high level’ and ‘low level’ and count how many ‘1’ and ‘0’ are in the 7 command bits. From this counting, microcontroller recognizes the different buttons. Then data are sends to the user PC via USB. We‘ve used HID (human interface device) mouse protocol to generate different mouse signals. Here user PC can recognize the device by its pull up registers at D+ and D- pins of USB port. On low and full speed devices, a differential ‘1’ is transmitted by pulling D+ over 2.8V with a 68? ohm resistor pulled to ground. And in the main program, different mouse commands are assigned for the ground and D- under 0.3V with a 68? ohm resistor pulled to 3.6v. A differential ‘0’ on the other hand is a D- greater than 2.8V and a D+ less than 0.3V with the same appropriate pull down/up resistors.
1.6 Algorithm: Flowchart
Fig: – 1.2 Flowchart
1.7 Project Overview:
The title of the project is IR mouse. In our project, we try to control the mouse of a PC via a TV remote (using infrared ray). Here any Sony remote can be used for the controlling. We use USB interfacing for the communication with the PC. Hardwires used for the project are microcontroller (AT mega 8L), USB connector, Zener diodes (3.6V), 68? resistances, 12 MHz crystal oscillator, IR detector (38 KHz) and capacitors (27p, 4.5? and 100?). We use AVR Studio as our compiler and pony prog as program loader. Though the movement of the mouse pointer is slow and tiring but we wish that good TV remote will make the device more users friendly.
Figure: – 1.3 IR mouse with USB interface
Table 1: Components Used and Cost:
| Name of the component | Number used | Price (Tk) |
| Atmega8 L-8PU | 1 | 200 |
| Sony TV remote | 1 | 80 |
| IR Receiver | 1 | 20 |
| 12 MHz Crystal Osc. | 1 | 15 |
| 4.7uF Capacitor | 1 | 2 |
| 2.7pF Capacitor | 2 | 2 x 0.5 |
| LED | 1 | 2 |
| 3.6 V Zener Diode | 2 | 2 x 1 |
| 68 Ohm Resistors | 3 | 3 x 0.25 |
| 1.5K Ohm Resistors | 1 | 0.25 |
| USB male port | 1 | 20 |
| USB extension cord | 1 | 50 |
| PCB Board | 1 | 130 |
| Total | 523 |
1.8 Required Software:
1. Adobe Reader
2. AVR_Studio_VER_4.13
3. Pony Prog For AVR
4. Proteus 7.7 Professional
5. K Lite Mega Codec
Background Study
2.1 Introduction on USB:
USB is versatile enough to serve a multitude of device functions. Familiar USB peripherals include mice, keyboards, drives, printers, speakers, and cameras. USB is also suitable for data-acquisition units, control systems, and other devices with specialized functions, including one-of-a-kind designs. USB is reliable, fast, versatile, power-conserving, inexpensive, and supported by major operating systems. USB is a likely solution any time you want to use a computer to communicate with an external device.USB supports four bus speeds: SuperSpeed at 5 Gbps, high speed at 480 Mbps, full speed at 12 Mbps, and low speed at 1.5 Mbps.The USB protocols support data transfers at around 400 MB/s for super speed, 53 MB/s for highspeed, 1.2 MB/s for full speed, and 800 B/s for low speed. Hardware and software limitations can result in lower real-world rates, however.
To communicate with USB devices, a computer needs hardware and software that support the USB host function. The host has to know what devices are on the bus and the capabilities of each deviceto ensure that all devices on the bus can send and receive data as needed. Each transfer uses a de?ned format tosend data, addressinginformation, error-detecting bits, and status and control information. The format varies with the transfer type and direction. The host manages traf?c on the bus, and the device responds to communications from the host. Each endpoint has a number, a direction, and a maximum number of data bytes the endpoint can send or receive in a transaction .Each USB transfer consists of one or more transactions that can carry data to or from an endpoint. USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow and whether the data transaction will be a read or write and what the device’s address and designated endpoint is. The next packet is generally a data packet carrying the payload and is followed by a handshaking packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not available to accept data. USB has four different packet types. Token packets indicate the type of transaction to follow, data packets contain the payload, handshake packets are used for acknowledging data or reporting errors and start of frame packets indicate the start of a new frame. The Universal Serial Bus specification defines four transfer types- Control Transfers, Interrupt Transfers, Isochronous Transfers and Bulk Transfers. All USB devices have a hierarchy of descriptors which describe to the host information such as what the device is, who makes it, what version of USB it supports, how many ways itcan be configured, the number of endpoints and their types etc. The more common USB descriptors are- Device Descriptors, Configuration Descriptors, Interface Descriptors, Endpoint Descriptors and String Descriptors.
USB is much more complex than e.g. a serial interface. The standard de?nes not only how the bits are transferred, but also how information about a device can be obtained by the host. Every USB device must comply with this basic protocol. During the designing, it must be decided how the device presents and expects data from host. There are two accepted format of data exchange, each of which is de?ned as a device class. The existing device classes are: Human Interface Device (HID) Class, Custom Class. The most straight forward way to implement a device is by choosing class Custom, which basically means that you comply with no known class. Data can be transferred in blocks up to 254 bytes in both directions over the default control endpoint.
The human interface device (HID) class was one of the first USB classes supported under Windows. The HID class supports exchanging data for application-specific purposes. All data exchanged resides in fixed-length structures called reports. The host sends and receives data by sending and requesting reports in control or interrupts transfers. The report format is flexible and can handle just about any type of data. A HID must have an interrupt IN endpoint for sending Input reports. The rate of data exchange is limited. For full-speed endpoints, the maximum is 64 kb/s. Under Windows, supporting an alternate HID interface requires a vendor-provided driver, which eliminates the advantage of using Windows-provided drivers. The HID specification defines six class-specific requests. Two requests, Set Report and Get Report, provide a way for the host and device to transfer reports to and from the device using control transfers. Set Idle and Get Idle set and read the idle rate, which determines whether or not a device resends data that hasn’t changed since the last report. Set Protocol and Get Protocol set and read a protocol value, which can enable a device to function with a simplified protocol when the full HID drivers aren’t loaded on the host, such as during boot up. Here in HID, specific report descriptor format is used. The Usage Page item (05h) specifies the general function of the device, such as generic desktop control, game control, or alphanumeric display. The Usage item (09h) specifies the function of an individual report in a Usage Page such as mouse or keyboard. The Collection (Application) item (A1h) begins a group of items that together perform a single function, such as keyboard or mouse. The Collection contains three reports. Each report has these items: A vendor-defined Usage applies to the data in the report. A Logical Minimum and Logical Maximum specify the range of values that the reportcan contain. The Report Size item indicates how many bits are in each reported data item. The Report Count item indicates how many data items the report contains. An End Collection item (C0h) closes the Application Collection.
2.2 Infrared Receivers (IR receiver):
The TSOP17.. sseries are miniaturized receivers for infrared remote control systems. PIN diode and preamplifier are assembled on lead frame, the epoxy package is designed as IR filter. The demodulated output signal can directly be decoded by a microprocessor. TSOP17.. is the standard IR remote control receiver series, supporting all major transmission code.
Fig:-2.1 IR Receiver
The received IR signal is picked up by the IR detection diode on the left side of the diagram. This signal is amplified and limited by the first 2 stages. The limiter acts as an AGC circuit to get a constant pulse level, regardless of the distance to the handset. As you can see only the AC signal is sent to the band pass filter. The band pass filter is tuned to the modulation frequency of the handset unit. Common frequencies range from 30 kHz to 60 kHz in consumer electronics. The next stages are a detector, integrator and comparator. The purpose of these three blocks is to detect the presence of the modulation frequency.
2.3 IR Remote Control Theories:
The cheapest way to remotely control a device within a visible range is via infra-red light. Almost all audio and video equipment can be controlled this way nowadays. Due to this wide spread use the required components are quite cheap, thus making it ideal for us hobbyists to use IR control for our own projects.
2.4 Infra-Red Light:
Infra-red actually is normal light with a particular color. We humans can’t see this color because its wave length of 950nm is below the visible spectrum. That’s one of the reasons why IR is chosen for remote control purposes, we want to use it but we’re not interested in seeing it. Another reason is because IR Leds are quite easy to make, and therefore can be very cheap.
Fig: – 2.2 IR Light
2.5 Modulation:
Modulation is the answer to make our signal stand out above the noise. With modulation we make the IR light source blink in a particular frequency. The IR receiver will be tuned to that frequency, so it can ignore everything else.
Fig: – 2.3 Modulation
Receiver side a ‘space’ is represented by a high level of the receiver’s output. A ‘mark’ is then automatically represented by a low level.
ATmega8 Microcontroller:
Fig: – 2.4 ATmega8 Microcontroller
2.6 The ATmega8 provides the following features:
-8K bytes of In-System Programmable Flash with Read-While-Write capabilities,
-512 bytes of EEPROM, 1K byte of SRAM,
-23 general purpose I/O lines,
-32 general purpose working registers,
-3 flexible Timer/Counters with compare modes, internal and external interrupt, a serial programmable USART,
-A byte oriented two wires Serial Interface,
-A 6-channel ADC (eight channels in TQFP and QFN/MLF packages) with10-bit accuracy,
-A programmable Watchdog Timer with Internal Oscillator, an SPI serial port,
– Five software selectable power saving modes
– Operating Voltages: 4.5 – 5.5V (ATmega8)
– Speed Grades: 0 – 16 MHz (ATmega8)
– Power Consumption at 4 MHz, 3V, 25 C
Active: 3.6 mA
Idle Mode: 1.0 mA
Power-down Mode: 0.5 ?A
Port B (PB7-PB0),XTAL1/XTAL2/TOSC1/TOSC2
– Port B is an 8-bit bi-directional I/O port with internal pull-up resistors
– As inputs, Port B pins that are externally pulled low will source current if the pull-up resistors are activated
– The Port B pins are tri-stated when a reset condition becomes active, even if the clock is not running.
– Depending on the clock selection fuse settings, PB6 can be used as input to the inverting Oscillator amplifier and input to the internal clock operating circuit.
Port C (PC5-PC0)
– Port C is a 7-bit bi-directional I/O port with internal pull-up resistors,
-The Port C pins are tri-stated when a reset condition becomes active, even if the clock is not running.
Port D (PD7-PD0)
– Port D is an 8-bit bi-directional I/O port with internal pull-up resistors
-The Port D output buffers have symmetrical drive characteristics with both high sink and source capability.
PC6/RESET
– If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that the electrical characteristics of PC6 differ from those of the other pins of Port C.
– If the RSTDISBL Fuse is un-programmed, PC6 is used as a Reset input. A low level on this pin for longer than the minimum pulse length will generate a Reset, even if the clock is not running.
RESET
– Reset input. A low level on this pin for longer than the minimum pulse length will generate a reset, even if the clock is not running.
– Shorter pulses are not guaranteed to generate a reset.
AVCC
– A Vcc is the supply voltage pin for the A/D Converter, Port C (3…0), and ADC (7…6). It should be externally connected to Vcc, even if the ADC is not used. If the ADC is used, it should be connected to Vcc through a low-pass filter.
AREF
– AREF is the analog reference pin for the A/D Converter.
ADC7-6 (TQFP and QFN/MLF Package Only
– In the TQFP and QFN/MLF package, ADC7…6 serve as analog inputs to the A/D converter. These pins are powered from the analog supply and serve as 10-bit ADC channels.
2.7 Sony SIRC Protocol:
ü 5-bit address and 7-bit command length (12-bit protocol)
ü Pulse width modulation
ü Carrier frequency of 40kHz
ü Bit time of 1.2ms or 0.6ms
Table 3: Remote Button &Mouse Operation
| Remote Button | Mouse Operation |
| Volume + | Move right |
| Volume – | Move left |
| Channel+ | Move up |
| Channel – | Move down |
| Key 4 | Left Click |
| Key 6 | Right Click |
| Key 5 | Scroll up |
| Key 8 | Scroll down |
| Key 1 | Move up left |
| Key 3 | Move up right |
| Key 7 | Move down left |
| Key 9 | Move down right |
| Key 2 | Click and drag |
| Key 0 | Double click |
Discussion on hardware
3.1 About the principle of the mouse:
The standard mouse sends data using three consecutive packets. Each packet begins with the Start bit (always Low), followed by a data byte (starting with least significant bit), the Odd Parity bit and the Stop bit (always High). Data bytes contain mouse movement and button status information. Byte 2 and Byte 3 contain the motion values stored in two’s complement format. Byte 1 contains the overflow bits (Yo and Xo), the sign bits (Ys and Xs) and button status bits (M for middle, R for right and L for left). Mouse interface would be more reliable if a clock filter is applied. Some features of Sony TV remote are: 12-bit, 15-bit and 20-bit versions of the protocol exist (12-bit described here), 5-bit address and 7-bit command length (12-bit protocol), Pulse width modulation, Carrier frequency of 40 kHz, Bit time of 1.2ms or 0.6ms. Here 1.2ms represents logic ‘1’ and 0.6ms represents logic ‘0’. The LSB is transmitted first. The start burst is always 2.4ms wide, followed by a standard space of 0.6ms. Apart from signaling the start of a SIRC message this start burst is also used to adjust the gain of the IR receiver. Then the 7-bit Command is transmitted, followed by the 5-bit Device address. Commands are repeated every 45ms (measured from start to start) for as long as the key on the remote control is held down.
3.2 Discussion on circuit diagram:
We use AT mega 8 L microcontrollers, the heart of the overall system, to receive the IR signal and decode and send to the host. For the interfacing a 12 MHz oscillator is used along with Zener diodes, resistances and capacitors. Some power indicating LEDs are also used. INT1 pin of the microcontroller is used as the input pin and PD2 and PD4 pins are used for data transmission. We use type ‘A’ USB connector having 4 connections, one for owner, one for ground, and two for signal, labeled D+ and D-.The 12MHz crystal is required to allow the microcontroller to run at 12MHz, enabling it to operate as a low speed USB device.
Fig: – 3.1 Circuit Diagram
3.3 Working Principle:
As from Sony remote, we get 12-bit along with a starting bit. We set a timer (initial value is 0) to count the time of two adjacent ‘high level’ and ‘low level’ and count how many ‘1’ and ‘0’ are in the 7 command bits. Here NRZ decoding and Bit stuff decoding are used by the device. From this counting, microcontroller recognizes the button. And in the main program, different mouse commands are assigned for the different buttons. Then data are send to the host via define way. Here host can recognize the device by its pull up registers at D+ and D- pins. On low and full speed devices, a differential ‘1’ is transmitted by pulling D+ over 2.8V with a 68? ohm resistor pulled to ground and D- under 0.3V with a 68?ohm resistor pulled to 3.6V. A differential ‘0’ on the other hand is a D- greater than 2.8V and a D+ less than0.3V with the same appropriate pull down/up resistors .
3.4 Discussion on Microcontroller Code:
For the recognition of the device, devices have to send some description value to the host to make it ready for data transmission. At first we write some header files and some variable whose define variables. Then we wrote the USB Hid Report Descriptor function and define the structure of report buffer. A short and complete API documentation can be found in the comments in the file USB drv.h which ships with the driver. This document describes the most commonly used features. The standard rules of interface are to Call USB Device Disconnect, wait several 100 milliseconds and then call USB Device Connect. Then Calling USB Init to initialize the driver. During the main loop USB Poll must be called to perform administrative tasks in the driver. When the host sends or receives a control message on endpoint which is addressed to “vendor” or “class”, the function USB Function Setup is called in your code. It has one parameter: A pointer to the 8 bytes of setup data. It is your duty to check which functionality should be performed and whether more data should be received or returned to the host. Any short of change in assigned pins must be mentioned in USB drv.h for proper working.
3.5 Main Code:
/*********** MOUSE CONTROL with IR *************
/Controller: ATmega8 (12MHz external Crystal)
/Compiler: AVRStudio
/Author: Group–06060-(64,66,72)
/Date: Oct 2010
/************** HEADER FILE main.c *****************
/*
This example should run on most AVRs with only little changes. No special
hardware resources except INT1 are used. You may have to change usbconfig.h for
different I/O pins for USB. Please note that USB D+ must be the INT0 pin, or
at least be connected to INT0 as well.
We use VID/PID 0x046D/0xC00E which is taken from a Logitech mouse. Don’t
publish any hardware using these IDs! This is for demonstration only!
*/
#include <avr/wdt.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <avr/pgmspace.h> /* required by usbdrv.h */
#include “usbdrv.h”
#include “oddebug.h” /* This is also an example for using debug macros */
#define OSCILLATOR 12
#define dig_key_0 9 //for double click
#define dig_key_1 0 //for moving left-up
#define dig_key_2 1 //for drag and move
#define dig_key_3 2 //for moving right-up
#define dig_key_4 3 //for left click
#define dig_key_5 4 //for wheel up
#define dig_key_6 5 //for right click
#define dig_key_7 6 //for moving left-down
#define dig_key_8 7 //for wheel down
#define dig_key_9 8 //for moving right-down
#define channel_plus 16 //for moving up
#define channel_minus 17 //for moving down
#define volume_plus 18 //for moving right
#define volume_minus 19 //for moviing left
//#define mute 20 //for middle click
/*———————–USB Interfacing —————————*/
PROGMEM char usbHidReportDescriptor[52] = { /* USB report descriptor, size must match usbconfig.h */
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x02, // USAGE (Mouse)
0xa1, 0x01, // COLLECTION (Application)
0x09, 0x01, // USAGE (Pointer)
0xA1, 0x00, // COLLECTION (Physical)
0x05, 0x09, // USAGE_PAGE (Button)
0x19, 0x01, // USAGE_MINIMUM
0x29, 0x03, // USAGE_MAXIMUM
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
0x95, 0x03, // REPORT_COUNT (3)
0x75, 0x01, // REPORT_SIZE (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x95, 0x01, // REPORT_COUNT (1)
0x75, 0x05, // REPORT_SIZE (5)
0x81, 0x03, // INPUT (Const,Var,Abs)
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
0x09, 0x38, // USAGE (Wheel)
0x15, 0x81, // LOGICAL_MINIMUM (-127)
0x25, 0x7F, // LOGICAL_MAXIMUM (127)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x03, // REPORT_COUNT (3)
0x81, 0x06, // INPUT (Data,Var,Rel)
0xC0, // END_COLLECTION
0xC0, // END COLLECTION
};
/* This is the same report descriptor as seen in a Logitech mouse. The data
* described by this descriptor consists of 4 bytes:
* . . . . . B2 B1 B0 …. one byte with mouse button states
* X7 X6 X5 X4 X3 X2 X1 X0 …. 8 bit signed relative coordinate x
* Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 …. 8 bit signed relative coordinate y
* W7 W6 W5 W4 W3 W2 W1 W0 …. 8 bit signed relative coordinate wheel
*/
typedef struct{
uchar buttonMask;
char dx;
char dy;
char dWheel;
}report_t;
static report_t reportBuffer;
static uchar idleRate;
unsigned char flag = 0;
unsigned char flag1=0;
void initialize(void);
ISR (INT1_vect);
unsigned char IR_reader(void);
usbMsgLen_t usbFunctionSetup(uchar data[8])
{
usbRequest_t *rq = (void *)data;
if((rq->bmRequestType & USBRQ_TYPE_MASK) == USBRQ_TYPE_CLASS) { /* class request type */
DBG1(0x50, &rq->bRequest, 1); /* debug output: print our request */
if(rq->bRequest == USBRQ_HID_GET_REPORT){ /* wValue: ReportType (highbyte), ReportID (lowbyte) */
/* we only have one report type, so don’t look at wValue */
usbMsgPtr = (void *)&reportBuffer;
return sizeof(reportBuffer);
}
else if(rq->bRequest == USBRQ_HID_GET_IDLE)
{
usbMsgPtr = &idleRate;
return 1;
}
else if(rq->bRequest == USBRQ_HID_SET_IDLE)
{
idleRate = rq->wValue.bytes[1];
}
}else
{
/* no vendor specific requests implemented */
}
return 0;
}
/* ————————Initialization————————- */
void initialize(void)
{
DDRD &= ~(0x08);
GICR |= 0x80;
MCUCR |= 0x08;//Enable Falling Edge
TCCR0 =0x04;//Prescaler 256
TCNT0 = 0;
TIMSK &=~(0x01);
}
/* ————————Interrupt Service Routine ————————– */
ISR (INT1_vect)
{
unsigned char count;
TCNT0 = 0;
while(!(PIND&0x08));
count = TCNT0;
if(count<8*OSCILLATOR)
{
_delay_ms(20*OSCILLATOR);
TCNT0 = 0;
flag1 = 0;
}
else
flag1 = 1;
//PORTC |= 0x20; //for IR indication
}
/* ———————— IR decoder ——————————– */
unsigned char IR_reader(void)
{
unsigned char i=0, command=0, count;
while(i<7)
{
while(PIND&0x08);
TCNT0 = 0;
while(!(PIND&0x08));
count = TCNT0;
if(count>4*OSCILLATOR)
{
command = command | (1<<i);
}
else
{
command = command & ~(1<<i);
}
i++;
}
return command;
}
void remote_control (void)
{
char remote_command = 0;
if(flag1 == 1)
{
remote_command = IR_reader();
}
if(remote_command == volume_plus) //for moving right
{
reportBuffer.dx = 10;
reportBuffer.buttonMask &= ~(0x10);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
}
else if(remote_command == volume_minus) //for moving left
{
reportBuffer.dx = -10;
reportBuffer.buttonMask &= ~(0x10);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
}
else if(remote_command == channel_plus) //for moving up
{
reportBuffer.dy = 10;
reportBuffer.buttonMask &= ~(0x20);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dy = 0;
}
else if(remote_command == channel_minus) //for moving down
{
reportBuffer.dy = -10;
reportBuffer.buttonMask &= ~(0x20);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dy = 0;
}
else if(remote_command == dig_key_5) //for moving wheelup
{
reportBuffer.dWheel = 10;
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dWheel = 0;
}
else if(remote_command == dig_key_8) //for moving wheeldwn
{
reportBuffer.dWheel = -10;
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dWheel = 0;
}
else if(remote_command == dig_key_4) //for left click
{
reportBuffer.buttonMask |= 0x01;
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.buttonMask &= ~(0x01);
}
else if(remote_command == dig_key_6) //for right click
{
reportBuffer.buttonMask |= 0x02;
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.buttonMask &= ~(0x02);
}
else if(remote_command == dig_key_1) //for moving leftup
{
reportBuffer.dx = -10;
reportBuffer.dy = -10;
reportBuffer.buttonMask &= ~(0x30);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
reportBuffer.dy = 0;
}
else if(remote_command == dig_key_3) //for moving rightup
{
reportBuffer.dx = 10;
reportBuffer.dy = -10;
reportBuffer.buttonMask &= ~(0x30);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
reportBuffer.dy = 0;
}
else if(remote_command == dig_key_7) //for moving leftdwn
{
reportBuffer.dx = -10;
reportBuffer.dy = 10;
reportBuffer.buttonMask &= ~(0x30);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
reportBuffer.dy = 0;
}
else if(remote_command == dig_key_9) //for moving rightdwn
{
reportBuffer.dx = 10;
reportBuffer.dy = 10;
reportBuffer.buttonMask &= ~(0x30);
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.dx = 0;
reportBuffer.dy = 0;
}
else if(remote_command == dig_key_2) //for drag & move
{
reportBuffer.buttonMask |= 0x01;
DBG1(0x03, 0, 0);
}
else if(remote_command == dig_key_0) //for double click
{
reportBuffer.buttonMask |= 0x01;
_delay_ms(25);
reportBuffer.buttonMask |= 0x01;
DBG1(0x03, 0, 0);
remote_command = -1;
reportBuffer.buttonMask &= ~(0x01);
}
/*
else if(remote_command == mute) //for drag & move
{
reportBuffer.buttonMask |= 0x04;
DBG1(0x03, 0, 0);
}*/
}
/* ————————– Main ——————————— */
int main(void)
{
uchar i;
wdt_enable(WDTO_1S);
DBG1(0x00, 0, 0); /* debug output: main starts */
odDebugInit();
usbInit();
usbDeviceDisconnect(); /* enforce re-enumeration, do this while interrupts are disabled! */
i = 0;
while(–i){ /* fake USB disconnect for > 250 ms */
wdt_reset();
_delay_ms(1);
}
usbDeviceConnect(); /*device is now connected*/
initialize();
sei(); /*enable interrupt*/
DBG1(0x01, 0, 0); /* debug output: main loop starts */
for(;;){ /* main infinite loop */
DBG1(0x02, 0, 0); /* debug output: main loop iterates */
wdt_reset();
usbPoll(); /* need for data transmission*/
if(usbInterruptIsReady()){
/* called after every poll of the interrupt endpoint */
remote_control();
usbSetInterrupt((void *)&reportBuffer, sizeof(reportBuffer));
}
}
return 0;
}
/* ————————————————————————- */
Conclusion
4.1 Limitations:
1. Our device is only compatible in Windows XP, Vista and Windows 7.
2. As we used USB instead of PS2 port, so our mouse is little slow.
3. The circuit is very much dependent on the sensitivity of IR receiver.
4. The TV remote available in market is not good enough, so sometime
it may be needed to press a button repeatedly.
5. Also some buttons in our remote don’t work properly.
4.2 Future Improvement:
1. Just changing the code we can also interface the Keyboard using the same circuit and remote.
2. The code can be transformed to work with any TV remote.
3. Modifying the code other commands like “Shut down”, “Sleep”, “Volume up”, “Volume down”, etc. can be controlled by remote too.
4. Instead of IR other signal like RF, Bluetooth® can be used modifying the receiver circuit.
4.3 Calculation:
The construction and working principle of the project is explained in details in this report. The description of the physical implementation of the project is left for the video since the report is size limited.For full clarity, a demonstration is required which is provided in the attached video.In our project, we only show 14 functions of the mouse and we use Euclidean geometry for mouse movement. But any one can use polar geometry for this purpose. Moreover, anyone can extend the controlling functions (such as some keyboard functions) by using other buttons. For instrumental inefficiency, some of functions are not working properly. Nevertheless, we have learnt many topics on microcontroller and interface, which will be fruitful for us in future.
References:
Ø Sony SIRC infrared protocol, http://picprojects.org.uk/, February 2010
Ø USB COMPLETE FORTH EDITION, JON AXELSON
Ø DRIVER API –V-USB , http://vusb.wikidot.com/driver-api
Ø Universal Serial Bus (USB) HID Usage Tables, 10/28/2004,Version 1.12
Ø Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Firmware Specification—6/27/01, Version 1.11
Ø The PS/2 Mouse Interface, http://www.Computer-Engineering.org
Ø USB in a nutshell , making sense of the USB standard
Ø http://www.dharmanitech.com/2009/01/ir-remote-controlled-car-pwm-motor