Embedded Systems Design Fall 2015

Networked Smart-lighting System on

an Embedded Platform
Issac Sharp, Jared Smith, Alex Hooten
University of Tennessee

Abstract
This document describes a network of connected light nodes that work together to reduce the
power consumption of lighting streets or hallways. We propose a pedestrian detection system
built on an embedded platform using ultrasonic motion sensors to dynamically light a hallway
as the traveler moves through the monitored space. A conservative model for powering the
light system would aim to only light areas in the immediate vicinity of the traveler, with a
gradient of light concentrated at the position of the traveler. We present a networked model
that aims to broadcast pedestrian status across the network so that the light controllers may
respond appropriately.

I.

Motivation

ighting can be a heavy burden for

many buildings or city streets. Controlling the amount of light produced directly impacts the power consumption of the building or city. Considering that power consumption can be
the biggest constraint on some systems, it
is important to minimize the power demands of a systems constituent components. As mentioned before, accomplishing the goal of the project would result in
a smart-lighting system that consumes less
power. The use of less power will have a
two-fold benefit for the city and the environment: First, the spending for electricity
will be reduced allowing the extra savings
to be budgeted for other critical needs. Second, the reduced power consumption will

have an impact on the environment by potentially reducing the amount of power

generation.
Current similar solutions on the market
include the Leviton RF gateway, and ADT
Business Automation, a security service
that can control lighting within a home
or small business. The proposed device
would have more focus on lighting efficiency than security.

II.

Background

The following self-contained components

will be used in a each network node:

I.

Hardware
Arduino Uno Clone (Practical ATmega238P UNO R3)
This will house the microprocessor.
1

Embedded Systems Design Fall 2015

HC-SR04 Ultrasonic Distance Measuring Sensor Module

The distance sensor will be used to
determine whether or not a pedestrian is present.
HC-05 Bluetooth Serial Module
This module allows bluetooth packets to be sent between each node.
Potentiometer
Digital
100KOhm 8-Pin

256POS

The digital potentiometer will act as

a dimmer switch controlled via the
SPI interface.
Light source and circuit
The final main component is the light
emitting device. This will probably
take the form of an LED, though an
incandescent light bulb may be used
as well.

II.

Software

Each nodes Arduino unit will be flashed

with a program that carries out the desired
behavior.

III.

Challenges

There are three main challenges that must

be addressed during this project. The first
is the calibration of the motion sensors for
all possible modes of operation. The second challenge is the implementation of a
control interface between sensor and light.
2

The third primary challenge is the communications between nodes. The communications and routing between nodes serves as
the most challenging requirement for the
system. Within each of these challenges,
there are hardware and software components.

IV.

Details and Specification

The proposed network should be easily

configured by an individual with access
to a main control location. The hardware
requirements for the proposed system are,
motion sensors, communication network,
light controller, and light source. Sensor
connected to the control board. This sensor
will monitor the current environment and
control the intensity of the light source. After motion detection occurs, the node will
notify its neighbors and control light intensity appropriately. A timer begins to
count down at detection, after which light
intensity will be decreased. The communication network will be used to communicate between nodes. The network will
be wireless. Each node will have a list of
neighbors that it can communicate with.
Each node will collaborate with its neighbors and ensure the street has adequate
light as traffic moves ahead through the
path. If there is no traffic for a specified
time the light network will transition into
a low-power mode by reducing light intensity or completely turning off the light.
A light controller will directly control the
amount of light generated.

Embedded Systems Design Fall 2015

Figure 1: System schematic (single node)

A schematic will help describe the

wiring of the nodes. Each node contains
the circuit shown in the figure below. (Fig.

1). Notice that the circuit contains the pin

wirings that go to the Arduino, which is
not pictured.

The software of for each node works

like a state machine that gets its next state
by testing its environment.
It is helpful to specify the general be-

havior of a given node via a flowchart. This

description can be found in the figure. (Fig.
2)

Each sensor has a set ID, which will be

used in conjunction with a list of neighbors to determine the next states for the
individual nodes. Such a configuration
requires each bluetooth packet to contain
the node-ID of the node that broadcast it.

Then, nodes can calculate their distance

from the originating node to determine
whether they should react to the new information.
Depending on whether or not the radio
reception of the radios in our prototype is
3

Embedded Systems Design Fall 2015

Figure 2: System flow control (with events)

good or bad, it may be necessary for each

node to rebroadcast packets in a multi-hop
manner. If that is the case, a simple protocol will have to be developed that includes
a unique packet ID and a time-to-live field.
Together this information can be used to
ensure that packets can travel freely across
the network. Otherwise, every packet will
simply be recieved over the bluetooth modules of each node, and the resulting behavior will be carried out.
The model may be modified by placing
the first two nodes in a hallway closer together so that direction can be determined
more quickly, allowing pre-emptive lighting to take place. In such a configuration,
the first and second nodes would communicate and act as a sentinel that determines
whether or not the pedestrians are mov4

ing into the room or are simply passing

through from the other end. If it is determined that an entrance is being made,
one of the first two nodes will send out
a special packet notifying the network to
perform pre-emptive lighting.
Wihout pre-emptive lighting, the model
reduces to a simple gradient of light concentrated on the pedestrian. This configuration will resemble a moving wave of
light travelling through the room as the
pedestrian. If post-detection timers are enabled, the lights will be configured to persist at a lower intensity for a specified time,
after which they will turn off, rather than
only adjusting based on pedestrian state.
A top-view of the system in a hallway
shows the layout of the network (Fig. 3)
The topology of the network will be linear,

Embedded Systems Design Fall 2015

Figure 3: Top-view of system

with each node having a list of hard-coded

neighbors. The linear model serves our

V.

Goals

The overall goal is to reduce the energy

