Low-Power Distributed Vehicle Detection and Contextualisation

University of Southampton Electronics and Computer Science A Group Design Project report submitted for the award of MEng Electronic Engineering

By: Palkesh Nuwal Rohan Koshy Ioana Anastasia Oprescu Silviu Cosmin Chirila-Berbentea Maulik Rameshchandra Patel

Project supervisors: Dr. Geoff Merrett, Dr. Alex Weddell Second examiner: Dr. John Tudor Sponsor: Selex ES

Low-Power Distributed Vehicle Detection and Contextualisation 12th December 2013

1

2

Abstract The aim of this project was to develop and implement an intelligent street lighting system capable of reducing the financial and energy consumption of street lights through intelligent motion detection. The project intended to design, build, develop and test low-cost, lowpower electronic systems consisting of spatially scattered autonomous wireless sensing nodes, which include placing distributed sensors on street lights to enhance their efficiency by adaptively adjusting their brightness levels according to detection of vehicles and pedestrians in their vicinity. The project was sectioned into 6 stages: researching and investigating existing vehicle detection methods, including analysis of their performance and finding room for improvement; gestating the complete system and laying down system specifications and objectives; developing different system units such as sensing, processing, wireless and subsequent testing; building and integrating individual units into a prototype, including its implementation and further construction to realise several prototypes; implementing all prototypes as an intelligent network for system realisation; evaluating system capabilities against set specifications. The project successfully integrated several modules into a working prototype, and 4 such prototypes were realised and tested individually and collectively as a complete wireless sensor network.

3

Table of Contents Abstract ................................................................................................................................... 3 Acknowledgements ................................................................................................................. 7 1.

Introduction ..................................................................................................................... 8 1.1 Background and Motivation ......................................................................................... 8

2.

1.2

Objectives ................................................................................................................. 9

1.3

Report Structure...................................................................................................... 10

Literature Review .......................................................................................................... 11 2.1

Previous Work ........................................................................................................ 11

2.2

Wireless Sensor Node ............................................................................................. 13

2.3

Sensors for Motion Detection ................................................................................. 15

2.3.1

Microwave Radar .......................................................................................... 15

2.3.2

Passive Infrared (PIR) Sensors ...................................................................... 16

2.3.3 Magnetic Sensors ............................................................................................... 17 2.3.4 Passive Acoustic Sensors ................................................................................... 18 2.3.5 Inductive Loops .................................................................................................. 20 2.3.6 3.

System Overview .......................................................................................................... 22 3.1

4.

Video Image Processors ................................................................................ 20 Sensing Unit ......................................................................................................... 23

3.1.1

Microwave Radar .......................................................................................... 23

3.1.2

PIR Sensor ..................................................................................................... 23

3.1.3

Magnetic Sensor ............................................................................................ 23

3.1.4

Passive Acoustic Sensor ................................................................................ 23

3.2

Wireless module ................................................................................................... 23

3.3

Microcontroller Unit ............................................................................................. 24

Design and Test of Sensor Subsystem ........................................................................... 25 4.1

Microwave Radar ................................................................................................... 25

4.1.1 Component ......................................................................................................... 25 4.1.2

Signal Processing for Radar .......................................................................... 27

4.1.3 Microcontroller Interface for Sampling ............................................................. 32 4.1.4 Frequency Spectrum........................................................................................... 35 4.1.5

Controlled Testing ......................................................................................... 37

4.1.6

Outdoor Testing ............................................................................................ 39 4

4.2

Passive Infrared (PIR) Sensor ................................................................................. 42

4.3

Magnetic Sensor ..................................................................................................... 45

4.3.1

Design ................................................................................................................ 45

4.3.2 Testing ................................................................................................................ 46 4.3.3 4.4

Conclusions ........................................................................................................ 51

Passive Acoustic Sensors ....................................................................................... 52

4.4.1

Test Setup ........................................................................................................ 52

4.4.2

Test Results ..................................................................................................... 53

4.4.3 Conclusions .......................................................................................................... 60 4.5

Photoresistor............................................................................................................ 61

4.5.1 Circuit Design ..................................................................................................... 61 4.5.2 Outdoor testing ................................................................................................... 62 5.

Wireless Communication ............................................................................................... 63 5.1 Requirements ............................................................................................................. 63 5.2 Components ............................................................................................................... 64 5.3 Network and routing .................................................................................................. 64 5.4 Serial Communication ............................................................................................... 66 5.5 Implementation .......................................................................................................... 67 5.5.1 XBee Configuration ............................................................................................ 67 5.5.2 Programming the Microcontroller ...................................................................... 68 5.5.3 Network Implementation .................................................................................... 68 5.6

6.

Testing and Debugging ........................................................................................... 70

Algorithm for Intelligent Streetlight System ................................................................. 75 6.1

Constraints............................................................................................................... 75

6.1.1

Sensors ............................................................................................................ 75

6.1.2

Direction Detection ......................................................................................... 75

6.2 Algorithm Design ...................................................................................................... 77 6.3

First Approach.......................................................................................................... 79

6.4

Final Approach .......................................................................................................... 82

6.5

Timers...................................................................................................................... 84

6.5.1 Timers Controlling the Brightness ...................................................................... 84 6.5.2 Timers Controlling the Transmission.................................................................. 85 6.5.3 Receiving form Parallel Unit .............................................................................. 86 6.6

Implementation ......................................................................................................... 87

6.6.1 Initialization and Header Files ............................................................................ 87 5

6.6.2 Algorithm Logic ................................................................................................. 88 6.6.3 Initial Algorithm ................................................................................................. 91 6.6.4 ADC for the Magnetic Sensor ............................................................................ 91 6.6.5 Integrating the Wireless Module ........................................................................ 92 6.6.6 Integration the Microwave Sensor ..................................................................... 92 6.7 Algorithm Deployment Testing ................................................................................. 92 6.7.1 Calibration .......................................................................................................... 93 6.7.2 Received Information from Adjacent Node ....................................................... 93 6.7.3 Received Information from Parallel Node ......................................................... 95 6.7.4 No Received Information ................................................................................... 97 6.7.5 Challenges .......................................................................................................... 99 7.

Prototype planning and construction ........................................................................... 100 7.1

Design ................................................................................................................... 101

7.2

Construction ......................................................................................................... 102

8.

Testing and Evaluation ................................................................................................ 105 8.1

Controlled Testing .................................................................................................. 105

8.2. Outdoor Testing ...................................................................................................... 110 8.3. Power Consumption ............................................................................................... 112 9.

Conclusions ................................................................................................................. 114 9.1

10.

Future work .......................................................................................................... 115 Project Management................................................................................................... 116

10.1

General Management ........................................................................................... 116

10.2 Time Management ................................................................................................. 118 11. References ..................................................................................................................... 121 12. Appendices ................................................................................................................. 126 Appendix 1: Costs breakdown ........................................................................................ 126 Appendix 2: Final Code For the System Algorithm at one unit (C) ............................... 128 Appendix 3: ADC Code for sampling the magnetic sensor ............................................ 146 Appendix 4. Risk assessment form ................................................................................. 147

6

Acknowledgements We would like to thank our supervisors, Dr. Geoff Merrett and Dr. Alex Weddell for their constant support and guidance throughout the entire project. We would also like to thank Tara Kitson, Jevan Bryant and Robert Cook, engineers at Selex ES, for taking the time to come and watch our seminar presentations as well as for suggestions on how to improve the system and Selex ES, our sponsor, for providing the necessary funds to buy all the required components. Finally, we would like to thank Jeff Hooker, David Oakley, David Kemmish, Barry Bailey and other technicians from Zepler Stores for providing certain consumables and components for the project.

7

Chapter 1 1. Introduction

1.1 Background and Motivation Street lights are an integral part of the world today as they light up roads and pathways during night hours [1, 2]. They facilitate transportation during darkness, and encourage various social and economic activities by allowing people to go out during night and increasing business hours. Additionally, they play an important role in averting crime, increasing public safety and lowering the number of accidents during darkness. They have been found to curtail pedestrian accidents by nearly 50% [3, 4]. Furthermore, towns and cities around the world hang banners and adverts in the area illuminated by lampposts [5].

In spite of all these benefits offered by street lights, their continuous operation requires huge amounts of electricity, which places a momentous stress on the finite amount of financial and energy resources. For instance, studies in Norway demonstrated that the daily costs of outdoor lighting consumes nearly 20-40% of the total energy budget [6]. In USA, an approximated 60 million lampposts in 2001 exhausted 31 TWh of electricity and 6.5 million tonnes of CO2.

Considering these environmental and economic burdens, numerous efforts have been made to diminish the energy consumption of street lights. As a result, intelligent vehicle detection systems have recently been gaining appreciation and recognition as they are capable of reasonably reducing the financial and energy consumption of the street lights. For example, Transport for London has just started implementing London’s largest energy efficiency lighting programme [7]. It aims to reduce CO2 associated with street lighting by almost 9,700 tonnes per year, and reduce energy consumption by 40% through substituting nearly 35,000 street lights with LEDs by 2016. Additionally, savings of approximately £1.85 million a year by 2016 are also promised.

In ordinary street lighting schemes, the lampposts are turned on at full brightness during functional hours. They are generally activated by an integrated light sensor, which turns them on when there is a lack of natural light [1]. Such schemes are prone to wasting vast quantities of energy as the lampposts are continually turned on, regardless of the presence of vehicles or pedestrians. Furthermore, complete illumination is not essential during night hours when traffic flow is low. Consequently, part night lighting strategies have been developed to reduce the financial and carbon footprint of conventional street lights. These schemes usually dim the street lights (or switch them off) at particular geographic locations and times. For instance, products like Philips Chronosense can provide flexible independent dimming control for outdoor street lighting [8]. It works with a wide variety of luminaries, and has been demonstrated to attain energy savings of above 35%.

8

Another product from Philips, Dynadimmer, maximizes energy savings by up to 50% by configuring different levels of brightness at different times [9, 10]. For example, 5 different brightness levels can be achieved at different times (depending upon the traffic flow) with the aid of Dynadimmer, as illustrated in Figure 1.1.

Figure 1.1: Different brightness levels achieved by using Dynadimmer, sourced from [10] Despite the reductions in costs and carbon discharge, these part night lighting strategies fail to fully accomplish the purpose of street lights when their brightness is decreased according to time. For instance, Dynadimmer dims the brightness levels of lampposts to 40% between 23:00 and 5:00 (Figure 1.1) which may critically hinder the ability of vehicles or pedestrians to avoid obstacles during those hours. Additionally, dimming lampposts at certain geographic locations is not always helpful as accidents or crimes may occur anywhere. Due to this unpredictability, embedding adaptive intelligence into outdoor street lighting presents favourable circumstances for accomplishing all the anticipated benefits of street lights, while sensibly reducing the associated financial and environmental burdens at the same time. Spatially scattered autonomous wireless sensing nodes provide sensing, processing and communication capabilities, which makes them the quintessential choice for smart vehicle detection.

1.2

Objectives

The project deals with developing an intelligent system for vehicle detection. The primary objective is to design, build, develop, and test low-cost, low-power distributed electronic prototypes i.e. wireless sensor nodes for detecting vehicles and pedestrians. Furthermore, the system should be able to gather speed information for both vehicles as well as pedestrians. Determining their direction and classifying different vehicle types were optional objectives.

The team decided on building 6 prototypes of these wireless sensor nodes. Each node should be strapped to an individual lamppost, and be capable of adaptively adjusting the brightness levels of the lampposts, depending upon the proximity of nearby vehicles or pedestrians. To achieve this, every node should have a sensing unit (for detection), a processing unit (for local data processing), and a wireless unit (for communicating with 9

other nodes). Every node should be powered by a battery. Together, these nodes should form a Wireless Sensor Network (WSN) capable of detecting vehicles/pedestrians, retrieving relevant information such as presence, speed etc., and reducing the financial and energy expenditure on street lights with the help of adaptive, intelligent sensor nodes.

1.3

Report Structure

The report is structured into different chapters to organise the information. Chapter 2 provides an overview of the background information relevant to the system. Chapter 3 sketches a high level overview of the intelligent vehicle detection system including a brief explanation of different system modules like sensing, processing and wireless. Chapter 4 deals with the design of the sensing system and presents results obtained through testing various sensors. Chapter 5 describes the testing of the wireless module and its implementation as a complete network. Chapter 6 goes through the design, implementation and testing of the algorithm used to give intelligence to the lampposts. Chapter 7 demonstrates the strategies adopted while constructing system prototypes and provides an illustration of a complete prototype. Chapter 8 presents results obtained from system testing and provides an evaluation of the system performance. Conclusions are presented in Chapter 9, along with ideas for further work. Chapter 10 illustrates various rules and practices adopted for successfully managing this project.

10

Chapter 2 2. Literature Review

The following sections give a brief overview of different types of sensors used for vehicle detection. Following that, the reasons for choosing WSNs for vehicle detection are elucidated, along with an explanation of factors influencing the design of WSNs.

2.1

Previous Work

A fair amount of work and research has been done on systems capable of enhancing the efficiency of street lights. Following points highlight a few of these systems.

1. Multi-Sensor system The energy saving control system demonstrated in Figure 2.1 extended the functional time of LED street lights powered via solar radiations by decreasing average energy expenditure by 40% [11]. This reduction was attained by utilising acoustic and Passive Infrared (PIR) sensors for detecting pedestrians and adaptively adjusting the output power and lamp brightness by implementing a lighting control method.

Figure 2.1: Block diagram of multi-sensor system, sourced from [11]

11

2. Intelligent street lighting scheme at TU Delft (July 2011) Tvilight, a Dutch company providing intelligent street lighting solutions partnered with Delft University of Technology (TU Delft) to create adaptive intelligent lighting control solutions like ‘CitySense’ and ‘SkyLite’ which use presence detection to adjust the brightness of street lights [12, 13]. The solutions claim to decrease the energy consumption by 80% and maintenance costs by 50% in comparison with the conventional street lighting system.

3. Smart Street Lighting (SSL) system The pedestrian aware SSL system was implemented by utilising GPS (Global Positioning System) technology and an internet enabled smart phone [14]. Street lights were switched on and off using the received GPS signal as pedestrians walked past them. However, a system dependent on mobile phones gets limited by the available network coverage and battery power. In addition, the privacy of pedestrians gets compromised as their locations can be tracked.

4. Power Saving Mechanism Viraktamath and Attimarad suggested to use SMS (Short Messaging Service) to switch lampposts on and off at demand to reduce power wastage [15]. The block diagram of their proposed system is depicted in Figure 2.2. A SIM (Subscriber Identification Module) is inserted in the GSM receiver at the lamppost to receive the SMS in the text format. The SMS is then processed by the MCU and the lights are switched on/off accordingly.

Figure 2.2: Block diagram of Viraktamath’s and Attimarad’s proposed system, sourced from [15]

12

There may be several problems with this approach if implemented in reality. Users need to write special commands in SMS to make a request to switch street lights on or off, but typo errors can easily occur while writing. In addition, the character limit of 160 for each SMS limits its suitability for different applications [1].

2.2

Wireless Sensor Node The sensing nodes used for vehicle detection typically consist of 4 main units: 1)

Sensing unit As the name suggests, the sensing unit’s primary function is to detect vehicles.

It generally includes more than one type of sensor for detection. It outputs an analogue electric voltage corresponding to variations in its surroundings, which is then passed through an ADC (Analogue-to-Digital Converter) to digitise the information obtained from sensors. There can be separate dedicated ICs (Integrated Circuits) for ADC conversion, or it can also be achieved via the inbuilt ADC converters in the processor. For this project, the ADC conversion was implemented by the processor.

2) Processing unit It includes a MCU (Micro Controller Unit), also referred to as the processor, for processing the sensed data. Depending upon the performance and capabilities of the MCU and the complexity of the algorithm running on it, a diverse array of tasks can be executed by the processing unit. For instance, it conducts and governs the procedures and policies that enable different units in a sensor node to collaborate among themselves [16].

3) Wireless unit It includes a transceiver unit for connecting the node to the WSN. Subsequently, it allows all the nodes in the network to communicate and collaborate with each other.

4) Power unit It is justifiably the most critical unit in a node as it supplies energy to all the other units, and enables the pre-programmed task to be successfully carried out.

These wireless sensor nodes together form a Wireless Sensor Network (WSN) capable of smartly detecting vehicles via adaptive intelligence embedded in the nodes [1]. The design of a WSN may be affected by various factors, some of which are described below.

13

1. Reliability Reliability or fault tolerance reflects the ability to maintain the WSN functionalities regardless of any disruption due to failure of sensor nodes [17].

The level of reliability can be varied by designing smarter algorithms and protocols. The acceptable level of reliability for a sensor network depends upon the nature of the application.

2. Scalability From a few to hundreds to millions in some cases, the number of sensor nodes in a region can vary drastically depending upon the application [16]. As with reliability, the node density also depends upon the application. For instance, in machine diagnosis applications, the density is typically around 300 nodes per 5𝑥𝑥5 m2 region, whereas the node density for vehicle detection applications is typically around 10.

3. Production costs Due to the high density of nodes in WSNs, the cost of a single node plays an important role in substantiating the complete cost of a WSN. A node may also possess additional functionalities such as a location finding unit or a power harvesting unit depending upon the application, thereby increasing its cost [16].

4. Environment Wireless sensor nodes may be deployed in environments as diverse and harsh as the bottom of an ocean to a battlefield to an airplane engine’s nozzle. Therefore, the design of a sensor node and thus the network is heavily influenced by the surroundings in which it is placed.

5. Power Consumption As sensor nodes are often deployed in inaccessible terrains, their lifetime firmly depends on the lifetime of the power unit. In a wireless sensor node, power is consumed for sensing, data processing and wireless communication. Sensing unit requires the least amount of power for its operation compared to the other units.

On the other hand, wireless communication depletes the maximum amount of energy, including both wireless transmission and reception. Inside the transceiver circuitry, electronic components like mixers, VCOs (Voltage Controlled Oscillators), frequency synthesizers, PLLs (Phase Locked Loops) consume valuable power. The total amount of power consumed during communication can 14

be modelled by equation (1)

Pc = NT[PT(Ton + Tst) + Pout(Ton)] + NR[PR(Ron + Rst)]

(1)

where

NT/NR - the number of times the transmitter/receiver is activated per unit time, PT/PR - power consumed by the transmitter/receiver, Ton/Ron – the on time of the transmitter/receiver, Tst/Rst – the startup time of the transmitter/receiver, Pout – the transmitter output power, Pc – total power consumed during radio communication The energy depletion in data processing is much smaller compared to wireless data communication. For instance, assuming 4th power distance loss and Rayleigh fading, the amount of energy required for transmitting 1KB of data to a destination 100m apart is nearly similar to executing 300,000 instructions by a 100,000,000 instructions per second by a processor [16]. Therefore, in a multihop WSN, local data processing at every node helps in reducing the total power consumption.

2.3

Sensors for Motion Detection

The sensing unit is perhaps the most important unit in a vehicle detection system as it regularly monitors its surroundings for input signals generated from the presence of vehicles or pedestrians. Different types of sensors are usually employed for optimal vehicle detection as a moving automobile generates a wide variety of disturbances in its vicinity, particularly acoustic, thermal, magnetic, electrical, seismic, optical, chemical etc. [18].

Sensors can be categorised into active or passive from a signal conditioning point of view.

An active sensor requires a separate electronic circuit to provide a “source of excitation” [19]. The excitation source, which is usually an electrical current or voltage, enables active sensors to perform sensing and produce measurements. On the other hand, passive sensors don’t require any external currents or voltages to produce their output signals [20]. The following sub-sections provide background information on different sensing methods engaged in vehicle detection.

2.3.1

Microwave Radar

Radar is an acronym for Radio Detection and Ranging system, introduced by U.S Navy researchers [21]. It uses electromagnetic waves to detect an object. It can also determine the distance from transceiver, speed, altitude and direction of both stationary and moving objects such as aircrafts, ships, motor vehicles etc. [21]. The radar transmits a radio signal at a fixed frequency. When this signal hits an object, it is reflected back from the object, and a 15

receiver is placed in proximity to the transmitter to detect this reflected signal. The received signal has many characteristics that can be used to determine the distance, speed, direction and altitude. An example of determining the speed of the moving object by radar would be analyzing the frequency of the received signal as the received signal is at a higher frequency than the transmitted signal due to the Doppler shift.

Doppler shift or Doppler effect is “the shift in frequency and wavelength of waves which results from a source moving with respect to medium, a receiver moving with respect to medium, or even a moving medium” [22]. The change in the received frequency is called the Doppler beat frequency or the Doppler frequency. Equation (2) is used for calculating the Doppler frequency where 𝑓𝑓 ′ is the received Doppler frequency, 𝑓𝑓𝑡𝑡 is transmitted frequency, 𝑣𝑣0 is the velocity in the medium, 𝑣𝑣𝑟𝑟 is the velocity of the receiver and 𝑣𝑣𝑠𝑠 is the velocity of the source [22].

