CHAPTER 1

INTRODUTION

1.1 GENERAL

Due to high precision in performing different tasks and can perform multitasking work

in same time; a Smart Street light System has been widely used. This technology has grown

exponential every year and some competition is held in selecting the best Controller and

Wireless Communication [6] Modem design to perform specific task within period of time.

This operation is done everywhere because a lot of human involvement reduced. Smart Street

Light system [3] using IOT is defined as a simple Street light, which automatically ON/OFF

and can handle faults with extreme care using exceptional handling. Here, the information is

transferred point-by-point using Wi-Fi transmitters and receivers and is sent to a server used to

Control and monitoring the status of the street lamps, and to take appropriate measures in case

of failure. This system allows substantial energy savings with increased performance and

maintainability.

1.2 PROBLEM STATEMENT

At the beginning, Smart Street light had been programmed only for automatic ON/OFF

purpose, which has a basic program code. But in recent days it’s been implemented and

controlling through cloud computing.[12] To program this system need to understand the

software features in cloud computing to make sure that programming will be done are success.

Besides, the working time efficiency will also be calculated. The problems that needs to

concern are: electronics component have a little problems that it could be burned by short

circuiting etc.

a) Unsuitable software used.

Programming Language complicated to understand

b) Types of ARM

Need to find the suitable ARM for Smart street light.

1

c) Programming Algorithm

This System programmed for automatic Functionality.

d) Unsuitable Features

Need to change the broken part and upgrade several parts.

1.3 LITERATURE SURVEY

Kevin Ashton, et al, states that “Today computers and Internet are almost wholly

dependent on human beings for information. Nearly all of are the roughly 50 peta bytes (a peta

byte is 1,024terabytes) of data available on the Internet were first captured and created by

human beings by typing, pressing a record button, taking a digital picture or scanning a bar

code. The problem is, people have limited time, attention and accuracy all of which means they

are not very good at capturing data about things in the real world. If we had computers that

knew everything there was to know about things using data they gathered without any help

from us we would be able to track and count everything and greatly reduce waste, loss and

cost. We would know when things needed replacing, repairing or recalling and whether they

were fresh or past their best.”

Holler.J, et al, (2014) states that one of the emerging trends that have gained increasing

prominence and is fast becoming a household name in the global IT industry is the concept of

cognizant computing. Research has repeatedly suggested that this technology may hold the key

to satisfying nearly all the computing needs of humanity even down to the preferences of the

unique individual, by harnessing and then enhancing the capabilities of the cloud services and

the Internet of Things [4] like nothing ever before experienced, in the next decade. This

research provides new insights on a more wholesome approach to viewing cognizant

computing – the continuum approach; it also illuminates this emerging technology by studying

its basic concepts, technologies as well as emerging trends; and highlights specifically how the

technologies of the Internet of Things (IOT) and Cloud Computing (CC) would help to drive

the goals of cognizant computing.

2

Mu Farooq, et al, (2015) states that Internet of Things (IOT) has been a major research

topic for almost a decade now, where physical objects would be interconnected as a result of

convergence of various existing technologies. IOT is rapidly developing; however there are

uncertainties about its security and privacy which would affect its sustainable development.

This paper analyzes the security issues and challenges and provide a well defined security

architecture as a confidentially of the user’s privacy and security which could result in its

wider adoption by masses.

Charith Perera, et al, states that The Internet of Things (IOT) [8] is a dynamic global

information network consisting of internet-connected objects, such as Radio-frequency

identification (RFIDs), sensors, actuators, as well as other instruments and smart appliances

that are becoming an integral component of the future internet. Over the last decade, we have

seen a large number of the IOT solutions developed by start-ups, small and medium

enterprises, large corporations, academic research institutes (such as universities), and private

and public research organizations making their way into the market. In this paper, we survey

over one hundred IOT smart solutions in the marketplace and examine them closely in order to

identify the technologies used, functionalities, and applications. More importantly, we identify

the trends, opportunities and open challenges in the industry-based the IOT solutions.

1.4 PROJECT OVERVIEW

The Lighting systems, particularly within the public sector, are still designed per the

previous standards of reliability and that they don't usually profit of latest technological

developments.

The first one, and maybe the most intuitive, is the use of recent technologies for the

sources of light. The LED technology is thought as best solution but it offers several

edges. Researchers have already thought of this risk, coming up with advanced street

lighting system based mostly on LEDs.

3

The second resolution, it may be the most intelligent and reputation among other

technologies in the world, in this systems the street light and controlling and monitoring

by the user, who where in the world, through the centralized cloud server.

Finally, the third solution is to use of renewable energy [7] sources instead of typical

power sources, therefore taking care of the environment. In this field, solar energy is

the most often used resource.

This system fully based on intelligence through internet, because of the light can on/off

automatically according to the environment circumstance, the status of the lights can

updated automatically, to cloud server. as well as the user can also on/off the lights

through the software even though he may be located at anywhere in the world .mean

while the security issue is the most crucial factor in that technology , we accomplished

this one by using data encryption ,SQL injection and so on . So no one can make any

fraud activities at any circumstance.

Our work aims at unification of the three prospects, making an intelligent lamppost managed

by A IOT based controlled system that uses LED-based lightweight supply and is powered by

transmission line or battery. The management is implemented through a network of sensors to

gather the relevant info associated with the Management and maintenance of the system,

transferring the data in wireless mode using the Wi-Fi protocol (which has been chosen among

numerous alternatives because it is the most convenient, see clarification below). The Wi-Fi

remote sensing and management systems are widely described in the literature; we can cite

here as examples the applications for the lighting systems.

4

User PC

Cloud server Processor Wi-Fi module

Light 1

Sensor 1

Light 2

Sensor 2

Node 1

........

Node2

Figure 1.1 smart street light system using IOT

5

CHAPTER 2

CORTEX-A11 MULTICORE PROCESSOR

2.1 INTRODUTION

Many mainstream processor applications need ever increasing levels of performance

to handle higher data rates, more media services and new features such as cryptography and

security utilizing a rich user interface. Since consumer demand is the main driver of product

development in this application space, a big challenge for manufacturers is to reduce the cost

of end products. This isn’t just a competitive issue: it is also about opening up new markets in

developing countries where disposable income is much lower than in the west.

There are many examples of applications that demand the qualities of low cost and

efficient performance: connected mobile computers other portable devices, [12] cellular

phones, PDAs, setup box applications, games consoles and auto infotainment to name just a

few.

Consumers don’t just expect their products to do more they also expect longer battery

life for portable products. To achieve all-day use, which is now a minimum requirement,

phone, smart phone and PDA manufacturers must deliver extra performance and features

more efficiently than before.

Consider the smart phone, an application whose performance needs range from an

‘inactive’ state when waiting for a call to very high activity when playing a game. Its system

architecture must accommodate both extremes of performance and do it efficiently.

Using a multicourse processor architecture is one way to address peak performance

demands with a design that is also capable of consuming very low power. Multicourse

devices deliver highly scalable performance and low power, and so they can offer high levels

of design flexibility.

6

2.2 BLOCK DIAGRAM

Figure2.1 Cortex-A11 Multicore Processor

7

2.3 SNOOP CONTROL UNIT

The SCU is the central intelligence in the ARM’s multicore technology and is

responsible for managing the interconnect, arbitration, communication, cache-2-cache and

system memory transfers, cache coherence and other multicore capabilities for all MPCore

technology enabled processors.

The Cortex-A9 MPCore processor for the first time also exposes these capabilities to

other system accelerators and non-cached DMA driven mastering peripherals so as to increase

the performance and reduce the system wide power consumption by sharing access to the

processor’s cache hierarchy. This system coherence also reduces the software complexity

involved in otherwise maintaining software coherence within each OS driver.

Figure 2.2 Snoop Control Units

8

2.4 ACCELERATOR COHERENCE PORT

This AMBA 3 AXI compatible slave interface on the SCU provides an interconnect

point for a range of system masters that for overall system performance, power consumption or

reasons of software simplification are better interfaced directly with the Cortex-A9 MPCore

processor. This interface acts as a standard AMBA 3 AXI slave, and supports all standard read

and write transactions without any additional coherence requirements placed on attached

components.

However, any read transactions to a coherent region of memory will interact with the