consumed by lighting systems by optimizing the light level provided by individual
lighting units. This overall goal must be
attained in stages, first by creating a single operational node/controller pair. Once
the motion detection system is configured,
the next step will be achieving a simple
on/off control via the potentiometer. After
this, multiple light levels can be configured,
and the network components can become
more integrated as the protocol is developed. This will result in a fully-realized
smart-lighting system.

VI.

Testing

A description of the testing procedures follows:

goals well since we are targeting straightline paths in a straight hallway.

I.

Hardware

I.1

Test Plan

The test plan began by looking at the different aspects of the project in order to
ensure that all aspects of the project were
completed.
I.2

Acoustic Sensor

The SR-04 ultrasonic sensor test began by

ensuring that the sensor would detect a
change in distance thus signifying that an
individual had entered the lighting area.
The distance from the sensor was not that
import, however ensuring that the sensor
was accurate across the full range was a
very important to the overall functionality
of the system. Because the sensor would
become unreliable near the extreme edges
of its specified range we set that max allowed range to 200cm. Because our system
will be employed as a stationary sensor and
will be required to operate for extended periods of time we tested the extended usabil5

Embedded Systems Design Fall 2015

ity of the sensor. During this phase of the

testing an error was discovered within the
hardware of the sensor. The SR-04 ultrasonic sensor would be accurate for about
10-15 min but then would begin to behave
in a non-deterministic manner.
I.3

Digital Potentiometer

The testing of the digital Potentiometer began with a communication test ensuring
that the device would dynamical change
the output voltage based on the input
value. These tests went well, allowing the
dimming and brightening of an LED light.
After verifying that the digital potentiometer would change values testes were performed to find the relative value for Low,
Medium, High, off would be 0 volts. Initial the full range of input values was divided into three equal parts. Testing the
relative light output based on the linear
division of the possible output range revealed that the voltage output was not completely linear with respect to relative light.
Therefore the values for ,Low, Medium,
High were adjusted and relative values that
would give a noticeable change in brightness between Low, Medium, and High.
I.4

Bluetooth Transceiver

Bluetooth Transceiver (HC-05): The Bluetooth communication module that was chosen was initially tested to ensure that two
of the adapters would recognize and pair
with each other. This test was successful. The next test looked at connecting
6

one adapter to many adapters this test was

moderately successful, because the more
devices that were added to the network
some devices would drop their connection
at random times. The last test was to see if
each device could pair with many different
device but the this was not allowed by the
adaptors because each device must maintain a master/slave connection. Creating a
pairing between two master units was not
allowed. This caused a major problem in
our initial design this communication was
critical to allow each unit to communicate
with its four neighbors. Due to this issue
each unit was linked using wired serial
communication.

II.

Software

The software test plan began with the analysis of the timing constraints within the
Arduino programing environment. Arduino boards are programed using two
basic steps. First was the setup: here the
device is initialized and internal structures
and devices are setup. Second was the void
loop: the device continually loops through
the set of instructions found within the
loop. One time events and function calls
were called within the setup function while
the main operations take place within the
loop. Because the detection of motion was
the primary purpose of the unit, the section
of code that operates the sonar was time
critical. If other functionality delayed the
operation of the motion detection then an
event could be missed. Therefore testing
the timing was a large portion of the soft-

Embedded Systems Design Fall 2015

ware tests. During these tests it was found

that the serial communications would not
interfere, unless very large data packets
were sent. The communication packet used
for our communication was just a few bytes
this did not hinder the operation of the system.

VII.

Results

We ended up only having a 3 node system

because of the limitation on our power supply setup. We had one node connected to
a laptop and this node supplied power to
its adjacent node via a wire and another
wire from the adjacent node linked the final node. This system only required one
power supply, but the magnitude of the
power supply was not enough to connect
another node, so we settled on a 3 node system because of the time restraint kept us
from pursuing an alternative solution. Another constraint that we had was the range
of the HC-SR04. We set the range only to
200cm even though the data sheet of the
HC-SRO4 states that its maximum range of
500cm. We limited our system to 200cm because the HC-SR04 returned more reliable
results with this configuration. Once we set
up each Arduino configuration with their
HC-SR04s, leds, and breadboards, we had
a system. We also ended up implementing
our node communication with wire connections between each node rather than
using bluetooth. This was easy to implement given how few nodes our system had.
Our only other design issue was that our

sensors tended to give corrupt data after

10 to 15 minutes of being turned on. We
ended up not having enough time to fix
this issue, but we were still able to film a
quick demo of our project.

VIII.
I.

Discussion

Future Work

While working with the device there was

one use case scenario that was overlooked
during the design process. The system was
designed to control a block of lights down
a hallway, however there was only one motion sensor included in the design this left
one of the two possible entry points unmonitored. For our initial proof of concept this was not a major problem, but the
addition of an additional motion detector
would add additional complexity to the
overall hardware and software designs.

II.

Comments

The use of a sonar range sensor was a poor

substitute for a motion detector. The sonar
is under utilized and its primary functionality of detecting the range between itself
and another object is largely overlooked.
This sensor could easily be replaced with
a passive infrared motion detector. This
would likely fix our reliability issue with
the sonar sensors returning erroneous data
after 10 to 15 minutes of use. Using a wireless communication protocol would greatly
enhance the usability of the system, and
make installation much easier. However
7

Embedded Systems Design Fall 2015

the wireless communication would add additional complexities within the software
and hardware designs.

IX.

Conclusion

Though the end device was a functional

prototype, there were several design flaws

within the system that would need to be

addressed before the system would be completely functional. The wired communication would need to be upgraded to a wireless communication protocol this would
allow for simpler installation. Overall, the
project was successful in achieving most of
the outlined goals in an acceptable manner.