𝑓𝑓 ′ = 𝑓𝑓𝑡𝑡 �

𝑣𝑣0 ±𝑣𝑣𝑟𝑟 𝑣𝑣0 ±𝑣𝑣𝑠𝑠

�

(2)

The plus (+) and minus (-) sign can be changed according to the standard convention that if both the receiver and the source are moving towards each other the received frequency (f’) is higher than the transmitted frequency (ft) and vice versa [22]. Equation (2) can be modified to detect the velocity of a vehicle by analyzing the reflected frequency from the object. For a system that is transmitting electromagnetic waves at frequency 𝑓𝑓𝑡𝑡 , the received frequency is 𝑓𝑓𝑟𝑟 , the source is stationary, the object moving at velocity v and Doppler beat frequency is 𝑓𝑓𝑑𝑑 = 𝑓𝑓𝑟𝑟 − 𝑓𝑓𝑡𝑡 . The Doppler beat frequency can be given by (3), as shown in [23], and can be further simplified to equation (4) as shown in [24]. For this project, the velocity of vehicle v ≪ c (speed of light) and therefore equation (4) can be used.

𝑓𝑓𝑑𝑑 = 𝑓𝑓𝑟𝑟 − 𝑓𝑓𝑡𝑡 = 2𝑣𝑣 𝑐𝑐𝑐𝑐𝑐𝑐(𝛼𝛼) 𝑓𝑓

𝑓𝑓𝑑𝑑 = 2𝑣𝑣 ∗ � 𝑡𝑡� 𝑐𝑐

2.3.2

𝑓𝑓𝑡𝑡 𝑐𝑐−𝑣𝑣

(3) (4)

Passive Infrared (PIR) Sensors

The PIR sensor works by detecting infrared radiations emitted from thermal bodies (objects which emit heat) which are in the proximity of the sensor, inside its field of view [25]. The term ‘Passive’ indicates the fact that the sensor does not emit any radiation of its own for detecting objects, instead it operates solely by detecting radiation emitted from surrounding objects. Also, it has been traditionally used for human detection, smart home systems and motion sensing applications [26-28]. The PIR sensor is suitable for motion detection due to its low-power consumption, simplicity in detecting pedestrians and its efficient operation at night. A possible disadvantage of using PIR for motion detection is the fact that it may be 16

wrongly activated due to bad weather conditions.

2.3.3 Magnetic Sensors Magnetic sensors detect disturbances in Earth’s magnetic field generated by the movement of vehicles [29]. AMR (Anisotropic Magneto-Resistive) sensors use incorporated Wheatstone bridges for magnetic detection. The Wheatstone bridge is made of four permalloy thin film resistors (sensitive to magnetic field) aligned as in Figure 1 [30].

When no magnetic field is applied, the Out+ and Out- nodes in Figure 2.3 are at 𝑉𝑉 approximately 2𝑏𝑏 voltage level each, where Vb denotes the bridge voltage, but when a magnetic field is applied in one of the sensitive axis, the voltage across R1 and R4 (as per Figure 2.3) will decrease while the voltage across R2 and R3 will increase [30]. By default, the magnetic field of Earth is present everywhere and is sensed by the magnetic sensor. This creates a voltage difference between Out+ and Out-, which stays constant when only the magnetic field from Earth is sensed. But when another magnetic field is present in the proximity of the sensor, the voltage level changes according to the disturbance created by the nearby object.

Figure 2.3: Wheatstone bridge configuration of an AMR sensor, adapted from [30] The output of an AMR sensor is a differential output given by (5), taken from [30].

Out(+) - Out(-) = S*Vb*Bs

(5)

In (5), S is the sensitivity of the magnetic sensor, Vb is the bridge (supply) voltage and Bs is the magnetic flux applied (in Gauss) [30]. Magnetic sensors can perform reliably in all 17

weather conditions like snow, fog, rain etc. However, they cannot be used for detecting pedestrians

2.3.4 Passive Acoustic Sensors An acoustic sensor picks up acoustic/sound signals from its surroundings by detecting variations in the sound pressure [31]. It performs motion detection by analysing acoustic signals emitted from different sources within a vehicle like its engine, and from interaction of vehicular tires with the road [32]. Microphones are suitable for sensing acoustic information as they offer an acoustic-to-electric interface that transforms sound into an electrical signal. Specifically, condenser microphones are used for vehicle detection applications. Upon detection of a vehicle, the microphone generates an AC output. The output is in mV scale, and requires amplification. Additionally, vehicular acoustic signals are corrupted heavily by environmental noise eg. high winds, which creates the need for filtering to reject signals at unwanted frequencies.

Condenser Acoustic Sensor A condenser microphone is also referred to as a capacitive microphone as it fundamentally functions like a capacitor. Figure 2.4 represents the schematic for a typical condenser microphone.

Figure 2.4: Schematic for a typical condenser microphone, sourced from [31] In Figure 2.4, the label 1 depicts the stretched metallic diaphragm which essentially acts like a capacitor plate [31]. On the other hand, the metal disk, represented by label 2 in Figure 2.4, forms the capacitor’s backplate. Labels 3 and 4 represent the insulator and the case respectively. To initially charge the capacitor’s plates, a steady DC voltage is passed through a high resistance. Following this, the capacitance between the plates changes whenever the diaphragm is excited by a sound field. The varying capacitance produces an AC electric output signal, proportional to the variations in the sound pressure. The acoustic sensor 18

output signal is subsequently obtained by modulating the ultralow frequency AC signal by a high frequency carrier voltage [31].

Panasonic WM-62A microphones illustrated in Figure 2.5 were utilised as condenser acoustic sensors in the MICA mote depicted in Figure 2.6.

Figure 2.5: Panasonic WM-62A condenser microphones, sourced from [31]

Figure 2.6: MICA mote, sourced from [31]

Pickup Pattern Acoustic sensors pick up pattern is 3D in character, and represents the microphone’s response to sound coming from various directions [31]. Microphones can be classified into omnidirectional and unidirectional, based upon their pickup patterns. The first category picks up sound information from all directions, whereas the latter category attenuates the sound from its back and sides. Figures 2.7 and 2.8 illustrate the pickup patterns of omnidirectional and unidirectional microphones respectively.

19

Figure 2.7: Omnidirectional microphone pickup pattern, sourced from [31]

Figure 2.8: Unidirectional microphone pickup pattern, sourced from [31] As demonstrated in Figure 2.8, the pickup pattern moderately reduces pickup from the sides and drastically reduces rear pickup. The unidirectional microphones are more suitable for this project as only single lane detection is required.

2.3.5 Inductive Loops Inductive loops detect vehicles with the assistance of electrical conducting loops buried beneath the pavement. They signal the presence or passage of a vehicle when it passes over the underground electrical wiring. They can determine vehicle count, gap, passage, presence, speed and occupancy [20]. However, they are not suitable for this project because of the underground electrical wiring required for their implementation. Additionally, multiple detectors are usually required for instrumenting an area.

2.3.6

Video Image Processors

They detect vehicles through investigating the imagery from roads and motorways by identifying variations between consecutive frames [29]. They can monitor multiple lanes, and have a wide detection range due to large field of view. However, they require complex 20

image processing algorithms for detection and to overcome effects produced by shadows, changes in brightness, reflections etc. Also, cameras with night vision features are more expensive than other sensors. For these reasons, the team decided not to investigate them further, considering constraints on time and financial budget.

21

Chapter 3 3. System Overview

Figure 3.1 sketches an overview of an individual prototype containing specific blocks.

Figure 3.1: Prototype overview 4 types of sensor blocks displayed in Figure 3.1 are elucidated in Chapter 4, namely Passive Infrared, Microwave Radar, Magnetic and Passive Acoustic Sensors. The Wireless Module is used for effective communication between system prototypes. The MCU (Microcontroller Unit) is used for processing data and making decisions based on data from sensor and wireless modules. The Power Module is used to provide required and regulated voltage to system components.

Following is a list of the particular components which were chosen for the specific system modules presented in Figure 3.1, along with their specifications and the reasons for why they were chosen. Links to individual components datasheets can be found in Appendix 1.

22

3.1

Sensing Unit

3.1.1

Microwave Radar

The microwave radar module from Agile Sense was chosen as it is the only Doppler radar module available at low cost in the market. The module consumes low current (typically 30mA) and has a long detection range of up to 30m for cars and 15m for pedestrians [33].

The operating voltage is between 4.75V and 5.25V and the transmitting frequency is 10.525GHz. The output is an analogue signal with amplitude of 200µVp-p, which requires amplification and filtering.

3.1.2

PIR Sensor

The PIR sensor module from Parallax Inc. was chosen as it is a complete and independent module. It has a better detection range than other similar modules, low price and availability from an approved supplier (RS Components). Its range of operating temperatures is between 0 and 50℃, so it is suitable for most seasons and weather conditions in the UK [25]. The chosen PIR sensor is easy to test and integrate with the system because when detection occurs, the sensor outputs a high voltage (same level as the source voltage), while when there is no object in its field of view, the output is a low signal corresponding to 0V. Hence, it does not require external electronic circuitry for any kind of amplification, filtering or analog to digital conversion before being connected to the processor.

3.1.3

Magnetic Sensor