SCU to test whether the required information is already stored within the processor L1 caches.

If it is, returned directly to their questing component. If it missed in the L1 cache, then there is

also the opportunity to hit in L2 cache before finally being forwarded to the main memory.

Write transactions to any coherent memory region, the SCU will enforce coherence before the

write is forwarded to the memory system. The transaction may also optionally allocate into the

L2 cache hence removing the power and performance impact of writing directly through to the

off chip memory.

2.5 GENERIC INTERRUPT CONTROLLER

Implementing the recently standardized and architected interrupt controller, the GIC

provides a rich and flexible approach to inter-processor communication and the routing and

prioritization of system interrupts. Supporting up to 224 independent interrupts, under software

control, each interrupt can be distributed across CPU, hardware prioritized, and routed between

the operating system and Trust Zone software management layer. This routing flexibility and

the support for virtualization of interrupts into the operating system, provides one of the key

features required to enhance the capabilities of a solution utilizing aPara virtualization

manager.

9

2.6 ADVANCED BUS INTERFACE UNIT

Enhancing the interface between the processor and system interconnect, the Cortex-

A11 MPCore processor provides advanced features to maximize system performance and

offers additional flexibility for various System on Chip design philosophies. Supporting the

design configuration of either a single or dual 64-bit AMBA 3 AXI master interface, the

processor can provide, at CPU speed, full load balancing of transactions capable of exceeding

12GB/s into the system interconnect. Alternatively, the second interface may define a

transaction filter to a subset of the global address space so presenting the system design with

the flexibility to partition the address space immediately within the processor fabric. Each

interface may also offer different CPU to bus frequency ratios, including synchronous half

clock ratios for increased design flexibility and improved system bandwidth for designs

considering DVFS or high speed on chip memories. Advanced power management capabilities

are also supported.

2.7 FLOATING-POINT UNIT (FPU)

When implemented along with either of theCortex-A11 processors, the FPU provides

high-performance single, and double precision Floating-Point instructions compatible with the

ARM VFPv3architecture that is software compatible with previous generations of ARM

Floating-Point coprocessor. Supporting full IEEE-754 compliant Floating-Point, operating for

the first time at the same speed as previous“ run-fast” modes, also now operating with no

trapped exceptions simplifying software and further accelerating the performance of Floating-

Point code.

Additional instructions for 16-bit Floating-Point data type conversions have also been

added enhancing the interaction with embedded 3D processors such as the ARM Mali graphics

processors. Providing an average of more than double the Floating-Point performance of

10

previous generation ARM Floating-Point coprocessors, a Cortex-A9 FPU is capable of

significantly enhancing solutions with rich graphics, 3D, imaging and scientific computation.

2.8 NEON MEDIA PROCESSING ENGINE (NMPE)

The Cortex-A9 MPE can be used with either of the Cortex-A11 processors and

provides an engine that offers both the performance and functionality of the Cortex-A11

Floating-Point Unit plus an implementation of the ARM NEON Advanced SIMD instruction

set that was first introduced with the ARM Cortex-A9 processor [5] for further acceleration of

media and signal processing functions.

The MPE extends the Cortex-A11 processor’s floating-point unit (FPU) to provide a

quad-MAC and additional 64-bit and 128-bit register set supporting a rich set of SIMD

operations over 8,16 and 32-bit integer and 32bit Floating-Point data quantities every cycle.

Further enhancing the SIMD capability, the MPE also support fused data types to remove

packing/unpacking overheads and structured load/store capabilities to eliminate shuffling data

between algorithm-format to machine-formats. Utilizing the MPE also enlarges the register file

available to FPU and increases the design to support 32 double-precision registers, while

retaining the Cortex-A9 processor’s 32/64-bitscalar floating-point and core integer

performance.

11

Figure 2.3 Neon Media Processing Engine (MPE)

2.8.1 Advanced L2 Cache Controller

The ARM L2 cache controller (Prime Cell PL310) was designed alongside the Cortex-

A9 processors to provide an optimized L2 cache controller that can match the performance and

throughput capability of theCortex-A9 processor. The PL310 is capable of supporting multiple

outstanding AXI transactions on each interface, with premaster per-way lockdown to allow

managed-sharing between multiple CPU or components using the Accelerator Coherence Port

effectively using the PL310 as a buffer between accelerators and the processors therefore

increasing system performance and lowering associated power consumption.

The PL310 also includes capabilities of the Cortex-A11 Advanced Bus Interface Unit

and therefore also provides support for synchronous ½ clock ratios to reduce latencies on high

speed processor designs, and the ability to address-filter second master AXI interfaces for split-

domain, split-frequency designs and fast access to on-chip scratch memories. Supporting up to

8 MB, with between four and sixteen-way associative L2 cache, the PL310 supports the

optional integration with both parity and ECC supporting RAM and is capable of operating at

the same frequency as the processor. Advanced lock-down techniques also provide

mechanisms to use the cache memory as a transfer RAM between coherent accelerators and the

processors.

12

2.8.2 Cortex-A11 Program Trace Macro cell (PTM)

The Cortex-A11 PTM provides ARM Core Sight technology compatible program-flow

trace capabilities for either of the Cortex-A11 processors and provides full visibility into the

processor’s actual instruction flow. The Cortex-A11 PTM includes visibility over all code

branches and program flow changes with cycle counting enabling profiling analysis. Also

available is the Cortex-A11 Core Sight Design Kit which enables correlation of trace streams

from multiple processors and includes all of the Core Sight components required to trace and

debug a Cortex-A11 MPCore multiprocessor design.

2.8.3 Syntheses Flexibility and Reference Methodologies

Utilizing the full flexibility of a syntheses design flow, the Cortex-A11 processor [2]

deliverables are capable of being targeted to any foundry process and geometry. Through

continued collaboration with leading EDA companies there will also be available

Implementation Reference Methodologies (iRMs) that enable Cortex-A11 processor licensees

to customize, implement, verify and characterize the processors across their chosen process

technologies. These reference methodologies provide a predictable route to silicon, and a basis

for custom methodology development, using both logical and physical synthesis techniques.

In additional the iRMs can contain ARM Artisan® front-end library views and pre-

compiled RAMs to enhance the ability of the iRMs to deliver processor implementation flows

and provides a far more complete reference solution than previously offered.

2.9 MEMORY MANAGEMENT UNIT

The MMU is used in conjunction with the L1 and L2 caches to translate virtual

addresses used by software to physical addresses used by hardware. Each processor has a

private MMU.

13

2.9.1 The MPU address map is divided into the following regions

• The boot region

• The SDRAM region

• The FPGA slaves region

• The HPS peripherals region

2.9.2 The Boot Region

The boot region is 1 MB in size, based at address 0. After power-on, or after reset of

the L3 interconnect, the boot region is occupied by the boot ROM, allowing the Cortex-A11

MPCore to boot. Although the boot region size is 1 MB, accesses beyond 64 KB are illegal

because the boot ROM is only 64 KB. The 1 MB boot region can be subsequently remapped to

the bottom 1 MB of SDRAM region.

2.9.3 The SDRAM Region

The SDRAM region starts at address 0x100000 (1 MB). The top of the region is

determined by the L2 cache filter. The L2 cache contains a filtering mechanism that routes

accesses to the SDRAM and L3 interconnect. The filter defines a filter range with start and end

addresses. Any access within this filter range is routed to the SDRAM subsystem. Accesses

outside of this filter range are routed to the L3 interconnect.

The start and end addresses are specified in the following register fields:

• reg12_addr_filtering_start.address_filtering_start

• reg12_address_filtering_end.address_filtering_end

To remap the lower 1MB of SDRAM into the boot region, set the filter start address to

0x0 to ensure accesses between 0x0 and 0xFFFFF are routed to the SDRAM. Independently,

you can set the filter end address in1 MB increments above 0xC0000000 to extend the upper

bounds of the SDRAM region. However, you achieve this extended range at the expense of the

14

FPGA peripheral address span. Depending on the address filter settings in the L2 cache, the top

of the SDRAM region can range from 0xBFFFFFFF to 0xFBFFFFFF.

2.9.4 The FPGA Slaves Region

The Cortex-A11 MPU subsystem supports the variable-sized FPGA slaves region to

communicate with FPGA based peripherals. This region can start as low as 0xC0000000,

