PROJECT REPORT ON
MULTI UTILITY SENSOR NETWORK EMBEDDED SOFTWARE
SUBMITTED BY
KIRTI RAMNATH LELE SNEHA ARUN
MISHRA VARSHA SMITA KUMAR
UNDER THE GUIDANCE OF
ASST. PROF. MR. ABHAY H. KSHIRSAGAR IN PARTIAL FULFILLMENT OF THE REQUIREMENT OF THE DEGREE OF BACHELOR OF ENGINEERING IN ELECTRONICS IN MUMBAI UNIVERSITY
DEPARTMENT OF ELECTRONICS VIVEKANAND EDUCATION SOCIETY’S INSTITUTE OF TECHNOLOGY, CHEMBUR – 71 UNIVERSITY OF MUMBAI 2005 - 2006
Vivekanand Education Society’s Institute of Technology
Project Report On
Multi Utility Sensor Network Embedded Software
Submitted by
Kirti Ramnath Lele Sneha Arun Mishra Varsha Smita Kumar
Under the Guidance of
Asst. Prof. Mr. Abhay H. Kshirsagar
Department of Electronics VES Institute of Technology, University of Mumbai 2005 – 2006
Vivekanand Education Society’s
INSTITUTE OF TECHNOLOGY Sindhi Society, Chembur, Mumbai-400 071
CERTIFICATE OF APPROVAL OF PROJECT WORK
This
is
to
Certify
that
Miss Sneha Arun Lele has satisfactorily carried out the project work entitled Multi Utility Sensor Network (Embedded Software Design) in partial fulfillment of the B.E. Degree in Electronics of the University of Mumbai, Maharashtra state during 2005-2006
PRINCIPAL
PROJECT GUIDE
HEAD OF DEPARTMENT
EXAMINER
Multi Utility Sensor Network Embedded Software
MUSN Embedded Software
A Tribute to Deep S. Bhattacharjee
Deep S. Bhattacharjee was a brilliant and one of the finest students of Vivekananda Education Society's Institute of Technology, where he was pursuing his Bachelor of Engineering (B.E.) in Computer Engineering. A very sincere and hardworking student by nature, Deep always excelled in studies and was a topper of his class consistently. He was very jolly and always ever ready to help his friends and colleagues in their times of need. Unfortunately, Deep left us in a tragic accident during the floods of 26th July 2005. This project is an earnest tribute by his friends to a life which our world was blessed with for so tragically short a time. Our heartfelt prayers are with his family and friends on this occasion of unspeakable grief. May his soul rest in peace!
2
MUSN Embedded Software
Acknowledgements For guiding us throughout and supporting us relentlessly, our most sincere thanks to Abhay Kshirsagar Sir, Assistant Professor, Electronics Department and Prof. K.G. Balakrishnan, Assistant Professor, IT Department. Our sincere thanks to Dr. D. V. Gadre, Asst. Professor, NSIT, Delhi for showing us the way and pushing us in the right direction. We are grateful to him for sharing his profound knowledge and resources for AVR micro controller. Many thanks to the Principal and Management of Vivekananda Education Society’s Institute of Technology for helping us stage our project at ‘ELECRAMA 2006’. And special word of thanks to Vivekananda Education Society’s Institute of Technology’s Development Laboratory Incharge, Mr. V.M. Misra, for perennially keeping us on our toes and giving us some fantastic moments to cherish, both during and after ‘ELECRAMA 2006’. Also, our heartfelt thanks to our Laboratory Incharges, Chandrashekhar Sir, Rajesh Sir, Purohit Sir and Chandane Sir, for helping us with all the necessary laboratory resources, throughout the development phase of ‘Multi Utility Sensor Network’.
Kirti Ramnath Lele Sneha Arun Mishra Varsha Shashikant Smita Kumar D-16 Final Year Electronics, 2005-06
3
MUSN Embedded Software
Contents 1. INTRODUCTION………………………………………………………………………..7 2. BASIC TOPOLOGY OF NETWORK…………………………………………………...8-17 2.1
RS485 bus
2.2
Sensor nodes
2.3
Host Computer
2.4
RS232 to RS485 bridge with Power Supply
2.5
Program for RS232 to RS485 bridge
3. ARCHITECTURE OF AVR MICROCONTROLLER………………………………….18-26 3.1
Features
3.2
Block Diagram
3.3
Pin Configuration
3.4
Architectural Overview
3.5
Programmer’s Model
3.6
Register Summary
3.7
Instruction Set Summary
4. PROGRAMMING RESOURCES……………………………………………………….27-31 4.1
Programming Language
4.2
Programmer’s Notepad
4.3
Assembler
4.4
Compiler
4.5
WinAVR
4.6
STK500
4.7
Terminal
5. VOTING PADS…………………………………………………………………………32-42 5.1
Audience Poll
5.2
Implementation
5.3
Hardware Design
5.4
Pictures of Current Implementation
5.5
Embedded Software Design
4
MUSN Embedded Software
5.6
Software Model
5.7
Algorithm for MUSN Voting Pad application
5.8
Program for MUSN Voting Pad application
5.9
Host Software Design
5.10
Future Scope for voting pads
6. HOME MONITORING SYSTEM……………………………………………………...43-64 6.1
Home Networking Technologies
6.2
Architecture
6.3
Programs and Algorithms of MUSN home monitoring application 6.31 6.32 6.33 6.34 6.35 6.36 6.37 6.38
6.4
Algorithm for node 1 Program for node 1 Algorithm for node 2 Program for node 2 Algorithm for node 3 Program for node 3 Algorithm for node 4 Program for node 4
Conclusion
7. INDUSTRIAL PROCESS MONITORING SYSTEM…………………………………65-66 7.1
Introduction
7.2
Case Study: A Food Industry
8. CONCLUSIONS AND FUTURE SCOPE……………………………………………..67-70 8.1
Voting pads
8.2
Smart Home
8.3
Industry
9. THE ELECRAMA EXPERIENCE……………………………………………………..71-72 10. REFERENCES ………………………………………………………………………...73 11. APPENDIX – A……………………………………………………………………….. 74-83 Sensor Descriptions .
11.1
Mercury Switch
11.2
Motion Detector
11.3
Temperature Sensor
11.4
Humidity Sensor
11.5
Light Dependent Resistor (LDR)
11.6
GAS Detector 5
MUSN Embedded Software
11.7
Infrared proximity sensor
11.8
Smoke detector
12. LIST OF FIGURES…………………………………………………………………… 84-85 13. LIST OF TABLES……………………………………………………………………..86 14. GLOSSARY……………………………………………………………………………87-88 15. ACRONYMS…………………………………………………………………………..89 16. INDEX…………………………………………………………………………………90-91
6
MUSN Embedded Software
1. Introduction Technological advances in communications and electronics has enabled the development of low-cost, low power, multifunctional sensor nodes. These sensor nodes are capable of data collection, data processing and can communicate over long distances, leveraging the idea of sensor networks. Sensor networks have significantly improved over traditional sensors and have become an indispensable tool in various fields such as industry, entertainment, military, health, etc. A sensor network consists of a large number of sensor nodes that can be deployed either inside the measurand or very close to it. These nodes may be deployed in remote locations and thus allow for remote monitoring of various parameters. The sensor nodes are fitted with onboard processors. Thus the nodes carry out simple calculations and transmit only the required and partially processed data. The above-described features enable sensor networks to be used for wide range of applications. In health, for example, sensor networks can be deployed to monitor and assist disabled patients. In military, the rapid deployment and fault tolerant characteristics of sensor networks make them a very promising sensing technique for military command and control. Other commercial applications include voting pads for game shows, home security, inventory management, monitoring product quality, monitoring disaster-prone areas. The sensor nodes are usually strategically placed in the sensor field. Each of these nodes has the capability to collect and route data back to the host monitoring system. Data are routed back using a multidrop network. This network reduces the number of wires required to connect field devices to the host. Our multi-utility sensor network aims at satisfying the following criteria 1. 2. 3. 4. 5. 6. 7.
Cost effectiveness Easy procurability of components High immunity to noise Ease of operation, flexibility and user friendly GUI Ease of reconfiguration for other applications Scalability Rudimentary built-in processing capability
The focus of the Embedded Software Team is to develop the intelligence for this prototype Multi-utility Sensor network. The software development for the onboard AVR Microcontrollers, which collect and process sensor data, is done using Embedded C Language. Programming for applications as varied as Industrial Process Monitoring, Home Monitoring and Voting Pads has been done. Communication between the Sensor Network and the Host Computer follows a self developed protocol.
7
MUSN Embedded Software
2. Basic Topology of the Network The General Structure of the network is as shown below:
Figure 1 Basic Structure of our Network
The network consists of the following components: • RS485 Bus • Sensor Nodes • Host computer • RS232-RS485 Bridge with Power Supply
2.1 RS485 Bus RS485 bus is a 3-wire interface which can be used to implement multi-drop networks. When a network needs to transfer small blocks of information over long distances, RS-485 is often the 8
MUSN Embedded Software
interface of choice. The network nodes can be PCs, microcontrollers, or any devices capable of asynchronous serial communications. Compared to Ethernet and other network interfaces, RS-485’s hardware and protocol requirements are simpler and cheaper. The RS-485 standard is flexible enough to provide a choice of drivers, receivers, and other components depending on the cable length, data rate, number of nodes, and the need to conserve power. Several vendors offer RS-485 transceivers with various combinations of features. Also, there are options for methods of terminating and biasing the line and controlling the driver enable inputs. The interface popularly known as RS-485 is an electrical specification for multipoint systems that use balanced lines. RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. The specification document (TIA/EIA-485-A) defines the electrical characteristics of the line and its drivers and receivers. There are brief suggestions relating to terminations and wiring, but there’s no discussion of connector pin outs or software protocols (as there is for RS-232). An RS-485 network can have up to 32 unit loads, with one unit load equivalent to an input impedance of 12k. By using high-impedance receivers, you can have as many as 256 nodes. An RS-485 link can extend as far as 4000′ and can transfer data at up to 10 Mbps, but not both at the same time. At 90 kbps, the maximum cable length is 4000′, at 1 Mbps it drops to 400′, and at 10 Mbps it drops to 50′. For more nodes or long distances, you can use repeaters that regenerate the signals and begin a new RS-485 line. Although the RS-485 standard says nothing about protocols, most RS-485 links use the familiar asynchronous protocols supported by the USARTs in PCs and other computers. A transmitted word consists of a start bit followed by data bits, an optional parity bit, and a stop bit. We have implemented the RS485 Network using MAX485/DS72176 Driver ICs. We have used a twisted pair of wires as the RS485 Medium as shown in Figure 2. The network has been implemented in a daisy chain fashion as shown in Figure 3. The Daisy Chain topology allows for efficient management of termination of reflections on the bus. 120 Ohm resistors are used for termination of the bus on either end.
9
MUSN Embedded Software
Figure 2 RS485 Network Implementation using MAX485/DS75176 Half Duplex Drivers 10
MUSN Embedded Software
Figure 3 Daisy Chaining MAX485/DS75175 are 8 Pin ICs which can be used to drive the RS485 Bus. Figure 4 shows an extract from the MAX485 Datasheet. MAX485 are non slew rate limited ICs which support up to 2.5 Mbps data rate. MAX483 have slew rate limited to 0.25 Mbps. This can allow for noise immunity in the network in cases where the data rate required is low.
Figure 4 Extract from MAX485 Datasheet
2.2 Sensor Nodes The sensor node is the main workhorse of system. At its heart lies the ATMega8 microcontroller which is a high performance RISC controller with a built-in USART, Analog to Digital Converter (ADC) and Self Programming Capabilities. It communicates with other nodes and the host over the RS485 Bus. MAX485 level converter is used to convert the signals between TTL and RS485 levels.
11
MUSN Embedded Software
The sensor node uses its ADC to sample data from its sensors and convert them to digital format. This collected sensor data is then processed by the ATMega8 microcontroller. The result of this processing is sent over the network to the host. ATMega8 contains a self programming feature. This allows us to write a piece of code called a bootloader into its program memory. This piece of code allows it to be reprogrammed over the RS485 network by the host thereby eliminating the need for a person to physically go to the various nodes to reprogram them. The following sensors maybe used with the network: • Infrared/Capacitive/Inductive Proximity Sensor for counting objects on the Assembly Line • Single chip Temperature sensor or PT100 based Temperature sensor • Power supply monitoring ICs • Humidity Sensors • Gas Sensors (Carbon Monoxide, Nitrogen Oxide) • Calibrated Strain Gauge based Load Cells (For measuring weight) • Accelerometer (for measuring acceleration) • Tilt Switches (Mercury Switches) • Hall effect switch IC • Hall Effect Vane Switch • Opto-interrupters • LVDTs • Shaft Encoders • Reed Switches • Flame Sensors (UV Sensors) • Any other sensors which are available pre-calibrated or don’t require calibration. More about AVR Microcontroller is covered in the following chapter. Information about the sensors used are covered in the chapters describing the various application of the network. The circuit diagram of the nodes is shown in Figure 5.
12
MUSN Embedded Software
Figure 5 Schematic of a Sensor Node
13
MUSN Embedded Software
2.3 Host computer The host computer runs a software for acquiring data from the network. The software running on the host computer is written in JAVA. Eclipse IDE was used during the creation of the software. The library used for implementing serial communications in Java was RX/TX. The host computer communicates with the RS485 Network using the RS232-RS485 Bridges. The host computer is a windows based system with multiple RS232 serial ports. 2.4 RS232 to RS485 bridge with Power Supply It is used to connect the RS485 bus to the host computer via the RS232 communications ports. It consists of a MAX232 Level converter which converts RS232 signals from the computer to TTL levels. These TTL signals are further converted to RS485 signals using the MAX485/DS75176 Driver ICs. An AVR ATMega8 Microcontroller is used to monitor the incoming and outgoing data from the host computer and switch the MAX485 between the transmitting and receiving mode accordingly. The Power Supply to the network is injected from this point. The Bridge can be mounted on the Power Supply itself for compactness. The Power Supply is a 2 ampere/12 volts switching power supply which itself draws power from 240V Mains. Multiple RS232-RS485 Bridges can be used at either end of the network to increase network reliability and fault tolerance. It means that the networks can withstand breaks in the RS485 medium (twisted pair) by querying the nodes from multiple points on the network. This requires multiple RS232 Ports on the host computer. Figure 6 shows a photograph of the power supply.
Figure 6 12 volts – 2 ampere Power Supply
14
MUSN Embedded Software
Figure 7 Schematic of the RS232-RS485 Bridge
15
MUSN Embedded Software
2.5 Program for RS232 to RS485 bridge Algorithm (version 1) 1. A character ‘b’ is sent by the central host (PC) before it starts any communication with the sensor nodes. 2. The remaining packet is sent as per the specified protocol. #include
#include #include #define syncchar 'a' volatile uint8_t bytctr=0,recval=0,rx_no_of_data_bytes=0; volatile uint8_t eepromctr=0x02; SIGNAL(SIG_UART_RECV) { recval=UDR; switch(bytctr) { case 0 : if(recval == 'b') { PORTD=PORTD | 0b00000100;//RX# disable TX enable bytctr=bytctr+1; } break; case 1 : if(recval == syncchar) bytctr=bytctr+1; else { bytctr=0; PORTD=PORTD & 0b11111011;//RX# enable TX disable } break; bytctr=bytctr+1; //source id break; bytctr=bytctr+1; //destination id break; rx_no_of_data_bytes=recval-0x30;//packetlength bytctr=bytctr+1; break; if (rx_no_of_data_bytes != 0)
case 2 : case 3 : case 4 :
case 5 : {
rx_no_of_data_bytes--; if(rx_no_of_data_bytes == 0) { bytctr=0; PORTD=PORTD & 0b11111011;//RX# enable TX disable } } break; } }
16
MUSN Embedded Software
int main(void) { DDRD=0b11111111; //output port //UCSRA=0x02; UCSRB=(1<
Algorithm (version 2) 1. By default the Atmega8 is in the listening mode (i.e it listens to data coming from the RS485 network) and the receive pin of MAX485 is enabled 2. Whenever it receives data from the PC it enables the transmitter of MAX485 and transmits this data to the RS485 network #include #include #include volatile uint8_t bytctr=0,recval=0,rx_no_of_data_bytes=0; volatile uint8_t eepromctr=0x02; SIGNAL(SIG_UART_RECV) { uint8_t recval; recval = UDR; // read data from uart buffer PORTD=PORTD | 0b00000100; UDR=recval; } SIGNAL(SIG_USART_TRANS) { PORTD=PORTD & 0b11111011;//RX# enable TX disable } int main(void) { DDRD=0b11111111; //output port UCSRB=(1<
17
MUSN Embedded Software
3. Architecture of AVR Microcontrollers The ATmega8 is a low-power CMOS 8-bit microcontroller based on the AVR RISC architecture. By executing powerful instructions in a single clock cycle, the ATmega8 achieves throughputs approaching 1 MIPS per MHz, allowing the system designer to optimize power consumption versus processing speed. The Atmel ATmega8 is a powerful microcontroller that provides a highly-flexible and cost-effective solution to many embedded control applications.
3.1 Features 1. High Performance, low power AVR 8-bit microcontroller 2. Advanced RISC architecture. 130 powerful instructions most of which execute in a single clock cycle. 3. Program Memory is 8KB of In-System Programmable Flash with Read-While-Write capabilities 4. 512 bytes of EEPROM 5. 1K byte of SRAM 6. 23 general purpose I/O lines 7. 32x8 bit general purpose working registers with single clock cycle execution time three flexible Timer/Counters with compare modes. Two 8-bit timer/Counters with Separate Prescalar, one Compare Mode and one 16-bit time/Counter with Separate Prescalar, Compare Mode and Capture Mode. 8. Internal and external interrupts 9. A serial programmable USART 10. A byte oriented Two-wire Serial Interface 11. A 6-channel ADC (eight channels in TQFP and MLF packages) with 10-bit accuracy 12. A programmable Watchdog Timer with Internal Oscillator 13. An SPI serial port 14. Five software selectable power saving modes i.e. Idle, Power-down, Power-Save, ADC noise reduction mode, Standby mode 15. On-Chip Analog Comparator
18
MUSN Embedded Software
3.2 Block Diagram
Figure 8 Block Diagram of Atmel Atmega8
19
MUSN Embedded Software
3.3 Pin Configuration
Figure 9 Pinout of Atmega8
3.4 Architectural Overview
Figure 10 Architecture of Atmel Atmega8 20
MUSN Embedded Software
AVR uses a Harvard architecture – with separate memories and buses for program and data. Instructions in the Program memory are executed with a single level pipelining. While one instruction is being executed, the next instruction is pre-fetched from the Program memory. Most AVR instructions have a single 16-bit word format. Every Program memory address contains a 16- or 32-bit instruction. Program Flash memory space is divided in two sections, the Boot program section and the Application program section. Both sections have dedicated Lock Bits for write and read/write protection. The SPM instruction that writes into the Application Flash memory section must reside in the Boot program section. The data SRAM can easily be accessed through the five different addressing.
3.5 Programmer’s model AVR CPU general purpose working registers
Figure 11 Register Set of Atmel Atmega8
21
MUSN Embedded Software
The specifics of the interrupt handling performed by the AVR Atmega8 Microcontroller are presented in the table below:
Table 1 Interrupt Vectors in order of priority
22
MUSN Embedded Software
3.6 Register Summary
Table 2 Register of Atmel Atmega8
23
MUSN Embedded Software
3.7 Instruction Set Summary
Table 3 Instruction Set Summary
24
MUSN Embedded Software
Table 3 Instruction Set Summary (Contd.)
25
MUSN Embedded Software
Table 3 Instruction Set Summary (Contd.)
26
MUSN Embedded Software
4. Programming Resources 4.1 Programming Language (Embedded C) Factors considered while choosing programming language: 1. 2. 3. 4. 5. 6. 7.
Efficiency of compiled code Source code portability Program maintainability Typical bug rates (say, per thousand lines of code) The amount of time it will take to develop the solution The availability and cost of the compilers and other development tools Our personal experience (or that of the developers on your team) with specific languages or tools
After careful consideration of the above factors and based on the resources available in our laboratory, the programming language chosen for MUSN was Embedded C. The use of Embedded C resulted in a shorter program development cycle and enabled the use of a modular programming approach. 4.2 Programmer’s Notepad Programmer’s Notepad is a free, open source, text editor with special features for coders.
Figure 12 Screenshot of Programmer’s notepad 27
MUSN Embedded Software
4.3 Assembler AVR Studio 4 is the new professional Integrated Development Environment (IDE) for writing and debugging AVR applications in Windows 9x/NT/2000/XP environments. AVR Studio 4 includes an assembler and a simulator. The following AVR development tools are also supported: ICE50, ICE40, JTAGICE mkII, JTAGICE, ICE200, STK500/501/502 and AVRISP.
Figure 13 Screenshot of AVRStudio4
4.4 Compiler Factors considered while choosing compiler 1. ANSI compliance: Adherence to the ANSI standard for the C language is critical for about 80 to 85% of code because this feature facilitates portability from part to part, as well as from software platform to software platform. ANSI-compliant software also integrates easy-to-understand code into your library. Even if portability is not an issue, it is important to understand how the compiler differs from ANSI and whether those differences will impact development. 2. Size and speed optimizations: These features are somewhat mutually exclusive but the compiler software should be able to optimize either one or the other. Size optimization 28
MUSN Embedded Software
refers to the optimization of the compiler output code for small code (because memory is precious in controllers or processors) whereas speed optimization is concerned with whether the application executes in a timely or time-accurate manner. 3. Portability: Portability allows you to change quickly from one controller to another during application development. It also makes your code libraries more valuable over time. 4. Supporting tools: Some other characteristics that make up a good compiler are the availability of code libraries and library support. The AVR-GCC is a freeware C compiler (and assembler) that is made available through the GNU project.
4.5 WinAvr WinAVR (pronounced "whenever") is a suite of executable, open source software development tools for the Atmel AVR series of RISC microprocessors hosted on the Windows platform. It includes the GNU GCC compiler for C and C++.
4.6 STK500 The Atmel AVR STK500 is a starter kit and development system for Atmel's AVR Flash
Figure 14 STK500 microcontrollers. The STK500 gives designers a quick start to develop code on the AVR combined with features for using the starter kit to develop prototypes and test new designs. The STK500 interfaces with AVR Studio, Atmel's Integrated Development Environment (IDE) for code writing and debugging. Expansion cards are available for the different AVR sub-families and larger devices.
29
MUSN Embedded Software
The communication between the STK500 and the PC is done over RS232 (PC COM port). The STK500 uses: 115.2 kbps, 8 data bits, 1stop bits, no parity. The PC should be set up similarly for the communication to work. Steps involved in programming using STK500 • • • • •
Connect a 9-15V AC/DC adapter to the power connector Firmly mount the microcontroller in the appropriate socket depending on the number of pins in the IC Connect the ISP6 pin to the SPROG3 using the 6-pin flat cable Make sure the jumpers are in the appropriate position The “RS232 CTRL” USART connector is connected to the PC
Figure 15 Screenshot of AVRStudio4 Programming window
30
MUSN Embedded Software
4.7 Terminal Terminal is a simple serial port (COM) terminal emulation program. It can be used for communication with different devices such as modems, routers, embedded microcontroller systems, GSM phones. Terminal has been extensively used as a debugging tool for our application.
Figure 16 Screenshot of Bray’s Terminal .
31
MUSN Embedded Software
5. Voting Pads ‘Kaun Banega Crorepati’ a game show adapted from the popular British version ‘Who wants to be a Millionare’ is perhaps the most popular television show in India. The show is filmed in front of a studio audience of about 200 civilians who are arranged in circular tiers around a pit in which the action takes place. Ten contestants play Fastest Finger First and the winner makes it to the hotseat. Once in the hotseat, the contestant is asked increasingly difficult general knowledge questions by the host. Questions are multiple choices: four possible alternatives are given to the contestant and he must choose the correct one. 5.1 Audience Poll If at any point the contestant is unsure of the answer to a question, they can use one of three ‘lifelines’. Out of those three lifelines one of them is ‘Audience Poll’. The studio audience is asked to vote on their keypads, and the contestant is shown a bar chart of their answers, which indicates the trends in voting. A network of keypads used during such an audience poll, is one of the utilities of our sensor network. Some of the properties of the keypad are as follows: • The keypads consist of 4 push buttons for selecting one of the four choices. • One of 4 LEDs indicates the selected answer. • An acknowledge and a power LED is optional. • Failure of one keypad does not cause the whole network to fail.
5.2 Implementation The current implementation of the network comprises of nodes consisting of an ATMega8 microcontroller and a MAX485/DS75176 RS485 Transceiver. They are connected to a single RS 485 bus by using a daisy chain topology. Male and female 9 pin Sub-D connectors are used for this purpose. 5.3 Hardware Design Keypad nodes consist of ATmega8 microcontrollers interfaced to the RS485 bus using a RS 485 to TTL converter. The network provides 12 volts to each node. An onboard 7805 translates 12 volts to 5 volts. Micro-switches are used to get the input from the audience members. LEDs are used to display the selected option. Acknowledge LEDs and power supply LEDs are also provided. The PCB layout is created using Eagle Layout Editor. The RS485 network is connected to a host PC using a RS232 to RS485 Bridge which consists of a MAX232 connected to a MAX 485/DS75176. An ATMega8 acts as the sniffer and is responsible for controlling the RX/TX enable of the RS485 Transceiver. The RTS signal of the
32
MUSN Embedded Software
PC Serial port was too slow to enable or disable the TX or RX of the transceiver. For redundancy two RS232 to RS485 bridges are connected to two serial ports of the PC with one operational at a time.
5.4 Schematic of current implementation
Figure 17 Schematic of hardware implementation of voting pad
33
MUSN Embedded Software
Figure 18 Photograph of single keypad
Figure 19 Line up of RS485 Keypads 34
MUSN Embedded Software
5.5 Embedded Software Design The software for the microcontroller is written in Embedded C language. The compiler used is a freeware open source project called WinAVR. The protocol used by us for communication with the PC (host) is loosely based on the SNAP protocol. Field Synchronization field
Length
Explanation 8 bits A synchar ‘a’ is used by the PC to initiate communication with the microcontroller Source identification 8 bits Each node on the network is assigned an ID. The source ID indicates the identity of the transmitting entity and the destination ID indicates the identity of receiving entity. In Destination identification 8 bits MUSN the PC is assigned an ID ‘0’ and the nodes are assigned numbers between 1-9 Number of data bytes 8 bits This indicates the number of data bytes in the packet Data bytes 0-255 bytes The actual data in the packet Table 4 Protocol for communication with the host Atmega8 has 512 bytes of EEPROM memory. The device identity of each sensor node is set in the EEPROM memory using the following program. Program to set device ids: Algorithm 1. The device id is set in the pgm using the fn eeprom_write_byte (address, value). 2. Since the ASCII values have to be written we use 0x31 – 0x39 for setting IDs from 1-9 respectively. #include #include #include #include
int main(void) { uint8_t deviceid=0x32,val; // to assign a deviceid of 2 eeprom_write_byte (0x00, deviceid); val=eeprom_read_byte (0x00); DDRC=0xff; PORTC=val; for (;;){} }
35
MUSN Embedded Software
5.6 Software Model
36
MUSN Embedded Software
5.7 Algorithm for MUSN Voting Pad application 1. Define variables used for communication with the host computer. Initialize microcontroller ports and USART for receiving and transmitting of data. Set speed for data transfer. 2. With Microcontroller Receiver enabled, if the microcontroller has not yet received the data bytes, and if the latest content of the UDR is the synchronization character 'a', then read the contents being received in the UDR, into previously defined variables viz. rx_source_id, rx_destination_id and rx_no_of_data_bytes respectively. 3. If the rx_destination_id is the same as the identity of the microcontroller, that is programmed into its EEPROM, then store the incoming data bytes into a character string called 'packetdata[pcktctr]'. 4. The incoming data will be 'K' indicating the Voting pad application of MUSN, followed by either a Reset command 'R' or a Query request 'Q'. 5. Incase of a query, set the details of character string packetdata[pcktctr] as follows for transmission to the host computer when polled. packetdata[0]=tx_source_id packetdata[1]=rx_source_id packetdata[2]=0x32 packetdata[3]='K' packetdata[4]=kbcchoice 6. The variable kbcchoice may be set to values A,B,C,D or 'N' for no answer. 7. Continuously monitor the status of the input port C to find out whether or not the user has registered his voting choice
5.8 Program for MUSN voting pad application #include #include #include #include
#define syncchar 'a' volatile uint8_t rx_source_id=0; volatile uint8_t rx_destination_id=0; volatile uint8_t rx_no_of_data_bytes=0; volatile uint8_t packetdata[6]; volatile uint8_t pcktctr=0;
37
MUSN Embedded Software
volatile uint8_t bytctr=0; volatile uint8_t tx_source_id=0; volatile uint8_t kbcchoice='N'; volatile uint8_t x=0x00;
SIGNAL(SIG_UART_TRANS) { WDTCR = 0x18; WDTCR = 0x08; if (bytctr <= pcktctr) { UDR=packetdata[bytctr]; bytctr++; } else { PORTD=PIND & 0xfb;//RX# enable TX disable 0b11111011 pcktctr=0; bytctr=0; } WDTCR = 0x18; WDTCR = 0x00; } SIGNAL(SIG_UART_RECV) { WDTCR = 0x18; WDTCR = 0x08; switch(bytctr) { case 0 :
if(rx_no_of_data_bytes == 0) { if(UDR==syncchar) { bytctr=bytctr+1; } } else rx_no_of_data_bytes=rx_no_of_data_bytes-1; break;
case 1 :
rx_source_id=UDR; bytctr=bytctr+1; break;
case 2 :
rx_destination_id=UDR; bytctr=bytctr+1; break;
case 3 :
rx_no_of_data_bytes=UDR; rx_no_of_data_bytes=rx_no_of_data_bytes-0x30; if(rx_destination_id==tx_source_id) { bytctr=bytctr+1; } else
38
MUSN Embedded Software
{ bytctr=0; } break; case 4 :
if (rx_no_of_data_bytes != 0) { rx_no_of_data_bytes=rx_no_of_data_bytes-1; packetdata[pcktctr]=UDR; pcktctr++; if(rx_no_of_data_bytes == 0) { bytctr=0; if(packetdata[0] == 'K') { WDTCR = 0x18; WDTCR = 0x08; switch(packetdata[1]) { case 'R' : kbcchoice='N'; pcktctr=0; PORTD = PORTD|0xf8; // switch off all LEDs 0b11111000 break; case 'Q' :PORTD=PORTD & 0x7f; //switch on ACKNOWLEDGE LED 0b01111111 packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='K'; packetdata[4]=kbcchoice; pcktctr=4; PORTD=PIND|0x04;//RX# disable TX enable 0b00000100 UDR='a'; break; } WDTCR = 0x18; WDTCR = 0x00; } } } break;
} WDTCR = 0x18; WDTCR = 0x00; } int main(void) { //WDTCR = 0x18; //WDTCR = 0x0F; DDRC=0x00; // input port DDRD=0xff; //output port PORTC=0xff; //pullups enabled /* init the uart for receiving and transmitting of data */ UCSRB=(1<
39
MUSN Embedded Software
UBRRL=1; /* init speed */
tx_source_id=eeprom_read_byte (0x00); sei(); /* enable interrupts */ PORTD=PIND & 0xfb;//RX# enable TX disable 0b11111011 PORTD=PORTD|0xf8; //leds off 0b11111000 for(;;) { WDTCR = 0x18; WDTCR = 0x08; if(kbcchoice == 'N') { x=PINC & 0x0f; switch(x) { case 0x07 : kbcchoice = 'A'; PORTD=PORTD & 0xf7;//switch on red LED 0b11110111 break; case 0x0b : kbcchoice = 'B'; PORTD=PORTD & 0xef;//switch on green LED 0b11101111 break; case 0x0d : kbcchoice = 'C'; PORTD=PORTD & 0xdf;//switch on yellow LED 0b11011111 break; case 0x0e : kbcchoice = 'D'; PORTD=PORTD & 0xbf;//switch on blue LED 0b10111111 break; default : PORTD=PORTD & 0xff;//switch off all LEDs } } WDTCR = 0x18; WDTCR = 0x00; } }
//WDTCR = x x x WDCE WDE WDP2 WDP1 WDP0 //WDTCR = 0x18; //WDTCR = 0x0F;
40
MUSN Embedded Software
5.9 Host Software Design The Network Management Software is written in JAVA using Eclipse Editor. The main functionalities of the software are a GUI for the user to create network representation and to present data from various nodes in the form of graphs.
Figure 20 Screen shot of the running JAVA application
41
MUSN Embedded Software
5.10 Future scope for Voting Pads Our network works in half-duplex mode (Single Master, Multiple slaves), where a single master in a system sends a command to one of several "slave" devices on a network. Typically one device (node) is addressed by the host computer and a response is received from that device. The network can be made event driven. A RS485 (MAX485/DS75176) transceiver can support only 32 nodes per segment (slew rate limited devices can support up to 128 devices per segment) but by using another kind of driver and suitable cabling this number can be extended to around 250. This network can be further extended by the use of Ethernet. Bootloading features and error correction can be implemented in microcontroller separately. Controller Area Network (CAN) can be used as a better alternative over RS485 due to the following properties: • CAN allows multimaster communication • CAN has CRC based built-in error detection • Supports several hundreds of devices on a single segment, theoretically • Highly fault tolerant • AVR has CAN enabled microcontrollers with bootloading over CAN already supported
42
MUSN Embedded Software
6. Home Monitoring System Home Monitoring System is a collective term for information and communicationtechnology in homes, where the components are communicating through a local network. Smart home technology is the integration of technology and services through home networking for better quality of living with applications in the areas of home automation, information & communication, home security and entertainment. Crucial in this definition is the word, "integration". The various home networks connect and integrate the many sensors (all kinds of input), actuators (all kinds of equipment which do something) and the intelligent central unit. The technology may be used for monitoring, setting off alarms and executing actions, according to programmed criteria.
Figure 21 Components of a Home Monitioring System
It is basically the integration of inhouse and outdoor systems. The local network communicates with the external world by telephone or through the Internet, sending messages or alarms to one or more recipients. These may be residents of the house, family, private security-companies or the community-team. This communication makes it possible to program the smart home from inside or outside the house.
43
MUSN Embedded Software
In a home monitoring system one may integrate: • Safety alarms • Environmental control systems, for eg. remote control or programmed control of doors, windows and lights • Communication linked to the telephone or the Internet • Energy-control-systems for adjusting heating at all hours • Entertainment for eg. television, film and music
6.1 Home networking technologies Direct Cable: Connects two computers through serial, parallel, or USB port. Ethernet: Connects 2-12 computers using hub system and network cards in each device. Driver installation and wiring required, hardware conflicts possible, more expensive. AC Network: Uses power lines and wiring already within home to connect parallel port to adapter in outlet. Difficult to set up, slow networking, problems with interference from other devices, expensive. Phone Line: Data shares phone line frequency; requires phone jack everywhere a networked device is located. Also requires special cards and drivers. Radio Free Network: Uses radio frequency waves to transmit data through walls and doors up to 800 feet, requires network card, can have some interference. Spread Spectrum Wireless: Fast transfer speeds, limited range. Bluetooth: Cross device wireless standard created for cell phones and PDAs, can link up to 8 devices.
6.2 Architecture In our project we have successfully implemented the first two steps of Smart Home technology i.e. Monitoring and Alarming. Smart homes rely on the abilities to distribute information and commands around the home, one of which is use of a wiring bus. A wiring bus is a dedicated wiring system installed purely for the purposes of distributing information. The various sensors implemented in the project are as follows: • Mercury switch, to sense entry of a person into the house through the main door • Motion detector, to sense the presence of an unwanted visitor • A temperature sensor (LM 35) for continuous monitoring of the temperature • Humidity sensor for constant monitoring of the humidity level
44
MUSN Embedded Software
• • • •
Light sensor (LDR), to sense the ‘ON’ state of the tube light Gas detector to detect LPG leakage in the house Proximity sensor to count the number of visitors entering our home Smoke Detector to detect fires
There are in all four sensor nodes in the sensor network implemented in our Smart Home. Each sensor node comprises of one AVR microcontroller Atmega8 interfaced with two sensors each. The microcontroller is programmed as per the sensor interfaced with it using Embedded C.
Figure 22 Smart Home Implementation
45
MUSN Embedded Software
6.3 Algorithms and Programs for MUSN Home Monitoring System 6.31 ALGORITHM FOR NODE 1 – Light and Fan control 1. Define and Initialize variables for communication with the host computer. Initialize microcontroller ports and UART for receiving and transmitting data. Set speed for data transfer and Enable microcontroller interrupts. 2. With Microcontroller Receiver enabled, if the microcontroller has not yet received data bytes, and if the latest content of the UDR is the synchronization character 'a’, then read the contents being received in the UDR, into previously defined variables viz. rx_source_id, rx_destination_id and rx_no_of_data_bytes respectively. 3. If the rx_destination_id is the same as the identity of the microcontroller (programmed in its EEPROM) then store the incoming data bytes into a character string called ‘packetdata [pcktctr]'. 4. If packetdata[0] = ‘A’ indicating the light switch and if it is followed by a query, then prepare a data packet of the following format packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='A'; packetdata[4]=light; 5. The variable ‘light ’ contains information regarding the ON or OFF status of the light switch. 6. However if (packetdata[0] == 'B'), then as per the Host’s nstructions, we have one of the following cases. If packetdata[1] = ‘p’, then the light switch is turned ON; If packetdata[1] = ‘q’, then the light switch is turned OFF If packetdata[1] = ‘r’, then the fan is turned ON If packetdata[1] = ‘s’, then the fan is turned OFF
46
MUSN Embedded Software
6.32 Program for node 1 #include #include #include #include #define #define #define #define
syncchar 'a' LIGHTOFF 'q' FANON 'r' FANOFF 's'
volatile uint8_t rx_source_id=0; volatile uint8_t rx_destination_id=0; volatile uint8_t rx_no_of_data_bytes=0; volatile uint8_t packetdata[6]; volatile uint8_t pcktctr=0; volatile uint8_t bytctr=0; volatile uint8_t tx_source_id=0; volatile uint8_t lightoutput, light, digital; volatile uint8_t x=0x00; SIGNAL (SIG_ADC) { digital=ADCH; } SIGNAL(SIG_UART_TRANS) { if (bytctr <= pcktctr) { UDR=packetdata[bytctr]; bytctr++; } else { PORTD=PIND & 0b11111011;//RX# enable TX disable pcktctr=0; bytctr=0; } } SIGNAL(SIG_UART_RECV) { switch(bytctr) { case 0 :if(rx_no_of_data_bytes == 0) { if(UDR==syncchar) { bytctr=bytctr+1; } } else rx_no_of_data_bytes=rx_no_of_data_bytes-1; break;
47
MUSN Embedded Software
case 1 :rx_source_id=UDR; bytctr=bytctr+1; break; case 2 :rx_destination_id=UDR; bytctr=bytctr+1; break; case 3 :rx_no_of_data_bytes=UDR; rx_no_of_data_bytes=rx_no_of_data_bytes-0x30; if(rx_destination_id==tx_source_id) { bytctr=bytctr+1; } else { bytctr=0; } break; case 4 :if (rx_no_of_data_bytes != 0) { rx_no_of_data_bytes=rx_no_of_data_bytes-1; packetdata[pcktctr]=UDR; pcktctr++; if(rx_no_of_data_bytes == 0) { bytctr=0; if(packetdata[0] == 'A') { switch(packetdata[1]) { case 'S':PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='A'; if(lightoutput>0x40) { light = 'N'; } else light = 'D'; packetdata[4]=light; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='a'; break; } } else if(packetdata[0] == 'B') { switch(packetdata[1])
48
MUSN Embedded Software
{ case 'p': PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED PORTB = 0b00000100; //LIGHT ON break; case 'q':PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED PORTB = 0b00000000; //LIGHT OFF break; case 'r':PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED PORTC = PORTC|0b00010000;//FAN ON break; case 's':PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED PORTC = PORTC & 0b11101111;//FAN OFF break; } PORTD=PIND & 0b11111011;//RX# enable TX disable bytctr=0; pcktctr=0; } else { packetdata[0]='*'; packetdata[1]='*'; packetdata[2]=0x32; packetdata[3]='*'; packetdata[4]='*'; pcktctr=4; PORTD=PIND | 0b00000100;//RX# disable TX enable UDR='*'; }
} } break; } } int main(void) { DDRC=0b00010000; //pc4 output DDRD=0xff; //output port DDRB=0xff; //output PORT
/* init the uart for receiving and transmitting of data */ UCSRB=(1<
49
MUSN Embedded Software
for(;;) { ADMUX=0b01100011;//channel 3 ADCSRA=0b11011100;//start conversion lightoutput=digital; } }
6.33 ALGORITHM FOR NODE 2 - Humidity and Gas Sensors 1. Define and Initialize variables for communication with the host computer. Initialize microcontroller ports, USART and ADC for receiving and transmitting data. Set speed for data transfer and Enable microcontroller interrupts. 2. With Microcontroller Receiver enabled, if the microcontroller has not yet received data bytes, and if the latest content of the UDR is the synchronization character 'a', then read the contents being received in the UDR, into previously defined variables viz. rx_source_id, rx_destination_id and rx_no_of_data_bytes respectively. 3. If the rx_destination_id is the same as the identity of the microcontroller (programmed in its EEPROM) then store the incoming data bytes into a character string called 'packetdata[pcktctr]'. 4. If packetdata[0] == C, identifying the Humidity Sensor, and if packetdata[1]=='S', indicating a query, then prepare a data packet of the following format: packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='C'; packetdata[4]=c+0x30; packetdata[5]=c+0x30; 5. packetdata[4] and [5] represent the value of relative humidity computed on the basis of a look up table. Enable the transmitter of the microcontroller and send this data packet to the Host, when polled. 6. If packetdata[0] == C, identifying the Gas Sensor, and if packetdata[1]=='S', indicating a query, then prepare a data packet of the following format: packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='D'; packetdata[4]=status; 7. The variable 'status' indicates whether or not gas has been detected. Enable Transmitter and send this data to the Host Computer when polled. If packetdata[1]=='S', then set that status of the gas sensor to 'N', i.e. No gas detected.
50
MUSN Embedded Software
6.34 Program for node 2 #include #include #include #include
#define syncchar 'a'
// Synchronisation Character
volatile uint8_t rx_source_id=0; // Recognising the Host Computer as having id 0 volatile uint8_t rx_destination_id=0;// Identification of AVR Microcontroller from Host's perspective volatile uint8_t rx_no_of_data_bytes=0; // Number of Databytes in Data Packet
volatile uint8_t packetdata[8]; volatile uint8_t pcktctr=0;
// Defining a character array // Initialise cnter variable to 0
volatile uint8_t bytctr=0;
// Initialise cnter variable to 0
volatile volatile volatile volatile volatile
uint8_t uint8_t uint8_t uint8_t uint8_t
tx_source_id=0; c; x = 0x00; humidityoutput,digital; humidity, status;
SIGNAL (SIG_ADC) { digital=ADCH; }
SIGNAL (SIG_UART_TRANS) { if (bytctr <= pcktctr) { UDR=packetdata[bytctr]; bytctr++; } else { PORTD=PIND & 0b11111011;//RX# enable TX disable pcktctr=0; bytctr=0; } }
SIGNAL(SIG_UART_RECV) { switch(bytctr) {
51
MUSN Embedded Software
case 0 : if(rx_no_of_data_bytes == 0) { if(UDR==syncchar) { bytctr=bytctr+1; } } else rx_no_of_data_bytes=rx_no_of_data_bytes-1; break; case 1 : rx_source_id=UDR; bytctr=bytctr+1; break; case 2 : rx_destination_id=UDR; bytctr=bytctr+1; break; case 3 : rx_no_of_data_bytes=UDR; rx_no_of_data_bytes=rx_no_of_data_bytes-0x30; if(rx_destination_id==tx_source_id) { bytctr=bytctr+1; } else { bytctr=0; } break; case 4 : if (rx_no_of_data_bytes != 0) { rx_no_of_data_bytes=rx_no_of_data_bytes-1; packetdata[pcktctr]=UDR; pcktctr++; if(rx_no_of_data_bytes == 0) { bytctr=0; if(packetdata[0] == 'C') // humidity sensor { switch(packetdata[1]) { case 'S': packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x33; packetdata[3]='C'; if (humidityoutput>=0x34 && humidityoutput<0x3D) { humidity = 30; } else if (humidityoutput>=0x3D && humidityoutput<0x44) { humidity = 35; } else if (humidityoutput>=0x44 && humidityoutput<0x4F) { humidity = 40;
52
MUSN Embedded Software
} else if (humidityoutput>=0x4F && humidityoutput<0x58) { humidity = 45; } else if (humidityoutput>=0x58 && humidityoutput<0x60) { humidity = 50; } else if (humidityoutput>=0x60 && humidityoutput<0x69) { humidity = 55; } else if (humidityoutput>=0x69 && humidityoutput<0x72) { humidity = 60; } else if (humidityoutput>=0x72 && humidityoutput<0x7A) { humidity = 65; } else if (humidityoutput=0x7A && humidityoutput<0x83) { humidity = 70; } else if (humidityoutput>=0x83 && humidityoutput<0x8C) { humidity = 75; } else if (humidityoutput>=0x8C && humidityoutput<0x95) { humidity = 80; } else if (humidityoutput>=0x95 && humidityoutput<0x9D) { humidity = 85; } else if (humidityoutput>=0x9D) { humidity = 90; } else { humidity = 20; } c=(humidity/10); packetdata[4]=c+0x30; c=humidity-(10*c); packetdata[5]=c+0x30; pcktctr=5; PORTD=PIND | 0b00000100;//RX# disable TX enable UDR='a'; break; }
53
MUSN Embedded Software
} else if(packetdata[0] == 'D') //GAS DETECTOR { switch(packetdata[1]) { case 'R' : packetdata[4]='N'; pcktctr=0; break; case 'S' : packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='D'; packetdata[4]=status; pcktctr=4; PORTD=PIND|0b00000100; //RX# disable TX enable UDR='a'; break; } } else { packetdata[0]='*'; packetdata[1]='*'; packetdata[2]=0x32; packetdata[3]='*'; packetdata[4]='*'; pcktctr=4; PORTD=PIND | 0b00000100;//RX# disable TX enable UDR='*'; } } } break; } }
int main(void) { DDRD=0xff;//pin d3 input port DDRC=0xff; status='N'; //init the usart for receiving and transmitting of data UCSRB=(1<
54
MUSN Embedded Software
ADCSRA=0b11011100;//start conversion humidityoutput=digital; x=PINB & 0b00000010; if (x==0) status = 'D'; else status = 'N'; } }
6.35 ALGORITHM FOR NODE 3 – Smoke Detector and Temperature Sensor 1. Define and Initialize variables for communication with the host computer. Initialize microcontroller ports, UART and ADC for receiving and transmitting data. Set speed for data transfer and Enable microcontroller interrupts. 2. With Microcontroller Receiver enabled, if the microcontroller has not yet received data bytes, and if the latest content of the UDR is the synchronization character 'a', then read the contents being received in the UDR, into previously defined variables viz. rx_source_id, rx_destination_id and rx_no_of_data_bytes respectively. 3. If the rx_destination_id is the same as the identity of the microcontroller (programmed in its EEPROM) then store the incoming data bytes into a character string called 'packetdata[pcktctr]'. 4. If packetdata[0] == E, identifying the Smoke Sensor, and if packetdata[1]=='S', indicating a query, then prepare a data packet of the following format: packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='E'; packetdata[4]=smoke; 5. The variable 'smoke' indicates whether or not smoke is detected. Enable Transmitter and send this data to the Host Computer when polled. 6. If packetdata[0] == F, identifying the Temperature sensor, and if packetdata[1]=='S', indicating a query, then prepare a data packet of the following format: packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='F'; packetdata[4]=digital; 7. The variable 'digital' contains the digital equivalent of the room temperature being monitored. Enable Transmitter and send this data to the Host Computer when polled.
55
MUSN Embedded Software
6.36 PROGRAM FOR NODE 3 #include #include #include #include
#define syncchar 'a'
// Synchronisation Character
volatile uint8_t rx_source_id=0; // Recognising the Host Computer as having id 0 volatile uint8_t rx_destination_id=0;// Identification of AVR Microcontroller from Host's perspective volatile uint8_t rx_no_of_data_bytes=0; // Number of Databytes in Data Packet
volatile uint8_t packetdata[8]; volatile uint8_t pcktctr=0;
// Defining a character array // Initialise cnter variable to 0
volatile uint8_t bytctr=0;
// Initialise cnter variable to 0
volatile uint8_t tx_source_id=0; volatile uint8_t x = 0x00; volatile uint8_t smoke, tempoutput, digital;
SIGNAL (SIG_ADC) { digital=ADCH; }
SIGNAL(SIG_UART_TRANS) { if (bytctr <= pcktctr) { UDR=packetdata[bytctr]; bytctr++; } else { PORTD=PIND & 0b11111011;//RX# enable TX disable pcktctr=0; bytctr=0; } }
SIGNAL(SIG_UART_RECV) { switch(bytctr)
56
MUSN Embedded Software
{ case 0 :if(rx_no_of_data_bytes == 0) { if(UDR==syncchar) { bytctr=bytctr+1; } } else rx_no_of_data_bytes=rx_no_of_data_bytes-1; break; case 1 :rx_source_id=UDR; bytctr=bytctr+1; break; case 2 :rx_destination_id=UDR; bytctr=bytctr+1; break; case 3 :rx_no_of_data_bytes=UDR; rx_no_of_data_bytes=rx_no_of_data_bytes-0x30; if(rx_destination_id==tx_source_id) { bytctr=bytctr+1; } else { bytctr=0; } break; case 4 :if (rx_no_of_data_bytes != 0) { rx_no_of_data_bytes=rx_no_of_data_bytes-1; packetdata[pcktctr]=UDR; pcktctr++; if(rx_no_of_data_bytes == 0) { bytctr=0; if(packetdata[0] == 'E') // smoke detector { switch(packetdata[1]) { case 'R' :packetdata[4]='N'; pcktctr=0; case 'S' :packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='E'; packetdata[4]=smoke; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable
57
MUSN Embedded Software
UDR='a'; break; } } else if(packetdata[0] == 'F') // temperature sensor { switch(packetdata[1]) { case 'S' :packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='F'; packetdata[4]=tempoutput; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='a'; break; } } else { packetdata[0]='*'; packetdata[1]='*'; packetdata[2]=0x32; packetdata[3]='*'; packetdata[4]='*'; pcktctr=4;
PORTD=PIND|0b00000100;//RX# disable TX enable UDR='*'; } } } break; } }
int main(void) { DDRD=0xff; //output port smoke = 'N'; //init the uart for receiving and transmitting of data UCSRB=(1<
58
MUSN Embedded Software
PORTD=PORTD | 0b11111000; //leds off for(;;) { ADMUX=0b01100011;//channel 3 ADCSRA=0b11011100;//start conversion for(int i=0;i<0xff;i++) for(int j=0;j<0xff;j++); tempoutput=digital; x = PINB & 0b00000010;
// smoke detection
if (x == 0) smoke = 'D'; else smoke = 'N'; } }
6.37 ALGORITHM FOR NODE 4 – Motion Sensor and Mercury Switch 1. Define and Initialize variables for communication with the host computer. Initialize microcontroller ports and UART for receiving and transmitting data. Set speed for data transfer and Enable microcontroller interrupts. 2. With Microcontroller Receiver enabled, if the microcontroller has not yet received data bytes, and if the latest content of the UDR is the synchronization character 'a’, then read the contents being received in the UDR, into previously defined variables viz. rx_source_id, rx_destination_id and rx_no_of_data_bytes respectively. 3. If the rx_destination_id is the same as the identity of the microcontroller (programmed in its EEPROM) then store the incoming data bytes into a character string called ‘packetdata [pcktctr]'. 4. If packetdata[0] == I, identifying the Motion Sensor, and if packetdata[1]=='S', indicating a query, then prepare a data packet of the following format: packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='I'; packetdata[4]=m; 5. The value of m indicates whether or not motion is detected. Enable Transmitter and send this data to the Host Computer. 6. If packetdata[0] == G, identifying the Mercury Switch, and if packetdata[1]=='S', then prepare a data packet of the following format packetdata[0]=tx_source_id; packetdata[1]=rx_source_id;
59
MUSN Embedded Software
packetdata[2]=0x32; packetdata[3]='G'; packetdata[4]=n; 7. The value of n indicates whether the status of the door. Enable Transmitter and send this data to the Host Computer. 8. Continuously poll the microcontroller for status of Motion Sensor and Mercury Switch. 9. If packetdata[0] == H, identifying the Proximity Sensor, and if packetdata[1]=='S', then prepare a data packet of the following format packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x34; packetdata[3]='H'; packetdata[4]=c+0x30; packetdata[5]=d+0x30; packetdata[6]=c+0x30; 10. The contents of packetdata[4],[5] and [6] gives a count of the number of objects counted by the Proximity Sensor.
6.38 PROGRAM FOR NODE 4 #include #include #include #include
#define syncchar 'a'
// Synchronisation Character
volatile uint8_t rx_source_id=0;
// Recognising the Host Computer as having id 0 // Identification of AVR Microcontroller from Host's perspective
volatile uint8_t rx_destination_id=0;
volatile uint8_t rx_no_of_data_bytes=0; // Number of Databytes in Data Packet volatile uint8_t packetdata[8]; volatile uint8_t pcktctr=0;
// Defining a character array // Initialise cnter variable to 0
volatile uint8_t bytctr=0;
// Initialise cnter variable to 0
volatile uint8_t tx_source_id=0; volatile uint8_t x=0x00; volatile uint8_t y=0x00;
60
MUSN Embedded Software
volatile volatile volatile volatile volatile volatile
uint8_t uint8_t uint8_t uint8_t uint8_t uint8_t
z=0x00; m='N'; n='N'; no_of_objects=0; c; d;
// Motion Detector Status // Mercury Switch Status
SIGNAL(SIG_UART_TRANS) { if (bytctr <= pcktctr) { UDR=packetdata[bytctr]; bytctr++; } else { PORTD=PIND & 0b11111011;//RX# enable TX disable pcktctr=0; bytctr=0; } } SIGNAL(SIG_UART_RECV) { switch(bytctr) { case 0 :
if(rx_no_of_data_bytes == 0) { if(UDR==syncchar) { bytctr=bytctr+1; } } else rx_no_of_data_bytes=rx_no_of_data_bytes-1; break;
case 1 :
rx_source_id=UDR; bytctr=bytctr+1; break;
case 2 :
rx_destination_id=UDR; bytctr=bytctr+1; break;
case 3 :
rx_no_of_data_bytes=UDR; rx_no_of_data_bytes=rx_no_of_data_bytes-0x30; if(rx_destination_id==tx_source_id) { bytctr=bytctr+1; } else { bytctr=0; } break;
61
MUSN Embedded Software
case 4 :
if (rx_no_of_data_bytes != 0) { rx_no_of_data_bytes=rx_no_of_data_bytes-1; packetdata[pcktctr]=UDR; pcktctr++; if(rx_no_of_data_bytes == 0) { bytctr=0; if(packetdata[0] == 'I') // MOTION SENSOR { switch(packetdata[1]) { case 'S' :PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='I'; packetdata[4]=m; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='a'; break; } } else if(packetdata[0] == 'G') // MERCURY SWITCH { switch(packetdata[1]) { case 'S' :PORTD=PORTD & 0b01111111;//switch on ACKNOWLEDGE LED packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x32; packetdata[3]='G'; packetdata[4]=n; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='a'; break; } } else if(packetdata[0] == 'H') //proximity sensor { switch(packetdata[1]) { case 'R' :pcktctr=0; no_of_objects=0; break; case 'S' :packetdata[0]=tx_source_id; packetdata[1]=rx_source_id; packetdata[2]=0x34; packetdata[3]='H'; c=(no_of_objects/100); packetdata[4]=c+0x30; c=no_of_objects-(100*c); d=(c/10);
62
MUSN Embedded Software
packetdata[5]=d+0x30; c=(c%10); packetdata[6]=c+0x30; pcktctr=6; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='a'; break; } } else { packetdata[0]='*'; packetdata[1]='*'; packetdata[2]=0x32; packetdata[3]='*'; packetdata[4]='*'; pcktctr=4; PORTD=PIND|0b00000100;//RX# disable TX enable UDR='*'; } } } break; } } int main(void) { DDRB=0x00; // input port DDRD=0xff; //output port DDRC=0x00; // input port PORTB=0xff; //pullups enabled PORTC=0xff; //pullups enabled /* init the uart for receiving and transmitting of data */ UCSRB=(1<
// Motion Sensor
// Mercury Switch
63
MUSN Embedded Software
n='N'; else n='D'; z = PINB & 0b00000010; // Mercury Switch if (z == 0) { no_of_objects=no_of_objects+1; for(int i=0;i<0xff;i++) for(int j=0;j<0xff;j++) for(int K=0;K<0xff;K++) {} } } }
6.4 Conclusion The use of modern technology is adding to a safe and comfortable living environment for everybody. For a disabled person, the benefits are even greater. Smart home technology has contributed to increased independence and safety for plenty of end-users and their families. Smart home technology may be used to minimize disabling obstacles. • • • • • • • •
The main arguments against smart home can be listed down as follows: too expensive handling too complex programming too complicated installation problems/ no plug and play high repairing costs risk of intervention into intimacy control of privacy necessary dominance of technology
Smart home technology is becoming increasingly more common to ordinary consumers, and the owner of many new building projects are proud to announce it, if the flats are fitted with “new, intelligent technology”. There is a responsibility resting on governmental bodies and professionals to involve in the future planning of community care, to ensure that technology are used to assist the human helpers that always will be the basis in all care. The technology should also aim at providing all the user requirements and to overcome the above mentioned problems. Future trends in Smart Home: The development offers the following key features: • Electronic neighborhood watch, which turns the lights on and alerts police via the Internet in case of security breach • Community television broadcasts of emergency weather information, school-related messages, and offers from local merchants, broadcast via a set-top box • A “digital town square” – system allows for intranet chat among community households • Ability to control systems (e.g.furnace, lights) from remote locations via wide area protocol IAs (e.g., cell phones, PDAs).
64
MUSN Embedded Software
7. Industrial Process Monitoring System 7.1 Introduction Intelligent sensors have become an integral part of processing industry. Today industrial applications require real-time access to information to make intelligent decisions. Currently wired infrastructure is used for communications. The main reasons against wireless sensors are cost considerations, non-use of existing infrastructure, and security concerns. Industrial applications typically employ various types of sensors (thermo, magneto, pressure, accelerometer, gyros) often deployed in the same network, having different interfaces and using different protocols for data and communications. Extensive data systems are employed in industrial plants to measure, collect, transmit, and display information. Valves must be controlled while temperature and pressure are measured, displayed, and fed to the processcontrol system. Formation of monitoring systems from such diverse sensors is an inherent part of a sensor network. In our project, we have successfully accomplished the above-mentioned functions of the sensor network, i.e. continuous monitoring and display of the various parameters. The sensors used in our industrial application are infrared proximity sensor and smoke detector.
7.2 Case Study: Food Industry Food industry is generally receptive to information technology. Smart sensor networks have been successfully deployed in various food-processing industries. In addition to this, growers also have requirements that can be met by sensor networks. The most well known example of this is “smart vineyard.” The sensor network used in this case measures wind speed and direction, temperature, humidity, light, soil moisture, and leaf wetness. Given that weather conditions and monitoring of the same is a key factor in the production of quality wine, it is obvious that the use of sensor network can be of great benefit to vine growers. Such a system also has the potential to give vine growers better information for monitoring the crop and can ultimately play a role in anticipating problems such as presence of pests and insects which results in rotting of the plant. The sensors can be virtually deployed anywhere in a vineyard as long as they are in requisite range of each other.
65
MUSN Embedded Software
Figure 23 Typical industrial sensor network implementation The above characteristics of sensor networks are not just useful to vine growers. Any fruit grower will have similar requirements, as indeed will growers of cereals and vegetables and sugar beet. Once again, the potential use of Sensor Networks is wide ranging. Another potential application of sensor network is the wine-industry. Intelligent sensors clearly play an important role in the fermentation process whether it is in temperature or sulphurdioxide monitoring. The final step in the production process of course is storage. Once again, sensors can be used here to detect levels of humidity and temperature in a storehouse. Randomly deployed sensors could also be potentially used to detect what is commonly called “corkage” (inadequate corking) in wine bottles or batches. The deployment of a Smart Sensor Network would greatly increase the efficiency of this process.
66
MUSN Embedded Software
8. Future Scope 8.1 Voting pads The current implementation of the network being used for the game show voting pads comprises of nodes consisting of an ATMega8 microcontroller and a MAX485/DS75176 RS485 Transceiver. They are connected to a single RS 485 bus segment. Only 32 nodes are supported by such a design. MAX487 Transceivers can be used to support up to 128 nodes per segment.
Figure 24 KBC Studio The Studio which comprises of such a network can hold up to 200 audience members; hence two segments of the RS485 bus will be able to accommodate everyone. • •
1. 2. 3. 4.
Only by suitable changes in the software, ‘Fastest finger first’ can also be implemented. Broadcast packets are incorporated for starting and stopping internal timers and counters. Larger reply packets may be used with additional information about time taken to select a choice. The actual implementation would include the following steps: Host sends broadcast packet to reset all nodes and start their timers. Nodes start timer and wait for keypress. At end of the time allotted for answering question, host sends broadcast packet to stop the timers. Host queries all nodes for the answer selected and time taken by the participant to do so. 67
MUSN Embedded Software
A much compact and easy to use enclosure can be used. Push button switches with builtin LEDS as follows can be used for convenience.
Figure 25 Push button switches and twisted pair cables Twisted 2 pair or 5 pair cables and improved connectors as shown can be used for better reliability of the network.
Figure 26 Improved connectors Better bus standards like CAN and Ethernet are an improvisation over RS485. Controller Area Network, is a serial bus network of microcontrollers that connects devices, sensors and actuators in a system or sub-system for real-time control applications. There is no addressing scheme used in controller area networks, as in the sense of conventional addressing in networks. Rather, messages are broadcast to all the nodes in the network using an identifier unique to the network. Based on the identifier, the individual nodes decide whether or not to process the message and also determine the priority of the message in terms of competition for bus access. This method allows for uninterrupted transmission when a collision is detected. CAN can theoretically link up to 2032 devices (assuming one node with one identifier) on a single network. 68
MUSN Embedded Software
Ethernet is the most widely-installed local area network (LAN) technology. Ethernet uses a bus or star topology and supports data transfer rates of 10 Mbps. An Ethernet LAN typically uses coaxial cable or special grades of twisted pair wires. Ethernet is also used in wireless LANs. Devices are connected to the cable and compete for access using a Carrier Sense Multiple Access with Collision Detection (CSMA/CD ) protocol. 8.2 Smart Home As an extension to the smart home implementation, a security system can be built in a building. Newer buildings have have ducts for wiring for networks like Cable TV, Telephone, Internet on LAN, Ethernet infrastructure already in place. Embedded Ethernet boards can be used on each floor which are connected to the building’s Ethernet Network. The nerves of the network are formed by RS485/CAN subnetworks. The sensor nodes with their sensors form the nerve endings.
Figure 27 A typical sensor network in a housing complex
69
MUSN Embedded Software
Each Embedded Ethernet Board as shown as the blue node above has the following components: • ATMega128 (or AT90CAN128) • Ethernet Interface with NutOS providing TCP/IP Stack • Dual RS485 ports (Redundancy) or a CAN interface - The sensor network could be administered by any PC connected to the building’s Ethernet Network. The Gateway can restrict access to the range of IP addresses allotted to each floor to maintain security. Each Embedded Ethernet board will collect data from its RS485/CAN Subnetwork sensor nodes and forward that data to the Administration PC. - A person living in one of the apartments in the building can login to the buildings web server using a login name and password. The web server maintains a network graph of the whole sensor network. The resident can look at the sensor layout of his own home and can configure various parameters of his home manually. - The system will have a distributed UPS. All Ethernet boards will have their own small rechargeable battery backup. This will help in case of fire and other disasters. The network can automatically shutdown the electric supply to the affected sector of the building and open water valves for fire control. - The sensor network can be used to log sensor data which might be useful later in case of crimes. The building can have its own mini weather station. The network can collect data such as water supply/electric usage characteristic of residents in a particular flat. The residents can use this data to help cut down their utility bills. - The network can be used to control solar cells/water heater mounted on the roof for optimum alignment towards the sun. It can control the water levels in overhead tanks. It can be used to implement traffic management for the Elevator System.
8.3 Industry In any industrial application, huge data systems need to be installed to perform various operations such as data collection, processing, communication, and display. To connect the controller unit with sensors and actuators, many process and manufacturing facilities still include field multiplexers or multi-wire connections (based on 4-20mA loops or 0-10V circuits). Because the wiring required in the older systems is enormous, modern plants often save wiring effort by employing a serial, real-time, data-link industrial network (field bus system) for process and manufacturing control. Fieldbus systems are similar to the widespread Ethernet office networks, in that a single bus connects all devices on one network to a central controller. Not only does that arrangement require substantially less wire, it also increases the system modularity. All devices are addressed via software, so any device can be connected to any socket along the network. The master detects which device is connected to the network, and initiates the action required to start communications.
70
MUSN Embedded Software
9. The Elecrama Experience
Industrial electrical and electronics manufacturer's Association (IEEMA) organizes an international level exhibition for electrical and electronic goods under the banner of 'Elecrama' biennially. This year ‘Elecrama 2006' the 7th International exhibition of Electrical, Professional electronics and Allied Products was held in Mumbai at Bombay Exhibition Center from 18th to 22nd January, 2006. Elecrama is a platform where the best of industries, both Indian and multinational showcase their cutting edge technologies and cost effective products. About 1,500 companies participated in the exhibition with visitor count reaching up to 20,000 each day. The exhibition was segregated into many halls such as International Pavilion, Power Electronics Pavilion, Industrial Automation Pavilion etc. A small but significant part of the exhibition was the Students’ Pavilion, which brought forward many constructive ideas. The Elecrama 2006 organizing committee received up to 80 entries from various colleges across India. The committee short-listed 41 competitive projects. The criteria of selection were as follows 1) Practical approach 2) Innovative Idea 3) Market value 4) Technological content Our project ‘Multi-Utility Sensor Network’ was selected to represent our college at the 'Elecrama 2006' contest. The contest stretched over a period of 5 days. We reached the contest venue a day before the contest to feel the pulse of the exhibition. Over the next few days a crowd of people and many distinguished businessmen and top-level executives visited our project stall and gave us their valuable feedback. The feedback comprised a gamut of ideas - Market oriented approach, Technical limitations, aesthetic value of the product and many more interesting comments. All visitors appreciated the novelty of our project. They were especially impressed by our implementation of ‘Kaun Banega Crorepati’ and thanks to this implementation we were easily amongst the most popular stalls in the Students’ Pavillion.
71
MUSN Embedded Software
What encouraged us even more was the constant interest from people from Industry. They were impressed by the utilitarian value of our project and even enquired if we could implement similar networks for them in their industrial plants. All in all, 'Elecrama 2006' provided us with a platform through which we could display our product in front of the masses and only through this, did we realize the market potential of our product. It also helped us in interacting with eminent people who were well aware of the market technicalities and their feedback was a morale booster. It was a superb experience which we shall always cherish.
72
MUSN Embedded Software
10. References
1. ATmega8 AVR Datasheet 2. Embedded C Programming and the Atmel AVR – Richard Barnett, Larry O’Cull and Sarah Cox (Thomson) 3.
haraleit.pdf - Harald Leintner
4. COTS Dust – Thesis by Seth Edward-Austin Hollar 5. Man pages WinAVR 6. Serial Port Complete – Jan Axelson 7. Embedded Systems : Architecture, Programming and Design – Rajkamal 8. www.avrfreaks.net/AVRGCC
73
MUSN Embedded Software
11. APPENDIX - A Sensor Descriptions 11.1 Mercury Switch A mercury switch is a switch whose purpose is to allow or interrupt the flow of electric current in an electrical circuit in a manner that is dependent on the switch's physical position or alignment relative to the direction of the ‘pull’ of earth's gravity. Mercury switches consist of one or more sets of electrical contacts in a sealed glass envelope which contains a bead of mercury. The envelope may also contain air, an inert gas, or a vacuum. Gravity is constantly pulling the drop of mercury to the lowest point in the envelope. When the switch is tilted in the appropriate direction, the mercury touches a set of contacts, thus completing the electrical circuit through those contacts. Tilting the switch the opposite direction causes the mercury to move away from that set of contacts, thus breaking that circuit. The switch may contain multiple sets of contacts, closing different sets at different angles allowing, for example, Single-Pole, Double-Throw (SPDT) operation.
Figure 28 Mercury Switch In our smart home, the switch is mounted on the door knob in such a way that when the knob is pressed down to open the door, the electrical circuit as mentioned above is completed and a ‘high’ appears on a pin of port A of the microcontroller. Due to continuous polling by the host computer, the microcontroller sends the current status of the sensor and accordingly displays whether the door is open or not.
74
MUSN Embedded Software
11.2 Motion Detector The motion detector used here DP-550 detector that combines a passive infrared (PIR) and a microwave (MW) sensor. The alarm signal is transmitted when both sensors detect the motion at the same time. A ‘high’ is obtained at the output of the detector, and the microcontroller is triggered. This sensor is mounted near the ‘Safe’ in the home, where reliability in intrusion detection has to be superior. The detector consists of an Infrared sensor which forms the basis of the working of this detector. The sensor is made of a crystalline material that generates a surface electric charge when exposed to heat in the form of infrared radiation. When the amount of radiation striking the crystal changes, the amount of charge also changes and can then be measured. Hence whenever there is motion in front of this sensor, the red led will lit, as it detects this motion.
Figure 29 Motion Detector
75
MUSN Embedded Software
11.3 Temperature Sensor The LM35 series are precision integrated-circuit temperature sensors, whose output voltage is linearly proportional to the Celsius (Centigrade) temperature. The LM35 thus has an advantage over linear temperature sensors calibrated in Kelvin, as the user is not required to subtract a large constant voltage from its output to obtain convenient Centigrade scaling. The LM35 does not require any external calibration or trimming to provide typical accuracies of g/4C at room temperature and g*/4§C over a full b55 to a150§C temperature range. Low cost is assured by trimming and calibration at the wafer level. The LM35's low output impedance, linear output, and precise inherent calibration make interfacing to readout or control circuitry especially easy. It can be used with single power supplies, or with plus and minus supplies.
Figure 30 Connection Diagrams for LM35D
76
MUSN Embedded Software
11.4 Humidity Sensor The humidity sensor used is of the SY-HS 220 series. As per the datasheet, a look up table is fed into the microcontroller, onto which this humidity sensor is connected. Depending upon the current humidity level a corresponding voltage appears at the Vout terminal, and microcontroller accordingly sets the humidity. This reading is then displayed on the host computer.
%RH SPECIFICATIONS SPECIFICATIONS HS-220 RS-220 30 990 -35 1160 -40 1300 1446 45 1490 1603 50 1650 1760 55 1820 1917 60 1980 2074 65 2150 2231 70 2310 2388 75 2480 2544 80 2640 2701 85 2810 2858 90 2970 3015 95 -3172 %RH SPECIFICATIONS SPECIFICATIONS SPECIFICATIONS 10°C 25°C 40°C 20 0.012 0.017 0.019 30 40 50 60 70 80 90
0.042 0.128 0.330 0.601 0.808 0.919 0.972
0.053 0.156 0.382 0.602 0.794 0.904 0.958
0.053 0.153 0.355 0.573 0.768 0.884 0.946
Table 5 Standard specifications corresponding to relative humidity
77
MUSN Embedded Software
Figure 31 Humidity sensor
11.5 Light Dependent Resistor (LDR) An LDR is an input transducer (sensor) which converts brightness (light) to resistance. It is made from cadmium sulphide (CdS) and the resistance decreases as the brightness of light falling on the LDR increases. Typical results for a standard LDR: • •
Darkness: maximum resistance, about 1M . Very bright light: minimum resistance, about 100 .
78
MUSN Embedded Software
Circuit symbol :
Figure 32 LDR There are two ways of constructing the voltage divider, with the LDR at the top, or with the LDR at the bottom as follows:
Figure 33 Typical connections of an LDR
The LDR is first calibrated and a suitable value resistor is chosen in its circuit. This simple circuit as per its range is kept in the vicinity of a source of light, such as a tubelight. When the tubelight switches ‘ON’ the resistance of the LDR varies so as to produce a suitable output voltage. This voltage fixed to be above a certain threshold value triggers the interrupt pin of the microcontroller and hence indicates the switching ON of the tubelight. This may help in preventing electricity loss, owing to the fact that the tubelight may be manually switched off if such an interrupt occurs.
79
MUSN Embedded Software
11.6 Gas Detector The Gas detector used here is of the SL-88 family. This household gas leaking detector with advanced low-current gas sensitivity components, enables detect the gas leaked in time, then sends out the alarm correctly.
Figure 34 General view of the detector
Figure 35 Connections for the detector
80
MUSN Embedded Software
Induced gas Power input Operating current Alarm density Buzzer level Operating temperature Stableness Repetition Alarm density error Alarm pattern Size
Coal gas/ Natural gas/ LPG 220v 50hz (household) 50ma – 400ma 10% LEL ≥ 70db/m -10°c ~+55°c ≤ ± 5% LEL ≤ ±5% LEL ≤ ±5% LEL Flash and sound alarm Shut off Gas valve/Network alarm signal 120 x 70 x 44 mm (lh-88)
Table 6 Technical specifications for the gas detector The glowing of leds on the gas detector indicate the following things : RED LED FLASH YELLOW LED FLASH YELLOW LED ON YELLOW LED OFF GREEN LED FLASH GREEN LED ON GREEN LED OFF
Gas leak Valve controller open Valve controller unconnected or error Valve controller close Running the inside sensor Working normally Power off or sensor deployed
Table 6 Specifications Continued
11.7 Infrared proximity sensor Infrared proximity sensors work by sending out a beam of IR light, and then computing the distance to any nearby objects from characteristics of the returned (reflected) signal. Proximity sensors are used for position sensing in industries as diverse as aircraft, ordnance, marine, mass transit and so on. They are well suited to applications with particularly demanding requirements on temperature, vibration, and shock.
81
MUSN Embedded Software
Figure 36 Proximity Sensors
11.8 Smoke detector The Smoke Detector is a sensitive yet rugged, state-of-the-art protection device that is designed for use in hazardous industrial and commercial locations. The detector is designed to operate effectively with both slow smoldering and fast burning fires. Typical applications that use smoke detector include: • • • • • •
Combustible storage facilities Munitions manufacturing Volatile chemical storage Chemical processing plants Petroleum refineries Turbine enclosures
The photoelectric smoke detector uses a solid-state infrared emitting diode (IRED) and a light sensing photovoltaic cell arranged in a labyrinth assembly. The labyrinth permits free access to smoke but restricts external light. Because of its critical function to the operation of the detector, each IRED is selected with extreme care and is subjected to rigorous pre-production testing to ensure long-term reliability and performance. During normal operation (no smoke), the detector samples the air approximately every four seconds for a period of less than one millisecond. The photovoltaic smoke cell, which is placed at an angle to the pulsed invisible light source, is sensitive to the infrared light in the specified frequency emitted by the IRED light source and is designed to receive a signal only when the pulsed IRED source is activated. When smoke enters the chamber, the light from the IRED reflects off the smoke particles and reaches the photovoltaic smoke cell. When the amount of light reflected by smoke reaches the factory set threshold level, the smoke alarm circuit is actuated.
82
MUSN Embedded Software
The detector will respond to a slow smoldering fire when smoke in the chamber reaches the preset sensitivity setting, typically 1.5%. If a fast burning fire should occur, including fires in flammable liquids and other materials such as plastics that generate black smoke, the abnormally rapid movement of smoke into the detection chamber is sensed by a special rate compensating circuit. An increase in smoke within the detection chamber that exceeds a preset rate causes the rate compensation circuit to increase the intensity of the light source, which increases detector sensitivity. If the smoke continues to build at this rate, an amplifier circuit is triggered and the unit generates an alarm. If not, the detector reverts to normal sensitivity. In normally smoky atmospheres the detector will not go into alarm as long as the concentration is less than the fixed sensitivity of the detector. This results in a sensitive and positive response with the lowest potential for unwanted alarms.
Figure 37 Smoke Detector
83
MUSN Embedded Software
12. List of Figures Fig.no. 1 2
Description Basic structure of our network
3
RS485 Network Implementation using MAX485/DS75176 Half Duplex Drivers Daisy chaining
4
Extract from MAX485 Datasheet
5
Schematic of a sensor node
6
12 volts – 2 ampere Power Supply
7
Schematic of the RS232-RS485 Bridge
8
Block Diagram of Atmel Atmega8
9
Pinout of Atmega8
10
Architecture of Atmel Atmega8
11
Register Set of Atmel Atmega8
12
Screenshot of Programmer’s notepad
13
Screenshot of AVRStudio4
14
STK 500
15
Screenshot of AVRStudio4 Programming window
16
Screenshot of Bray’s Terminal
17
Schematic of hardware implementation of voting pad
18
Photograph of single keypad
19
Line up of RS485 Keypads
20
Screen shot of the running java application
21
Components of a Home Monitioring System
22
Smart Home Implementation
23
Typical industrial sensor network implementation
24
KBC Studio
25
Push button switches and twisted pair cables
26
Improved connectors
27
A typical sensor network in a housing complex
28
Mercury Switch
Pg.no.
8 10 11 11 13 14 15 19 20 20 21 27 28 29 30 31 33 34 34 41 43 45 66 67 68 68 69 74 84
MUSN Embedded Software
29
Motion Detector
30
Connection Diagrams for LM35D
31
Humidity sensor
32
LDR
33
Typical connections of an LDR
34
General view of the detector
35
Connections for the detector
36
Proximity sensor
37
Smoke detector
75 76 78 79 79 80 80 82 83
85
MUSN Embedded Software
13. List of Tables
Table no.
Description
Pg. no.
1
Interrupt Vectors in order of priority
22
2
Register of Atmel Atmega8
23
3
Instruction Set Summary
4
Protocol for communication with the host
35
5
Standard specifications corresponding to relative humidity
77
6
Technical specifications for the gas detector
81
24-26
86
MUSN Embedded Software
14. Glossary 1. RS 232, RS 485 RS232 and RS485 are serial communication methods for computers and devices. RS232 is the best known serial interface implemented on almost all computers available today. RS485 is currently a widely used communication interface in data acquisition and control applications where multiple nodes communicate with each other. 2. BOOTLOADER In computing, booting is a bootstrapping process that starts operating systems when the user turns on a computer system. A boot sequence or bootloader is the set of operations the computer performs when it is switched on which load an operating system. 3. DAISY CHAIN A bus wiring scheme in which, for example, device A is wired to device B, device B is wired to device C, etc. The last device is normally wired to a resistor or terminator. All devices may receive identical signals or, in contrast to a simple bus, each device in the chain may modify one or more signals before passing them on. 4. USART A USART or universal synchronous and asynchronous receiver-transmitter is a piece of computer hardware that translates between parallel bits of data and serial bits. A UART is usually an integrated circuit used for serial communications over a computer or peripheral device serial port. 5. ASSEMBLER An assembler is a computer program for translating assembly language , essentially, a mnemonic representation of machine language , into object code. 6. CROSS ASSEMBLER A cross assembler produces code, by translating assembly language into machine code, for one type of processor, but runs on another.
87
MUSN Embedded Software
7. SIMULATOR A simulator is a device, computer program or system used during software verification, which behaves or operates like a given system when provided with a set of controlled inputs. 8. ECLIPSE EDITOR Eclipse is an open source community whose projects are focused on providing an extensible development platform and application frameworks for building software. 9. CAN Controller Area Network (CAN) is a multicast shared serial bus standard originally developed for connecting electronic control units (ECUs). CAN was specifically designed to be robust in electromagnetically noisy environments. It can be even more robust against noise if twisted pair wire is used. Although initially created for automotive purposes (as a vehicle bus), nowadays it is used in many embedded control applications (e.g., industrial) that may be subject to noise. 10. ETHERNET The term Ethernet refers to the family of local-area network products covered by the IEEE 802.3 standard that defines what is commonly known as the CSMA/CD protocol. Three data rates are currently defined for operation over optical fiber and twisted-pair cables:10 Mbps-10Base-T Ethernet ,100 Mbps—Fast Ethernet, 1000 Mbps—Gigabit Ethernet. 11. SNAP PROTOCOL The Subnetwork Access Protocol (SNAP) is a mechanism for multiplexing, on networks using IEEE 802.2 LLC, more protocols than can be distinguished by the 8-bit 802.2 Service Access Point (SAP) fields. SNAP supports identifying protocols by Ethernet type field values; it also supports vendor-private protocol identifier spaces. 12. CRC A cyclic redundancy check (CRC) is a type of hash function used to produce a checksum - which is a small, fixed number of bits - against a block of data, such as a packet of network traffic or a block of a computer file. The checksum is used to detect and correct errors after transmission or storage. A CRC is computed and appended before transmission or storage, and verified afterwards by recipient to confirm that no changes occurred on transit.
88
MUSN Embedded Software
15. Acronyms ADC ALU ANSI AVR-GCC AVRISP CAN CMOS CSMA/CD CRC EEPROM EIA GUI ICE IDE ISP JTAG LAN LDR LVDT Mbps MUSN PT100 RISC RS485, 232 SNAP SPDT SPM SRAM TCP/IP TIA TTL UART UDR USART USB
Analog to Digital Converter Arithmetic Logic Unit American National Standards Institute AVR GNU Compiler Collection AVR In-System Programmer Controller Area Network Complementary Metal Oxide Semiconductor Carrier Sense Multiple Access with Collision Detection Cyclic Redundancy Check Electrically-Erasable Programmable Read-Only Memory Electronics Industry Association Graphical User Interface In-Circuit Emul Integrated Development Environment In-System Programming Joint Test Action Group Local Area Network Light Dependent Resistor Linear Variable Differential Transformer Megabits per second Multi-Utility Sensor Network Platinum 100 Reduced Instruction Set Computer Recommended Standard 485, 232 Scalable Node Address Protocol Single Pole Double Throw Store Program Memory Static Random Access Memory Transmission Control Protocol / Internet Protocol Telecommunications Industry Association Transistor Transistor Logic Universal Asynchronous Receiver/Transmitter USART Data Register Universal Synchronous Asynchronous Receiver Transmitter Universal Serial Bus
89
MUSN Embedded Software
16. Index A Accelerometer 12, 70 AC Network 45 Application program section 21 Atmega8 18-27 Audience Poll 32 AVR Studio 4 28 AVRISP 32 AVR-GCC 29
Flame Sensors 12 Flash memory 21
G Gas Sensors 12 GNU project 29 GSM 30 GUI 7, 42
H B Basic Topology of the Network 8 Bootloading 43 Boot program section 21
Half-duplex mode 43 Hall effect switch IC 12 Hall Effect Vane Switch 12 Harvard Architecture 21 Humidity Sensors 12, 84, 85
C Cadmium sulphide (CdS) 86 Calibrated Strain Gauge based Load Cells 12 Connectors - 9 pin Sub-D connectors 32 Controller Area Network (CAN) 43, 96 CRC 43, 96
I
D
J
Daisy Chain 9, 11 Digital town square 69 Direct Cable 45 DP-550 detector 84
JAVA 42 JTAGICE mkII/ JTAGICE 28
E Eclipse Editor 42, 96 EEPROM 35 Embedded C 27 Error correction 43 Ethernet 45, 74, 75, 96
F Fastest Finger First 32, 73 Fieldbus systems 72, 76 Field multiplexers 72, 76
ICE50/ ICE40/ICE200 28 IDE 28 Infrared/Capacitive/Inductive Proximity Sensor 12 ISP6 30
L LDR 86 LM35 80, 83 Lock Bits 21
M MAX485/DS72176 Driver IC’s 9 MAX483 11 MAX232 14, 32 Mercury switch 81 Micro-switches 32 Microwave (MW) sensor 82 Motion Detector 82 Munitions manufacturing 90 90
MUSN Embedded Software
N Network Management Software 42
O Opto-interrupters 12
P Passive infrared (PIR) 82 Petroleum refineries 90 Phone Line 45 Programmer’s notepad 27 Power supply monitoring ICs 12
R Reed Switches 12 RISC 11, 18, 29 RS485 8, 10, 14, 43, 73 RS232 14, 29, 32 RS485-RS232 Bridge 14 RTS signal 32
S Sensor Networks 7, 70 Shaft Encoders 12 Single chip Temperature sensor or PT100 based Temperature sensor 12, 45, 83 SL-88 88
Smart home 44, 69, 75 Smoke Detector 90, 91 SNAP 35, 96 SPI 18 SPM instruction 21 Spread Spectrum 45 SPROG3 30 STK500/501/502 28 SY-HS 220 84
T Terminal 30, 31 Tilt Switches (Mercury Switches) 12 Timer/Counter 18 TTL 11, 14, 32 Turbine enclosures 90
U USART 9, 11, 18, 30, 95
V Volatile chemical storage 90 Voltage regulator -7805 32
W WATCHDOG TIMER 18 WinAvr 29
91