The magnetic sensor chosen is Honeywell`s HMC1002 2-axis magnetic sensor. It was chosen for a variety of reasons, including high sensitivity (about 3 times higher sensitivity than similar sensors, such as the HMC1022), low dimensions and 2-axis detection, which is a distinct advantage as will be explained in the Section 4.3.2.

3.1.4

Passive Acoustic Sensor

For acoustic sensing, a mobile’s microphone was used for recording acoustic signals emitted from engines and tires of vehicles. A simple microphone on a mobile phone is easy to use and can accurately record the desired signals.

3.2

Wireless module

An XBee Series Two wireless module was chosen for the purpose of wireless communication. The XBees are low power modules with 2mW transmit power and 40mA transmit and receive current at 3.3V. They are reasonably priced at around £22 and can be used to form a Personal Area Network (PAN) [34]. Wireless communication takes place via the Industrial, Scientific and Medical (ISM) frequency band at 2.4GHz. Although this 23

channel frequency band is used commonly, the XBee can communicate via 16 channels, thereby switching the channel in case of high interference. They can interface with the Stellaris board using the Universal Asynchronous Receiver/Transmitter (UART) interface [34]. The UART uses serial data communication between the XBee and the Stellaris board.

A maximum data rate of 250 kbps is provided which suits the small amount of information that is required to be transferred [34]. The specific XBee module chosen was a XB24Z7WIT-004 which has Line of Sight (LOS) range of up to 120m. XBees are commonly used and well documented, which makes understanding and configuring the modules easier.

3.3

Microcontroller Unit

The Texas Instruments Stellaris LM4F120 LaunchPad Evaluation Board was chosen for implementing the processor algorithm. It includes an ARM Cortex M4 based microcontroller (LM4F120H5QR) [35]. This microcontroller contains a hibernation module that allows everything to be powered off except for the hibernation module when the peripherals and processors are not required to execute any function [36]. The processor consumes around 5μA of current in the hibernation mode and around 370μA per MHz when it is powered on [37]. Also, it only needs a steady voltage between 4.75 Vdc and 5.25 Vdc to be powered on [35]. All these features indicate low power consumption which is one of the main specifications of the project.

The Stellaris microcontroller fits into the low cost specifications as its price per unit is $7.99 in the US. In terms of speed, it runs up to a frequency of 80MHz [36] which indicates high performance strongly desired for handling different sensors, complex data pre-processing such as the use of a Fast Fourier Transform computed at each iteration and implementing a complex detection algorithm.

It supports two in-built Analogue to Digital Converters that are used for reading the analogue data from the magnetic and microwave sensors [37]. The microcontroller provides 256KB of flash memory, 32 KB of single-cycle SRAM and 2KB of EPROM together with a memory protection unit [36].

The Stellaris microcontroller is programmed using Code Composer Studio. This software encapsulates C compilers for various device families, debugger, source code editor, simulators and various other tools for embedded application development [38]. In order to efficiently program the microcontroller, Stellaris Ware software can be used [39]. It includes Stellaris Peripheral Driver Library (functions that control the peripherals on the microcontroller), Stellaris Graphic Library (creates graphical user interface with primitives and widget), Stellaris USB Library, code examples, In-system Programming support, CMSIS (cortex Microcontroller Software Interface Standard) [39].

24

Chapter 4 4. Design and Test of Sensor Subsystem 4.1

Microwave Radar

There are different methods of determining the Doppler frequency and thus the speed of a vehicle [40, 41]. Two different methods that were thought plausible and could be realized were chosen due to the restrictions in the radar transceiver modules available in the market currently.

Figure 4.1: (Top) Block Diagram of Radar Signal Processing Scheme using a Frequency Spectrum by FFT (Bottom) Block diagram of Signal Processing Scheme using a Frequency to voltage converter circuit.

A brief description of these two methods is described in Figure 4.1. The first method (top) is to apply Fourier transform on the filtered received signal on a microcontroller. This method allows to get a frequency spectrum of the received signal and this frequency spectrum can be analysed to detect the Doppler frequency and thus the speed of the detected vehicle. The second method (bottom) is to send the filtered received signal to a frequency to voltage converter circuit. The output of this circuit gives voltage that is proportional to the frequency of the signal at the input. The output voltage can be analysed by a microcontroller and used to compute speed of the detected vehicle

4.1.1 Component The component that was chosen is HB100. It is a miniature microwave radar system working in the X-band frequency range. It has a built-in Dielectric Resonator Oscillator (DRO) and a pair of Microstrip Patch antenna array [33]. Its operating frequency is between 10.520GHz to 10.530GHz depending upon the voltage applied to the device. Standard frequency of operation is at 10.525GHz (Figure 4.2a). Device parameters given on the datasheet are given in Figure 4.2a, the block diagram of the device given on the datasheet is show in figure 4.2b and the antenna beam pattern is shown in figure 4.2c sourced from [33].

25

Figure 4.2: (a) The parameter description of the device HB100, (b) The block diagram and connection description of the device, (c) The antenna beam pattern of the device in two different orientations of the device, sourced from [33] Figure 4.2a describes the parameters of HB100 microwave radar. Important parameters considered are highlighted in green colour. The operating voltage of the device is 5V at 30mA current consumption with the DRO working at 10.525GHz output frequency. The typical power consumed by the device will be 150mW. The output voltage of the circuit is about 200μV, which means an amplifier with a very high amplification is required for detecting a vehicle. Figure 4.2b represents the block diagram of HB100. On analysing the block diagram, it is seen that the receiver output is passed through a mixer and then given to the output pin IF. The mixer is connected to the oscillator, which implies that it subtracts the main transmitting frequency from the received signal. Thus filtering out the high transmitting frequency components from the received signal. Therefore, the output at IF should only have the Doppler shifted frequencies. Additionally, a filter at the output is necessary to remove the unnecessary high frequency components. Figure 4.2c describes the antenna beam pattern in two different orientations, namely Azimuth and Elevation. Azimuth and Elevation are part of the horizontal co-ordinate system; azimuth is the angular distance 26

measured east from north, parallel to horizon and elevation is angular distance above the horizon [42].

For this component, a table of output Doppler shifts are calculated using equation (4) that could be outputted from the IF pin of the device.

Velocity Doppler shift Velocity Doppler shift Velocity Doppler shift (m/s) (Hz) (m/s) (Hz) (m/s) (Hz) 1m/s 70.16Hz 6m/s 420Hz 11m/s 770Hz 2m/s 140.3Hz 7m/s 490Hz 12m/s 840Hz 3m/s 210.5Hz 8m/s 560Hz 13m/s 910Hz 4m/s 280Hz 9m/s 630Hz 14m/s 980Hz 5m/s 350Hz 10m/s 700Hz 15m/s 1050Hz Table 4.1: Doppler Shifts calculated according to corresponding velocities using equation (4) Table 4.1 displays the approximate output Doppler shifts corresponding to the given numerical velocities. This gives an estimate frequency to expect for a vehicle moving at a particular velocity.

The way of determining the Doppler shift chosen was using a filter amplifier, sampling the analogue signal, using Fast Fourier Transform on the sampled signal to obtain the frequency spectrum and analysing the frequency spectrum to detect the Doppler shift.

4.1.2

Signal Processing for Radar

The output from the microwave radar module is around 200μVp-p as shown in the device parameters on the datasheet in Figure 4.2a. This output will be difficult to differentiate from atmospheric noise unless the signal is conditioned and amplified. This requires a filter to remove unwanted noise and an amplifier to amplify the signal that it can be differentiated by an Analogue to Digital converter of the microcontroller. Two main iterations were carried out in the design of the filter and amplifier. The requirement was a filter and amplifier that lead to the choice of using Operational Amplifier (Op-amp) for amplifier and a RC filter.

The First Amplifier design was based on using RC filter and Op-amp as the amplifier. Filter design requires a band of frequencies that are to be passed through and while the other frequencies are to be attenuated. This band of frequencies was estimated from the project specification. The aim is to detect vehicles with a velocity up to 30mph, which is 13.41m/s, in terms of Doppler shift of 941Hz at the IF pin of the radar module. A lower frequency band is considered to allow a steady DC voltage at the output and placed at 10Hz. The higher frequency band is placed at 1.4kHz after considering the slight deviation in the vehicular traffic speed at night and taking into consideration that realistic filter behave slightly differently from the simulation on computers.

The bands of frequencies that are devised are 10Hz as the lower cut-off and 1.4kHz as the upper cut-off, this leads to designing a band-pass filter design using RC filter. A RC filter can be configured as a high pass filter or a low pass filter using different configuration of 27

Resistor and capacitor in the filter design. A band pass filter is created cascading a high pass filter at the first stage and a low pass filter at the second stage. Since 2-stage filter design was devised, using 2 Op-amps gives a higher configuration in gain of each stage and a higher overall gain. The RC circuit configuration as a high pass and low pass filter is shown in Figure 4.3.

Figure 4.3: (Left) Low Pass RC Filter configuration, (Right) High Pass RC Filter configuration The cut-off frequency for a RC filter is calculated from equation (6) for both low pass and high pass filters

𝑓𝑓𝑐𝑐 =

1

2𝜋𝜋𝜋𝜋𝜋𝜋

(6)

After a few iterations in resistor and capacitor values a final values for the both the lower cut-off and the upper cut-off frequency were calculated using equation (6). The resistor value for low pass filter is 8.2kΩ and the corresponding capacitor value is 10nF thus the cutoff frequency is at 1900Hz. The corresponding values for the high pass filter are 150kΩ and 100nF with cut-off frequency at 10Hz. The op-amp amplifier IC chip considered was LM324N. LM324N is a low power Quad opamp with features such as low supply current of 375μA per amplifier, a low input offset voltage of 5mV, large voltage gain of 100dB and with a wide range of power supply from +3V to +30V [43]. The operational amplifier was configured as a Non-inverting amplifier for both stages of the filter and amplifier. The output in this configuration is amplified by an order of 1+ R2/R1, where R1 and R2 are the feedback resistors to inverting input of the Opamp. The circuit diagram is shown in figure 4.4a and its AC response for a 200μV signal is shown in 4.4b.

The first Stage in figure 4.4a is a high pass RC filter and the feedback resistor R1 is 1kΩ and R2 is 5.6kΩ that gives an amplification of 6.6. The second stage consists of a 2-stage low pass filter for a higher attenuation after the lower cut-off frequency and feedback resistor R1is 1kΩ and effective R2 as 23.7kΩ that gives amplification of 24.7. When opamps are cascaded together, the effective amplification of the circuit is the given by the product of respective gains of each stage. The total amplification of the circuit given in 28

figure 4.4a should be 160. The amplification of the circuit can be confirmed with the AC response of the filter shown in figure 4.4b. The maximum amplification is at 100Hz with and amplitude of 11mV and the AC input voltage of 200μV gives the amplification of 55.

Figure 4.4: (a) 1st Filter design circuit diagram with 1st stage as high pass filter and 2nd stage as low pass filter, (b) 1st Filter Design AC response from 0Hz to 3kHz The output of this circuit was tested with the IF input from the microwave radar circuit. It is shown in Figure 4.10a. The output is amplified and can be seen on the oscilloscope screen.

It was found out that the output is not amplified sufficiently to detect motion at a couple of meters away from the radar inside the laboratory conditions. A conclusion was devised by this result that a filter design with higher amplification is required for detection of motion of a vehicle few meters away from the radar module.

29

The second iteration of the device was carried out with a main aim of a band pass filter with a high gain. The filter amplifier considered was using Op-amp as a band pass filter. The application note for the device also displays a circuit using Op-amp as a band-pass filter with high gain in the pass band [44]. This circuit did not meet the requirements for this application but a change in the design provided the required filter for this application.

The design realised used two Op-amps with different configurations. The 1st stage used Opamp as non-inverting band pass filter and the 2nd stage used Op-amp as inverting band pass filter.

Figure 4.5: (a) Inverting band pass filter configuration in audio band, (b) Non-Inverting band pass filter configuration in the audio band, (c) AC Frequency response of the Inverting band pass filter, (d) AC Frequency response of the Non-Inverting band pass filter, sourced from [45].

The inverting band-pass filter configuration is shown in Figure 4.5a, and its AC response is shown in Figure 4.5c. The non-inverting band-pass filter configuration is shown in Figure 4.5b, and its AC response is shown in Figure 4.5d. The capacitor C1 and resistor R1 forms a high pass filter and the capacitor C2 and R2 forms a low pass filter and the upper and lower cut off frequency of the band pass filter are calculated using equation (6) for both inverting and non-inverting band pass filters. The amplification for the inverting band pass filter is given by –R2/R1 and for the non-inverting band pass filter is given by 1+R2/R1.

The design of the filter is shown in Figure 4.6a and its AC response is shown in Figure 4.6b.

The first stage is configured as non-inverting band pass filter with the lower cut-off at 30

3.39Hz and the upper cut-off at 723.43Hz with amplification of 101. The second stage is configured as inverting band pass filter with lower cut-off at 4.13Hz and the upper cut-off at 72.34Hz with amplification of 120 and the total amplification of the filter is approximately 12k. The cut-off frequencies were calculated using equation (6).

Figure 4.6: (a) 2nd Filter circuit diagram with 1st stage as non-inverting band pass filter and 2nd stage as inverting band pass filter, (b) 2nd Filter AC response from 0Hz to 3kHz.

31

4.1.3 Microcontroller Interface for Sampling

The output of the filter has to be converted into a digital signal to apply a Fourier transform for detecting the Doppler shift frequency and this requires using an Analog to Digital converter (ADC) circuit. The microcontroller, LM4F120 has two built in Analog to Digital converter with features such as 12-bit precision ADC with a maximum sample rate of 1 million samples per second and with flexible triggers such as timers and ability to use direct memory access (DMA).

The ADC uses sample sequencers to collect and sample data and each sequencer can transfer data using DMA channel [46]. The analogue signal is needed to be sampled at least twice the Nyquist frequency to avoid aliasing in the sampled digital signal [47]. The ADC has fixed reference inputs at VCC i.e. 3.3V and GND and with a 12-bit ADC the voltage resolution is approximately 1mV.

The main challenges of incorporating the ADC and Timer together were to trigger the ADC sample sequencer when the timer ticks. This required configuring the control registers of ADC and Timer with the correct values.

The ADC and Timer setup is shown in Figure 4.7a that consists of the code for setting up the ADC and Timer and Figure 4.7b is code to be run when ADC Interrupt is triggered by the timer tick. When the ADC interrupt is called, The ADC values are transferred to FFTInput array. The values transferred to the FFT input array are close to the actual voltage values. When FFTInput array is filled up the flag for sampling finish is set to 1. When sampling is finish, the FFT function is called to compute the FFT

The main drawback with running the ADC in this configuration is that a large number of the CPU clock cycles are used up in transferring data from one memory block to another that is waste of useful resources. The way this can be avoided is to setup a Direct memory access channel between the ADC sample register and output memory array. This is incorporated in the final version of the code for sampling the output from the filter.

32

Figure 4.7: (a) ADC and Timer setup code for sampling at 7 kHz. ADC configured to get 4 values when timer ticks. And call ADC interrupt when 4th sample is finished sampling, (b) ADC Interrupt Routine to transfer ADC Values to FFT input array and Set flag to call FFT function.

33

The Stellaris has a DMA controller that is known as micro DMA (μDMA) and can transfer data from memory to peripherals and vice versa [46]. Each peripheral that supports μDMA has a control channel on the μDMA controller and can be programmed to transfer data in variety of ways such as basic mode, Ping-Pong mode and scatter-gather mode. The ADC module uses burst request to transfer data from its memory registers to other memory locations. The burst request once triggered runs until the transfer is completed and cannot be interrupted, which allows transferring data in shorter periods of time compared to other request modes. The main challenge setting up the μDMA channel for the ADC transfer, was to set up the cascading channels for the data transfer between the ADC memory register and the array for sampled values since large number of transfers were to be setup between those two memory addresses.

The μDMA channel for the system uses a peripheral to memory transfer between the register memory of the ADC sequencer and the array of gathered sample data. The channel is set to use burst request and basic mode for the transfer of data between these two memory locations.

The setup of μDMA channel is shown is Figure 4.8a. The code shows that if the total number of elements to transfer is greater than the maximum transfer size, only the maximum number of elements supported by the transfer size array are transported, which implies a new transfer to be set up for the remaining data. This new transfer set up is shown in Figure 4.8b. In this new transfer, the amount of data transferred is calculated and then the next transfer is setup inside the ADC interrupt handler.

The μDMA channel allows the ADC to sample data without using CPU clock cycles to transfer data, which allows the CPU to work on different tasks and thus allowing more operations done every second.

34

Figure 4.8: (a) Setup for μDMA in Burst mode and Transfer size set according to no. of FFT points, (b) Code for setting up the transfer of the next set of Data.

4.1.4 Frequency Spectrum The frequency spectrum of the sampled signal has to be calculated so that the Doppler frequency shift can be estimated for the received signal from the microwave radar and the speed of the vehicle is calculated. Fourier transform is a transform function that tells us the frequencies a time domain signal consists [47]. This will transform our time domain signal received form the microwave radar into its basic frequency components and give us a frequency spectrum, which can be used to analyze and calculate the Doppler frequency shift.

35

In 1965 Cooley and Tukey demonstrated a new algorithm to compute discrete Fourier transform that required fewer computations than a discrete Fourier transform algorithm [48].

Using FFT decreases the amount of computation required to calculate the frequency spectrum of the received signal. The algorithm used to calculate the Fast Fourier transform is created by ARM in the CMSIS-DSP library, which consists of over 60 functions in both fixed point and floating-point implementation [49]. Cortex Microcontroller Software Interface Standard (CMSIS) DSP library has different digital signal processing functions that are built specifically for Cortex-M series. The function that is used to compute FFT is a radix-4 implementation of the FFT, which require fewer computations than a radix-2 implementation of FFT [24]. After the FFT is computed, a complex square magnitude and a peak detection functions are used to determine the Doppler frequency shift.

The FFT output also gives the frequency resolution i.e. each element of the FFT output array represent a given band of frequency and that is calculated as given in equation (7)

𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 =

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹

(7)

The number of FFT points is the length of the sample array and Sample rate is the sampling frequency. The frequency resolution for in this case is 7000 divide by 2048, which is 3.417 and no. of FFT output elements or FFT bars are half of the input FFT points. This is crucial for estimating the Doppler frequency shift because the function to detect the peak returns the max value and its array number. The frequency resolution is used to calculate the approximate frequency represented by that FFT bar and thus the Doppler frequency shift.

The speed is calculated by using equation (4) and the Doppler frequency shift. The calculated speed is then sent to the algorithm used to control the brightness of the streetlamp.

Figure 4.9: Function calculating the Fast Fourier Transform and calculating speed according the Doppler frequency shift.

36

The function called for FFT is shown in Figure 4.9. The function arm_cfft_radix4_f32 computes a radix-4 Fourier transform on the FFTInput array. The f32 is that that it is computing on float values of 32bit size. The next function calculates the power of the frequency spectrum and then detect the peak of the frequency spectrum. Using (4) and (7), the speed and the Doppler frequency is calculated.

4.1.5

Controlled Testing

4.1.5.1 Radar with 1st Filter The microwave radar was first tested with the 1st filter design with cascaded RC band-pass filter amplifier inside the Laboratory to avoid unnecessary noise. The Figure 4.10a shows the output on the oscilloscope screen when a hand is moved above the microwave radar.

Figure 4.10b shows the output when there is no motion around the microwave radar.

Figure 4.10: The amplified signal of the microwave radar with the 1st Filter with the scale of 500mV per division on Y axis and 50ms per division on X axis (a) with Motion (b) without motion.

The oscilloscope screen is displaying the Doppler shifted frequencies due to the motion of a hand in Figure 4.10a and without motion of a hand in Figure 4.10b. The amplitude of the output signal is proportional to the distance of the hand from the microwave radar and the amplification of the filter. It was seen that the microwave radar range was only a couple of meters for a person moving inside the lab. This concluded that the amplification is not sufficient to detect motion for more that few meter away.

4.1.5.2

Radar with 2nd Filter

The radar was tested with the 2nd filter design with inverting and non-inverting band-pass filter inside the Laboratory to avoid unnecessary noise. The Figure 4.11a shows the output on the oscilloscope screen when the hand is moved above the microwave radar. Figure 4.11b shows the output when the hand is not moved i.e. there is no motion around the microwave radar.

37

Figure 4.11 Amplified signal of the microwave radar with the 2nd filter. Scale of 1V per division on Y axis and 50ms per division on X axis (a) with motion (b) without motion.

The oscilloscope screen in Figure 4.11a displays the Doppler shifted frequencies due to the motion of the hand and Figure 4.11b displays without the motion. It is observed that for Figure 4.11a and 4.10a, the output observed at the oscilloscope screen is a sinusoidal wave for 4.10a and for 4.11a it is a square wave. This is due the different gain of the amplifiers and different configuration of the op-amp. The output in Figure 4.11a is saturated, this is because the amplitude of the output signal at IF pin on the microwave radar is proportional to the distance of the object from its receiver. In this case the hand is very close to the receiver of the microwave radar hence the output shown on the oscilloscope screen is saturated. This concludes that the 2nd filter has a very high amplification and it has also been seen that motion at 2.5m away from the microwave radar is detected shown in Figure 4.13b for a person walking.

4.1.5.3 Frequency and Speed Testing After finishing a complete system that can sample at 7 kHz and compute FFT, a test was carried out to check the accuracy of the Doppler shift calculated by the Fourier transform code. The output from a signal generator was connected to PE3 pin on Stellaris Launchpad, which is the ADC pin set by the code. When the FFT is computed, the frequency calculated is displayed on the COM port on a PC. The values of calculated frequencies are plotted with the frequency showed on the signal generator. Figure 4.12 displays the result.

The Figure 4.12 gives an estimate of the error between the actual frequency of the signal and the calculated by the code on Stellaris. This error can be used to get an estimate of the signal frequency and can be compensated in the code so that such errors can be minimized.

A trend can also be observed that the error in frequency increases as the frequency at the input is increasing. The error in frequency calculation is passed to calculation of the speed a detected vehicle because the speed is calculated using the detected Doppler frequency.

38

Figure 4.12: The calculated frequency by the code on Stellaris versus the signal frequency shown on the Signal generator.

4.1.6

Outdoor Testing

4.1.6.1 Probability of Detection The first outdoor testing with a complete system for the microwave radar consisted of calculating the probability of detecting a person or a car at certain distance away from the microwave radar sensor. The probability for detecting a car for the range of 0m to 15m is plotted on the Figure 4.13a and that for a person for the range of 0m to 5m is plotted on Figure 4.13b. There are two different orientations the microwave radar can be place as shown in Figure 4.2c, where 2 different orientation’s beam pattern is shown. Probabilities for both the orientations are plotted in Figure 4.13a and 4.13b.

Figure 4.13: (a) Probability of a car detected from a particular distance from the radar module (b) Probability of a person detected from a particular distance from the radar module.

39

The Figure 4.13a displays the probability of a car detected from the microwave radar at a particular distance and Figure 4.13b displays the probability of a person detected from the microwave radar at a particular distance. In the Elevation orientation, distance up to 6m, a car can always be detected while for Azimuth orientation it is up to 8m. After that distance the probability of detecting a car decreases, i.e. there is 50% probability of a car being detected at a distance of 10m in the elevation orientation while for azimuth orientation the distance for the same probability is 12m

4.1.6.2 Detection and Speed Calculation The second outdoor testing with a complete system for the microwave radar consisted of determining that the vehicle is detected and calculating the speed of the detected vehicle that implies determining the Doppler shifted frequency. This required a vehicle travelling at a known speed through the range of the microwave radar at first should be detected and the Doppler frequency should be estimated through the frequency spectrum analysis. The output calculated from the Stellaris was considered to get the approximate frequencies that consisted in the movement of the vehicle.

When testing was carried out, it was seen that the car was detected but the results of the speed calculated were completely different than that from the known speed of the car. This required further debugging to know what exactly was causing this to happen so that it can be fixed. The array ADCValues was plotted on a graph in Code composer studio, under continuous refreshing of the ADCValues the graph was working like an oscilloscope, displaying the waveform from the filter’s output that was sampled. When a car passed through the range of the microwave radar, the output on the graph was changed due to the motion of the car but there is always noise present at the output of the filter that is caused by the mains hum received by the receiver of the microwave radar and amplified by the filter.

There is a certain threshold of power that needs to be crossed to actually have a significant motion in the range of the radar to avoid false triggering it by noise. When the car is detected, the signal received by the microwave radar did have the significant power to cross the threshold but the noise component in the signal is also significant that changes the frequency spectrum of the sampled signal. The higher power in the frequency spectrum is in the noise component rather than in the received signal component and hence the speed calculated using the frequency spectrum is different than the actual speed of the received signal.

Figure 4.14a displays the sampled signal when the car was detected. It is observed that the signal is consists a large amount of noise along with received signal. Figure 4.14b displays the sampled signal when there were no cars in the radar range. It can be observed that the signal consists mostly of noise which is significant in this case as there was no motion inside the radar’s range.

40

Figure 4.14: (a) Signal sampled by the microcontroller when the car is detected. Signal consisting the received signal and the noise and (b) Signal sampled by the microcontroller when no car in the microwave radar range. Signal consisting of the noise received due to the mains hum and amplified by the filter.

41

4.2

Passive Infrared (PIR) Sensor

Testing was firstly done indoors by connecting the PIR sensor to a simple circuit on a breadboard which was supposed to turn an LED ON whenever the PIR sensor detected motion. The setup for the indoor test is demonstrated in Figure 4.15. On the left hand side of Figure 4.15, there is no motion in front of the PIR and hence the LED is OFF; as soon as an object (in this case a small calculator) is moved in front of the sensor, the LED turns ON, signaling that the PIR has detected motion. Additionally, an oscilloscope was used to confirm that the output voltage of the PIR sensor module followed the voltage of the power supply.

Figure 4.15: PIR sensor module connected on a breadboard with LED

Indoor testing done on a long corridor showed a maximum detection range of 12.03m (for humans). Outdoors, the PIR sensor showed a maximum detection range of 14m for pedestrians when it was mounted at approximately 1.8m elevation from the ground and 11.5m at 60cm elevation. Vehicle detection was also performed with PIR; at 60cm elevation, the maximum detection range obtained was 6.85m. The ideal positioning of the PIR sensor should be at an elevation of 2.5m from the ground but for stability reasons it was held at approximately 1.8m elevation during testing, at a height which ensured that it could be held securely. Also, it was established that maximum detection range and best detection occurs when the object moves not toward or away from the PIR sensor, but at a certain angle perpendicular to the field of view, as illustrated in Figure 4.16. Owing to this reason, the PIR sensor will point at a certain angle relative to the pavement to obtain the best compromise between range and accuracy, as demonstrated in Figure 4.17. The arrangement in Figure 4.17 will also ensure that the PIR will not be false triggered by vehicles passing close to the pavement, because the algorithm running on the processor works with the assumption that the PIR sensor will only detect pedestrians.

42

Figure 4.16: Worst and ideal movement cases for PIR detection

Figure 4.17: PIR positioning at a certain angle relative to the pavement, to ensure accurate detection of pedestrians. Not drawn to scale Figure 4.18 shows how the maximum detection range for the PIR sensor varies with different elevations from the ground, as well as with different angles. As it can be seen, the maximum detection range occurs at an elevation of 1.8m from ground, while decreasing the elevation below 1m provides a significant reduction of the sensing distance. In terms of detection with varying angles, as illustrated in Figure 4.18, the PIR can achieve lateral detection as high as 90°, but the sensing distance decreases as opposed to the case where the object crosses right in front of the PIR sensor.

43

Figure 4.18: Maximum sensing distance plotted against different PIR elevations (a) and different angles of detection (b)

44

4.3

Magnetic Sensor

4.3.1

Design

Using equation (5) from Section 2.3.3, the output voltage of the HMC1002 magnetic sensor can be calculated. The sensitivity is 3.2mV/V/G (in comparison with HMC1022 which is a 2-axis magnetic sensor from the same family of sensors but has a sensitivity of 1mV/V/G); assuming a typical supply voltage of 5V and Earth`s magnetic field as approximately 0.5G, the difference between the two output pins is about 8mV [30]. This is a very low signal which needs amplification by a differential amplifier in order to provide a meaningful signal for vehicle detection.

The circuit was firstly tested on a breadboard, using an oscilloscope and connected to a differential amplifier with a gain of 200. The amplifier consisted of an op-amp used in a differential amplifier configuration which provided the desired gain. The amplifier circuit was firstly simulated in OrCAD in order to check that it gave the correct behavior. Figure 4.19 shows the circuit diagram of the differential amplifier in OrCAD.

Figure 4.19: OrCAD schematic showing the differential amplifier. With an amplification of 200x, an input of 6.25mV is amplified to 1.252V

45

4.3.2 Testing The HMC1002 came in a SOIC (Small-Outline Integrated Circuit) package and, in order to be used for testing on a breadboard and then included on a stripboard circuit, it had to be soldered onto a SOIC to DIP (Dual In-Line Package) 20 pin adapter, as shown in Figure 4.20.

Figure 4.20: HMC1002 magnetic sensor soldered on a SOIC to DIP 20 pin adapter, for an easier breadboard connection

In a plain configuration, with no sources of magnetic disturbance around, the two outputs of the magnetic sensor are around 2.5V, separated by a small value so as to provide the desired signal in mV. This was verified on the oscilloscope prior to the sensor output being connected to the amplifier, as shown in Figure 4.21.

The difference obtained between the two outputs (10.625mV) differs slightly from the one calculated with the theoretical formula for a number of reasons, such as magnetic interference from other objects inside the laboratory and the relative positioning of the magnetic sensor. Different orientations of the sensor provided different results. For example, the magnetic field of the earth detected by the sensor changed significantly at a 90° angle change. This change can be observed in Figure 4.22, where three different orientations of the sensor were used (indicated by the small rectangle, where the small black dot denotes pin 1).

46

Figure 4.21: Output level of the Out (+) (yellow line) and Out (-) (green line) as seen on the oscilloscope. Captured using an Agilent Technologies MSO-X 4022A oscilloscope The magnetic detection was performed inside the laboratory by placing an object with a ferrous mass (in this case a typical copper wire stripper) in the vicinity of the sensor. In an attempt to simulate a vehicle detection scenario, the ferrous object was moved in close proximity of the sensor and the plots illustrated in Figure 4.22 were obtained on the oscilloscope, with both x and y sensitive axis connected and at different orientations. In Figure 4.22, the yellow line is the x-sensitive axis and the green line is the y-sensitive axis.

Figure 4.22 clearly shows that, for cases (a) and (b), when the ferrous object moves in the yaxis, the voltage change in the y-axis is much greater than in the x-axis. As opposed to the first two cases, the detection in (c) is done in the x-sensitive axis and hence there is hardly any noticeable difference in the voltage level in the y-axis. This shows a distinct advantage from using 2-axis detection as compared to 1-axis detection because 2-axis detection gives a better chance of detecting a vehicle, at least in one of the axis, whereas the vehicle could pass in the single axis sensor without being detected.

The vehicle detection scenario would be the following: when there is no vehicle present, the voltage level is at a specific value, provided by the orientation of the sensor, supply voltage and amplifier gain. When a vehicle approaches the sensor, an increase followed by a decrease (or the other way round, depending on the car direction) in the voltage level would appear. This would be detected by the 12-bit ADC on the processor, which would have a constant value until the car detection event when it would jump at different values and would tell the system that a car has been detected. Using this method it is also possible to detect the direction the car is travelling in (by looking at whether a voltage increase or decrease comes first).

47

Figure 4.22: Indoor laboratory test with a ferrous object in three different orientation cases.

Yellow line is x-sensitive axis, while green line is y-sensitive axis 48

After successful testing of the sensor on breadboard, it was soldered onto a stripboard for outdoor testing. LEDs were connected to the outputs in order to detect the presence of a change in magnetic field. This was firstly tried with the ferrous object. The output LEDs on the stripboard turned ON depending on the orientation, as per Figure 4.23. In the top part of Figure 4.23, the object is positioned in the y-sensitive axis as indicated in the figure, and detection is indicated by the right-hand side LED being turned ON. In the bottom part of Figure 4.23, the object is positioned in the x-sensitive axis and detection in the x-axis is indicated by the left-hand side LED being turned ON.