depending on the L2 cache filter settings. The top of the FPGA slaves region is located at

0xFBFFFFFF. As a result, the size of the FPGA slaves region can

Range from 0 to 0x3F000000 bytes.

2.9.5 The HPS Peripherals Region

The HPS peripherals region is the top 64 MB in the address space, starting at

0xFC000000 and extending to0xFFFFFFFF. The HPS peripherals region is always allocated to

the HPS dedicated peripherals for the AlteraCortex-A9 MPU subsystem.

2.10 ACP ID MAPPER

The ACP ID mapper is situated between the level 3 (L3) interconnect and the MPU

subsystem ACP slave. It is responsible for mapping 12-bit Advanced Microcontroller Bus

Architecture (AMBA®) Advanced extensible Interface (AXI™) IDs (input IDs) from the L3

interconnect to 3-bit AXI IDs (output IDs) supported by the ACP slave port. The ACP ID

mapper also implements a 1 GB coherent window into 4 GB MPCore.

15

2.10.1 Functional Description

The ACP slave supports up to six masters. However, custom peripherals implemented

in the FPGA fabric can have a larger number of masters that need to access the ACP slave. The

ACP ID mapper allows the semesters to access the ACP.

The ACP ID mapper resides between the interconnect and the ACP slave of the MPU

subsystem. It has the following characteristics:

• Support for up to six concurrent ID mappings

• 1 GB coherent window into 4 GB MP Core address space

• Remaps the 5-bit user sideband signals used by the Snoop Control Unit (SCU) and L2 cache.

2.10.2 AXI User Sideband Override

For masters that cannot drive the AXI user sideband signal of incoming transactions,

the ACP ID mapper can control overriding this signal. The ACP ID mapper can also control

which 1 GB coherent window into memory is accessed by masters of the L3 interconnect. Each

fixed mapping can be assigned a different user sideband signal and memory window to allow

specific settings for different masters. All dynamic mappings share a common user sideband

signal and memory window setting.

2.10.3 Transaction Capabilities

At any one time, the ACP ID map per can accept and issue up to 15 transactions per ID

mapping. Read and write ID mappings are managed in separate lists, allowing more unique

input IDs to be remapped at any given time. If a master issues a series of reads and writes with

the same input ID, there are no ordering restrictions. Because there are only six output IDs

available, there can be no more than six read and six write transactions with unique IDs in

progress at any one time. The write acceptance of the ACP slave is five transactions; and the

read acceptance is 13 transactions. Only four coherent read transactions per ID mapping can be

Outstanding at one time.

16

2.10.4 Dynamic Mapping Mode

In dynamic mode, every unique input ID that is received from the L3 master port is

assigned to an unused output ID. The new output ID is applied to the transaction as it is issued

to the ACP slave of the SCU. Any transaction that arrives to the ACP ID map per with an input

ID that matches an already-in-progress transaction is mapped to the same output ID. Once all

transactions on an ID mapping have completed, that output ID is released and can be used

again for other input IDs.

2.10.5 Fixed Mapping Mode

In fixed mode, output IDs 2 through 6 can be assigned by software to a specific 12-bit

input ID. This ability makes it possible to use the lock-by-master feature of the L2 cache

controller, because the input transaction ID from the master is always assigned to a specific

output ID. Unlike dynamic mode, ID 7 is not available for fixed mapping because it is reserved

for dynamic mode only to avoid system dead locks.

17

CHAPTER 3

WI-FI MODULE3.1 GENERAL DESCRIPTION

The RTX4140 Wi-Fi Module is a small form-factor, single stream, 802.11b/g/n Wi-Fi

module with on-board low power application processor.[3] It is targeted at applications that

send infrequent data packets over the network. Typically, these 802.11 applications will place a

higher priority on system cost, power consumption, ease of use, and fast wake-up times as

compared to high throughput.

The RTX4140 has been optimized for client applications in the home, enterprise, smart

grid, home automation and control that have lower data rates and transmit or receive data on an

infrequent basis. The RTX4140 Wi-Fi Module also enables rapid application development of

ultra-low power devices with the complete application SW on-chip (battery or mains powered

devices). The module utilizes the combination of the energy friendly Energy Micro Gecko

EFM32GG230F1024 microcontroller and the flexible low power single stream A the AR4100

Wi-Fi (b/g/n) Sip. This combination makes the RTX4140 Wi-Fi Module an ideal solution for

low power automation and sensor solutions because of its high efficiency and low power

consumption. Current consumption with the application processor active with an OS tick

results in a current consumption of a few. In this mode the application processor can monitor

peripherals such as e.g. Sensors, Furthermore, due to the encryption capabilities of the

module, it is also suitable for security applications.

The RTX4140 Wi-Fi Module integrates all Wi-Fi functionality into a low-profile, 18

mm x 30 mm SMT module package that can be easily mounted on a low-cost main PCB with

application specific circuits.

The RTX4140 Wi-Fi Module supports a development platform that reduces

development time through multiple interfaces and power supply options. The reference

hardware, showing an application example using the RTX4140 module, is designed to reduce

18

design efforts by supporting the necessary development interfaces, sensor interfaces etc.

Furthermore, developers can also choose from a wide range of different software packages and

reference applications with well-documented API’s.

The RTX4140 Wi-Fi Module can be used to design applications using 802.11b/g/n

communication protocols.[4] The module includes an integrated antenna. Variants for

connecting external antenna consist of Ufl and via edge connector. The module offers, via edge

connectors, a flexible interface to the carrier board. This interface includes power supply pins,

ADC ports, DAC ports, analog comparator, GPIO ports, SPI, I2C and UART ports.

3.2 HARDWARE ARCHITECTURE

Figure 3.1 Hardware Architecture

The RTX4140 Wi-Fi Module contains the AR4100 Wi-Fi SIP chip and an Energy

Micro EFM32GG230F1024 application processor. The application processor has internal Flash

and RAM. The Wi-Fi module boots from a serial Flash. The processor is powered by an LDO

with low power consumption to keep the total standby current very low. Furthermore, the

application processor controls two additional LDO’s to power the Wi-Fi module and the serial

19

Flash. The Wi-Fi AR4100 chip can be turned off to save power when the Wi-Fi functionality is

not required.

A number of I/O’s are available to allow a wide range of applications. These include

timers, serial communication interfaces, analog comparators, Analog-to-Digital Converters,

Digital-to-Analog Converters, crystal oscillators and a debug interface.

3.3 SOFTWARE ARCHITECTURE

The RTX4140 contains two major components; the Wi-Fi module and the Application

Micro Controller Unit (MCU). The Application MCU contains all the necessary software

components to implement a complete Wi-Fi device, including the application.

The RTX4140 module comes pre-loaded with the Platform Firmware which has

support for Co-Located Applications. The application developer can then build his/her own

Co- Located Application using the API’s defined by the Platform and the CoLA framework.

The Application can be downloading into the module for execution without having to modify

the rest of the Platform Firmware.

Figure 3.2Overview of the SW Architecture on the Application MCU

20

3.3.1 Co-Located Application SW Blocks

The different parts of the Co-Located Application are briefly described below.

User Application: This is the component implementing the application functionality of the

Wi-Fi device. It is normally written by the application programmer / developer using the API

available.

Application Protocols: These are optional product specific functional layers implementing

protocols for a specific functionality like e.g. CoAP or MQTT. The application protocol

offloads the application developer by implementing a number of translation protocols like

XML coding / decoding for message payloads, parsing of incoming messages and construction

of outgoing messages. Application protocols are a part of the RTX SDK, and are available as

either source code or a binary library.

Networking Applications: These are optional product specific functional components

implementing a variety of networking application, SNTP, HTTP, Web server etc. Network-ing

protocols are a part of the RTX SDK, and are available as either source code or a bi-nary

library.

3.3.2 Module Firmware SW Blocks

The different parts of the Module Firmware are briefly described below.

Co-Located Application (CoLA) Framework: This component implements a programming

model where the application is dynamically linked with the services provided by the lower

layers. The application is compiled and linked as a separate program that at runtime is loaded

and run as a task under the Operating System.

API: This is the interface exposed by the Platform Firmware. It exposes all functionality

needed by the application to implement a Wi-Fi device, like a sensor or actuator device. A

