The document discusses the Cortex-A11 multicore processor and its components. It describes the processor's architecture including the snoop control unit, accelerator coherence port, generic interrupt controller, advanced bus interface unit, floating point unit, NEON media processing engine, L2 cache controller, program trace macrocell, and memory management unit. The purpose of these components is to provide efficient performance, low power consumption, and scalability for applications such as mobile devices and infotainment systems.

1. 1
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.

2. 2
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.

3. 3
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.

4. 4
 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.

5. 5
Node 1
........
Node2
Figure 1.1 smart street light system using IOT
User PC
Cloud server
Processor
Wi-Fi
module
Light 1
Sensor 1
Light 2
Sensor 2

6. 6
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.

7. 7
2.2 BLOCK DIAGRAM
Figure2.1 Cortex-A11 Multicore Processor

8. 8
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

9. 9
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.

10. 10
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

11. 11
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.

12. 12
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.

13. 13
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.

14. 14
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

15. 15
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.

16. 16
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.

17. 17
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.

18. 18
CHAPTER 3
WI-FI MODULE
3.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

19. 19
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

20. 20
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

21. 21
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.

22. 22
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.

23. 23
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

24. 24
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.

25. 25
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.

26. 26
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

27. 27
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.

28. 28
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.

29. 29
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.

30. 30
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.

31. 31
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.

32. 32
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.

33. 33
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.

34. 34
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.

35. 35
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

36. 36
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

37. 37
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.

38. 38
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

39. 39
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)

40. 40
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.

41. 41
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.

42. 42
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.

43. 43
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

44. 44
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

45. 45
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

46. 46
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.

47. 47
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.

48. 48
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

49. 49
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 element in the more and more present smart-grid solutions, the latest one
constituting the foundation towards the realization of smart cities experimentation.

50. 50
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.

51. 51
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)
{
digitalWrite (LED, HIGH) ; // On
}
else
{

52. 52
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
DAEMON_ARGS="-config=/home/pi/project/sensor"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed

53. 53
[ -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
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
#

54. 54
# 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
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
echo "started"
do_start

55. 55
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

56. 56
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.
[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.

57. 57
[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.
[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,