Figure 4.23: Circuit for testing outdoors detecting a ferrous object in different orientations and turning an LED ON accordingly Outdoors, the circuit did not manage to power the LED when placed close to vehicles and this was due to very small amplification of the sensor’s output signal. The magnetic sensor`s output was also connected to the ADC on the processor, which in turn was connected to a laptop. Code Composer Studio software for the processor was running on the laptop to display the ADC readings on the screen. A value between 0 (0V) and 4096 (5V, 4096 coming from 212 corresponding to a 12-bit ADC) was read, but no difference was observed when the sensor was in the proximity of vehicles.

49

As a result, the amplification was changed from 200 to 2000 and the sensor was tested again, but this time the amplification proved to be too high and the LEDs were always turned ON, even without any disturbance (due to very high voltage level). Also, saturation was observed when the output signal reached the supply voltage level.

Following this, the amplification was reduced to 1000 and this provided the most meaningful results. The circuit was able to detect large ferrous objects such as an iron lamppost. However, when placed on the pavement, it could not detect approaching vehicles on the road. The best it could do was to detect a double-decker bus from a very small distance, when the sensor circuit was placed next to its engine. To make outdoor testing more efficient, the sensor was tested with a team member’s car. It proved beneficial as it was possible to ‘manually adjust’ the distance between the sensor and the car. Also all the tests needed were performed repeatedly for accuracy. With the setup demonstrated in Figure 4.24, the magnetic sensor managed to detect a vehicle from a very small range (less than 1m) and only in the areas where the most amount of ferrous material is concentrated, such as the engine and the wheels.

Figure 4.24: Setup for the magnetic sensor which managed to detect the vehicle. A program which can perform ADC was loaded onto the processor which was connected to the output of the magnetic sensor. When the vehicle was approaching, a change in the ADC value caused by a change in the voltage level could be observed. The voltage change was however not big enough to turn the LED on. Distance magnetic sensor - vehicle is approximately 20cm 50

4.3.3

Conclusions

After testing the magnetic sensor and given the time left for completing the project, it was decided not to proceed further with its implementation because by then, there were already two types of sensing, PIR and Radar, which had a better detection range and a more reliable detection.

While the magnetic sensor has been successfully implemented in applications such as parking meter sensing, railroad crossing and fast food vehicle detection [30], it does not seem feasible for an early vehicle detection which will ensure reliable turn-on of public lights. The very small detection range is the primary limiting factor. The second factor, as discussed earlier in the Testing section, is the different voltage levels that are obtained for every distinct orientation of the magnetic sensor. This will be a major problem because different roads will have different orientations and every single prototype containing a magnetic sensor will need to have a distinct processor algorithm running, with a different threshold value which will need to be set according to the voltage reading from that particular sensor. Therefore, magnetic sensing was dropped in the final design.

51

4.4

Passive Acoustic Sensors

4.4.1

Test Setup

For testing the performance of acoustic sensors, the acoustic signals emitted by Vauxhall Corsa vehicle were recorded using the inbuilt microphone in Alcatel onetouch (mobile phone). The testing was done on Honeysuckle road. Acoustic signals emitted by the vehicle’s engine were recorded by the mobile phone by placing it next to the engine when the vehicle was stationary. In addition, they were also recorded when the vehicle was moving at speeds of 5mph (miles per hour), 10mph, 15mph, 20mph, 25mph and 30mph.

The sound files were transferred to a PC for analysis. Figure 4.25 demonstrates the setup described above.

Figure 4.25: Setup for outdoor testing, sourced from [31]

The sound files were originally in .3gpp format. They were converted to .wav format with the help of Zamzar (an online conversion tool). The wave files were then analysed in Matlab by using the wavread function [50]. The time domain behavior of the recordings was obtained by plotting the output of the wavread function. To obtain the frequency domain behavior, FFT (Fast Fourier Transform) was performed on all .wav files. PSD (Power Spectral Density) estimates were also obtained by utilising the FFT outputs. The results are presented in the next section.

52

4.4.2

Test Results

All the test results are demonstrated in the form of Matlab simulations. The sampling rate for obtaining the magnitude spectrums and PSD estimates presented below was 44.1 KHz. As a rule of thumb, the spectrum plots were scaled to include 8 kHz as the highest frequency component. Following numbered points include all the test cases that were considered and present the corresponding simulation results.

1. Vehicle was stationary Vehicle Stationary - 0m from car

Vehicle Stationary - 0m from car

0.25

180

0.2

160

0.15

140 120

0.05

Magnitude

Magnitude

0.1

0 -0.05

100 80 60

-0.1 -0.15

40

-0.2

20

-0.25 0

X: 488.4 Y: 169.9

5

10

15

0 0

20

2000

Time[s]

4000

Figure 4.26: Acoustic signals in Time domain

PSD when vehicle stationary

-40 -60 X: 488.3 Y: -58.37

-80 Power/Freq (dB/Hz)

8000

Figure 4.27: Acoustic signals in Frequency domain

-20

-100 -120 -140 -160 -180 -200 0

6000

Freq [Hz]

2000

4000

6000

Freq [Hz]

Figure 4.28: PSD estimate 53

8000

The time domain plot in Figure 4.26 indicates how long the acoustic information was recorded for. The magnitude spectrum was obtained by using the fftshift function, which shifts the zero frequency component to the center of the spectrum [51]. As depicted in Figure 4.27, the frequency at peak magnitude is 488.4 Hz (indicated by the datatip). It corresponds to the frequency generated by the vehicle’s engine, and therefore has a higher magnitude than other frequency components which correspond to the background noise.

Also, the background noise energy mainly intensifies between DC and 500 Hz as illustrated in Figure 4.27. It decreases gradually with some random peaks at components below 2000 Hz, and is negligible for components above 4000 Hz. The PSD estimates are presented in Figure 4.28. It can be observed that the frequency component having highest power is 488.3 Hz, which is the same as the peak magnitude frequency component in Figure 4.27. The peak value of -58.37 dB requires an amplification of almost 1000 along with filtering to remove unwanted frequency components. The power for frequency components above 2000 Hz is negligible.

2. Vehicle was moving at 5mph Vehicle moving at 5mph

1800

0.8

1600

0.6

1400

0.4

1200 Magnitude

Magnitude

Vehicle moving at 5mph

1

0.2 0

1000 800

-0.2

600

-0.4

400

-0.6

200

-0.8 0

2

4

6

8

10

12

0 0

14

Time [s]

Figure 4.29: Acoustic signals in Time domain

X: 155.1 Y: 1747

2000

4000

6000

8000

Freq [Hz]

Figure 4.30: Acoustic signals in Frequency domain

Figures 4.29, 4.30 and 4.31 depict the time domain behavior, frequency domain behavior and PSD estimate respectively when the vehicle was moving at 5mph. In Figure 4.30, the peak magnitude frequency component generated by the moving vehicle is at 155.1 Hz, and the higher frequency components (>1000 Hz) have negligible magnitude. Similarly, as expected, the PSD estimate depicted in Figure 4.31 has the highest power component at 155 Hz, and decreases sharply for the higher frequency components.

54

PSD when vehicle moving at 5mph

-20

X: 155 Y: -36.48

-40 -60

Power/Freq (dB/Hz)

-80 -100 -120 -140 -160 -180 -200 0

4000

2000

6000

8000

Freq [Hz]

Figure 4.31: PSD estimate Figures 4.32 – 4.46 illustrate the time domain plots, frequency domain plots, and PSD estimates for cases when the vehicle was moving at speeds of 10mph, 15mph, 20mph, 25mph and 30mph respectively. The peak magnitude frequency components and highest power frequency components (essentially the same) are indicated by datatips for every case.

3. Vehicle was moving at 10mph

Vehicle moving at 10mph

1

Vehicle moving at 10mph

2000 0.8

1800

0.6

1600 1400

0.2 Magnitude

Magnitude

0.4

0 -0.2 -0.4

1200 1000 800 600

-0.6

400

-0.8

200

-1 0

X: 180.3 Y: 1982

5

10

0 0

15

Time [s]

Figure 4.32: Acoustic signals in Time domain

2000

4000

6000

8000

Freq [Hz]

Figure 4.33: Acoustic signals in Frequency domain

55

PSD when vehicle moving at 10mph

-20 -40

X: 180.3 Y: -35.69

-60

Power/Freq (dB/Hz)

-80 -100 -120 -140 -160 -180 -200 0

2000

4000

6000

8000

Freq [Hz]

Figure 4.34: PSD estimate

4. Vehicle was moving at 15mph

Vehicle moving at 15mph

800

0.6

700

0.4

600

0.2

500 Magnitude

Magnitude

Vehicle moving at 15mph

0.8

0 -0.2

400 300

-0.4

200

-0.6

100

-0.8 0

X: 137.3 Y: 759.1

5

10

15

20

0 0

Time [s]

Figure 4.35: Acoustic signals in Time domain

2000

4000

6000

8000

Freq [Hz]

Figure 4.36: Acoustic signals in Frequency domain

56

PSD when vehicle moving at 15mph

-20 -40 X: 137.3 Y: -44.45

-60 Power/Freq (dB/Hz)

-80 -100 -120 -140 -160 -180 -200 -220 0

2000

6000

4000

8000

Freq [Hz]

Figure 4.37: PSD estimate

5. Vehicle was moving at 20mph

Vehicle moving at 20mph

Vehicle moving at 20mph

0.25

400

0.2

350

0.15

300 250 Magnitude

Magnitude

0.1

X: 245.3 Y: 358

0.05 0

200 150

-0.05

100

-0.1

50

-0.15 -0.2 0

1

2

3

4

5

6

0 0

7

Time [s]

Figure 4.38: Acoustic signals in Time domain

2000

4000

6000

8000

Freq [Hz]

Figure 4.39: Acoustic signals in Frequency domain

57

PSD when vehicle moving at 20mph

-20 -40

Power/Freq (dB/Hz)

-60

X: 245.4 Y: -47.08

-80 -100 -120 -140 -160 -180 -200 0

6000

4000

2000

8000

Freq [Hz]

Figure 4.40: PSD estimate

6. Vehicle was moving at 25mph

Vehicle moving at 25 mph

450

0.2

400

0.15

350

0.1

300

0.05

Magnitude

Magnitude

0.25

0

Vehicle moving at 25mph

X: 261.6 Y: 413.5

250 200

-0.05

150 -0.1

100

-0.15

50

-0.2 -0.25 0

2

4

6

8

10

12

0 0

Time [s]

Figure 4.41: Acoustic signals in Time domain

2000

4000

6000

8000

Freq [Hz]

Figure 4.42: Acoustic signals in Frequency domain

58

PSD when vehicle moving at 25mph

-20 -40 X: 261.5 Y: -47.76

Power/Freq (dB/Hz)

-60 -80 -100 -120 -140 -160 -180 -200 -220 0

2000

4000

6000

8000

Freq [Hz]

Figure 4.43: PSD estimate

7. Vehicle was moving at 30mph

Vehicle moving at 30mph

1400

Vehicle moving at 30mph

0.8

1200

0.6 0.4

X: 152.1 Y: 1390

1000 Magnitude

Magnitude

0.2 0 -0.2 -0.4

800 600 400

-0.6

200

-0.8 -1 0

2

4

6

8

10

12

0 0

14

Time [s]

Figure 4.44: Acoustic signals in Time domain

2000

4000

6000

8000

Freq [Hz]

Figure 4.45: Acoustic signals in Frequency domain

59

PSD estimates when vehicle moving at 30mph

-20

X: 152 Y: -38.46

-40

Power/Freq (dB/Hz)

-60 -80 -100 -120 -140 -160 -180 -200 -220 0

2000

4000

6000

8000

Freq [Hz]

Figure 4.46: PSD estimate

4.4.3 Conclusions A wide range of frequencies were detected by the microphone during testing. As observed from the magnitude spectrums and PSD estimates for different cases, majority of the higher frequency components corresponding to the background noise are considerably lower in signal strength and can easily be filtered out. But strong environmental winds are difficult to completely filter out with a band pass filter as they are present at all frequencies and may lead to false detection.

Furthermore, acoustic signals from only one vehicle (Vauxhall Corsa) were recorded and used for testing to generate the plots depicted in the last section. In reality, a different class or type of vehicle may have a different make of engine, which leads to different acoustic attributes or frequencies [19]. In addition, different engine types usually have different number of cylinders leading to different firing rates for engines, which ultimately leads to different acoustic behavior. Owing to all these factors, it becomes challenging to design and implement a band pass filter capable of rejecting all the unwanted frequency components to prevent false detection. As a result, the team decided to abandon further investigation into acoustic sensors considering the time and resources available for the project.

60

4.5

Photoresistor

The system needs to be able to distinguish between day and night such that it only operates during night-time. For this purpose, a photoresistor is used. It decreases its resistance with increasing light intensity, where the light intensity is usually expressed in Lux [52].

4.5.1 Circuit Design For night detection, the photoresistor is implemented in a simple voltage divider configuration, as shown in Figure 4.47, where R1 has a value of 10kΩ. The output from the voltage divider circuit (Vout) is fed as input to an ADC on the processor which converts the voltage into a decimal value ranging from 0 (0V) to 4096 (equivalent to source voltage Vcc).

The mathematical equation for the voltage divider, given by (8), is used to verify the value which is expected at the output in different lighting conditions.

The photoresistor used is manufactured by LPRS. It has a dark resistance Rdark = 5MΩ and a resistance of 50 to 100kΩ at a light intensity of about 10Lux [53]. For instance, when the system is in dark, the value of the output voltage (for a source voltage of 5V) will be 4.99V, which is very close to the source voltage. In the case of twilight, the value of the output voltage will drop to approximately 4.1V.

Figure 4.47: Voltage divider configuration of the photoresistor (represented by Rf)

61

Vout = Vcc*

𝑅𝑅𝑓𝑓

𝑅𝑅𝑓𝑓 +𝑅𝑅1

(8)

Indoor the photoresistor circuit was tested on breadboard, with the output connected to an oscilloscope. The photoresistor was exposed to different light levels. Table 4.2 shows the output voltage from a 5V power supply in different illumination conditions.

Illumination Output Voltage (V) Normal laboratory illumination 1.8 Completely in dark 4.98 Table 4.2: Output voltage of the photoresistor circuit during indoor testing in different illumination conditions

4.5.2 Outdoor testing A small photoresistor circuit was built on stripboard and tested outside using a multimeter to monitor the voltage levels at different times. Testing was done at the transition between day and night to see how the voltage changes according to the intensity of outdoor lighting. It was done from 16:00 to 16:30 and measurements were taken at small time intervals. The circuit was powered from a battery pack of 5V, and according to measurements, it was predicted whether the lamppost would turn OFF or ON for each particular reading. The results can be seen in Table 4.3. The system will need to turn ON around the 4.73-4.76V region.

Time

Voltage (V)

Lamppost condition (OFF/ON) 4.1 OFF 16:00 4.35 OFF 16:10 4.43 OFF 16:13 4.51 OFF 16:15 4.62 OFF 16:18 4.73 OFF 16:20 4.76 ON 16:22 4.8 ON 16:25 4.82 ON 16:27 4.86 ON 16:30 Table 4.3: Output voltage of the photoresistor circuit at outdoors testing at the transition between day and night

62

Chapter 5 5. Wireless Communication One of the primary objectives of this project is to create a network of units that will monitor and track the location of a vehicle or pedestrian in a designated area. Each prototype will include a wireless module that will facilitate communication between the prototype units.

As the first prototype in the area detects the presence of a vehicle, it will transmit the relevant data to surrounding lampposts to provide adequate lighting. With the wireless unit included, the system is less dependent on the range of the sensors as the lamppost will be notified by the previous node of the presence of oncoming vehicles before it is detected by its sensors. In addition, the system can provide better lighting in accordance with the vehicle speed. For example, if a vehicle is traveling at a high speed, the wireless module can send data to lampposts positioned further away. When a nearby lamppost receives the speed of a distant vehicle, it may adaptively switch on at a specific brightness which would assist in conserving energy. Implementation and testing will be carried out using 6 prototypes, therefore for this project application, each unit will transmit data to the adjacent lampposts.

However, when applied to real world applications this system may be extended to communicate with units at lampposts positioned further away. This will be necessary for cars travelling at higher speeds and to provide better lighting. With an effective wireless system, additional energy may be saved by doing away the sensor modules at alternate lampposts.

5.1 Requirements The wireless unit in the prototype design is required to be low power and low cost. As the maximum distance between two lampposts is about 30m, the range of the wireless module should be at least 30m. Over this range, the modules should transmit at a rate that would support regular transmission of information such as speed and presence detection. Receipt of data at this range should be instantaneous between two units. They should have the capability to form a mesh network, as this would allow the system to overcome the issue of dead nodes. A mesh network implies that the complete network is not compromised in the case of a few node failures. The unit must be compatible with the Stellaris microcontroller chosen.

Once the unit is chosen, it must be tested to understand its limitations. Tests will be conducted to measure the delay between transmission and receipt of data, the amount of packet loss and the relationship between received signal strength and distance. Its resilience against interference and harsh weather condition will be briefly explained. This will be followed by programming and configuring the wireless unit with the rest of the system. The network and data format should be designed so that data may be read easily. Each unit will transmit information produced by the sensors and other required information decided by the algorithm. After successful integration, tests will be conducted to measure the performance of the network.

63

5.2 Components The component selected works on the Zigbee protocol as it seemed like the ideal wireless protocol to choose for a wireless sensor network [34]. Other options taken into consideration included Wi-Fi and Bluetooth. Wi-Fi is the most commonly used. The protocol provides large data rates of 1-5 Mbps and work on the 2.4 GHz band. However, it usually works on more powerful microcontroller and as it communicates via the Web, the network requires an access point which is a wired connection [54]. Bluetooth suits suites the prototype requirement of low cost and low power. An additional advantage is that it avoids interference well by working on multiple channels. The disadvantage is that it usually forms a star topology network with one master and multiple slaves. Bluetooth communication does not facilitate multi-hopping data as it uses point to point communication. For these reasons, Bluetooth was discarded as an option for the wireless communication [55].

Figure 5.1: XB24- Z7WIT-004, sourced from [56] XBees are wireless modules that support the Zigbee protocol. The next step was to choose an XBee that would suite out requirements. While the XBee Series Two runs on the ZB firmware, the Series One modules run on 802.15.4 firmware. The Series One XBee was initially an option for the wireless module. But As the ZB firmware supports mesh networking, it is more suited for the project application compared with the 802.15.4 firmware which supports point to point and star topology [57]. The selected XBee comes in two forms, the regular version and a Pro version. If a more powerful model is required, the Pro version may be used. It has a much higher range of 1500m LOS but uses more power and is slightly more expensive. However, the regular model seemed adequate for the project application.

5.3 Network and routing An example of a mesh network connected by XBees is displayed in Figure 5.2. The network consists of different types of nodes, each having their own roles and functionalities.

Together these nodes form a mesh network capable of self-routing and bypassing dead nodes [34]. In each network, one of the nodes has the role of coordinator which is responsible for selecting the PAN ID and a channel to initialise the network. They allow 64

other nodes like routers and end devices to join the network. Besides this, they have routing functions and can behave as a “parent” for end device nodes. A router has similar functions to a coordinator except that they can only join the network once the coordinator is set up.

While there is only one coordinator in a network, there may be multiple routers. Neither of these nodes may sleep due to their routing functions. The last type of node is the end device which cannot route information. They have the ability to go to sleep, thus saving power in the network, but they can only speak to the network through a router or coordinator known as its parent device.

E R C R

E

E

R

R

R R

E

E

Figure 5.2: Mesh Network Example, sourced from [34] Ad-hoc On Demand Distance Vector routing (AODV) protocol is used to route information from a source to a destination [34]. A route between a source and destination is established by the routers and coordinators in the system. The route discovery method is based on AODV protocol. Each router and coordinator has a database which stores the next hop address for a source transmitting to a particular destination. Given below is a sample route discovery table. In the case where the next hop is unknown, the route discovery process takes place to identify the next hop address. The database may only store a limited number of entries, therefore in the case of a large network with varied connections between different nodes, the route discovery process will occur more often.

Source Node Destination Next Hop Router 5 Router 4 Router 1 Router 2 Router 4 Coordinator Coordinator Router 4 Router 2 Table 5.1: Example Route discovery table, adapted from [34] For route discovery, a source broadcasts a route request command, which consists of the source and destination address including a path cost field. The command passes through the network and at each node, the path cost field is updated before it re-transmits the command.

Simultaneously, the nodes create a temporary entry in their route database. As the destination receives all the route request commands from all the possible paths, it compares the path cost field and choses the path with the lowest path cost. It then sends a route reply packet back to the original source node. All the intermediate nodes that retransmit the reply packet update their route discovery tables accordingly.

65

5.4 Serial Communication

MCU

TX

RX

RX RTS

TX Xbee RTS

CTS

CTS

TX

RX

RX Xbee RTS

TX RTS

CTS

CTS

MCU

Figure 5.3: UART Pin Connections The XBee module is connected to the Microcontroller as shown in the pin out diagram in Figure 5.3 via the UART interface. To begin with, the UART of the microcontroller and the XBee must be configured with matching parameters such as baud rate, start, stop and parity bits. Figure shows the XBee buffers used to hold data for processing [34]. A serial receive buffer receives data from the microcontroller and stores data until it can be processed for transmission. The information may not be transmitted instantly as either the transceiver is busy receiving external data or the module is waiting for a route discovery process to complete. Similarly, there is a serial transmit buffer which moves data from the transceiver towards the microcontroller. Information is held in this buffer when the RF data rate is higher than the interface data rate.

Figure 5.4: XBee Internal Data Flow Diagram, sourced from [34] The Microcontroller UART consists of two 16x8 first in first out (FIFO) buffers [58]. While transmitting, data undergoes parallel to serial conversion from the transmit FIFO to the configured UART Tx pin. A reverse process of serial to parallel conversion occurs when information is received at the UART Rx pin and sent to the receive FIFO. The microcontroller provides 8 configurable UARTs, of which UART0 is used for a USB connection and UART1 supports hardware flow control. UART data flow can be controlled either by software or hardware.

The XBee supports two Serial Interface protocols - Transparent (AT) and Application Programmable Interface (API) serial interfaces [34]. API mode is a frame based technique.

Each frame is a command that will alter the module configurations and set module 66

operations. This mode assists the application to interact with the networking capabilities and edit the parameters without having to use AT command mode. As AT command mode has a second delay each time it enters and exits command mode, API mode is a better option when transmitting to multiple destinations. The API mode can be used to measure the performance of the system as the Received Signal Strength and the transmit/receive success and failure rates can be viewed on a packet by packet basis. For each packet, a confirmation is produced on its receipt and its source address can be identified. Besides using the transmit status frame to measure the performance, it may be also used in debugging as it gives the reason for transmission failures. In this mode, an application may remotely configure an XBee placed in another location. The alternative is AT mode which is much simpler to use.

Data received at the DIN pin is queued for transmission and data is sent out from the DOUT pin when information is received by the module. To alter the parameters or reconfigure the module, AT command mode may be used. Although API mode is more suited for the project application, AT mode may be used as well due to its simpler implementation.

5.5 Implementation To integrate the XBee module, it must first be configured and then mounted with the microcontroller. For both configuration and mounting purposes, two XBee USB adapters were acquired. Four XBee explorers were purchased to mount the XBees for the remaining four prototypes. XBee explorers are cheaper than the USB adapter and are used for mounting purposes, however they cannot configure the XBee.

5.5.1 XBee Configuration Digi provides a software known as X-CTU which can be used to configure the XBees directly by the computer through a USB adapter. Parameters stay constant through most of the application. The parameters defined handle the networking between the wireless units.

Each XBee must be configured as a coordinator, router or end device. For the application and to suit the algorithm chosen, one node is set as the coordinator while the rest are routers.

Despite the advantages of including end device nodes, as each node must transmit or receive from at least two others, end devices were omitted from the network. Initially, all the nodes were set in transparent mode which is much easier to implement than API mode. To implement the system in AT mode, there were two options in the approach for transmitting data. The XBee can be configured with only one destination address at a time and the application requires a node to transmit data to at least two destinations. An option was to set the destination address as a broadcast, hence flooding information to every node in the network. The alternative is to enter AT command mode which can be used to reconfigure the wireless unit and continuously switch the destination address. This method is possible as the address and location of all the nodes are known. The last important step while configuring each wireless unit was to set a common PAN ID. This common PAN ID stops one Zigbee network from interfering with another. The weakness of this network is its reliance on the coordinator, which is if the coordinator crashes, the system will go down.

67

5.5.2 Programming the Microcontroller The procedure after configuring the XBee is to program the microcontroller to interface with the wireless unit. A programming software specific to the Stellaris is used to program the microcontroller. The Launchpad has 8 sets of pins that can be configured as a UART interface of which one set is a USB connection. UART1 is the only set which supports hardware flow control and hence will be used as the connection with the XBee. These features must be initialized on the microcontroller. The first step was to configure the UART1 pins as peripherals and set the necessary pins as a transmitter and receiver. This was followed by setting the parameters for communication such as the baud rate, parity, number of data bits and stop bits. To facilitate communication with the wireless unit, the XBee must be set with matching configurations. The UART and FIFO were enabled and the level of the transmit and receive FIFO were set. When these levels in the FIFO were reached, the transmit or receive interrupt was triggered. Transmit and receive Interrupts were used for software flow control. However, as the situation where other processes in the processor are interrupted is not desired, hardware flow control was implemented. The hardware flow control is implemented by connecting the clear to send (CTS) and request to send (RTS) pins to the wireless module. Transmission occurs on the condition that CTS is asserted. The RTS indicates the position of the received FIFO. Data will be sent by the Serial Transmit buffer in the XBee while the receive FIFO still has space and RTS is asserted [55]. The alternative is to use interrupts for flow control to indicate the status of the UART. In addition to flow control functions, the interrupt status can be viewed to detect errors, hence making it useful for debugging. With FIFO enabled, the receive interrupt is triggered when the received FIFO is filled up to a pre-programmed limit.

5.5.3 Network Implementation Figure 5.5 displays the network of the wireless system implemented in this project. Node C was set as the coordinator while the rest were set as routers. Each node transmits data to its adjacent nodes and its parallel node. The nodes on the opposite sides were made to mirror each other. For instance, node A and B are parallel nodes and will behave similarly. Every node has one associated parallel node on the opposite side of the road.

68

Figure 5.5: Complete System Network Although the wireless modules are configured to broadcast information to all the nodes in the network, predetermined data packets are transmitted and will only be read by the targeted nodes. Figure displays the 7 byte data packet formats used. As different types of data are transmitted at different times, for example when transmitting to the parallel or the adjacent nodes, 2 types of data formats are implemented. Format 1 is used when data is sent between adjacent nodes. It is represented by the red arrows in Figure 5.6. The packet consists of a start byte (ST0) and a stop byte (E0) used to distinguish between packets. S0 is the source byte which stores the name of the transmitting node. With this format, data can be sent to two destination nodes, whose address is stored in D0 and D1. As a receiver, the node will read the destination name and check if its name is present. The packet will be discarded by the node unless its name is present in the destination bytes. Format 1 packets are used to transmit speed or presence. The speed of the detected car or pedestrian is present in P0 and P1. If the system is extended to include more prototypes, the number of destination bytes can be increased. The second format is used to transmit a node’s dutycycle to its parallel node so that it may mirror its behavior. Format 2 is similar to format 1 except for the start byte so that the receiver can easily identify if the payload is speed or dutycycle.

Only one destination byte is required and an additional byte is used to store dutycycle.

Data Format Type 1: ST0 S0 Data Format Type 2: ST0 S0

D0

D1

P0

P1

E0

D0 P0 P1 Figure 5.6: 7 Byte Data packet

P2

E0

69

5.6 Testing and Debugging Initial tests were performed between two wireless units without the use of the microcontroller. Data was transmitted from one XBee to another connected to the same computer via different USB ports. X-CTU includes a terminal tab that can be used to view the received data and transmitted characters. Figure 5.7 shows this test, where “Test1234” is sent from the XBee connected to COM4 and received by the XBee connected to COM5.

Figure 5.7: XBee to XBee Test The first tests with the microcontroller tested the UART serial communication with a computer through a USB. This configuration of sending data serially to PC was useful as it was used to debug most of the wireless tests and parts of the Doppler radar tests.

Once the two individual units were tested, the combination of the MCU and Wireless modules was tested as a transmitter. An additional XBee was connected to a PC to view the received data on the terminal tab. On initial testing, there was no communication between the two XBees. The error was on account of the pin used as the transmitter. Pin D7 may be configured to function as UART2’s transmitter, however pin PD7 is protected as it is a NonMaskable Interrupt (NMI) pin. It must be unlocked to enable the UART functionality. The test was successfully completed when UART1 was configured with different pins. Data is received by an XBee connected to a PC and viewed on the terminal tab.

By configuring both UART1 and UART0 (USB connection), the Launchpad can display received data on a PC. This configuration was used to test the Stellaris as a receiver. While using an interrupt to trigger when information was received, data could be read and displayed. Figure 5.8 shows the results of a test using a receive interrupt that was triggered when the FIFO received 8 characters. The data that is sent is shown on the X-CTU tab and 70

the received data is on the Putty tab. It can be seen that a space is applied after 8 characters, implying that the data is read after 8 characters are received. However, the use of an interrupt for the receiver did not suit the algorithm and hence it was implemented without the interrupt. To overcome this problem, hardware flow control was implemented. Tests were conducted with varying data lengths sent at different time intervals and information was read when characters were available in the receive FIFO.

Figure 5.8: MCU using Receive interrupt The next step involved programming two Launchpad boards as a transmitter and receiver and to test communication between them. For these tests, data was sent in the form of the packets that would be used in the system network. Initially the data packets were in formats of 12 bytes. On testing the byte limit, two 13 byte packets were sent together at a time. This is similar to how our system would practically work, as data may be sent simultaneously to a parallel and adjacent nodes. Figure 5.9 shows the received information and it can be observed that the second data packet was cut off. This occurs as the FIFO buffer has a size of 16 bytes. Therefore, the first 16 bytes received are displayed while the remaining 10 sent in this test were not stored. This problem was bypassed by sending 7 byte data packets.

Figure 5.9: Maximum Byte Limit Test 71

The final test for functionality consisted of sending both Format 1 and Format 2 data packets and using the receiver to extract relevant data. Figure 5.10 shows the source address and speed or duty cycle of the packet extracted and displayed on putty.

Figure 5.10: Extracting and Displaying Information from Received Data Packets The tests explained so far were conducted indoors. To assess the wireless module’s performance when practically deployed, outdoor tests were required. Tests were performed by sending data packets at regular 6 second intervals. At the receiver, the packet’s Received Signal Strength (RSS) was recorded. The RSS was monitored over a range of distances between the transmitter and receiver. These values were taken on Burgess Road and University Road to observe the effects of different environments. Figure 5.11 displays the relationship between distance and the RSS which resembles an inverse square curve. This indicates that the RSS degrades with the square increase in distance. The error bars show the range of RSS at every distance. At University Road, where there is less traffic and interference, the curve is more uniform. On Burgess Road, there is a dip in RSS at 30m and 50m due to additional interference at the areas of the road. The packets were received instantaneously at a constant rate of 6 seconds up to a distance of 90m. Above 90m, packets were lost at instants of high interference such as increased traffic. Therefore, this tests concludes that data can be reliably sent with 80m between two nodes.

As it is an outdoor application, the wireless links must stay reliable through varying weather conditions. However, the effects of rain, fog and snow begin to show significant attenuation for frequencies above 5GHz. In the worst case scenario the fading would occur at a rate of 0.02dB/km which is negligible for this application [59]. The weakness of the wireless link is the interference at 2.4GHz from other wireless applications. If the interference in an area is significant, it may use a system of acknowledgments and retransmissions. The XBee supports a system for acknowledgments and retries in the MAC and Application Support 72

(APS) Layers [34]. The MAC layer acknowledgement occurs when data is transmitted from a source to an adjacent node. An acknowledgement is sent back towards the original transmitter to indicate successful reception even if the adjacent node is not the final destination. In case an acknowledgement is not received, the transmitter will retransmit the data up to four times. The APS layer acknowledgement occurs when the destination node receives the data.

RSS vs Distance Test -20 Burgess Rd University Rd

-30

RSS (dBm)

-40 -50 -60 -70 -80 -90

0

10

20

30

40

50 60 Distance (m)

70

80

90

100

Figure 5.11: Received Signal Strength vs. Distance

The technique used for sending data uses flooding information into every node. This method would certainly be inefficient for a large network, but it was implemented due to the small size of our prototype network. Yet, this imposes a few limitations to the rate at which the prototype can transmit data. It is a problem as the XBee module may only transmit or receive data at a time. Therefore, if a module is receiving data continuously over time, it will not be able to transmit its data. Another reason for packet loss is when the module is transmitting and incoming data is unable to be received. A test was performed to understand the effect of multiple nodes flooding information simultaneously.

73

Maximum Packet Loss Percentage (%)

Maximum Packet Loss Percentage for Varying T ransmission Delay and Number of T ransmitters 100

80

60

40

20

0

1

2 Delay between Packet T ransmissions (s)

3

Figure 5.12: Maximum Packet Loss Percentage The test was conducted with a network of four units where the number of transmitters were increased from one to four. As the network implementation is designed to transmit 7 byte data packets, the packets were transmitted with one, two, three and four second delays.

Figure 5.12 shows the results of this test where the maximum packet loss is compared for different transmission rates when the number of transmitting antennas are increased. The maximum packet loss is determined by the maximum number of times a packet was not received. For a four second delay between packet transmissions, there is no data loss. The maximum packet loss rapidly increases with the increase in transmitters and reduction in the delay between packet transmissions. For 4 transmitters and a one second delay between packets, the highest maximum delay is observed. One of the bytes was only received once out 11 transmissions.

This test concluded that data can be reliably transmitted and received for the project system when data is transmitted with a delay of 4 seconds between packet transmissions. Such a delay would not affect the project system as it is not expected that a streetlight would switch OFF in four seconds. Another conclusion observed during this test was that packets were not mixed when multiple nodes were transmitting.

74

Chapter 6 6. Algorithm for Intelligent Streetlight System The system requires an intelligent algorithm on each prototype that would handle information from all sensors as well as maintain communication with other prototypes. The algorithm is the feature that gives intelligence to each lamppost as it is responsible for controlling any action taken. Depending on the input data, the microcontroller must control the brightness of the streetlight and send the required data to the relevant surrounding lampposts. The logic of the algorithm should be the same for each prototype; the only difference consists in the addresses of the lampposts where information is received from and sent to. The challenge faced with the system algorithm is combining individual modules in a way that they won’t interfere with one another. As it is a critical part of the system, the algorithm was developed at an early stage, before the sensors were completely tested.

Therefore, it was revised several times over the course of the project depending on the results from sensor testing.

6.1

Constraints

There are certain limitations with the sensors available and the system algorithm had to adapt accordingly. Whenever one sensor failed to show its expected functionality, the concept of the algorithm had to change.

6.1.1

Sensors

The first version of the algorithm was developed to include magnetic, microwave and PIR sensors. The magnetic sensor was removed in a late stage of the project and some changes were rapidly implemented in the algorithm in order to make decisions based only on the information from microwave and the PIR sensors.

It was assumed that the magnetic sensor can only detect vehicles, the presence of both a vehicle and a pedestrian can be detected with the radar and PIR, and the speed can be detected with the radar. The only sensor which can extract information related to the direction of motion is the magnetic sensor. However in this project, the direction of motion is only important for pedestrians, as dedicated prototypes will be placed on both sides of the road and the direction of travelling vehicles on either sides of the road was known.

6.1.2

Direction Detection

A considerable amount of energy would be saved if the direction of motion would be known for each pedestrian detected as, in this case, information would be wirelessly transmitted 75

only to the adjacent lamppost corresponding to the detected direction to announce the presence of a pedestrian.

The initial approach for detecting the direction of pedestrians involved placing 2 passive infrared (PIR) sensors to point in opposite directions as per Figure 6.1. In this way PIR1 would turn on before PIR2 when a pedestrian is coming from the left hand side and PIR2 would turn on before PIR1 when a pedestrian is coming from the right hand side. The direction is determined based on which PIR sensor is the first to turn on. If two pedestrians are coming from opposite directions, both PIRs would turn on at very short time intervals and the system would transmit information to both adjacent lampposts.

Figure 6.1: PIR arrangement for direction detection

The problem with this concept is that it is very difficult to write a code to determine in an infinite while loop which PIR is the first to detect every time a new pedestrian is approaching. Obviously, whenever a pedestrian is moving towards the lamppost, even if one PIR detects it at the beginning, the other will detect it afterwards as the pedestrian is moving away from the lamppost. At the beginning, a delay was set whenever one PIR input was high in order to stop the second PIR detecting for a time long enough to allow the pedestrian to move away from the lamppost without being detected again. The main problem with this approach arises in the situation when 2 pedestrians are coming from opposite directions in the same time or at a very small time difference, in which case one PIR would be unable to detect.

Since 2 pedestrians coming at the same time is a very possible scenario, this approach would compromise the safety of one of them. The time constraint of this project made finding another approach to detect pedestrian direction unfeasible and therefore, it was decided that turning ON both adjacent lampposts whenever a pedestrian is detected will waste a little more energy but will not compromise public safety.

76

6.2 Algorithm Design Each streetlight in the system will have a predefined address so that the information will be transmitted to and received from only specific units. Figure 6.2 shows the streetlights in the system with their predefined addresses encoded as letters from ‘A’ to ‘F’. It is assumed that the cars from the lane closer to C would move from A towards E and the cars from lane closer to D would move from F towards B.

Figure 6.2: Assumed lampposts distribution for the system Each of the lampposts will have a prototype attached containing a processor running the algorithm. Because the logic of the algorithm on each processor is the same (only the address differs), it is sufficient to explain the decisions made at a single lamppost (in this case C), however this can be generalized to any other lamppost from the arrangement.

The flowchart describing the algorithm specific to the unit attached to lamppost C can be seen in Figure 6.3. When the light intensity is above a threshold (θ), daylight is assumed and the lamppost is turned off. Otherwise, night-time is assumed and the system will function as follows: When there is no detection and no information wirelessly received, the light at lamppost C is off only if enough time has passed since the last detection (Timer>=Threshold). Timer is a module that combines the information of the time passed after the last detection of a pedestrian or a vehicle or after information has been wirelessly received. The system would know when enough time has passed so that the last elements detected are far enough and they do not require illumination from lamppost C. If the timer is less than the threshold, the brightness would be adjusted according to the information given by the timer module.

When there is information wirelessly received and no sensor detection, the algorithm will look for the source it received information from. If the receiver is lamppost A or E, a 77

vehicle or pedestrian is present at one of these lampposts and according to its speed, the brightness of lamppost C will be adjusted in waiting for the arrival of that vehicle/pedestrian. Information should also be transmitted to the parallel lamppost D, which should illuminate with at least the same brightness as C. If the source is D, some information is received from the parallel lamppost D and hence the brightness of the parallel lamppost D should be transferred to C only if the current brightness of C is lower than for D. Check for night/ day according to the daylight intensity no

Brightness=BrightnessD

Error

yes

no

Brightness< BrightnessD

Brightness = 0

Intensity> θ

yes

no

D

Detection

no

no

Source A,E

yes

Transmit to D

yes

yes

yes

Brightness Level Adjustment

no

yes

Brightness = Maximum

Receive

Receive

no

no

Timer>=Threshold

Transmit information to the next or previous lamppost according to sensor`s input values