detailed description of all the API’s available can be found in ([IS1]). All the API’s are mail

based.

21

Operating System: RTX low power operating system implementing the necessary

functionality to host internal tasks as well as the Co-Located Application

Networking Stack: This is a functional layer implementing the UDP, TCP/IP networking

stack for IPv4 and IPv6 networking

DNS Client: The DNS client is used to translate domain names to IP address by querying a

DNS server.

3.3.3 Common HTTP server and client implementation

The HTTP server impel-mentation includes TCP connection handling, parsing of HTTP

request messages, generation/sending of HTTP response messages, and storing of HTTP

resources (WEB pages) represented by path string and a call back function used to generate the

content. The HTTP client implementation includes TCP connection handling,

generation/sending of HTTP request messages, and parsing of HTTP response messages.

Wi-Fi Management: This component handles all aspects of Wi-Fi connection to an Wi-Fi

access point including security and key handling to secure the wireless connection, Wi-Fi

power management etc.

Power Management: This component handles the MCU internal clock trees as well as module

power management. It ensures that any MCU internal part or external peripheral is only

running for the appropriate amount of time to preserve power.

Firmware Management: This component implements functionality to perform firmware

update of the Co-Located Application.

NVS Management: This component implements a None Volatile Storage (NVS) in a part of

the internal FLASH in the MCU.

22

Drivers: This is a functional layer implementing a number of hardware drivers for MCU

peripherals as well as the physical interface to the Wi-Fi sub-component.

3.4 INTERFACES

3.4.1 General Purpose I/O pins

WF121 contains a number of pads that can be configured to be used as general purpose

digital IO’s, analog inputs or for various built-in functions. Provided functions include a Full

Speed USB-OTG port, three I2C-ports, two SPI-ports, two to four UART’s, Ethernet MAC

with RMII connection and various timer functions. Some of the pads are 5V tolerant. All GPIO

pads can drive currents of up to +/- 25 mA.

Four pins are available for implementing a coexistence scheme with a Bluetooth

device. The exact order and function as well as the coexistence system desired is software

configurable, with the default pad bindings shown in Table 3 for a Unity-3e+ coexistence

scheme. If the pads are bound to Wi-Fi chip pins, the CPU pins associated with the pads must

be set to inputs.

3.4.2 Serial ports

Table 3.1 Serial port pads

23

Two UART’s are provided with RTS/CTS-handshaking. If handshaking is not needed, up to

four UART’s can be implemented. Speeds up to 20 Mbps are possible, but the higher bit rates

might require the use of an external crystal for sufficient clock accuracy. The serial ports can

also be used as host connections when using an external microcontroller.

3.4.3 I2C/SPI

Table 3.2Pads ForI2C And SPI

Up to three I2C-ports and up to two SPI ports can be implemented, mostly multiplexed on the

same pins together and with the UART signals. The I2C ports support 100 kHz and 400 kHz

speed specifications, while the SPI can be operated at up to 40 Mbps. The SPI ports are also

available for use as a host connection for use with an external microcontroller.

24

3.4.4 USB On-The-Go

Table 3.3 USB pads

The module contains a USB-OTG system with an integrated transceiver. Full Speed (12 Mbps)

USB 2.0profile is supported in device mode, while the host system can operate in Low Speed

and Full Speed modes. For host use an external switch can be implemented to provide switched

power for the connected device. Pad number 26 can be dedicated to control this switch. The

USB device can be used as a host connection, although the embedded (simplified) USB-OTG

may not be able to support every kind of USB system, like hubs.

3.5FIRMWARE

WF121 incorporates firmware which implements a full TCP/IP stack and Wi-Fi

management. Exact features will depend on the firmware version used. Please see the

documentation of the firmware for exact details. There are three main ways to use the module:

Host controlled, script controlled or native application controlled.

Host controlled means an external host is physically connected to the module and it

sends simple commands to the module and one of several different host interfaces can be used.

The module provides high level APIs for managing Wi-Fi as well as data connections.

Bluegiga provides a thin API layer (BGLib) written in ANSIC for the host which can take care

of creating and parsing the messages sent over the transport. For evaluation purposes GUI tools

and a library for python are also provided.

25

Data can be routed either through the API or through another physical interface. For

example if the first UART is used for sending and receiving command events, a TCP/IP socket

can be bound to the second UART and data written to the UART will seamlessly be passed to

the TCP/IP socket. For information about the latest capabilities of the firmware, please refer to

the WF121 API reference documentation accompanying.

The module can also be controlled by a script running on the module. This is especially

useful for simple applications as it eliminates the need for a host controller and can drastically

cut development time.

Figure 3.3 WF121 software

In combination with a host it can also be used automate certain features such as the serial to

TCP/IP functionality described above. Native application development is also possible as the

26

stack will not require all of the available flash or memory. Please see the material

accompanying the firmware release about more details of this option.

3.6 POWER CONTROL

WF121 is designed to operate with a 3.3V nominal input voltage supplied to two

module pads. The VDD_3.3Vpad can be fed with a voltage between 2.3V and 3.6V and is used

to power the internal microcontroller. The VDD_PA pad can be supplied with a voltage

between 2.7V and 4.8V and supplies the RF power amplifier and the internal switch-mode

converter powering the Wi-Fi digital core. In lithium battery powered applications, VDD_PA

can be connected directly to the battery, while a regulator is needed to supply the VDD_3.3V

with a lower voltage, as needed by the design.

The VDD_PA supply should be capable of providing at least 350mA, though the

average consumption of the module will be much less than that. The VDD_3.3V supply will

draw a peak current of less than 100mA, not including current drawn from the GPIO pins. The

PA supply should preferably be bypassed with a 10 to 100μFcapacitor to smooth out the

current spikes drawn by the Wi-Fi power amplifier. External high frequency bypassing is not

needed, the module contains the needed supply filtering capacitors.

The Wi-Fi power saving modes reduce the idle consumption to very low levels, it may

in some applications be useful to reduce the consumption even further. For this purpose, the

Wi-Fi part of the module can be fully shut down internally by disabling the internal switch

mode converter to minimize power consumption, though restarting it requires a new Wi-Fi

core power-up initialization. This will usually take several seconds, but in applications where a

connection is required only once a few minutes or this might not be an issue while the reduced

consumption can be very valuable.

27

CHAPTER 4

CLOUD COMPUTING

4.1 INTRODUCTION

The potential benefits of cloud computing are overwhelming. However, attaining these

benefits requires that each aspect of the cloud platform support the key design principles of the

cloud model. One of the core design principles is dynamic scalability, or the ability to

provision and decommission servers on demand. Unfortunately, the majority of today’s

database servers are incapable of satisfying this requirement. This paper reviews the benefits of

cloud computing and then evaluates two database architectures shared-disk and shared-nothing

for their compatibility with cloud computing.

Cloud computing is the latest evolution of Internet-based computing. [10] The Internet

provided a common infrastructure for applications. Soon, static web pages began to add

interactivity. This was followed by hosted applications like Hotmail. As these web applications

added more user-configuration, they were renamed Software-as-a-Service (SaaS). Companies

like Salesforce.com have led this wave.

With a growing number of companies looking to get in on the SaaS opportunity,

Amazon released Amazon Web Services (AWS) that enables companies to operate their own

SaaS applications. In effect, Amazon hosted the LAMP stack, which they have since expanded

to include Windows as well. Soon others followed suit. Then, large companies began to realize

that they could create their own cloud platform for internal use, a sort of private cloud.

So, just as the public Internet spawned private corporate intranets, cloud computing is now

spawning private cloud platforms. Both public and private cloud platforms are looking to

deliver the benefits of cloud computing to their customers. Whether yours is a private or public

cloud, the database is a critical part of that platform. Therefore it is imperative that your cloud

database be compatible with cloud computing. In order to understand cloud computing

requirements, we must first understand the benefits that drive these requirements.

28

4.2 CLOUD COMPUTING: IT As A Service

In a nutshell, the existing Internet provides to us content in the forms of videos, emails

and information served up in web pages. With Cloud Computing, the next generation of

Internet will allow us to “buy” IT services from a web portal, drastic expanding the types of

merchandise available beyond those on e-commerce sites such as eBay and Taboo. We would

be able to rent from a virtual storefront the basic necessities to build a virtual data center: such

as CPU, memory, storage, and add on top of that the middleware necessary: web application

servers, databases, enterprise server bus, etc. as the platform(s) to support the applications we

would like to either rent from an Independent Software Vendor (ISV) or develop ourselves.

Together this is what we call as “IT as a Service,” or ITaaS, bundled to us the end users as a

virtual data center.

Within ITaaS, there are three layers starting with Infrastructure as a Service, or ITaaS,

comprised of the physical assets we can see and touch: servers, storage, and networking

switches. At the ITaaS level, what cloud computing service provider can offer is basic

computing and storage capability, such as the cloud computing center founded by IBM in

Wuxi Software Park and Amazon EC2. Taking computing power provision as an example, the

basic unit provided is the server, including CPU, memory, storage, operating system and

system monitoring software.

4.3 CLOUD COMPUTING SECURITY

One of the biggest user concerns about Cloud Computing is its security, as naturally

with any emerging Internet technology. In the enterprise data centers and Internet Data Centers

(IDC), service provider’s offer racks and networks only, and the remaining devices have to be

prepared by users themselves, including servers, firewalls, software, storage devices etc. While

a complex task for the end user, he does have a clear overview of the architecture and the

system, thus placing the design of data security under his control. Some users use physical

isolation (such as iron cages) to protect their servers.

29

A comparable analogy to data security in a Cloud is in financial institutions whereas

customer deposits his cash bills into an account with a bank and thus no longer has a physical

asset in his possession. He will rely on the technology and financial integrity of the bank to

protect his now virtual asset. Similarly we’ll expect to see a progression in the acceptance of

placing data in physical locations out of our reach but with a trusted provider.

To establish that trust with the end users of Cloud, the architects of Cloud computing

solutions do indeed designed rationally to protect data security among end users, and between

end users and service providers.

4.4 CLOUD COMPUTING MODEL APPLICATION METHODOLOGY

Cloud computing is a new model for providing business and IT services. The service

delivery model is based on future development consideration while meeting current

development requirements. The three levels of cloud computing service (IaaS,PaaS and SaaS)

cover a huge range of services. Besides computing and the service delivery model of storage

infrastructure, various models such as data, software application, programming model etc. can

also be applicable to cloud computing. [12] More importantly, the cloud computing model

involves all aspects of enterprise transformation in its evolution, so technology architecture is

only a part of it, and multi-aspect development such as organization, processes and different

business

models should also be under consideration. Based on standard architecture methodology with

best practices of cloud computing, a Cloud Model Application Methodology can be used to

guide industry customer analysis and solve potential problems and risks emerged during the

evolution from current computing model to cloud computing model. This methodology can

also be used to instruct the investment and decision making analysis of cloud computing

model, determine the process, standard, interface and public service of IT assets deployment

and management to promote business development. The diagram below shows the overall

status of this methodology.

30

4.5 CLOUD COMPUTING STRATEGY PLANNING PHASE

Cloud strategy contains two steps to ensure a comprehensive analysis for the strategy

problems that customers might face when applying cloud computing mode. Based on Cloud

Computing Value Analysis, these two steps will analyze the model condition needed to achieve

customers’ target, and then will establish a strategy to function as the guideline.

Figure 4.1 Cloud Computing Methodology Overview

4.5.1 Cloud Computing Value Proposition

The target of this step is to analyze the specific business value and possible

combination point between cloud computing mode and specific users by leveraging the

analysis of cloud computing user’s requirement model and considering the best practices of

cloud computing industry. [9] Analyze the key factors that might influence customers to apply

cloud computing mode and make suggestion son the best customer application methods. In this

analysis, we need to identify the main target for customer to apply cloud computing mode, and

the key problems they wish to solve.

31

4.5.2 Cloud Computing Strategy Planning

This step is the most important part of strategy phase. Strategy establishments based on

the analysis result of the value step, and aims to establish the strategy documentation according

to the good understanding of various conditions that customers might face when applying

cloud computing mode to plan for future vision and perspective. Professional analysis made by

the method above typically involves broad customer business model research, organization

structure analysis and operation process identification; also, there are someone-functional

requirement and limitation in the plan, such as the concern for security standard, reliability

requirement and rules and regulations.

4.6 CLOUD COMPUTING TACTICS PLANNING PHASE

At the phase of cloud planning, it is necessary to make a detailed investigation on

customer position and to analyze the problems and risks in cloud application both at present

and in the future. After that, concrete approaches and plans can be drawn tonsure that

customers can use cloud computing successfully to reach their business goals. This phase

includes some practicable planning steps in multiple orders listed as follows,

4.6.1 Business Architecture Development

While capturing the organizational structures of enterprises, the business models also

get the information on business process support. As various business processes and relative

networks in enterprise architecture are being set down one after another, gains and losses

brought by relative paths in the business development process will also come into people’s

understanding. We categorize these to business interests and possible risks brought by cloud

computing application from a business perspective.

32

4.6.2ITArchitecture Development

It is necessary to identify the major applications needed to support enterprises business

processes and the key technologies needed to support enterprise applications and data systems.

Besides, cloud computing maturity models should be introduced and the analysis of

technological reference models should be made, so as to provide help, advices and strategy

guide for the design and realization of cloud computing mode in the enterprise architecture.

4.6.3 Requirements on Quality of Service Development

Compared with other computing modes, the most distinguishing feature of cloud

computing model is that the requirements on quality of service (also called non-functional

needs) should be rigorously defined beforehand, for example, the performance, reliability,

security, disaster recovery, etc. This requirement is a key factor in deciding whether a cloud

computing mode application is success furor not and whether the business goal is reached; it is

also an important standard in measuring the quality of cloud computing service or the

competence in establishing a cloud computing center.

4.6.4 Transformation Plan Development

It is necessary to formulate all kinds of plans needed in the transformation from current

business systems to the cloud computing modes, including the general steps, scheduling,

quality guarantee, etc. Usually, an infrastructure service cloud cover different items such as

infrastructure consolidation plan report, operation and maintenance management system plan,

management process plan, application system transformation plan, etc.

33

4.7 CLOUD COMPUTING DEPLOYMENT PHASE

The deployment phase focuses mainly on the programming of both strategy realization

phase and the planning phases. Two steps are emphasized in this phase:

4.7.1 Cloud Computing Provider or Enabler Chosen

According to the past analysis and programming, customers may have to chooses cloud

computing provider or an enabler. It is most important to know that the requirement on service

level agreement (SLA) is still a deciding factor for providers in winning a project.

4.7.2 Maintenance and Technical Service

As for maintenance and technical service, different levels of standards are adopted;

these standards are defined by the requirement on quality of services made beforehand. Cloud

computing providers or builders have to ensure the quality of services, for example, the

security of customers in service operation and the reliability of services.

4.8 CLOUD COMPUTING FOR SOFTWARE PARKS

The traditional manufacturing industry has helped to maintain economic growth in

previous generations, but it has also brought along a host of problems such as labor market

deterioration, huge consumption of energy resources, environmental pollution, and ever-more

drive towards lower cost. As an emerging economy begins its social transformation, software

outsourcing has gained an edge compared with traditional manufacturing industry: on one

hand, it can attract and develop top-level talent to enhance the technical level and competitive

power of a nation; on the other hand, it can also prompt the smooth structural transformation to

a sustainable and green service industry, thereby ensuring continuous prosperity and endurance

even in difficult times.

34

As such, software outsourcing has become a main business line for many emerging

economies to ramp up their service economy, based on economies of scale and affordable

costs. To reach this goal, software firms in these emerging economies need to conform their

products and services to international standards and absorb experiences from developed

nations to enhance the quality of their outsourcing services.

Figure 4.2 Cloud Computing Platform And Software Outsourcing Ecosystems

That is to say, thanks to its brand effect, the platform developed by the software demonstration

plot is up to international advanced level, and could thereby enhance the service level of

software outsourcing in the entire park. The final aim is to measure up to international

standards and to meet the needs of international and Chinese enterprises. Meanwhile, a

platform of unified standard can lower IT maintenance costs and raise the response speed for

requirements, making possible the sustainable development of the Software Park. Lastly, the

management and development platform of cloud computing can directly support all kinds of

applications and provide enterprise users with various services including outsourcing and

commercial services as well as services related to academic and scientific researches.