yes

Figure 6.3: Flow chart describing the algorithm for node C If the sensors detect, the lamppost will illuminate at full brightness and the system will decide in which direction to transmit the detection information based on the sensor’s input values. In this case information would also be transmitted to the parallel lamppost D. The transmission direction will be decided according to the sensors input values. The information sent from one lamppost to its adjacent lampposts is the speed and the information sent from one lamppost to its parallel lamppost is the brightness.

If a speed of 0 is detected, the system will assume that something is moving very slowly and the lampposts would illuminate for a fixed time interval. This would give enough time, even to a very slow person to reach the next lamppost that should not be placed at more than 30 m away.

78

Store received data for later use

6.3

First Approach

At the beginning it was assumed that the sensors will be positioned according to Figure 6.4.

The PIR sensors should only detect pedestrians and the magnetic sensor, by its nature, would only detect cars. The radar should detect both vehicles and pedestrians as it is the only sensor that extracts the speed of the incoming vehicle or pedestrian.

Figure 6.4: Sensors position assumed for the first algorithm

The direction of transmission is established according to the sensor’s input values as per Table 6.1. In the case where the PIRs, magnetic and microwave sensors are: ’0’, ’0’ and ’1’, respectively, it is assumed that something is approaching but it is too far away to be detected by the PIRs or by the magnetic sensor. In this case nothing will be transmitted, as it is assumed that the vehicle/pedestrian approaches and will soon be detected by either the PIR (if it is a pedestrian) or by the magnetic sensor (if it is a vehicle).

As mentioned in the flow chart from Figure 6.3, the lamppost will turn on at full brightness for all cases from Table 6.1 except for the first one where all sensors are 0. In this case the brightness will depend on the received information, time passed since last detection of sensors or since last wirelessly received information, and it can be ’0’, if the street is empty.

79

PIR1 OR PIR2 0 0 0 0 1 1 1 1

Magnetic

Microwave