4.9 AN IDC CLOUD

An IDC in Europe serves industry customers in four neighboring countries, which

covers sports, government, finance, automobile and the healthcare. This IDC attaches great

importance to cloud computing technology in the hope of establishing a data center that is

flexible, demand-driven and responsive. It has decided to work with cloud computing

35

technology to establish several cross-Europe cloud centers. The first five data centers are

connected by virtual SAN and the latest MPLS technology. Moreover, the center complies

with the ISO27001 security standard, and other security functions that are needed by the banks

and government organizations, including auditing function provided by certified partners, are

also realized.

Figure 4.3 IDC cloud

The IDC uses the main Data Center to serve customers in its sister sites. The new cloud

computing center will enable this IDC to pay for fixed or usage-based changeable services

according to credit card bill. In the future, the management scope of this hosting center

expands to even more data centers in Europe.

4.10 The Cloud Computing in 3G

Ever since 3G services are launched by the major communication operators, the simple

voice and information service can no longer meet the growing requirements of users. The 3G

data services have become the focus of competition among operators. Many operators have

introduced some specialized services. And with the growth of3G clients and the expansion and

improvement of 3G networks, operators have to provide more diversified 3G services to

36

survive in the fierce market competition. Cloud can be used as a platform to provide such value

added services.

In this 3G era, mobile TV, mobile securities and data backup will all be come critical

businesses. Huge amounts of videos, images, and documents are to be stored in data centers so

that users can download and view them at any time, and they can promote interaction. Cloud

computing can effectively support this kind of business requirements, and get maximal storage

with limited resources. Besides, it can also search and provide the resources that are needed to

users promptly to meet their needs.

After the restructuring of operators, the businesses of leading service providers will all

cover fixed network and mobile service, and they may have to face up to fierce competition in

3G market. Cloud computing can support unified monitoring and dynamic deployment of

resources. So, during the business consolidation of the operators, the cloud computing platform

can deploy necessary resources in time to support business development, and respond quickly

to market requirements to help operators to gain larger market share.

The 3G-enabled high bandwidth makes it easier and quicker to surf Internet through

mobile phones and it has become a critical application of 3G technologies. Cloud computing

makes it compatible among different equipment, software and networks, so that the customers

can access the resources in the cloud through any kinds of clients.

37

CHAPTER 5

LDR & TEMPERATURE SENSORS

5.1 INTRODUCTION

A light dependent resistor also known as a LDR, photo resistor, photo conductor or

photocell, is a resistor whose resistance increases or decreases depending on the amount of

light intensity. LDRs (Light Dependent Resistors) are a very useful tool in a light/dark circuits.

LDRs can have a variety of resistance and functions. For example it can be used to turn on a

light when the LDR is in darkness or to turn a light when the LDR is in light. It can also work

the other way around so when the LDR is in light it turns on the circuit and when it’s in

darkness the resistance increase and disrupts the circuit.

Light-dependent resistances (LDR) are cheap light sensors. A less known light detector

is the electrets microphone, whose electrets membrane functions as a perfect absorber, but only

detects pulsed light. The aim of this study was to analyze the use of a LDR and an electrets

microphone as a light sensor [8] in an optical spectroscopy system using pulsed light. A photo

acoustic spectroscopy setup was used, substituting the photo acoustic chamber by the light

sensor proposed. The absorption spectra of two different liquids were analyzed. The results

obtained allow the recommendation of the LDR as the first choice in the construction of cheap

homemade pulsed light spectroscopy systems.

The light dependent resistor (LDR) is a sensor whose resistance decreases when light

impinges on it. This kind of sensor is commonly used in light sensor circuits in open areas, to

control street lamps for example. Another possible use is in spectroscopic apparatus. In this

kind of apparatus, continuous light or pulsed light can be used. Continuous light is used in

common spectroscopic apparatus. The use of lock-in amplifiers made the use of pulsed light in

spectroscopy easier, as is commonly used in photo acoustic spectroscopy. LDR’s are made of

semiconductors as light sensitive materials, on an isolating base. The most common

semiconductors used in this system are cadmium supplied, lead supplied, germanium, silicon

38

and gallium arsenide. A less known light sensor is the electrets microphone. As the electrets

membrane functions as an absorbing black body, and as the electrets microphone case has an

air chamber that can be used as photo acoustic chamber, the electrets microphone can be used

as a detector of pulsed light. This type of microphone can be used to obtain the transmission

spectrum of any transparent material. The aim of this communication is to study the response

of LDR to pulsed light and the analysis of the spectral curves obtained with a LDR and an

electrets microphone as light sensors in an optical spectroscopy device.

Figure 5.1 Light Dependent Resistance sensors (LDR)

39

5.2 HOW IT WORKS

The way an LDR works is that they are made of many semi-conductive materials with

high resistance.[6] The reason they have a high resistance is that are very few electrons that are

free and able to move because they are held in a crystal lattice and are unable to move. When

light falls on the semi conductive material it absorbs the light photons and the energy is

transferred to the electrons, which allow them to break free from the crystal lattice and conduct

electricity and lower the resistance of the LDR.

5.3 SENSITIVITY

The sensitivity of a photo detector is the relationship between the light falling on the

device and the resulting output signal. In the case of a photocell, one is dealing with the

relationship between the incident light and the corresponding resistance of the cell.

Figure 5.2 Resistances as Function of Illumination

5.4 SPECTRAL RESPONSE

Like the human eye, the relative sensitivity of a photoconductive cell is dependent on

the wavelength (color) of the incident light. Each photoconductor material type has its own

unique spectral response curve or plot of the relative response of the photocell versus

wavelength of light.

40

Figure 5.3 Spectral Response

5.5 EXPERIMENTAL SECTION

To study the response of the LDR to luminous stimulus, it was used a voltage divider

circuit, composed by a 4.7 kΩ resistance, a LDR and a 9 V battery. The voltage was measured

on the LDR using a multi meter or a lock-in amplifier.

First the response of the LDR to continuous light was studied. This was done using a

He-Ne laser as light source (UNIPHASE, mod. 1201-1) emitting at 633 nm with mean power

output of 1.9 mW. To control the light power, two linear polarizer’s were used, crossing their

polarizing axis at a fixed angle that permits the light power to be changed following the Mauls’

law. Here the light power was decreased and measured with a power meter (MELLES GRIOT,

mod. 13 PEM 001). The curve of the voltage as function of light power was constructed, and

analyzed using the software Microcell Origin.

After the continuous light analysis, a pulsed light analysis was done. Here the same

light source was used. The laser power was constant (1.9 mW) and a mechanical chopper

(STANFORDRESEARCH SYSTEMS Mod. SRS540) was used to pulse the light beam. A two

phase lock-in amplifier (Stanford Research Systems Mod. SR530) was used to measure the

amplitude and phase of the LDR voltage.

41

Absorption spectra were obtained using a home-built photo acoustic spectrometer

setup. A light beam supplied by a 1000 W Xenon lamp (model 66071, Oriel) was modulated at

17 Hz by a mechanical chopper (model 197, EG&G) and passed through a monochromatic

(model 77250, Oriel). Then the monochromatic beam was focused into the LDR or a

commercial electrets microphone using mirrors and lenses.

The electret microphone permits to obtain transmission spectra because it functions as a

Photo acoustic chamber. In this case the chamber is the frontal air gap of a cylindrical electrets

micro phone, and the sample is always mounted directly on top of it. The front sound-inlet of

the electrets microphone is a 3 mm diameter hole; the front air chamber adjacent to the

metalized face of the electrets diaphragm has a diameter of 7 mm and is roughly 1 mm high.

5.6 TEMPERATURE SENSORS

5.6.1 General Description

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

1⁄4°C at room temperature and ±3⁄4°C over a full −55 to +150°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. As

it draws only 60 μA from its supply, it has very low self-heating, less than 0.1°C in still air.

The LM35 is rated to operate over a −55° to +150°C temperature range, while the LM35C is

rated for a −40° to +110°C range (−10° with improved accuracy). The LM35 series is available

packaged in hermetic TO-46 transistor packages, while the LM35C, LM35CA, and LM35D

are also available in the plastic TO-92 transistor package. The LM35D is also available in an 8-

lead surface mount small outline package and a plastic TO-220 package.

42

Figure 5.4 Basic Centigrade Temperature Sensor

The LM35 can be applied easily in the same way as other integrated-circuit temperature

sensors. It can be glued or cemented to a surface and its temperature will be within about

0.01°C of the surface temperature.[7] This presumes that the ambient air temperature is almost

the

same as the surface temperature; if the air temperature were much higher or lower than the

surface temperature, the actual temperature of the LM35 die would be at an intermediate

temperature between the surface temperature and the air temperature. This is expecially true

for the TO-92 plastic package, where the copper leads are the principal thermal path to carry

heat into the device, so its temperature might be closer to the air temperature than to the

surface temperature. To minimize this problem, be sure that the wiring to the LM35, as it

leaves the device, is held at the same temperature as the surface of interest.

The easiest way to do this is to cover up these wires with a bead of epoxy which will insure

that the leads and wires are all at the same temperature as the surface, and that the LM35 die’s

temperature will not be affected by the air temperature. The TO-46 metal package can also be

soldered to a metal surface or pipe without damage. Of course, in that case the V− terminal of

the circuit will be grounded to that metal. Alternatively, the LM35 can be mounted inside a

sealed-end metal tube, and can then be dipped into a bath or screwed into a threaded hole in a

tank. As with any IC, the LM35 and accompanying wiring and circuits must be kept insulated

and dry, to avoid leakage and corrosion. This is especially true if the circuit may operate at

cold temperatures where condensation can occur. Printed-circuit coatings and varnishes such as

Hum seal and epoxy paints or dips are often used to insure that moisture cannot corrode the

43

LM35 or its connections. These devices are sometimes soldered to a small light-weight heat

fin, to decrease the thermal time constant and speed up the response in slowly-moving air. On

the other hand, a small thermal mass may be added to the sensor, to give the steadiest reading

despite small deviations in the air temperature.

The PCF8591 is a single-chip, single-supply low-power 8-bit CMOS data acquisition

device with four analog inputs, one analog output and a serial I2C-bus interface. Three address

pins A0, A1 and A2 are used for programming the hardware address, allowing the use of up to

eight devices connected to the I2C-bus without additional hardware. Address, control and data

to and from the device are transferred serially via the two-line bidirectional I2C-bus.

The functions of the device include analog input multiplexing, on-chip track and hold

function, 8-bit analog-to-digital conversion and an 8-bit digital-to-analog conversion. The

maximum conversion rate is given by the maximum speed of the I2C-bus.

5.6.2 Block diagram

Figure 5.5 Block diagram of PCF8591

44

5.7 Functional description

5.7.1 Addressing