Car Pedestrian Transmission Present Present 0 0 No No No transmission 0 1 Possible Possible No transmission 1 0 Yes No Transmit to Next Unit 1 1 Yes No 0 0 No Yes Transmit to Next 0 1 No Yes and Previous Units 1 0 Yes Yes 1 1 Yes Yes Table 6.1: Transmission decisions based on sensor’s input values

Whenever the microwave does not detect but any other sensor detects, it is assumed that a speed of 0 has been detected and the lamppost will stay on for a fixed time interval.

An example of how the system would work if only a car is passing by in the night is illustrated in Figure 6.5. Since there are no pedestrians on the road, both PIRs would be 0.

When the car is at unit A (Figure 6.5 (a)), the magnetic sensor would detect it and the system would know that only a car arrived. In this case, information will be transmitted only to C where the lamppost starts illuminating at half brightness. As the car is moving further, the brightness of A gradually decreases and the brightness of C gradually increases. After the car arrived at C (Figure 6.5 (b)), lamppost A will turn off and information will be again transmitted to next unit E.

80

Figure 6.5: Illustration of the transmission decisions when a car is moving from A to E and is detected in the first stage by A (a), then by C (b) and then by E (c). Rx and Tx stand for the receiver and transmitter, respectively.

81

6.4 Final Approach The exclusion of the magnetic sensor from the final prototype imposed a reconfiguration of the system as per Figure 6.6.

Figure 6.6: Sensors position assumed for the final algorithm In this case, the speed information is the key for differentiating between the situations when only a car is present or when a pedestrian is in the picture as well. Table 6.2 shows the transmission decisions based on the sensor detection and the value of the detected speed.

PIR1 OR Microwave Speed Cars Pedestrians Transmission PIR2 0 N/A No No No transmission 0 1 >5mph Yes No Transmit to Next Unit 0 1 <5mph Possible Possible Transmit to Next and 0 Previous Units 0 N/A Possible Yes 1 1 X Possible Yes 1 Table 6.2: Transmission decision based on the PIR, microwave sensor’s input and speed The only case when information is transmitted only to the next unit is when the PIRs do not detect and the microwave sensor detects a speed higher than 5mph which is too high for human walking. For any other case a pedestrian is assumed to be present and hence information would be transmitted in both directions.

Figure 6.7 illustrates an example of how the system would behave when a pedestrian is detected by the PIR sensor. When a moving pedestrian is detected by the PIRs at E (Figure 82

6.7 (a)) and information will be transmitted in both directions. As the pedestrian moves further away from E, the brightness at E gradually decreases. Once he reaches C and is detected by the PIRs (Figure 6 (b)), the wireless module from C will transmit information in both directions and both lampposts A and E will turn on starting at half brightness (and then gradually increase). Lamppost E might have just turned off as the pedestrian moved away but the wireless module from C will turn it on again. After the pedestrian moves away from E, the brightness again gradually diminishes. The procedure will be repeated once the pedestrian reaches lamppost A (Figure 6 (c)). Meanwhile, as the pedestrian moves away from C, E will turn off if nothing else is detected.

Figure 6.7: Information transmission when a pedestrian is moving. The pedestrian is detected at the beginning by E (a), then by C (b) and then by A (c). Tx and Rx stand for the transmitter and receiver, respectively 83

6.5

Timers

Timers have a very important role in the algorithm in order to determine for how much time and at which brightness a lamppost should illuminate right after the sensors stop detecting and/or information has been received from one of the previous units. Also, timers must be included in order to decrease the frequency of transmission and to control the information received form the parallel unit.

6.5.1 Timers Controlling the Brightness There are two timers implemented in the algorithm that have the role of adaptively controlling the brightness (increasing or dimming the brightness as the vehicle approaches or goes away from the unit), when the sensors detect nothing. The first one, “timersensor” computes how much time has passed since last detection. This timer will go to ‘0’ whenever at least one sensor detects something and increase when nothing is detected. While increasing, if it reaches its threshold value, it will stay at the value of that threshold plus one, until the sensors detect again.

The second timer “timerreceive” will go to ‘0’ whenever information is received from one of the adjacent lampposts and increase otherwise. Similarly to the previous timer, “timerreceive” will stay stuck at the value of its threshold plus one, until information is received again from the adjacent nodes. This timer is essential for estimating the time for which one lamppost should illuminate when a car/pedestrian is present at one of the previous units.

When nothing is detected by the sensors, the brightness of the lamppost will be computed according to the values of the timers described above. When “timersensor” and “timerreceive” are both greater than their specific thresholds, the lamppost will turn off.

The threshold for “timersensor” is determined according to the value of the minimum speed detected within a time interval at the current unit. The threshold for “timerreceive” is determined according to the value of the minimum speed detected within a time interval at the adjacent unit information was received from. This time interval represents the time between the first detection of sensors and the lampposts turning off. In this way, if more elements are detected at a very small time difference, the one with the minimum speed will be remembered by the algorithm in order to make sure that there is enough time for every car/pedestrian to reach the next unit.

The thresholds are calculated according to equations (9) and (10), where “threshold1” and “threshold2” are the thresholds specific to “timersensor” and “timerreceive”, respectively, “distance” is assumed to be the spacing between lampposts (in meters) and “cycles” represents the number of iterations executed in one second on the processor. In the code from Appendix 2, lampposts spacing is assumed to be 30m and cycles is 5 (lines 800 and 792 from Appendix 2).

84

𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟ℎ𝑜𝑜𝑜𝑜𝑜𝑜1 =

𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟ℎ𝑜𝑜𝑜𝑜𝑜𝑜2 =

𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠

𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠_𝑟𝑟

∗ 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐

(9)

∗ 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐

(10)

Both variables “speed” and “speed_r” store the minimum value of speed detected at the current and adjacent unit, respectively from the moment the sensors detect until the lamppost can be turned off. If the speed is 0 or not detected at all (PIRs detect but not the microwave), fixed values will be set for the thresholds. In the code form Appendix 2 (lines 788-801), the threshold for both “timersensor” and “timerreceive” is 750 when “speed” or “speed_r” is 0, which means that the vehicle/pedestrian will have 150 seconds (for “cycles” 5) to cross 30m. The minimum speed detected is 0.2 m/s and anything detected bellow will be assumed as 0.

Equations (11) and (12) represent the two ways in which the brightness (and hence the duty cycle) is controlled. MinValue is the value corresponding to a brightness of 0 and MaxValue is the value corresponding to the maximum brightness. Duty cycle is inversely proportional to the brightness and its value is estimated according to Table 6.3. In the code from Appendix 2, MinValue is “uLPeriod-1” and MaxValue is 0 or “ulPeriod”, where “ulPeriod” is a constant variable with the value 999.

𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 = 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 ∗

𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 = timersensor >threshold1 >threshold1 <threshold1 <threshold1

𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 2

𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟ℎ𝑜𝑜𝑜𝑜𝑜𝑜1

− 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 ∗

𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 2

𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟ℎ𝑜𝑜𝑜𝑜𝑜𝑜2

(11) (12)

timerreceive >threshold2 <threshold2 >threshold2 <threshold2

Duty Cycle Maximum Equation 12 Equation 11 Max(Equation11,Equation12 ) Table 6.3: Duty Cycle value according to “timersensor and “timerreceive” when nothing is detected by the sensors

6.5.2 Timers Controlling the Transmission Transmission cannot occur at every clock cycle the sensors detect as it would be dangerous for the other unit to continuously receive large amounts of information when it reads only one bit at a time. Therefore, 2 timers have been created: “timertransmit_right” and “timertransmit_rightleft” that count how many times a transmission to the right-hand side unit and left-hand side unit, respectively should occur. These timers are set to 0 when no 85

transmission occurs and increase whenever the appropriate transmission occurs. To decrease the frequency of transmission one can transmit information only when the appropriate timers are divisible with a number. For the code from Appendix 2, (“TransmitRight” and “TransmitRightLeft” functions), the number is 10. This number determines by how much the frequency of transmission will be decreased compared to the clock frequency.

An example of how these timers would behave is shown in Figure 6.8, where it is assumed that the frequency of transmission decreases by 10 times. It is assumed that PIR is the only sensor that detects. Therefore, information will be transmitted in both directions when PIR is high as a pedestrian is in the picture. Information will be transmitted only when “timertransmit_rightleft” is divisible to 10. Input Receive stands for the information received from the adjacent lampposts. Figure 6.8 also illustrates an example of how “timerreceive” and timersensor” work.

Figure 6.8: Timers behaviour assuming that PIR is the only sensor that detects There should also be a timer that counts the parallel transmission (“timerparallel”) and its behavior will be similar to “timertransmit_right” and “timertransmit_rightleft”. This timer will increase whenever a parallel transmission occurs and will go to ‘0’ otherwise.

6.5.3 Receiving form Parallel Unit The lamppost should illuminate whenever information is received from the parallel unit. But if the parallel transmission of the previous lamppost occurs at lower frequency, for example, from 10 to 10 clock cycles, this means that information would be received also from 10 to 10 clock cycles. The illumination should be continuous when something is detected at the parallel unit and not occur from 10 to 10 clock cycles. To handle this problem, another timer is introduced: “timerreceive_p”. The purpose of this timer is to determine when 10 clock cycles have passed after the last information received from the parallel unit. This timer goes to 0 whenever information is received from the parallel unit and increases otherwise until it exceeded the number giving the transmission frequency. When “timerreceive_p” exceeds this number, it will stay stuck at its next value until information from the parallel unit is received again.

86

The behaviour of “timerreceive_p” according to the received information from the parallel unit is illustrated in Figure 6.9 for a frequency of transmission of 10. After “timerreceive_p” reaches a value greater than 10, it is known that the parallel unit stops detecting as more than 10 clock cycles have passed and still no transmission from the parallel unit.

Figure 6.9: Behaviour of timerreceive_p according to the information received from the parallel unit

6.6 Implementation This section will describe briefly the algorithm code implemented at one unit (unit C from Figure 6.2) that is shown in Appendix 2. The initial implementation that included the magnetic sensors as well as the steps performed for integrating the algorithm with other physical modules (wireless, microwave sensor) will also be explained.

6.6.1 Initialization and Header Files A number of header files need to be included as explained in Table 6.4.

Header File "inc/hw_memmap.h" "inc/hw_types.h" "driverlib/sysctl.h" "driverlib/gpio.h" "inc/hw_ints.h" "driverlib/interrupt.h" "driverlib/pin_map.h" "driverlib/uart.h" "utils/uartstdio.h" "driverlib/timer.h" "driverlib/debug.h" "inc/hw_adc.h" "driverlib/adc.h" "driverlib/udma.h" "arm_math.h"

Used for memory mapping common types used for SysCtlClockSet and SysCTLClockGet functions related to GPIO interrupt allocation functions related to interrupts peripherals to pin mapping functions related to UART configuration and setup UART console functions (UARTprintf) functions related to the timer configuration and setup debug assisting access to the Analogue to Digital Convertor functions related to the Analogue to Digital Convertor functions related to micro direct memory access functions and instances to CMSIS (all the signal processing functions) library

87

Table 6.4: Header files and their descriptions [37] The first instruction executed is setting up the clock to run at 40 MHz as shown below: SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYS CTL_OSC_MAIN) The Phase-Locked-Loop (PLL) from the processor oscillates at 400 MHz, but it is driven by a 16 MHz crystal on the main oscillator [37]. It is specified a divide by 5 and there is another default divide by 2 for the PLL and hence, 40 MHz result for the system clock [37].

An ADC is required to sample the voltage from the photo resistor. This ADC is setup and initialized in the function ADC1Setup (lines 372-388 in Appendix 2). Step 0 from sequencer 3 from the built in ADC1 is used for sampling and ADC1 is set to be triggered by the processor. More details about how the code for an ADC on Stellaris works are provided in section 6.6.4.

Figure 6.10 shows the code for the function “InitializePWM” that performs the setup for controlling the brightness of the LED. Subtimer A (16 bit) from Timer 1 has been used as a Pulse-Width-Modulation Generator on PORT F2. The brightness is inversely proportional to the duty cycle set for the timer. If a period of 999 is loaded into the Timer’s Interval Load register, the duty cycle values corresponding to minimum and maximum brightness would be 998 and 0, respectively.

Figure 6.10: The use of Pulse Width Modulation generator in code The functions “InitializeWireless” and “InitializePIR” perform initial setups and configure the required ports and pins for using the XBees and the PIR sensors as inputs (lines 409-435 from Appendix 2).

6.6.2 Algorithm Logic The function “CalculateSpeed” (lines 635-649 from Appendix 2) is used to extract the minimum speed detected by the radar from the moment at least one sensor detects until the moment the LED turns off. The variable “speedof” is the speed detected by the microwave 88

sensor at every iteration. The variable “speed” will get the value of “speedof” only at the first detection after the LED was off or, after more detections, only if the new “speedof” found is smaller than the previous “speedof”. Only the value of “speed” which is the minimum speed will be used to estimate the time it takes for the vehicle/pedestrian to reach the next lamppost.

“Case1”, “Case2”, “Case3”, and “Case4” functions correspond to the situations when PIR and microwave sensors do not detect, when microwave detects and PIR does not, when PIR detects and microwave does not and when PIR and microwave detect, respectively (lines 654-734 in Appendix 2). The transmission to the adjacent lampposts is done according to Table 6.2 (in “Case2” the speed value that distinguishes between a car and a pedestrian is checked) and the appropriate function for transmission (“TransmitRight”, “TransmitRightLeft” or “TransmitParalel”) is called. “Case1” corresponds to the situation when there is no detection from the sensors and the timers described in section 6.5.1 are compared to their threshold values according to Table 6.3. The code written for implementing the overall system logic according to the flow chart from Figure 6.3 and Table 6.2 is shown in Figure 6.11. In the while loop, at every iteration, the sensor detection and received information is checked.

89

Figure 6.11: Code within the while loop inside main function that performs the system logic

90

6.6.3 Initial Algorithm The code for the first algorithm described in section 6.3 is attached in the archive submitted with the report. The structure of this code is very similar to the one shown in Appendix 2, except the fact that switches were used to model the magnetic and microwave sensors (as the sensors were not ready at that time) and different cases of input combinations are used to take into account the magnetic sensor as per Table 6.1. The speed supposed to be detected by the microwave sensor was assigned to a different value at every new run of the program.

In the first stage, the logic of this algorithm was implemented without the wireless module and therefore only the cases for no received information could be tested. The algorithm behaved as expected, the LED was turning on at full brightness whenever at least one sensor was ‘1’ and gradually dimming the brightness when all sensors stopped detecting.

The switches inputs standing for the magnetic and microwave sensors, the PIR inputs, the LED duty cycle and the timers were observed in the “Expressions” tab from Code Composer Studio and updated at every iteration from the infinite while loop. Updating the value was possible by placing a breakpoint inside the while loop and changing its “Action” property from the normal mode (“Remain Halted”) to “Update View”. With this setting the number of iterations per second will be much smaller than for the normal running mode.

This is why the thresholds for the timers are calculated differently when observing the variables in “Expressions” than when running in the normal mode and not observing the internal variables.

6.6.4 ADC for the Magnetic Sensor For calibrating the values read from the magnetic sensor, initially, a separate Analogue to Digital Converter module has been created (the ADC code is shown in Appendix 3). The code was adjusted from [37]. The sampler sequencers on the Stellaris ADC are the ones that control the sampling of data. The ADC module is enabled and set at a sample rate of 250 kilo-samples per second. The ADC’s sequencer 1 is used and configured to be triggered from the processor and the highest priority is set. It is necessary to disable Sequencer 1 before configuration and enable it after the configuration setups are done. All 4 steps from sequencer 1 are configured to sample the input on PORTB 5 (“ADC_CTL_CH1”). The instructions “ADC_CTL_IE” and “ADC_CTL_END” determine the interrupt flag to be set after sampling is finished and annotate the end of the conversion, respectively (line 42).

The interrupt “ADCINTHandler” occurs when the conversion is not complete yet. When the conversion finishes, the program goes back in the while loop and the ADC values for each step are stored in the array “ulADC0Value”. These 4 values are averaged afterwards and the value of the variable “voltagem” represents the voltage of the magnetic sensor.

This ADC module has been connected to the magnetic sensor’s output through pin 5 from PORB B. The variable “voltagem” has been observed in the Expression tab with the “Update View” setting. Different tests have been performed reading the ADC values to find out the range of the magnetic sensor as explained in Section 4.3.2.

91

6.6.5 Integrating the Wireless Module The function “ExtractCharacters” (lines 470-528 in Appendix 2) reads the data received from the wireless module (from either the parallel lamppost or adjacent lampposts).

Functions “TransmitRight”, “TransmitRightLeft” and “Transmitparallel” (lines 533580) use the UART interface to communicate serially with the XBee. Information is broadcast from the XBee in the form of character arrays with specific formats. The speed is transmitted by functions “TransmitRight” and “TransmitRightLeft”. “TransmitRight” sends data to the next prototype, while “TrasnmitRightLeft” communicates with the next and previous units. The duty cycle that stands for the LED’s brightness is transmitted within the function “TransmitParalel” to the parallel unit. In this case the adjacent units are A and E and the parallel unit is D. Initially the code for the wireless module was implemented using UART interrupts that were triggered whenever information was received. The use of interrupts would not have matched the logic of the algorithm as the entire execution would have been stopped whenever information was received and the goal was to track the received signal and the sensor inputs in the same time in the while loop. Therefore, the interrupt was replaced with a condition triggered whenever characters where available in the receive FIFO.

6.6.6 Integration the Microwave Sensor The integration with the microwave sensor was very fast. The variable “microwave” is used to determine whether the microwave sensor detects something and it was initially set according to the value of a provisory switch. Later, the functions “ARM_FFT”, “Timer0SetUp”, “ADC0TransSetup”, “uDMAErrorHandler”, “Timer0IntHandler” and “ADC1IntHandler” have been added. Their role is to process the speed from the microwave sensor by using the ADC to read data from the microwave sensor and then performing a FFT to determine the peak frequency and then calculate the speed. More details about these functions are provided in Section 4.1.3. The variable microwave was set to ‘1’ whenever the FFT was returning a frequency higher than a specific threshold and 0 otherwise.

The main challenge encountered while integrating the algorithm with the microwave sensor is the fact that the circuitry of the microwave sensor such as the filter or amplifier was often changing and therefore the variable “maxvalue” had to be recalibrated.

6.7 Algorithm Deployment Testing The functionality of the algorithm was demonstrated, in the first stage, by performing indoor testing. This is very important for differentiating between the errors determined by the sensors or by the code. This section will provide some examples of the tested algorithm functionality. When these tests were performed the microwave sensor was not completely 92

ready, the wireless module was using a less efficient implementation and the connections were made through a breadboard as the prototype enclosing the system was not yet built.

The aims of these tests are to prove the algorithm functionality and hence they are not related to the sensors performance. For observing the information received and transmitted within the system, two prototypes have been used and each prototype was connected to a separate laptop.

6.7.1 Calibration The algorithm has been tested indoors using the computer to observe the variables changing at every iteration it the Expressions tab (the setting Update View has always been used for the Action field of Breakpoint Properties).

Recalling equations (3) and (4) from section 6.5.1, it is known that the thresholds that determine how long should the LED illuminate (and the corresponding brightness) after the last detection or information received, depend on the number of iterations per second. When the same code is run on different laptops, the thresholds will change even if the speeds detected or received are the same, as the number of iterations per second changes.

Therefore, the algorithm is calibrated differently to set appropriate values for thresholds depending on the laptop it is running on. Also, the number of iterations per second will be much higher when the code is running normally on the processor without any Breakpoints used to observe the variables.

6.7.2 Received Information from Adjacent Node Figure 6.12 shows the behavior of unit C when it receives information from unit A (unit C and A are adjacent units). The top part of Figure 6.12 corresponds to the expression tab on Code Composer Studio connected to unit C and the bottom part of Figure 6.12 to the one connected to unit A. Note that the two units have been simulated on different computers and the program on unit C runs at 5 iterations/second and the one at unit A at 2.5 iterations/s.

Therefore, the thresholds for unit A are half the thresholds at unit C, for the same speed value. For unit A, the minimum speed detected by microwave is about 1.1 m/s and this speed is transmitted in m/s to unit C. At unit C, “timerreceive” is just 4, which indicates that information has been received 4 iterations ago. The variable “dutyCycle” is almost “ulPeriod”/2 which indicates that the LED starts at half brightness. The brightness is only dependent on “timerreceive” as “timersensor” is greater than “thresdhold1”, indicating that nothing has been detected recently. The transmitted speed is stored in the variable “speed_r” at unit C and has the value ‘1’ as “speed” from A has been converted to an integer to make the wireless communication easier. Since the speed detected at unit A is smaller than 2.23 m/s, a pedestrian might walk and in this case “transmit_rightleft” is increased so that the value of speed will be transmitted to both adjacent units. The value of “threshold2” at unit C is calculated according to the “speed_r” value. Note that for both case “timerparallel” increases as both A and C lampposts illuminate (although with different brightness) and they should send information to their parallel lampposts.