` Each PCF8591 device in an I2C-bus system is activated by sending a valid address to

the device. The address consists of a fixed part and a programmable part. The programmable

part must be set according to the address pins A0, A1 and A2. The address is always sent as the

first byte after the start condition in the I2C-bus protocol.

5.7.2 Control byte

The second byte sent to a PCF8591 device is stored in its control register and is

required to control the device function. The upper nibble of the control register is used for

enabling the analog output, and for programming the analog inputs as single-ended or

differential inputs. The lower nibble selects one of the analog input channels defined by the

upper nibble. If the auto-increment flag is set, the channel number is incremented

automatically after each A/D conversion. If the auto-increment mode is desired in applications

where the internal oscillator is used, the analog output enable flag must be set in the control

byte (bit 6). This allows the internal oscillator to run continuously, by this means preventing

conversion errors resulting from oscillator start-up delay. The analog output enable flag can be

reset at other times to reduce quiescent power consumption.

The selection of a non-existing input channel results in the highest available channel

number being allocated. Therefore, if the auto-increment flag is set, the next selected channel

is always channel 0. The most significant bits of both nibbles are reserved for possible future

functions and must be set to logic 0. After a Power-On Reset (POR) condition, all bits of the

control register are reset to logic 0. The D/A converter and the oscillator are disabled for power

saving. The analog output is switched to a high-impedance state.

5.7.3 D/A conversion

The third byte sent to a PCF8591 device is stored in the DAC data register and is

inverted to the corresponding analog voltage using the on-chip D/A converter. This D/A

45

converter consists of a resistor divider chain connected to the external reference voltage with

56 taps and selection switches. The tap-decoder switches one of these taps to the DAC output

line.

The analog output voltage is buffered by an auto-zeroed unity gain amplifier. Setting the

analog output enable flag of the control register switches this buffer amp on or off. In the

active state, the output voltage is held until a further data byte is sent. The on-chip D/A

converter is also used for successive approximation A/D conversion. In order to release the

DAC for an A/D conversion cycle the unity gain amplifier is equipped with a track and hold

circuit. This circuit holds the output voltage while executing the A/D conversion.

Figure 5.6 D/A conversion sequence

5.7.4 A/D conversion

The A/D converter uses the successive approximation conversion technique. The on-

hip D/A converter and a high-gain comparator are used temporarily during an A/D conversion

cycle. An A/D conversion cycle is always started after sending a valid read mode address to a

PCF8591 device. The A/D conversion cycle is triggered at the trailing edge of the

acknowledge clock pulse and is executed while transmitting the result of the previous

conversion. Once a conversion cycle is triggered, an input voltage sample of the selected

channel is stored on the chip and is converted to the corresponding 8-bit binary code. Samples

picked up from differential inputs are converted to an 8-bit two's complement code.

46

Figure 5.7 A/D conversion sequence

The conversion result is stored in the ADC data register and awaits transmission. If the auto-

increment flag is set, the next channel is selected. The first byte transmitted in a read cycle

contains the conversion result code of the previous read cycle. After a POR condition, the first

byte read is 80h.The maximum A/D conversion rate is given by the actual speed of the I2C-

bus.

5.8 Characteristics of the I2C bus

The I2C-bus is for bidirectional, two-line communication between different ICs or

modules. The two lines are a Serial Data line (SDA) and a Serial Clock line (SCL). Both lines

must be connected to a positive supply via a pull-up resistor. Data transfer may be initiated

only when the bus is not busy.

5.8.1 Bit transfer

One data bit is transferred during each clock pulse. The data on the SDA line must

remain stable during the HIGH period of the clock pulse, as changes in the data line at this

time are interpreted as a control signal.

47

5.8.2 START and STOP conditions

Both data and clock lines remain HIGH when the bus is not busy.

A HIGH-to-LOW transition of the data line while the clock is HIGH is defined as the START

condition.

A LOW-to-HIGH transition of the data line while the clock is HIGH is defined as the STOP

condition.

Figure 5.8 Definition of START and STOP conditions

5.8.3 System configuration

A device generating a message is a transmitter; a device receiving a message is a

receiver. The device that controls the message is the master; and the devices which are

controlled by the master are the slaves.

Figure 5.9 System configuration

48

CHAPTER 6

CONCLUSION AND FUTURE SCOPE

6.1 CONCLUSION

Thus the proposed system is described that integrates new technologies offering ease of

maintenance and energy savings and it is appropriate for street lighting[10] in remote as well

as urban areas where traffic is low at times. Wireless Sensor networks may present a new

solution to bring the installed cost down and to ensure energy efficiency. Over the past 10years

many new RF solutions have been developed into our every-day life. Smart Street lighting

application presented in this article describes a full system solution to efficiently manage a

public street lighting network. It quickly allows to build up own system thanks to provided HW

and SW materials.

In Smart Street lighting system,[5] the concept of efficiency involves many important

aspects such as energy savings, flexibility on network configuration and management, the

remote network maintenance together with a continuous monitoring of network conditions and status. The system solution is intrinsically scalable, so it can be immediately enlarged to whatever territorial extensions, the latter ones limited solely by the requirements and needs set by the public administrations. The functional characteristics of each network node and the proprietary implemented data protocol extend the applications copes, going beyond the management of a street lighting network. In fact, the PLM node acts like an electronic bridge towards the energy distribution grid and, on the other side; it can be connected with any electronic board, provided with aRS232 port and able to execute basic firmware code allowing user data exchange. Through this bridge, different kind of user information can be transmitted and received allowing to drive and to monitor smart pole for each ambient conditions. The solution described above can be rightly referred as smart pole concept and it naturally find a placing as basic

49

element in the more and more present smart-grid solutions, the latest one constituting the foundation towards the realization of smart cities experimentation.

6.2 FUTURE SCOPE

Once this Intelligent System is implemented, we could directly go for Wireless Power

Transmission which would further reduce the maintenance costs and power thefts of the

system, as cable breaking is one of the problems faced today. In addition to this, controlling the

Traffic Signal lights is another feature that we could look into after successful implementation

of our system. Depending on the amount of traffic in a particular direction, necessary

controlling actions could be taken. Also emergency vehicles and VIP convoys can be passed

efficiently. Moreover, attempts can be made to ensure that the complete system is self-

sufficient on nonconventional energy resources like solar power, windmills, Piezo-electric

crystals, etc. We hope that these advancements can make this system completely robust and

totally reliable in all aspects.

50

APPENDIX

#include <stdio.h>

#include <string.h>

#include <errno.h>

#include <wiringPi.h>

#include <stdlib.h>

#include <unistd.h>

#include <pcf8591.h>

#define LED 0

void file_write(char *File_path,char *file_txt)

{

FILE *p=NULL;

p=fopen(File_path,"w");

fwrite(file_txt,strlen(file_txt),1,p);

fclose(p);

}

main ()

{

char array[10],array1[10];

wiringPiSetup () ;

pcf8591Setup (200, 0x48) ;

pinMode (LED, OUTPUT) ;

for (;;)

{

printf ("%4d %4d \n", analogRead (200), analogRead (201)) ;

if(analogRead(200)>30)

{

51

digitalWrite (LED, HIGH) ; // On

}

else

{

digitalWrite (LED, LOW) ; // Off

}

sprintf(array,"%2d", analogRead(200));

file_write("/var/www/temp.txt",array);

sprintf(array1,"%2d", analogRead(202));

file_write("/var/www/ldr.txt",array1);

}

return 0;

}

#! /bin/sh

### BEGIN INIT INFO

# Provides: sensor.sh

# Required-Start: $remote_fs $syslog

# Required-Stop: $remote_fs $syslog

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: sensor.sh initscript

# Description: This file should be used to construct scripts to be

# placed in /etc/init.d.

### END INIT INFO

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script

PATH=/sbin:/usr/sbin:/bin:/usr/bin

NAME=sensor

DAEMON=/usr/sbin/$NAME

52

DAEMON_ARGS="-config=/home/pi/project/sensor"

PIDFILE=/var/run/$NAME.pid

SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed

[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present

[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables

. /lib/init/vars.sh

# Define LSB log_* functions.

# Depend on lsb-base (>= 3.2-14) to ensure that this file is present

# and status_of_proc is working.

. /lib/lsb/init-functions

#

# Function that starts the daemon/service

#

do_start()

{

# Return

# 0 if daemon has been started

# 1 if daemon was already running

# 2 if daemon could not be started

echo "Sensor Reading starting"

start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \

|| return 1

start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --make-pidfile

-- \

$DAEMON_ARGS \

|| return 2

echo "Start Sensor Program"

# Add code here, if necessary, that waits for the process to be ready

53

# to handle requests from services started subsequently which depend

# on this one. As a last resort, sleep for some time.

}

#

# Function that stops the daemon/service

#

do_stop()

{

# Return

# 0 if daemon has been stopped

# 1 if daemon was already stopped

# 2 if daemon could not be stopped

# other if a failure occurred

start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name

$NAME

RETVAL="$?"

[ "$RETVAL" = 2 ] && return 2

# Wait for children to finish too if this is a daemon that forks

# and if the daemon is only ever run from this initscript.

# If the above conditions are not satisfied then add some other code

# that waits for the process to drop all resources that could be

# needed by services started subsequently. A last resort is to

# sleep for some time.

start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON

[ "$?" = 2 ] && return 2

echo "Stopped Vehicle Program"

# Many daemons don't delete their pidfiles when they exit.

rm -f $PIDFILE

return "$RETVAL"

}

case "$1" in

54

start)

[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"

echo "started"

do_start

case "$?" in

0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;

2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;

Esac

;;

stop)

[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"

do_stop

case "$?" in

0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;

2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;

esac

;;

*)

echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2

exit 3

;;

esac

55

REFERANCE

[1] Caponetto, R., Dongola, G., Fortuna, L., Riscica, N. and Zufacchi, D. (2008), “Power

consumption reduction in a remote controlled street lighting system”, International Symposium

on Power Electronics, Electrical Drives, Automation and Motion (SPEEDAM 2008), Ischia,

11-13 June, pp. 428-33.

[2] Chen, P.-Y., Liu, Y.-H., Yau, Y.-T. and Lee, H.-C. (2008), “Development of an energy

efficient streetlight driving system”, IEEE International Conference on Sustainable Energy

Technologies(ICSET 2008), Singapore, 24-27 November, pp. 761-4.

[3] Cho, S. and Dhingra, V. (2008), “Street lighting control based on Lon Works power line

communication”, IEEE International Symposium on Power Line Communications and Its

Applications (ISPLC 2008), Jeju City, 2-4 April, pp. 396-8.

[4] Chung, H.S.H., Ho, N.M., Hui, S.Y.R. and Mai, W.Z. (2005), “Case study of a highly-

reliable dimmable road lighting system with intelligent remote control”, paper presented at

European Conference on Power Electronics and Applications, Dresden.

[5] Costa, M.A.D., Costa, G.H., dos Santos, A.S., Schaech, L. and Pin heiro, J.R. (2009), “A

high efficiency autonomous street lighting system based on solar energy and LEDs”, Brazilian

Power Electronics Conference (COBEP 2009), Bonito, 27 September-1 October, pp. 265-73.

[6] Denardin, G.W., Barriquello, C.H., Campos, A. and do Prado, R.N. (2009a), “An

intelligent system for street lighting monitoring and control”, Brazilian Power Electronics

Conference(COBEP 2009), Bonito, 27 September-1 October, pp. 274-8.

56

[7] Denardin, G.W., Barriquello, C.H., Pinto, R.A., Silva, M.F., Campos, A. and do Prado,

R.N. (2009b),“An intelligent system for street lighting control and measurement”, IEEE

Industry Applications Society Annual Meeting (IAS 2009), Houston, TX, 4-8 October, pp. 1-5.

[8] Iordache, C., Gavat, S., Mada, C., Stanciu, D. and Holban, C. (2008), “Streetlight

monitoring and control system part I: system structure”, IEEE International Conference on

Automation, Quality and Testing, Robotics (AQTR 2008), Cluj-Napoca, 22-25 May,

[9] Lee, J.D., Nam, K.Y., Jeong, S.H., Choi, S.B., Ryoo, H.S. and Kim, D.K. (2006),

“Development of Zigbee based street light control system”, IEEE PES Power Systems

Conference and Exposition (PSCE 2006 ), Atlanta, GA, 29 October-1 November, pp. 2236-40.

[10] Li, L., Chu, X., Wu, Y. and Wu, Q. (2009), “The development of road lighting intelligent

control system based on wireless network control”, International Conference on Electronic

Computer Technology, Macau, 20-22 February, pp. 353-7.

[11] Costa, M.A.D., Costa, G.H., dos Santos, A.S., Schuch, L. and Pin heiro, J.R. (2009), “A

high efficiency autonomous street lighting system based on solar energy and LEDs”, Brazilian

Power Electronics Conference (COBEP 2009), Bonito, 27 September-1 October, pp. 265-73.

[12] Denardin, G.W., Barriquello, C.H., Campos, A. and do Prado, R.N. (2009a), “An

intelligent system for street lighting monitoring and control”, Brazilian Power Electronics

Conference(COBEP 2009), Bonito, 27 September-1 October, pp. 274-8.

[13] Denardin, G.W., Barriquello, C.H., Pinto, R.A., Silva, M.F., Campos, A. and do Prado,

R.N. (2009b),“An intelligent system for street lighting control and measurement”, IEEE

Industry Applications Society Annual Meeting (IAS 2009), Houston, TX, 4-8 October, pp. 1-5.

57

[14]Iordache, C., Gavat, S., Mada, C., Stanciu, D. and Holban, C. (2008), “Streetlight

monitoring and control system part I: system structure”, IEEE International Conference on

Automation, Quality and Testing, Robotics (AQTR 2008), Cluj-Napoca, 22-25 May,

58