93

Figure 6.12: Unit C (a) and unit A (b) simulation when unit C receives information from A

For simplicity, Figure 6.13 illustrates the processes in the flowchart that unit C follows when it receives information from A.

94

Figure 6.13: Flowchart process that unit C follows for the example test from Figure 6.12

6.7.3 Received Information from Parallel Node A simulation of the situation when unit C receives information from unit D is shown in Figure 6.14, where D is the parallel unit of C. The PIR sensor at D detects and hence the LED is illuminated at full brightness (“dutyCycle”=0) and information is send to the parallel unit C. At unit C, the variable “parallel” is 1 and “timerreceive_p” is smaller than 10 (the transmission rate), indicating received information form the parallel unit. At unit C, “timersensor” and “timerreceive” are both greater than their threshold and the sensors do not detect, therefore, “dutyCycle” should have been 998 (brightness 0). Because information is received from the parallel unit, “dutyCycle” gets the value of “dutyCycler” which is 0 (maximum brightness).

95

Figure 6.14: Unit C (a) and unit D (b) simulation when unit C receives information from unit D

96

The path followed by unit C for this test case is shown in the flowchart of Figure 6.15.

Figure 6.15: Processes that unit C follows for the example test from Figure 6.14

6.7.4 No Received Information Figure 6.16 shows the behavior of unit C when no information is received and the microwave sensors detect. In this case “threshold1” changes according to the speed detected (0.556 m/s in this case). As the speed is small, a pedestrian might be walking and “timertransmit_rightleft” increases so that the information is transmitted at both adjacent lampposts. In this case, “timerparalel” also increases and has a higher value which means that before the microwave started detecting, the brightness was not 0.

Figure 6.17 illustrates the processes unit C follows in the example of Figure 6.16.

97

Figure 6.16: Unit C when only microwave sensor detects

98

Figure 6.17: Processes that unit C follows for the example test from Figure 6.16

6.7.5 Challenges The challenges with these test cases are related to the wireless transmission rate. Since the number of iterations per second differs for each laptop, the transmission rate would be different. For these tests, the transmission rate was set to the same value for both laptops as the main interest was to check whether the appropriate actions are taken according to the received information. With the calibration used, the wireless module was transmitted at a rate of 2s which is too frequent; the system should wait at least 3s before wirelessly transmitting the next information. Also, for different iterations/second, the timer responsible for receiving parallel information would not synchronize with the transmission rate at the parallel unit.

The laptop was only used for testing and in reality the calibration should be the same as the code is running on the same processor for each prototype and the number of iteration per second is about 40.

99

Chapter 7 7. Prototype planning and construction After all the sensors were tested, it was decided by the team to include only PIR and microwave radar in the final prototype. Therefore, the block diagram for the final individual prototype suffered slight changes from the one in Chapter 3 (Figure 3.1) and can be seen in Figure 7.1.

Figure 7.1: Block diagram for an individual prototype/wireless sensor node after testing

As shown in Figure 7.1, the output of all individual modules apart from the power module are controlled by the processor. The PIR sensor does not require any kind of amplification/filtering, it outputs a binary HIGH/LOW signal which alerts the processor on detecting a pedestrian. The microwave radar has a pre-processing step (filtering and amplification), followed by FFT and ADC which are implemented inside the processor. The photoresistor circuit outputs an analog reading which is converted into meaningful threshold by the ADC on the processor. The wireless module facilitates wireless data transmission/reception among adjacent and parallel nodes.

100

The power module is the most important system module as it supplies regulated voltage to all the components within the prototype. It is subdivided into battery pack, which includes the batteries and battery holders, a voltage regulator and a switch.

7.1

Design

For the construction of a single wireless node i.e. an individual prototype, the team decided to use two layers of stripboard prototyping board. The top layer contains the sensors (2 PIRs, Radar and Photoresistor) as well as the wireless module (XBee antenna + adapter) because these devices need to have an unobstructed field of view in order to sense and transmit signals. Additionally, for spacing reasons, the Stellaris processor is also placed on the top layer. The layout of the top layer is depicted in Figure 7.2. It was designed using the Diy Layout Creator software, which was downloaded from. The Layout Creator software allows flexible placing of components and wires and saves plenty of time as compared to traditional paper-based stripboard layout. Because there are no dedicated modules in the Diy Layout Creator for components such as the XBee, Radar or Stellaris, IC (Integrated Circuit) models with the appropiate number of pins and spacings were used to represent them.

Figure 7.2: Top layer of the stripboard layout for an individual prototype, created using Diy Layout Creator The bottom layer contains the filter/amplifier for the radar, the battery holder, the voltage regulator and the switch. Its layout is displayed in Figure 7.3. As before, the Battery Holder, Switch and Header were modelled using ICs from the Diy Layout Creator library. The 101

‘Header’ connects the top and bottom layers with the four required connections: Vcc (Red), GND (Black), Radar Input (Violet, from radar to the amplifier circuit) and Amplifier Output (Yellow, from amplifier to the processor). This made the prototype more compact as there were no long wires sticking around between the two layers.

Figure 7.3: Bottom layer of the stripboard layout for an individual prototype, created using Diy Layout Creator

7.2

Construction

Figure 7.4 shows one of the prototypes built for outdoor testing. The initial plan was to build 6 such prototypes, however due to the time constraints only 4 such prototypes were built by the end of the project. Even so, 4 prototypes have been enough to simulate and test the functionality of our vehicle detection system.

As displayed in Figure 7.4, the sensors, wireless module and processor all have dedicated connectors on the top layer rather than being soldered directly onto the stripboard, so that they can be easily removed from and stacked back onto the prototype. The PIR sensors are connected at the edges of the prototype to ensure they obtain a maximum field of view over the pavement. Long pin connectors, 6-way female connectors and ribbon wires are used to mount them onto the board such that orientation and angle of view of PIR sensors can be easily adjusted by bending the connectors. The PIR sensors are held still with the use of blu tack. The photoresistor is also mounted on the top so that it will not be affected by shading during the day. Shading might give the photoresistor circuit the false impression that it is dark outside and might result in the system being wrongly activated. The radar is positioned at the bottom left part of the top layer to ensure that its field of view is not obstructed by the 102

processor. Because the processor has connectors on adjacent rows, it would be almost impossible to connect it directly onto the stripboard which has interconnected rows using copper tracks. Two adjacent copper tracks are hard to break on a stripboard and hence dedicated holders for the processor were made using a small intermediate layer of tripad, which includes a break between rows at every three copper tracks.

Figure 7.4: Individual prototype Figure 7.5 shows the bottom layer of the prototype. The two stripboard layers are interconnected using screws and white pillars for spacing, so that the distance between the layers can be adjusted according to the height of the components. The battery holders are fixed onto the stripboard using screws for higher stability. The battery pack consists of 5 AA 1.5V alkaline batteries which are connected in series.

103

Figure 7.5: Bottom layer of the prototype constructed Different wire colours are used in order to ensure easier debugging. For testing purposes, an easily accessible switch is mounted on the bottom layer so that the system only receives power when required, thus improving the lifetime of the batteries. The LM7805 voltage regulator has decoupling capacitors mounted between Vcc and GND.

104

Chapter 8

8. Testing and Evaluation This section covers the tests effectuated with the complete system. The performance depends on the design, on each individual module, implementation and the manner in which the modules synchronize with each other. Initially controlled tests were performed in the labs where equipment was at hand to detect errors and fix any issues. The next stage involved outdoor testing which proved to be more challenging to execute. The energy conserved by the designed vehicle detection system is calculated and compared with existing street lighting schemes.

8.1 Controlled Testing It is important to test every situation possible in the lab, where it is much easier to observe the input and output values. Therefore, controlled testing is necessary to estimate the correct functionality of the system and measure the extent of its limits. Tests were performed to verify the system response to real-time sensor values, support a wireless network and follow the algorithm flow chart. In an outdoor environment, the traffic and pedestrian flow cannot be controlled, and hence it is difficult to cover all the test cases. For example, the case when a car is moving at a low speed is difficult to test in a real-time scenario as most cars travel at high speeds during night.

The lab test results from section 6.7 demonstrate the functionality of the algorithm, but they do not confirm the correct working of the sensors or wireless module. Therefore, the tests performed in this section involve the full system and represent relevant proof of the combined functionality of all the modules.

The testing results are presented for the scenario where the 4 prototypes/nodes A, C, E and D were connected. Table 8.1 shows the accuracy achieved during indoor testing for different test cases. A, C and E were configured as sensor nodes at adjacent positions while node D was configured as a sensor node that was on the opposite side of the road to lamppost C.

105

Situation Node PIR

Microwave

Speed

Actions

Test 1

0

X

Brightness=Maximum Transmit speed to A

Passed Cases/ Total 4/4 4/4

Transmit speed to E

4/4

Transmit duty cycle to D Brightness changing according to timers Brightness changing according to timers Brightness=Maximum Brightness=Maximum Transmit speed to A

4/4 4/4

Transmit speed to E

4/4

Transmit duty cycle to D Brightness changing correctly according to timers Brightness changing correctly according to timers Brightness=Maximum

4/4 4/4

Brightness=Maximum Transmit speed to A

4/4 4/4

Transmit speed to E

4/4

Transmit duty cycle to D Brightness=Maximum Timer for receiver goes to 0 Brightness changing correctly according to timers Brightness=Maximum Brightness correctly changing according to timers

4/4 4/4

Transmit to D

4/4

Test 2

Test 3

Test 4

C

1

A

0

0

X

E

0

0

X

D C

0 0

0 1

X <5mph

A

0

0

X

E

0

0

D

0

0

X

C

1

1

<5mph

A

1

0

X

E

0

0

X

D C

0 0

0 0

X X

A

1

E D

0 0

0

X

Brightness=Maximum Transmit to C 0 X Brightness=Minimum 0 X Brightness=Brightness of C Table 8.1: Indoor Test Case Results 106

4/4 4/4 4/4 4/4

4/4 4/4

4/4 4/4 4/4

4/4 4/4 4/4 4/4

For tests 1-4 in Table 8.1, whenever both PIR and microwave sensors were 0, the timer related to the sensor passed its threshold as long as enough time passed since the last detection. At this instant the LED would switch OFF and await data from sensors or wireless module before switching back ON. All test cases passed successfully, demonstrating overall functionality of the system. The only test cases that could not be covered indoors were when the speed was greater than 5mph (relevant when PIRs are 0) as it is difficult to simulate high speeds in the labs. Also, the speed value calculated from the microwave radar is not very accurate and errors are expected in these test cases.

The methodology of how each case was tested is demonstrated with a few sample cases. An example of how the prototype at unit C functions when the sensors stopped detecting is illustrated bellow in Figure 8.1. The duty cycle value gradually increases (brightness gradually decreases) as “timersensor” is below “threshold1”. Only when “timersensor” will be 750, the LED will turn off. The flowchart from Figure 8.2, displays the process flow for this case.

Figure 8.1: Results for Testing Unit C Behavior, when the Sensors just Stopped Detecting

107

Figure 8.2 Flowchart Illustrating the System Behaviour for the Test Case from Figure 8.1 Figure 8.3 shows the test results performed at units C (Figure 8.3(a)) and D (Figure 8.3(b)) where units C and D are parallel units. The sensors at C stopped detecting but “timersensor” was much lower than “threshold1” and the LED still illuminated with a high brightness (“dutyCycle” is 68). This dutyCycle was then transmitted to node D where “parallel” was asserted which meant that it received information from node C and the “dutyCycler” was 56 (it should have been 68, but there was a delay between the moment the screenshots were taken). The brightness at node D should have been 0 but due to the information received from C, “dutyCyle” got the value of the duty cycle received (“dutyCycler”). The flowchart from Figure 8.4 illustrates the process for the test case at unit D.

108

Figure 8.3: Results for Testing the System at Unit C (a) and Unit D (b), where D and C are Parallel Units 109

Figure 8.4 Flowchart Illustrating the System Behaviour for the Test Case from Figure 8.3

8.2. Outdoor Testing To comprehensively assess the system, 4 prototypes were tested outdoors in the manner they would be practically implemented. The test environment was the Avenue Road at 10pm where the prototypes were positioned at four neighbouring lampposts. A team member was positioned at each lamppost with a laptop to record the readings produced by the prototypes.

The test was carried out over a period of one hour where parameters were recorded for 20 vehicles and 10 pedestrians travelling on either side of the road. To quantify the performance of the system, the average performance of the four nodes is plotted as a bar graph in Figure 8.5 and the values of the node with the best and worst performance are displayed as error bars.

110

Figure 8.5: Average System Performance Looking at the performance, most of the data was transmitted at the correct instances.

However, an exception was recognised when 2 cars travelled quickly one after the other.

This occurs because the second car restarts the speed calculation before any data is transmitted, hence only the second car’s speed is transmitted. A lapse in transmission in these cases would not greatly affect the light in the area. Figure 8.5 shows that wireless reception is less than optimum and some packet loss was experienced. This mainly occurred when vehicles were travelling on both sides of the road and every node was transmitting data simultaneously. As this case rarely occurred, packet loss was low. Hence, it may be concluded that the wireless network may encounter larger amounts of packet loss during busier periods. In order to deal with this, the wireless network should be implemented in API mode where fewer transmissions are required.

The PIR sensor always managed to detect pedestrians, but on occasion they were falsely triggered by large passing vehicles. The probability of cars triggering the PIR is highlighted as PIR Error in Figure 8.5. This problem can be easily overcome by shielding the PIR’s view of the road to only detect pedestrians. The Doppler radar proved to be a more unpredictable module in the prototype. Although the average rate of vehicle detection was high, one particular node only managed to detect 65% of the vehicles. Another drawback observed was the inaccuracy of speed estimation. Only one prototype managed to estimate the speed of a few cars travelling at very low speeds. Therefore, the Doppler radar cannot be described as a highly reliable sensor. For the Doppler radar to be fully functional, further work must be carried out on outdoor noise cancellation. The LED used to simulate the lamppost was successfully controlled according to the behaviour of the sensor and wireless modules.

111

Outdoor testing procured a number of unexpected challenges. The main challenge encountered was calibrating the Stellaris. At 0°C, the process of running the program while watching the variables update on the laptop was much slower. This affected the timers and thresholds used in program. Each value had to be reduced to compensate for the slower clock speed. During the first outdoor test, the Doppler radar was functioning incorrectly, so the nature of received waveform was recorded and analysed at labs. The filter for the radar was repaired and tested in labs before performing a second outdoor test. Figure 8.6 shows test setup for one of the prototypes.

Figure 8.6: Setup for One Prototype

8.3. Power Consumption A comparison of the power consumed between different street lighting schemes and our scheme is shown in Figure 8.7. This figure illustrates the power that would have been saved if the system was implemented with streetlights during the outdoor test. The streetlight considered consisted of a high power LED with a power consumption of 100Wh. Since the speed of the cars was not calculated with accuracy, random car speeds within the system specification were taken into consideration (5mph-30mph). The total time period for which the streetlight was ON was calculated to match the time during which the LED was switched on by the microcontroller. The length of the time period is determined according to the speed of the detected vehicles and the presence of the pedestrians. Table 8.2 displays the power consumption of one complete node, as well as the individual modules.

112

Component Power consumption (mW) Entire prototype 561.12 Stellaris + Xbee + Active LED 345.69 Single PIR Sensor 12.525 Filter + Amplifier + Photoresistor Circuit + Doppler radar 190.38 Table 8.2: Power consumption of one prototype The power consumed for each prototype was also taken into consideration when calculating the total power consumed by a system of 4 streetlights. The other lighting schemes that were considered were the ‘Conventional Always ON Scheme’, the ‘Chronosense’ lighting scheme and the ‘Smart Street Lighting System’.

Figure 8.7: Comparison of Power Consumption between different Street Lighting Schemes and the designed system

The conventional street lighting system turns the streetlights ON at full brightness. This implies that the conventional street lighting system consumes the most power where the total power consumed by four nodes in an hour is 400W.

The vehicle detection system designed adaptively changes the brightness of the streetlight on detection of pedestrians and cars. Hence, the power consumed by the system, if it was implemented on four streetlights, would be the lowest compared with the other schemes as displayed in Figure 8.7.

113

Chapter 9 9.

Conclusions

This project has managed to integrate several modules into a complete prototype. Each prototype functions as a wireless sensor node, set up to detect vehicles and pedestrians. The street lights are adaptively switched on according to the information received by the sensors and wireless module. This project imposed the challenge of implementing a complex system which could only be achieved by careful planning and seamless teamwork. During this project, 4 prototypes were successfully built and tested individually and as a complete wireless sensor network.

A variety of sensors were investigated and tested considering the specifications and constraints of the project. The Doppler radar was tested with an associated circuit designed to filter out noise and amplify the relevant data. It was included in the prototype as it added the feature of reading the speed of a vehicle. Indoor tests were successfully conducted (with the help of a signal generator) where values of speed of about 20m/s were observed.

However, several issues were encountered on integration with the rest of the prototype and outdoor testing. Despite this, the Doppler radar tests gave the team firsthand experience with the challenges faced in deploying a real time, reliable outdoor system. The team gained an understanding of the importance of noise characterization and repeated trial and error testing. A similar problem of high noise and complex filtering was faced when passive acoustic sensors were investigated. To distinguish between pedestrians and cars, magnetic sensor were tested. These sensors had a new set of challenges and although the sensor circuit was repeatedly restructured and tested, the maximum range was found to be 1 meter which did not suite the prototype scope. The PIR sensors were successfully tested and included in the prototype for the purpose of detecting pedestrians. Hence, the procedure of investigating and testing multiple sensors proved to be an appropriate approach in tackling the project. From the 4 sensors selected, two were integrated in the final prototype and performed the function of vehicle and pedestrian detection. Each sensor was unique in its application to the project and imposed very different problems which helped the team gain a greater all round understanding of outdoor sensor implementation.

From a range of wireless module options, the XBee was chosen to form a wireless network.

A methodology for communication was specifically designed for this application. Tests indicated that data would be reliably received when the wireless units are placed at the lamppost’s position. An intelligent algorithm was developed to make decisions based on the state of the sensors and wireless module. The algorithm has been intensively tested indoors and has passed all the test cases for which it was designed. The wireless module was tested closely with algorithm to send data at a rate which would minimize packet loss. As the algorithm and wireless unit were crucial components, they were investigated and tested alongside the sensors and constantly updated according to the status of the sensors. This system of working was crucial to the seamless integration of each component and the formation of a wireless network.

114

Overall, the project of designing and implementing a Wireless Sensor Network involved a range of tasks from programming microcontrollers to designing circuits and building prototypes from scratch. The nature of the project required testing the individual modules and the complete system in labs and then outdoors in the application’s environment using controlled and real time tests. With such a wide range of tasks, the project was a unique and fulfilling experience for the team. Our interactions with the client and the progress seminars made the project feel like an industrial assignment. The clients input on sensors was particularly useful and highly valued as it is one of the company’s area of expertise. In addition, the team was extremely satisfied with the final product and progress made as 4 fully functional prototypes were successfully tested as a wireless sensor network that would conserve energy consumed by streetlights.

9.1

Future work

This section presents a few plausible opportunities for furthering work on the vehicle detection system developed in this project.

A larger detection range would efficiently overcome scenarios where vehicles are driven at higher speeds or more pedestrians come from different directions. A dedicated radar module, which has an internal low noise amplifier and an output amplifier on the module designed by RF beam (module name K-LC6) could be considered []. It has a detection range of up to 62m and could be used to extend the system to national roads and motorways.

To ensure the system can tackle extreme temperatures, hail, storms and other such calamities, it needs dedicated holders or cases which can protect the sensors and wireless module without compromising their functionality. The prototypes need to be placed inside structures made of hard material and fixed onto the streetlights with metal clamps.

This system works assuming a straight road, however for curved roads, traffic lights, junctions and other such parts of the road network, several changes would need to be implemented. As an example, for a roundabout, a sensor with a wider field of view (such as an image sensor) would need to be placed to observe the entire roundabout and the algorithm would need to make decisions based on the occupancy of the roundabout as well as on the information about approaching vehicles.

A dedicated Photo-resistor circuit which will give the threshold of when the system needs to be turned on and a piece of algorithm code which actually performs the system activation has been investigated for distinguishing between day and night. However, the idea was not implemented in the prototype due to the lack of time but with further research in the Hibernation mode of the processor it can be accomplished.

To make the system commercially viable, when one node on a streetlight detects it should transmit to the next 10 streetlights instead of two streetlights so that the driver or pedestrians can have enough visibility.

115

Chapter 10 Project Management

10.

10.1 General Management Due to the scale of this project, the team followed a set of protocols to avert issues from hindering the progress and delaying the planned schedule.

•

During initial stages, every team member was assigned the responsibility of individually researching into particular system modules. If any member required assistance with his/her specific tasks, available manpower was intelligently diverted to that task to ensure regular progress.

•

The team members consistently uploaded documents such as datasheets, individual reports etc. on Forge to have a central standard repository for all project files.

When uploading updated revisions of reports, a new file was created each time to ensure that all the previous versions were still accessible in case of any problems.

•

The prototype was designed and built with several components from different manufacturers and suppliers. This was done to mitigate interruptions in the project progress due to unavailability of certain components as another compatible component could be ordered from other suppliers. This approach helped when RS Components could not deliver the PIR sensors on time, so the team decided to order the same PIR sensors from DigiKey, a supplier in USA and cancelled the previous order. The order shipped from USA arrived 4 days earlier than the expected arrival date of PIR from RS Components.

•

Circuit block diagrams, design files, simulations, code files and reports were consistently backed up to a remote server or copied onto an external flash drive.

This avoided the situation of progress loss in the scenario of PC failure.

•

The team anticipated the scenario of prototype damage during testing (it could easily slip from someone’s hand). To overcome this, ordering more than required quantities of PIR, radar, Stellaris, batteries etc. proved to be a very helpful decision. It ensured prototype testing was not delayed for a long time period due to component failure or damage.

•

Risk assessment forms for lab and outdoor testing were produced as well. They can found in Appendix 4.

116

A table of risks associated with the project including possible actions to manage and mitigate them (Table 10.1) was developed in the beginning of the project. It provided a strong foundation for initial planning of the Gantt Chart.

The Risk analysis and management proved quite important because some of the risks arose during the project and were properly controlled. For example, the risk assessment form written for outdoor testing was important because high visibility vests have been purchased and team members were wearing them during the outdoor testing. This proved very useful for safety reasons, as well as because in one of the nights, during testing, a police car stopped to interrogate what the team was doing. Due to the fact that the members were wearing high visibility vests and hence complied with the legal requirements, the police considered the testing completely adequate and did not interfere in any way.

Risk Analysis and Management Risk

Likelihood (H/M/L) L

Impact (H/M/L) H

Action

IC/Sensor/Component fault

M

L

Components becoming unavailable from supplier/laboratories Reaching budget limit

L

L

L

H

Possibility of sensing methods being too complex given time constraint Outdoor testing risks

H

M

M

M

Have spare sensors to ensure failure of components will not delay the flow of the project See which components are available from Zepler Laboratories and which need to be ordered in time Keep a detailed list of orders to ensure budget limit is constantly tracked.

Allow £100-150 for last-minute orders Investigate four different sensors to ensure that at least one or two will be working as applied for this project Identify all possible risks associated with outdoor testing and write a dedicated risk assessment form.

PC/laptop/server/USB failure

Keep copies of work in different places, such as PCs, storage devices, email etc

Allow enough time for outdoor testing.

Plan for unpredictable weather, typically for November-December in the UK Components conflict on H M Chose components carefully and design integration. Multiple all required circuits ahead of physical modules could require same integration by using software like Diy port.

Layout Creator Table 10.1: Risk analysis and management 117

10.2 Time Management

For ensuring effective time management, a detailed Gantt Chart was produced at the beginning of the project, containing a detailed breakdown of tasks. Figure 10.1 shows the Gantt chart combining both the planned progress (denoted by blue bars) as well as the actual progress of the project (denoted by red bars).

As with any large-scale project, especially one involving significant amount of software and hardware work, the actual progress was different from the planned one. Overall, the team managed to keep within the planned tasks, however time discrepancies appeared. Longer time than expected was taken for testing individual components. This facilitated a robust design which managed to comply with the specifications. Decisions made during the project changed some of the actual tasks performed, e.g. even though the initial plan was to spend two weeks for storing sensor data, it was decided that data storage will not be performed in order not to compromise on the progress of the project and hence this has not been included in Figure 10.1.

118

Figure 10.1: Gantt Chart containing the planned progress (Blue) as well as the actual progress of the project (Red)

119

Team member Palkesh Nuwal

Contribution Project Management, Acoustic Sensor, Construction, Outdoor Testing Ioana Anastasia Oprescu Algorithm, Indoor Testing, Outdoor Testing Maulik Patel Radar, Construction, Outdoor Testing Rohan Koshy Wireless, Indoor Testing, Outdoor Testing Silviu Cosmin Chirila PIR, Magnetic Sensor, Photoresistor, Construction, Outdoor Testing Table 10.2: Individual Contributions

120

11. References [1] S. P. Lau, G. V. Merrett and N. M. White, “Energy-Efficient Street Lighting through Embedded Adaptive Intelligence,” in Advanced Logistics and Transport (ICALT), 2013 International Conference on., Sousse, May 2013, pp. 53-58.

[2] D. Herbert and N. Davidson, “Modifying the built environment: the impact of improved street lighting,” Geoforum, vol. 25, no. 3, 1994, pp. 339 – 350.

[3] R. Elvik, “Meta-Analysis of Evaluations of Public Lighting as Accident Countermeasure,” Transportation Research Record 1485, TRB, National Research Council, Washington D.C., 1995, pp. 112-123.

[4] Commission Internationale de l'Éclairage, “Road Lighting as an Accident Countermeasure,” CIE Publication No. 93, Vienna, Austria, 1992, pp. 122.

[5] Downtown decorations Incorporated, “Light Pole Banners & Brackets,” [Online].

Available: http://www.downtowndecorations.com/Products/LightPoleBannerAndBrackets [6] Guide for energy efficient street lighting installations (2007)., “Organizing outdoor lighting,” [Online].

Available: http://www.estreetlight.com/Documents/Homepage/0_3%20Guide_For%20EE%20Street%20Lighting.p df [7] E2B pulse (2 Dec. 2013). "TfL to invest £10.9m in LEDs and control systems boosting London’s street lighting energy efficiency,” 2 Dec. 2013. [Online].

Available:http://www.e2bpulse.com/Articles/381061/TfL_to_invest_10_9m_in_LEDs_and_ control_systems_boosting_London_s_street_lighting_energy_efficiency.aspx [8] Koninklijke Philips Electronics N. V. (2010). “Chronosense Controller,” [Online].

Available: http://www.lighting.philips.com/pwc_li/main/products/controls/assets/LLC7120ds.pdf [9] Koninklijke Philips Electronics N. V, “Lighting Controls – Dynadimmer,” [Online].

Available: http://www.lighting.philips.com/main/products/controls/products/dynadimmer/dynadimmer. wpd [10] Koninklijke Philips Electronics N. V. (2010). "Different ways: The Dynadimmer and the Chronosense," [Online]. Available: http://www.lighting.philips.co.uk/subsites/oem/product_pages/dynadimmer_overview.wpd.

121

[11] J. H. Sun, J. F. Su, G. S. Zhang, Y. Li and C. Zhao, "An Energy-Saving Control Method Based on Multi-sensor System for Solar Street Lamp," in Digital Manufacturing and Automation (ICDMA), 2010 International Conference on, 18-20 Dec. 2010.

[12] Tvilight, “CitySense,” [Online]. Available: http://www.tvilight.com/frontpage [13] TUDelft, “Intelligent street lighting at TU Delft saves up to 80% on energy,” [Online].

Available: http://www.tudelft.nl/en/current/latest-news/article/detail/intelligentestraatverlichting-tu-delft-bespaart-tot-80-energie/ [14] R. Müllner and A. Riener, "An energy efficient pedestrian aware Smart Street Lighting system," in International Journal of Pervasive Computing and Communication, vol. 7, no. 2, 2011, pp. 147-161.

[15] S. V. Viraktamath and G. V. Attimarad, “Power saving mechanism for street lights using wireless communication,” in Signal Processing, Communication, Computing and Networking Technologies (ICSCCN), 2011 International Conference on, July 2011, pp. 282285.

[16] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci, “Wireless Sensor Networks: a survey,” in Computer Networks, Volume 38, Issue 4, March 2002, pp. 393– 422.

[17] G. Hoblos, M. Staroswiecki and A. Aitouche, “Optimal design of fault tolerant sensor networks,” in IEEE International Conference on Control Applications, Anchorage, AK, September 2000, pp. 467–472.

[18] A. Arora, P. Dutta, S. Bapat, V. Kulathumani, H. Zhang, V. Naik, V. Mittal, H. Cao, M. Demirbas, M. Gouda, Y. Choi, T. Herman, S. Kulkarni, U. Arumugam, M. Nesterenko, A. Vora, and M. Miyashita, “A line in the sand: a wireless sensor network for target detection, classification, and tracking,” in Computer Networks: The International Journal of Computer and Telecommunications Networking - Special issue: Military communications systems and technologies, vol. 46 Issue 5, Dec. 2004, pp. 605–634.

[19] N. Evans, “Automated vehicle detection and classification using acoustic and seismic signals,” Ph.D. dissertation, Department of Electronics, Univ. of York, Sep. 2010.

[20] Sensor Technology Handbook, “Sensor Signal Conditioning,” [Online]. Available: http://een.iust.ac.ir/profs/Esmaeilzadeh/Instrumentation/Sensor%20Technology%20Handbo ok.pdf [21] Mashiur Rahman et al., “Dynamic Range Input FFT Algorithm for Signal Processing in Parallel Processor Architecture,” in Proceedings of the World Congress on Engineering and Computer Science 2011., San Francisco, 2011, pp.530 -535.

[22] Daniel A. Russell, The Pennsylvania State University. [Online]. Available: http://www.acs.psu.edu/drussell/Demos/doppler/doppler.html 122

[23] F.B.Berger, “The Nature of Doppler Velocity Measurement,” in IRE Trans. Aerosp.

Navig. Electron, vol. ANE-4, 1957, pp.103-112.

[24] Bharadwaja.K et al., “Arm Processor based Radar Velocity Measuring Algorithm,” in International Journal Of Engineering Science & Advanced Technology, Volume-2, Issue-4, 2012, pp. 1107 – 1114.

[25] Parallax Inc., PIR Sensor (#555-28027) Datasheet. [Online]. Available: http://uk.rsonline.com/web/p/interface-development-kits/7813024/ [26] K. N. Ha, K. C. Lee and S. Lee., “Development of PIR sensor based indoor location detection system for smart home,” in SICE-ICASE, Int. Joint Conf., Oct. 18-21, 2006, pp.

2162-2167.

[27] C. H. Tsai, Y. W. Bai, C. A. Chu and C. Y. Chung, “PIR-sensor-based lighting device with ultra-low standby Power Consumption,” in Consumer Electronics, IEEE Transactions on, vol. 57, issue 3, 2011, pp. 1157-1164.

[28] S. G. Hong, Y. B. Moon, N. S. Kim and W. W. Kim, “Window Energy Detection for Unmanned Surveillance with PIR Sensor”, in Trust, Security and Privacy in Computing and Communications (TrustCom), 2012 IEEE 11th International Conference on, June 2012, pp.

1543-1547.

[29] G. Padmavathi, D. Shanmugapriya and M. Kalaivani, “A Study on Vehicle Detection and Tracking Using Wireless Sensor Networks,” in Wireless Sensor Network, Vol. 2 No. 2, 2010, pp. 173-185.

[30] Honeywell, “Application Note – AN218 Vehicle Detection Using AMR Sensors”, Aug 2005. [Online]. Available: http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0C CoQFjAA&url=http%3A%2F%2Fwww51.honeywell.com%2Faero%2Fcommon%2Fdocu ments%2Fmyaerospacecatalog-documents%2FDefense_Brochuresdocuments%2FMagnetic__Literature_Application_notesdocuments%2FAN218_Vehicle_Detection_Using_AMR_Sensors.pdf&ei=2VSpUsTrPLDT 7Aavj4CQDw&usg=AFQjCNFVrqft45Jy4XrFLGHoj13HYAXwQ&bvm=bv.57967247,d.bGQ [31] J. Ding, S.Y. Cheung, C. Tan and P. Varaiya, “Vehicle detection by Sensor network nodes,” in Research Reports, California Partners for Advanced Transit and Highways (PATH), Institute of Transportation Studies (UCB), UC Berkeley, 2004, pp. 1-65.

[32] A Summary of Vehicle Detection and Surveillance Technologies used in Intelligent Transportation Systems, Federal Highway Administration’s Intelligent Transportation Systems Joint Program Office., 2000.

123

[33] Agile Sense, Product Datasheet (ver. 1.02). [Online]. Available: https://d9cq1vhji0gn4.cloudfront.net/blog/wpcontent/uploads/wpsc/downloadables/HB100_Microwave_Sensor_Module_Datasheet.pdf [34] Digi International (2010, November), XBee / XBee-PRO ZB RF Modules, XB24Z7WIT data sheet.

[35] Stellaris LM4F120 LaunchPad Evaluation Board, Texas Instruments, Dallas, Texas, 2012 pp. 6 [36] Texas Instruments. (2013, Feb.,20). Stellaris® LM4F120H5QR Microcontroller Datasheet [Online]. pp. 47,456. Available: http://www.mouser.com/ds/2/405/lm4f120h5qr124014.pdf [37] Getting Started with the Stellaris® EK-LM4F120XL LaunchPad Workshop Student Guide and Lab Manual, Texas Instruments, Dallas, Texas, 2013, 2013 pp. 1-4, 3-11, 3-12, 4-12, 5-6, 5-12, [38] Texas Instruments. Code Composer Studio (CCStudio) Integrated Development Environment (IDE) v5 [Online]. Available: http://www.ti.com/tool/ccstudio [39] Texas Instruments. StellarisWare® Complete (all boards, all components) [Online].

Available: http://www.ti.com/tool/sw-lm3s [40] E McCarthy , A. Paulraj and T. Kailath, "Eigenstructure approach to Doppler estimation for wideband signals," in Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing, 1986, pp.1345 -1348.

[41] Banjanin, Z., Zrnic', D. S. and Cruz, J. R., "A Linear Prediction Approach to Doppler Mean Frequency Retrieval in the Presence of Ground Clutter," in IEEE Trans. Aerospace and Electronic Systems, vol. 29, no. 3, July 1993.

[42] Swinburne University of Technology. [Online]. Available: http://astronomy.swin.edu.au/cosmos/H/Horizontal+Coordinate+System [43] STMicroelectronics (2011, June), Product Datasheet (rev. 9). [Online]. Available: http://www.st.com/st-webui/static/active/en/resource/technical/document/datasheet/CD00000457.pdf [44] Agile Sense, Product Application Note (ver. 1.02). [Online]. Available: https://d9cq1vhji0gn4.cloudfront.net/blog/wpcontent/uploads/wpsc/downloadables/HB100_Microwave_Sensor_Application_Note.pdf [45] Limpkin (2013, August 9), Image of Inverting and Non-inverting amplifier. [Online].

Available: http://www.limpkin.fr/index.php?post/2013/08/09/Making-the-electronics-for-a%247-USD-doppler-motion-sensor

124

[46] TI, Datasheet (2013, February 20). For LM4F120H5QR, Pages: 547,760. [Online].

Available: http://www.mouser.com/ds/2/405/lm4f120h5qr-124014.pdf [47] Mark Nixon et al, “Images, sampling and frequency domain processing,” in Feature Extraction and Image Processing, 1st ed. Oxford, United Kingdom: Newnes, 2002, ch. 2, sec. 2.3, pp. 40-47.

[48] James W. Cooley and John W. Tukey., “An Algorithm for the Machine Calculation of Complex Fourier Series,” Mathematics of Computation, vol. 19, no. 90, April 1965, pp 297301.

[49] ARM (2013), CMSIS Description. [Online]. Available: http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-softwareinterface-standard.php [50] MathWorks, “wavread,” [Online]. Available: http://www.mathworks.co.uk/help/matlab/ref/wavread.html [51] MathWorks, “fftshift,” [Online]. Available: http://www.mathworks.co.uk/help/matlab/ref/fftshift.html [52] Photocells: Overview. [Online]. Available: http://learn.adafruit.com/photocells [53] LPRS, “LDR CdS PHOTO CELL”, (2012). [Online]. Available: http://uk.farnell.com/lprs/n5ac501085/light-dependent-resistor5mohm/dp/7482280?Ntt=748-2280 [54] P. Bonnet, A. Beaufour, M. B. Dydensborg. “Bluetooth-Based Sensor Networks,” SIGMOD Recoed, Vol. 32, No. 4, December 2003.

[55] D. Lattibeaudiere, A. Venuturumilli, Microcontrollers and Wireless Connectivity in Smart Appliances. [Online]. Available: http://www.digikey.com/us/en/techzone/wireless/resources/articles/microcontrollers-andwireless-connectivity.html [56] Sparkfun Electronics, XBee 2mW Wire Antenna - Series 2. [Online]. Available: https://www.sparkfun.com/products/10414 [57] Sparkfun Electronics, XBee Buying Guide. [Online]. Available: https://www.sparkfun.com/pages/xbee_guide [58] TI, Datasheet (2013, February 20). For LM4F120H5QR, Pages: 851,862. [Online].

Available: http://www.mouser.com/ds/2/405/lm4f120h5qr-124014.pdf [59] Afar Communications, 900 MHz versus 2.4 GHz in Long Distance Links.

[Online]. Available: http://www.afar.net/tutorials/900-mhz-versus-2.4-ghz/

125

12.

Appendices

Appendix 1: Costs breakdown A cost breakdown of all the components ordered can be found in Table 1. In addition, Table 2 has links attached to the datasheets of all components ordered.

Product Quantit Unit Price (£) Total Price Supplier y (£) Parralax Inc PIR Sensor 4 5.96 23.84 RS Components Parralax Inc PIR Sensor1 10 6.792 67.92 DigiKey Microwave Radar HB100 8 8.10 64.8 Ebay2 TI LM4F120 Stellaris 6 9.94 59.64 Onecall processor TI LM4F120 Stellaris 2 10.14 20.28 Onecall processor3 HMC1002 Magnetic Sensor 2 23.1 46.2 RS Components MOSFET IRF7105 2 0.72 1.5 RS Components Xbee USB Adapter 2 15 30 Hobbytronics Xbee 2mW Wire Antenna 6 20.4 122.4 Hobbytronics Xbee Breakout Board 4 6.95 27.8 Hobbytronics SOIC to DIP 20 pin 2 0.96 1.92 Hobbytronics Duracell Batteries 8pk 5 4.452 22.26 RS Components 4pk Battery Holder 6 1.74 10.44 Onecall Light-dependant resistors 6 1.21 7.416 Onecall Table 12.1: Breakdown cost for the individual components 1

Second order of PIR was done from DigiKey Corporation due to unavailability from RS Components 2 Microwave Radars ordered from Ebay due to the fact that it was not on the catalogue of any approved supplier 3 Added twice due to a slight increase in price when ordering the last two Stellaris processors

126

Product Parralax Inc PIR Sensor Doppler Radar HB100 TI LM4F120 Stellaris processor HMC1002 Magnetic Sensor MOSFET IRF7105 Xbee USB Adapter Xbee 2mW Wire Antenna Xbee Breakout Board Light-dependant resistors LM324 Quad Op-amp LM7805 LDO Voltage regulator

Datasheet available at Datasheet PIR Datasheet HB100 Datasheet LM4F120H5QR Datasheet HMC1002 Datasheet IRF7105 Schematic Xbee USB Adapter Datasheet Xbee 2mW Wire Antenna Schematic Xbee Breakout Board Datasheet Photo resistor Datasheet LM324 Datasheet LM7805 Table 12.2: Datasheets of the Components used.

Table 3 shows a list of the components which have been provided by the Zepler laboratories.

Component Provided by Resistors, different values Zepler Laboratories Capacitors, different values Zepler Laboratories Pin connectors and headers, different sizes Zepler Laboratories Stripboard and tripad board Zepler Laboratories Ribbon cable Zepler Laboratories 6-way female connectors Zepler Laboratories Screws, nuts, washers Zepler Laboratories Red LEDs Zepler Laboratories Pillars (for spacing prototype layers) Zepler Laboratories Copper insulated cable Zepler Laboratories Switches Zepler Laboratories LM7805 Voltage Regulators Zepler Laboratories Single battery holders Zepler Laboratories LM324 Operational Amplifiers Zepler Laboratories IC holders, different sizes Zepler Laboratories Table 12.3: List of components provided by Zepler laboratories

127

Appendix 2: Final Code For the System Algorithm at one unit (C)

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

Appendix 3: ADC Code for sampling the magnetic sensor

146

Appendix 4. Risk assessment form

Figure12.1: Risk assessment form 147

Figure is a scanned copy of the risk assessment form for outdoor testing. Unfortunately, the original copy which was assessed and signed by Dr. Alex Weddell was lost and the team had to upload an unsigned copy, as the loss was only discovered before the project submission deadline. This was however brought to the attention of the supervisors and they agreed on an unsigned copy being uploaded for completeness.

Figure 12.2: Risk Assesment form for outdoor testing

148