Wifi RFID Scanner

UNIVERSITEIT•STELLENBOSCH•UNIVERSITY
jou kennisvennoot • your knowledge partner
Design Of An Automated
Class Attendance Recording System
by
Carel van Wyk

14543109
Project E448
Report submitted in partial fulfilment of the requirements of

the module Project (E) 448 for the degree Baccalaureus in
Engineering in the Department of Electrical and Electronic
Engineering at the University of Stellenbosch
Supervisor: H.R. Gerber
October 2008
Acknowledgements
I would like to express my sincere gratitude towards the technical and teaching staff of
the E&E Department of the Stellenbosch University Engineering faculty. Without their
professional and friendly assistance, this project would not have been realisable.
I would like to thank the following people specifically:
• Mr H.R. Gerber
• Mr Ashley Cupido
• Mr Ralph A. Dreyer
• Mr Quintis Brandt
• Mr Wessel Croukamp
• Mr Charles S. Fredericks
• Mr Johan Arendse
i
Declaration
By submitting this report electronically, I declare that the entirety of the work contained
therein is my own, original work, and that I am the owner of the copyright thereof (unless
to the extend explicitly otherwise stated) and that I have not previously in its entirety or in
part submitted it for obtaining any qualification.
Signature: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.P.J. van Wyk
Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copyright ° c 2008 Stellenbosch University

All rights reserved.
ii
Abstract
The goal of this project is to design and develop a fully functional automated class attendance
register system, including hardware, firmware and application software. The project makes
use of RFID and Wifi technology, and basic research of RFID equipment was conducted. It
was shown that an effective attendance register system can be implemented with the help of
new and emerging technologies. ConnectOne’s iWifi module is used for Wifi communication.
Python is used as far as possible in the development of application software. The application
software will be integrated with H.R. Gerber’s MyStudies application and server. This report
provides background information and an introduction to the project, a system level design
overview and detailed design solutions. Tests and measurements are also provided in the
final chapters.
iii
Uittreksel
Die doel van hierdie projek is om ’n volledige klasbywonings-register stelsel te ontwerp en te

implimenteer. Dit sluit in die ontwerp van hardeware, ’middel’-ware en sagteware. Die pro-
jek maak gebruik van ’RFID’ tegnologie en ’Wifi’ draadlose kommunikasie. Die werking van
’RFID’ is oppervlakkig ondersoek. Daar word gewys dat ’n effektiewe klasbywonings-register
stelsel met behulp van nuwe en opkomende tegnologie ontwikkel kan word. ConnectOne se
’iWifi’ module word gebruik vir draadlose kommunikasie. ’Python’ is so ver as moontlik
gebruik in die skryf van sagteware. Die stelsel se sagteware sal met H.R. Gerber se ”MyS-
tudies”program en bediener integreer. Hierdie verslag voorsien ’n agtergrond en inleiding tot
die projek, so wel as ’n stelsel vlak oorsig en detail ontwerpsoplossings. Toetse en meetings
word ook voorsien in latere hoofstukke.
iv
Contents
Declaration ii
Abstract iii
Uittreksel iv
Contents v
List of Figures viii
List of Tables ix
Nomenclature x
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Scope and Aims of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Introduction to Other Chapters . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 System Analysis and Design 4

2.1 System and Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Technologies Utilised . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Study of RFID technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 General concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Stellenbosch University Implementation . . . . . . . . . . . . . . . . . 8
2.3 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Chapter 2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Detail Hardware Design and Synthesis 10

3.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Student Identification Scanner . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Keypad or Touchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
v
CONTENTS vi
3.1.4 Interface PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Processing and Communications Unit . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Wireless Communications Module . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Antenna Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Memory Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5 Real Time Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.6 Bus Expander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.7 RS232 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.8 USB Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.9 Processing and Communications PCB . . . . . . . . . . . . . . . . . . 20
3.3 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Power Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Voltage Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Battery Charger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.4 Power Supply Control . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.5 Battery Level Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.6 Power Supply PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Chapter 3 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Detail Software Design and Synthesis 27

4.1 Database Table Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Attendance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 ClassInstance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3 Notes Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.4 classtype Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 LCD Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 iWifi configuration website . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1 index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 status.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.3 sync.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Lecturer Administration GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Wifi to MyStudies interface Server . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Thin Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Testing and Integration 32

5.1 Testing Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.1 Wifi Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.2 RFID Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.3 Printed Circuit Boards . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.5 LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.6 Touchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.7 Voltage Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CONTENTS vii
5.1.8 Battery Charger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.9 Other Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Integration of Hardware Components . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 Processing and Communications Unit . . . . . . . . . . . . . . . . . . 37
5.2.2 User interface module . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.3 Power Supply module . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Testing Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Integration of Software Components . . . . . . . . . . . . . . . . . . . . . . . 38
6 Measurements and Results 39

6.1 Hardware Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 iWifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2 RFID Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.3 3.3V Voltage Rail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.4 5V Voltage Rail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.5 Battery Charger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Total Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3 Software Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Conclusion and Recommendations 44

7.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Bibliography 46
A Project Planning Schedule 47
B Project Specification 48
B.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.1.2 Software and Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C Outcomes Compliance 51
D Circuit Diagrams and PCB layouts 53
E Photos and Screenshots 59
F Source Code 62
F.1 Secure Interface Webserver Prototype . . . . . . . . . . . . . . . . . . . . . . 62
F.2 iWifi configuration page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
F.3 RFID and iWifi Communcations Handling Module . . . . . . . . . . . . . . . 63
List of Figures
2.1 Design decision flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Tree-level diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Airgap Interface between card and scanner . . . . . . . . . . . . . . . . . . . . 8
3.1 Calibrated LCD resistor values. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Li-Ion Output Voltage Depletion Chart[1] . . . . . . . . . . . . . . . . . . . . 22
6.1 Low-power operation regulated output with max and min input voltage. . . . . 41
6.2 Full-power operation regulated output with max and min input voltage. . . . . 41
D.1 User Interface Module Schematic . . . . . . . . . . . . . . . . . . . . . . . . . 54

D.2 User Interface Module PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.3 Processing and Communications Unit Schematic . . . . . . . . . . . . . . . . . 56
D.4 Processing and Communications Unit PCB . . . . . . . . . . . . . . . . . . . . 57
D.5 Power Supply Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
E.1 Photo of user interface ontop of processing and communications unit. . . . . . 59

E.2 Screenshot of wifi configuration page. . . . . . . . . . . . . . . . . . . . . . . . 60
E.3 Screenshot of administration GUI. . . . . . . . . . . . . . . . . . . . . . . . . . 60
E.4 Screenshot of secure interface webserver. . . . . . . . . . . . . . . . . . . . . . 61
viii
List of Tables
3.1 Student Identification Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Wireless Communications Module Solutions . . . . . . . . . . . . . . . . . . . 15
3.3 Possible Microcontroller Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Rechargeable Battery Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Estimated Current Consumption . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Available 3.3V Regulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Available 5V Regulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Measurements taken at different input voltage levels for low-power operation. . 40
6.2 Measurements taken at different input voltage levels for full-power operation. . 41
A.1 Project Planning Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
ix
Nomenclature
Acronyms
WWW - World Wide Web
Wifi - 802.11b/g wireless network standard
RFID - Radio-Frequency Identification
USB - Universal Serial Bus
LF - Low Frequency
UHF - Ultra High Frequency
ISO - International Organization for Standardization
WORM - Write Once Read Many
LCD - Liquid Crystal Display
LED - Light Emitting Diode
MCU - Microcontroller
PCB - Printed Circuit Board
GSM - Global System for Mobile communications
IO - Input/Output
GPIO - General Purpose Input/Output
GUI - Graphical User Interface
UART - universal asynchronous receiver/transmitte
EEPROM - Electrically Erasable Programmable Read-Only Memory
RAM - Random Access Memory
RTC - Real Time Clock
DIP - Dual Inline Package
IC - Integrated Circuit
LDO - Low Dropout
bps - Bits per second
x
Chapter 1
Introduction
This chapter provides an introduction to this report, and provides background information
to the project. It includes a definition of the problem, and states the scope and aim of this
project. An introduction to following chapters are provided at the end of this chapter.
1.1 Background
Up until now, class attendance records have been maintained manually by having students
sign next to their names on printed class lists during class. This method is outdated and
time-consuming, and may be improved by applying technology and designing an automated
electronic class attendance recording system.
There are many cases in which it would be beneficial for the University of Stellenbosch to
be in possession of an automated class register system. Such a system would be of most value
to students, who may make use of system reports and statistics to assess their own approach
to their studies, and be kept informed about course material covered in classes attended and
missed.
An automated attendance recording system would be advantageous to the lecturer, by
providing data on student attendances which may be correlated with a student’s academic
progress.
Attendance recording is an important aspect of tests and exams, where a record must be
kept of students writing the paper.
Finally, such a system could provide evidence of a student’s class attendance habits in
cases where the University is accused by a student of providing insufficient guidance in
lectures. In such cases, the University holds no liability if it can be showed that the student
was regularly absent from class.
1.2 Problem Definition

This project is derived from a topic suggested by Mr. H.R. Gerber for the development of an
automated class attendance recording device. The device must positively identify students
and provide reliable class attendance logs for the benefit of students, lecturers and the Uni-
versity, as described in the previous section.
1
CHAPTER 1. INTRODUCTION 2
Attendance logs must be stored on a centralised database in order to generate reports and
statistics. Therefore, the device must be able to communicate with a central database server.
Students should be able to access information and personalized reports generated by the
system for effective self-assessment and keeping up to date. Lecturers should be able to view
attendance information and be able to add information to the system.
The system should also provide appropriate administration interfaces for administering the
recording devices and system parameters.
1.3 Scope and Aims of Project

As part of the original project proposal, it was specified that the student identification device
make use of RFID scanner technology, and that the device should be able to communicate
via wireless with the central database server. As such, using an RFID scanner and wireless
communications is part of the project scope, however alternatives to RFID and wireless com-
munication is discussed in Chapter 3 section 3.1.1 and 3.2.1 of this report.
The aims of this project are, in order:
• Provide a mobile RFID scanner device capable of scanning student cards with embedded
RFID chips and processing the data on the card.
• Provide a software suite to log information about scanned cards against a database and
provide detailed statistics and feedback about attended and missed classes to students
and the lecturer. The software suite must include sufficient administration capabilities.
• Provide a wireless interface between the scanner and database server.
• Maximize battery life of the mobile scanner device and provide a simple USB-charger
interface.
The scope of this project includes designing and assembling the mobile, Wifi enabled,
student card scanning device, designing and writing the firmware required for operating the
device, and designing and writing a full software suite for managing multiple scanning de-
vices and providing detailed feedback to students and lecturers as described in the project
specification in appendix B. The software suite must be integrated with H.R. Gerber’s MyS-
tudies framework as far as possible. The scope of this project does not include an in-depth
theoretical study on a particular subject.
CHAPTER 1. INTRODUCTION 3
1.4 Introduction to Other Chapters

Chapter 2 specifies the design process used, and states design limitations. It includes an
analysis of the problem, the design process and a system level analysis.
Chapter 3 and 4 contains detailed design considerations for all leaf-node components of this
project, as defined in chapter 2
Chapter 5 contains testing and integration information.
Chapter 6 contains recommendations and a conclusion to the project.
Chapter 2
System Analysis and Design
The design approach used in this project involves breaking the main system up into subsys-
tems called ’branches’. Each subsystem branch may be broken up further into subbranches,
and subbranches may again be broken up into ’leaf-nodes’, which represent the lowest level
of subsystems. This method forms a tree-like structure overview of the system as represented
in figure 2.2. In this way, system level analysis and design is done by looking at the over-
laying structure of the system, while detail design is limited to the leaf nodes. At the lowest
level, components and design methods are chosen based on functional and non-functional
requirements and design constraints.
Once the lowest levels of sub-systems are designed, they are integrated and tested in a
’Bottom-up’ approach until all subsystem branches are combined into the all encompassing
top-level system. In essence, a ’Top-Down’ analysis and design method with ’Bottom-Up’
integration and testing process is used. Figure 2.1 is a flow-chart representation specifying
the design approach used for this project, with inherent awareness of design constraints and
limitations.
Focusing on designing subsystems provides an advantage in that once one sub-system’s
design is completed, it may be sent in for manufacturing while design of the other subsystems
can continue in parallel with manufacturing, which saves time. If one subsystem fails, it can
be redesigned without influencing other sub-systems, and in this way valuable time is saved.
4
CHAPTER 2. SYSTEM ANALYSIS AND DESIGN 5
START
Can System be Yes Identify functional

broken up into requirements.
subsystems? Create new branch.
No
Create Leaf-Node.
Find suitable component
based on functional
requirements.
No
Does the component adhere

to non-functional requirements
and design constraints?
Yes
Use Component
Figure 2.1: Design decision flow chart
2.1 System and Design Overview

Before subsystems can be identified, the functional requirements for this project must be
identified first. The requirements have been derived from the original project proposal by
H.R. Gerber and are available in appendix B. Analysing the problem as defined in 1.2 then
becomes simple. By examining the project requirements, a tree-level diagram of subsystems
is created which represents a full system level overview.
The tree diagram in Figure 2.2 represents the system level analysis of the problem
defined in 1.2. The three main parts of the system is the hardware, firmware and application
software components. Hardware can be broken up into three main modules: A power supply,
a processing and communications module and a user interface. The firmware will control the
hardware and manage the interfaces between the hardware, application software and the user.
The application software component can also be broken up into three logical subsections: The
database, GUIs and wireless device administration and synchronisation. The bottom-level
or leaf-nodes are discussed in chapters 3 and 4.
2.1.1 Technologies Utilised

RFID
As per the project specification, an RFID scanner is used for student identification. A brief
study of RFID is included in the next section.
Figure 2.2: Tree-level diagram
802.11b/g Wifi
The mobile scanner device will use an 802.11b/g Wifi module to communicate with the
Stellenbosch University campus wide wireless network, ’Maties Wifi’.
Capacitive Sensors
The scanner device will use a capacitive sensor array for user input as opposed to a keypad.
Capacitive sensor technology is discussed further in section 3.1.3.
MyStudies
MyStudies is a framework for the management of students, courses, classes and work. It
consists of a server written in python with a SOAP interface and mysql database back-end,
that serves wxpython based GUI clients. This project’s application software will be integrated
with the MyStudies framework and will rely on the MyStudies server for data storage and
management.
SOAP
SOAP is a protocol that allows exchange of XML-based messages over HTTP or HTTPS. It
is the main transport method of data used in the MyStudies framework and this project.
Python
Python1 is a highly versatile and dynamic interpreted programming language. It will be
used as the basis for most application software in this project with the exception of device
firmware and configuration webpages. Python really is a remarkable language that provides
powerful libraries, and allows for rapid prototyping and development. VisualWx was used
for making WXPython based GUIs.
Twisted
Twisted2 is an event-driven networking engine programmed in Python. Twisted.Web is used
as webserver instead of apache to allow direct integration of the python based web server
code and other python based application software code. Data is transferred from the wireless
scanner device to a Twisted.Web server webpage via HTTP POST. The data is parsed and
then submitted to the MyStudies server via SOAP.
MySQL Database
MySQL is a relational database that is used by the MyStudies framework. The MySQL
database will be used for all data storage in this project.
2.2 Study of RFID technology

As RFID is an integral part of this project, the literature study focuses on a white paper on
RFID technology released by BITKOM[2], German Association for Information Technology,
Telecommunications and New Media.
2.2.1 General concept

RFID, or Radio Frequency Identification, relies on two main components: The RFID scanner
or reader and the RFID tag or transponder. For the one to communicate with the other,
both must make use of the same carrier frequency, with RFID frequencies currently ranging
from 125 kHz in the LF range to 5.8 Ghz in the UHF range[2]. Additionally, a secured system
may make use of cryptographic functions for one-way or two-way identification.
1
www.python.org
2
http://twistedmatrix.com/
2.2.2 Antenna
According to BITKOM[2], the typical read-range of ISO 14443 based cards (as used by
Stellenbosch University) are 7-15cm, even though tests mentioned elsewhere in this report
shows proximity distances of 1.6cm or less for this report’s specific application. In short
read-distance applications like this, the tag is within the near-field of the reader antenna’s
electromagnetic wave pattern when it is scanned. The card’s antenna is in the form of a
coil or inductive loops that run around the edge of the card, and the card’s RFID microchip
is powered by energy transferred from the reader to the card antenna’s inductive loops via
magnetic coupling[3].
2.2.3 Modulation
Figure 2.3: Airgap Interface between card and scanner
In essence, the connection between the reader and card is represented by an airgap in-
terface which is the distance the card is held from the scanner when it is being read. The
’airgap interface’ is represented by various layers[2]:
• On the physical layer, the card and reader are linked by an electromagnetic wave that
couples the reader and card antennas at a specific carrier frequency. This is represented
in figure 2.3.
• To enable a layer of communication, information must be modulated on the wave.
• On the logical layer, the structure of commands and data are specified by ISO or other
proprietary standards. It is important that all layers of the air interface adhere to
global standards in order to ensure compatibility with other RFID systems worldwide.
2.2.4 Stellenbosch University Implementation

The RFID tags embedded in Stellenbosch University student cards are Write Once Read
Many (or WORM) modules, with 26 bytes of user data, including 8 bytes representing the
student’s unique student number and 4 bytes representing the year of issue. These cards
operate at 13.56MHz and makes use of the ISO 14443 based, MIFARE secure encoding
standard, which has been shown by Nohl and Plotz[4] to have critical security vulnerabilities.
The RFID reader units used by the University are Model 718-10 scanners from GSC systems.
2.3 Design Constraints

One of the most important factors in deciding on a design process is to be fully aware of design
constraints and limitations. The chosen design process for this project aims to minimise the
impact of design constraints, and to defer design limitation resolution to the leaf-nodes (or
bottom design layers). This project was subject to several key design limitations which is
listed here:
Budget: With a limited project budget, it is not possible to simply select the first and best
option that presents itself. Care must be taken to minimize component and manufac-
turing costs and sometimes creative solutions need to be found for problems that may
be solved by more expensive components, but that will overshoot the budget too far.
Time: With a timeframe of 4 to 5 months to complete literature studies, hardware and soft-
ware design and synthesis, obtain all components and write a project report, the design
process must be optimized to maximize productive time. Design processes may take
place in parallel if properly coordinated, for example: software development may take
place while hardware components are being manufactured. Readily available compo-
nents must be selected as far as possible and critical non-readily available components
must be available in time.
Limited availability of passive components: Even though surface-mount resistors, ca-

pacitors or inductors may work better in some situations, these components are not
readily available in faculty stores. As these components are purchased in reels of thou-
sands and typically only one or two of specific values are required at a time, it is not
feasible to purchase such components on the project’s budget. Other examples of lim-
ited components include basic elements such as screw terminals, spacers, screws and
stand-offs.
Limited manufacturing capabilities: In some cases, the design process has to rely on
manufacturing facilities available at the Electronic Engineering faculty, as professional
manufacturing would overshoot the budget too far. In some cases, this limits component
selection and other design aspects.
2.4 Chapter 2 Conclusion

A system level design overview of the project can easily be seen in figure 2.2. As mentioned
in 2.1.1, this project implements several cutting edge and exciting technologies, both in
terms of hardware and software, to solve design problems.
Chapter 3
Detail Hardware Design and Synthesis
As discussed in section 2.1, the leaf-nodes of the hardware branch of the design tree are
analysed in this chapter. The design process used is specified in chapter 2 and is represented
by figure 2.1. From the tree-level diagram in figure 2.2 it can be seen that the hardware
components of the project can be broken up into three main sub-systems: The power supply,
processing and communications unit and user interface.
3.1 User Interface

3.1.1 Student Identification Scanner
The project specification requires RFID to be used for student identification, and the RFID
scanner must be provided by the University’s access control department since it is preconfig-
ured with encryption keys for Stellenbosch University student cards. Therefore, there were no
design choices possible for this hardware component, although alternatives are listed below.
Student cards are the primary method of student identification on campus. From the start
of 2007, all Stellenbosch University student cards are equipped with an RFID chip that can be
read by holding it briefly against a configured proximity sensor. Due to its ease of use, RFID
technology is perfectly suited for use in an automated class attendance recording system.
The advantages of using RFID are speed (cards can even be scanned through wallets), and
availability (students should have their cards available at all times). The disadvantages of
RFID are that students could lose their student cards, and that students could ’lend’ their
cards to their friends to have it scanned for them. In the former case, a class list may still be
made available for individuals without cards and the latter case is outside the scope of this
project.
Table 3.1 represents a list of possible solutions to the problem of student identification.
For this project, the GSC systems Model 718-10 Mifare RFID scanner is used.
Requirements
• Minimum 5V voltage rail.
• Approximately 120mA @ 5V according to datasheet.
10
CHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 11
• RS232 receiver @ 19200 bps baudrate
Name Description Advantages Disadvantages

RFID RFID chips embedded in all stu- Fast, Efficient, Card may be
dent cards. Availability given to friend
for scanning.
Biometrics Finger print or retina scanner. Absolute posi- Very expensive,
tive identifica- Slow
tion
Magstripe The magnetic strip on all student Availability Slow, Wear and
cards. Tear, Old tech-
nology, Card
may be given
to friend for
scanning
Table 3.1: Student Identification Solutions
3.1.2 LCD
A standard 16-pin KS0066U or equivalent alphanumeric LCD is used for user output. As with
most components, the primary design constraint for this component is cost, and the secondary
design constraint is size. A standard 20x2 characters LCD was chosen for maximising output
space while minimising cost and physical dimensions.
For this project the model 202A-FC-BC-3LP from Displaytech was ordered from RS South
Africa. This specific model features black on white text with a white LED backlight for a
more modern and professional look than a yellow on green LCD. The LCD will be operated
in 8-bit mode, as opposed to 4-bit mode, to increase display speed. Two control lines are
also required.
The LCD requires three resistors: Two determine contrast and one determines backlight
brightness. The method for choosing these resistors was by first connecting the corresponding
resistors pins to variable resistors and tuning the resistor parameters until optimal contrast
and brightness levels was found.
Figure 3.1 represents the calibrated resistor configuration for determining LCD contrast
and brighness.
Requirements
• Minimum 5V rail.
• Approximately 10mA @ 5V operating current + 20mA @ 5V backlight current.
• 8+2 General Purpose I/O lines directly to the MCU

Figure 3.1: Calibrated LCD resistor values.
3.1.3 Keypad or Touchpad

For user input, the conventional choice would have been a matrix keypad, but it was decided
that a more exciting and creative approach would be appropriate for this project, since other
central components used in this design (such as the RFID scanner and Wifi module men-
tioned later) are also examples of new and interesting technologies.
The ISQ221 proximity sensor chip from Paarl based company, Azoteq, provides a capac-
itive sensor array with binary outputs. This means that a custom touchpad can easily be
manufactured by etching conductive pads and tracks on a standard PCB. A touchpad also
offers several advantages over a traditional keypad:
• There are no mechanical components that can wear out over time.
• Buttons can take any shape, form or layout. This allows for custom and creative
touchpad designs.
• When a button pad is touched, a binary 1 is immediately output on the corresponding

output channel, as opposed to a matrix keypad that requires scanning which takes
several clock cycles.
• The IQS221 is designed and supported locally in Paarl, less than 40km from Stellen-
bosch.
See below for a basic explanation of capacitive sensors. A photograph of the user inter-
face’s custom touchpad is available in appendix E, as figure E.1.
Capacitive Sensors
LionPrecision[5] describes capacitive sensors as follows:
’Capacitive sensors use the electrical property of capacitance to make measure-

ments. Capacitance is a property that exists between any two conductive surfaces
within some reasonable proximity. A change in the distance between the surfaces
changes the capacitance. It is this change of capacitance that capacitive sensors
use to indicate changes in position of a target.’
For this project, the IQS221 evaluation module, model AZP075A05-2008, was obtained
from Azoteq.
Requirements
• Minimum 3.3V voltage rail
• 190uA operating current @ 3.3V
• 8 digital inputs, each corresponding to one touch pad. Connected either directly to the
MCU or to a bus expander.
3.1.4 Interface PCB

The PCB and schematic for the user interface module is available in appendix D. There is
no critical design constraints involved in the user interface’s PCB design. The only notable
aspect of this PCB’s design is the custom touchpad area, as discussed in section 3.1.3. Oth-
erwise, some care was taken to ensure proper mounting of the LCD, touchpad controller
module, RFID scanner and the other two project PCBs (Processing and communications
module and power supply module).
3.2 Processing and Communications Unit

The processing and communications unit is the core of the hardware device sub-systems
that the other sub-systems connect to. It handles processing and storage of data, provides
wireless communications and provides the appropriate interfaces for the power supply and
user interface module to connect to. The most integral leaf-node component (As defined
in chapter 2) of this subsystem is the wireless communications module. All other leaf-node
design choices for this sub-system must be compatible with the choice of wireless module.
3.2.1 Wireless Communications Module

The most integral design aspect of the processing and communications unit is the wireless
communications module, and therefore much care was taken in finding a suitable module.
Table 3.2 represents several possible solutions to this problem1 :
Protocol Selection
There are three main wireless protocols represented in the table 3.2 table: Zigbee, Bluetooth
and Wifi. The main design consideration for this component is compatibility with existing
wireless infrastructure in order to maximise operating range and minimise additional costs
and design, such as custom base station hardware. Stellenbosch University boasts a campus-
wide Wifi network, ’MatiesWifi’. Interoperability with this network will ensure wireless
connectivity across campus and in all classrooms, which makes it ideal for the objectives of
this project. Therefore, the wireless communications module choice is narrowed down to the
802.11b/g Wifi modules.
Module Selection
From the advantages and disadvantages columns in the table 3.2, it was concluded that the
most attractive option for this application is the Mini Socket iWifi module from ConnectOne.
It also happens to be least expensive of the Wifi modules (R470 at time of purchase), and is
only slightly more expensive than a Bluetooth or Zigbee solution.
The iWifi is an impressive piece of technology that lives up to all expectations. Released
in July 2008, it was very fortunate that one could be obtained in time for use in this project.
Core features include ease of use, an embedded web server, an AT command set via UART
and support for the following protocols[6]:
Internet Protocols: ARP, ICMP, IP, UDP, TCP, DHCP, DNS, NTP, SMTP, POP3, MIME,
HTTP, FTP and TELNET
Security Protocols: SSL3/TLS1, HTTPS, FTPS, RSA, AES-128/256, 3DES, RC-4, SHA-
1, MD-5, WEP, WPA and WPA2
The author can strongly recommend this module for use in future projects that require Wifi
communication capabilities.
1
Dollar to Rand conversion done using R8 per $1
Name Description Advantages Disadvantages Price

Jennic (Zigbee Low Power consump- Low data rate, Short R260
JN5121 802.15.4) Used for tion, Compact, Sim- Range (20m indoors), +
wireless personal ple, Combined wire- Requires base stationR800
area networks less module and MCU hardware Pro-
(WPANs). Simpler gram-
than Bluetooth. mer
Bluetooth (802.15.1) Used Low power consump- Low data rate, Short R460
for Wireless Per- tion, Compact, Uni- range
sonal Area Net- versal hardware (lap-
works. tops, PCs), AT com-
mand set interface
GSM (GSM 07.07) Universal hardware High power consump- R160
Global System for (mobile phones, tion, Data transmis- to
Mobile communi- laptops, PCs), AT sion not free R930
cations. Used for command set inter-
data transmission face, Higher Datarate,
by mobile phones. Very long range
RabbitCore (Wifi 802.11b/g) Universal hardware Relatively high power R790
RCM5400W Wifi enabled MCU (laptops, PCs, APs), consumption, Expen-
with 39 GPIO and High datarate, Pro- sive
512K Flash mem- grammed over serial,
ory Standard external
antenna connector,
long range
Ezurio (Wifi 802.11b/g) Universal Hardware No external antenna, R1045
WISMC01 Wifi enabled MCU (laptops, PCs, APs), Shorter range than
with 12 GPIO, 2 High datarate, Pro- other 802.11 modules,
10bit A/Ds and grammed over serial, Expensive
UART Relatively Low power
consumption
ConnetBlue (Wifi 802.11b/g) Universal Hardware Very expensive R1450
SPA311G Wifi module only (laptops, PCs, APs),
with AT command- High datarate, AT
set. Requires con- over UART interface,
trolling MCU. External antenna con-
nector, Long range,
Compact
ConnectOne (Wifi 802.11b/g) Universal Hardware Relatively high power R470
Mini Socket Wifi module only (laptops, PCs, APs), consumption (but less
iWifi with AT command- High datarate, AT than some other wifi
set and onboard over UART interface, modules)
web server. Re- External antenna con-
quires controlling nector, Long range,
MCU. Compact
Table 3.2: Wireless Communications Module Solutions
iWifi Requirements
• Minimum 3.3V (Maximum 3.6V) voltage rail
• 250 mA @ 3.3V for transmit, 8 mA @ 3.3V in power save mode
• One UART channel
• Any standard reverse polarity SMA connector dipole antenna
3.2.2 Antenna Selection

Any standard reverse polarity SMA connector 2.4 GHz antenna may be used with this mod-
ule. A 2.5dBi dipole antenna is recommended by ConnectOne, and one was ordered along
with the iWifi module from Mouser.com. Larger dipole antenna’s up to 9dBi is available
from Scoop Distributions2 in Cape Town. Range tests are available in Chapter 6.
2
www.scoop.co.za
3.2.3 Microcontroller
Choosing a microcontroller is not a critical design consideration of this project. Any generic
MCU with enough General Purpose IO pins, UART channels, an I2 C bus, and flash memory
will be sufficient. As with all leaf-nodes, non-functional requirements carry the most weight
in choosing the component, and therefore availability of the MCU chip and MCU programmer
played the most important role in this case. Table 3.3 presents the three possible MCU’s
that was readily available along with their programmers.
Name Description Advantages Disadvantages

Renesas 32 pin, 20Mhz general pur- Immediately avail- No Built-in RS232
R8C/27 pose MCU used in Design able, 32 pin wide
E314. DIP socket.
Renesas 62 pin general purpose Faster than mount LQFP64,
R8C/2B MCU. Advanced version of R8C/27, More Not immediately
the R8C/27 flash memory available, No
Surface built-in RS232
Microchip 28 pin general purpose Built-in RS232 in- Unfamiliar plat-
PIC18F2550 MCU. terface form
Table 3.3: Possible Microcontroller Solutions
There are no defining characteristics that put one MCU above the other. Therefore
the R8C/27 which was available immediately along with its programmer was chosen, even
though either of the other two chips would have been adequate. Furthermore, the R8C/27 is
inexpensive, and offers a familiar embedded development platform and requires little power.
Operating Voltage
One important design consideration regarding the microcontroller is its operating voltage,
as this will affect interfacing with components that operate at voltage levels different from
the MCU. Since the wireless communication module can handle an absolute maximum of
3.6V, and is considered one of the integral components of this project, it was decided that
the MCU operate at the same voltage as the wireless module at 3.3V to eliminate the need
for level translators.
Requirements
• 3.3V to 5V input voltage
• 32.768 kHz crystal
• Approximately 10mA @ 3.3V

3.2.4 Memory Module

The memory module must provide non-volatile data storage for when the scanning device is
out of range or in case of power loss. Any flash memory module with at least 8 kilobytes
of RAM will be sufficient for this project’s purposes. An M24C64 EEPROM module with
8 kilobytes of memory and I2 C interface was chosen as it was immediately available, has a
small footprint and is simple to program. The memory map of the EEPROM module for the
Wifi RFID scanner device is available in chapter 4.
Requirements
• 3.3V to 5V input voltage
• I2 C interface
• 5uA in standby mode, 2-5mA in read/write mode
3.2.5 Real Time Clock

A real time clock component will keep track of time, even if the device loses power, by means
of a separate battery backup. As motivated in 3.2.9, it was decided that the processing and
communications module PCB consist only of through-hole components. At time of writing,
there is only one I2 C real time clock available from RS South Africa3 in 8 pin DIP format,
the DS1307+ from Maxim-IC4 , and it was chosen for this project. Any I2 C RTC would have
been sufficient for this design. The DS1307 provides an ultra-low battery backup mode at
500nA with a 3V battery backup power supply, while the standard operating voltage for
reads and writes are 5V.
Requirements
• 32.768 kHz crystal
• 5V Input
• 1.5mA supply current @ 5V
• I2 C interface
• 3V battery + battery clip
3.2.6 Bus Expander

A bus expander interface is useful for key- or touchpad input. It frees up valuable general
purpose IO pins on the microcontroller and also provides suitable interrupt functionality. For
instance, a bus expander can generate an interrupt if any of its input pins change state, so
that the microcontroller is notified of a key change event, and need to poll the bus expander
3
www.rssouthafrica.com
4
www.maxim-ic.com
only once in order to determine which key was pressed. This method is opposed to connecting
a key- or touchpad directly to the MCU where pins would have to be polled continuously.
Since there are already two other components that make use of the I2 C bus, the bus
expander will also make use of I2 C. Any general purpose bus expander with 8 or more input
pins, an I2 C interface and an interrupt output pin is suitable for this project. The MCP23017
was chosen since it meets all these conditions and was instantly available.
Requirements
• 3.3V to 5V operating voltage
• 1mA operating current @ 3.3V
• I2 C interface
• One interrupt line
3.2.7 RS232 Interface

The RFID scanner outputs scanned student card data in RS232 format. The renesas R8C/27
microcontroler chosen for this project does not include a built-in RS232 interface. Where
UART represents a logical 1 with Vhigh and a logical 0 with Vlow , RS232 represents a logical 1
with -12V and a logical 0 with +12V[7]. The R8C is unable to generate these output levels,
so an RS232 interface chip is required. Since it was decided in 3.2.3 that the microcontroller
operate at 3.3V, the RS232 interface chip must also operate at 3.3V.
Two pin-identical DIP18 chips were obtained: The LTC1385 from Linear Technologies5
and the MAX3222CPN+ from Maxim-IC6 . These two chips are identical in almost all regards,
both are low-power chips, both operate at 3.3V and provide two RS232 to UART interface
channels, and they have identical pin-outs. There are only two differences. The first being
that the LTC1385 has electrostatic discharge protection while the MAX3222 does not, and
the second being that the LTC1385 actually supports EIA/TIA-562 (which is the low-voltage
version of RS232), while the MAX3222 supports true RS232. Both are compatible with the
RFID scanner.
Since both chips were already available, the LTC1385 was chosen, although it could be
swapped with the MAX3222 without any changes in PCB layout or component design.
Requirements
• 3.3V input
• 200uA @ 3.3V input operating current
• One UART channel
5
linear.com
6
maxim-ic.com
3.2.8 USB Communication

It was decided that USB communication between the Wifi scanner device and a host device is
an unnecessary feature. Even though it would be trivial to implement, USB communication
requires additional UART to USB conversion hardware and will only increase costs. Imple-
menting wired communication on a wireless device defeats the purpose of using a wireless
communication module.
If serial communication with a host device is required, it can easily be implemented by
using the unused secondary channel on the RS232 interface chip.
3.2.9 Processing and Communications PCB

The PCB and schematic for this module is available in appendix D. The processing and
communications PCB was the first to be completed, and at the time of layout there was
still uncertainty regarding the level of detail available in the manufacturing process made
available at the electronic engineering faculty. As such it was decided that components for
this PCB be limited to through-hole components and that surface-mount components be
eliminated. This also had the advantage of a simplified PCB design and use of more robust
components.
3.3 Power Supply

Design of the wireless scanner’s power supply is dependant on the requirements of all other
chosen hardware components. The DC voltage regulators are dependant on the requirements
of the other components used in hardware design, and the DC voltage source is dependant
on the power required by the voltage regulators.
3.3.1 Power Source

The project specification indicates that the scanner device must be mobile; therefore the
power source must be a battery. The battery must adhere to the following requirements:
• It must be rechargeable.
• It must have large capacity.
• It must be compact with an optimal energy density ratio.
• It must have a long lifespan.
• It must be able to deliver enough peak-current.
Table 3.4 lists possible battery solutions:
Type Nominal Voltage[V] Energy Density [Wh/kg] Lifespan [years]

Alkaline 1.5 85 <5
Ni-Cad 1.2 60
NiMH 1.2 80
Li-Ion 3.6 160 2-3
Li-Poly 3.7 130-200 2-3
Table 3.4: Rechargeable Battery Types
All batteries in the table are capable of delivering sufficient peak current for this project’s
application. From table 3.4, it was decided that a Li-ion cell be used, as it features a high
energy density ratio and is readily available. Figure 3.2 provides a graph of estimated battery
terminal voltage in terms battery depletion.
Two 2400mAh TrustFire Protected 18650 Lithium-Ion Batteries were ordered from DealEx-
treme7 at R45 per cell8 . This battery received overwhelmingly positive reviews and includes a
protective embedded PCB for short-circuit, overcharge and discharge protection. The author
can strongly recommend these cells for any mobile application.
7
www.dealextreme.com, stock number sku.5776
8
At an exchange rate of R8 per 1 USD
Figure 3.2: Li-Ion Output Voltage Depletion Chart[1]
3.3.2 Voltage Rails

Inspection of the other leaf-nodes of the hardware design branch, as indicated in figure 2.2,
indicates that two voltage rails are required: 3.3V and 5V. A rough estimation of the power
consumption for each rail must be made in order to determine the required power rating of
each rail’s regulator.
Assessment of the previous sections in this chapter shows the following components for
each rail, with their estimated peak current consumption:
3.3V Rail: Touchpad (190uA), Wifi (250mA), MCU (10mA), memory (5mA), bus expander
(1mA), RS232 (200uA)
5V Rail: RFID scanner (120mA), LCD (30mA), RTC (1.5mA)
As shown in table 3.5, the 3.3V regulator must be able to source a minimum of 293mA
peak current, while the 5V regulator must be able to source at least 167mA. The 5V regulator
must also include a disable/shutdown option, to provide an enhanced sleep mode for the
device
The requirements for both regulators are:
• It must be ultra-efficient.
3.3V Rail 5V Rail

Total Estimated Peak Current Consumption 266mA 152mA
10% Safety Factor 26.6mA 15.2mA
293mA 167mA
Table 3.5: Estimated Current Consumption
• It must require minimum external components.
• It must be as stable as possible.
• It must have an enable/shutdown control pin.
• It must be low-dropout (LDO).
3.3V Rail
Since a 3.6V Li-ion voltage source is used, the 3.3V regulator must be a step-down DC-DC
converter. Table 3.6 is a table of 3.3V step-down DC-DC converters that was acquired.
Name Description Maximum Efficiency Input

Output Voltage
Current
Texas In- 2.25Mhz high efficiency syn- 600mA 88 to 94% 2V-6V
struments chronous step-down converter
TPS62260 with low dropout. (Adjustable
version)
Texas In- High efficiency synchronous step- 800mA 90 to 9% 2.7V-10V
struments down converter with low dropout
TPS62056 and low noise operation (Fixed
3.3V version)
Linear High Efficiency Synchronous buck 1200mA 93 to 95% 2.65V-10V
Tech- (step-down) converter with low
nologies dropout. (Adjustable version)
LTC1879
Table 3.6: Available 3.3V Regulators
The Texas Instruments TPS62056 was chosen for the following reasons:
• It provides the highest efficiency.
• It is a fixed output voltage version which means less external components.
• It has a wide input voltage range for use with one or two Li-Ion cells.
• It can provide more than enough output current.

• It is a low noise component.
As the TPS62056 is a fixed 3.3V chip, no calculation of external components was required.
5V Rail
Since a 3.6V Li-ion voltage source is used, while the 5V regulator must be a step-up DC-DC
converter.
Table 3.7 is a table of 5V step-up DC-DC converters that was acquired.
Name Description Maximum Efficiency Minimum

Output Input
Current Voltage
Texas In- High Efficiency Synchronous 600mA 94 to 95% 1.8V
struments boost (step-up) converter. Ad-
TPS61120 justable version.
Maxim- Compact charge-pump (step-up) 250mA 70 to 71% 2.7V
IC regulator with minimal external
MAX682 components. Fixed 5V version.
Linear High Efficiency synchronous 1000mA 83 to 87% 2.5V
Tech- boost (step-up) regulator. Ad-
nologies justable version
LTC1306
Table 3.7: Available 5V Regulators
The TPS61120 was chosen because it provides the highest conversion efficiency and suf-
ficient output current. It is an adjustable version of the component range and therefore
requires more external components and it has an enable/shutdown pin for power save mode.
As the TPS61120 is an adjustable voltage version chip, the following external component
calculation was made: From the datasheet:
R3 = R6 × ( VVFOB − 1)
VF B = 0.5V, VO = 5V. The suggested range for R6 is 180kΩ.
5
Choose R6 = 200kΩ ,then R3 = 200000 × ( 0.5−1 ) = 1.8M Ω
3.3.3 Battery Charger

Much research and searching was done for an appropriate USB battery charger chip for this
project. Initially, the perfect chip was found in terms of total power management. The
Linear Technologies9 LTC 3567 is a high efficiency, next generation USB power manager plus
9
www.linear.com
integrated 1A 3.3V buck-boost (step-up/step-down) regulator for utilizing the full capacity
of the battery. The LTC 3567 includes control via an I2 C interface. Extensive searching
yielded no alternatives that came close to the functionality of the LTC 3567’s model range.
This IC is perfect for this project’s application in all regards, however it was not chosen due
to two design constraints:
• The component footprint is too small and sophisticated for PCB manufacturing at the
engineering faculty. This component requires a professionally manufactured PCB.
• The component requires several external passive components that are not available at
the engineering faculty. As components cannot be purchased in single unit quantities, it
was not feasible to purchase the required external components on the project’s budget.
The author can highly recommend this chip if the necessary equipment and components are
available.
As an alternative, the MAX1811 from Maxim-IC10 was chosen as it was the only USB
charger IC that could be found in a more convenient chip packaging, and that would be
sufficient for use in this project. The MAX1811 turned out to be a very convenient and
easy to use, and the author can recommend it for any application that requires a simple and
effective USB Li-Ion battery charger solution.
MAX1811
The MAX1811 allows configuration of input charge current, output charge voltage, charge
enable/disable and a charge active output pin for control. It also provides preconditioning
that soft-starts near-dead cells before charging, and other safety features. The MAX1811
supports the USB 500mA mode for maximum charge current.
3.3.4 Power Supply Control

Power Save Mode
Since only the RFID scanner, LCD and Real Time Clock (with battery backup) is connected
to the 5V rail, the wireless scanner device can allow the 5V regulator to be disabled when
entering a power saving sleep mode. The device can be awakened from sleep by pushing a
button on the touchpad which will remain active in sleep mode. This functionality requires
the 5V regulator to have an enabled/shutdown pin connected to a microcontroller output.
Charge Control
As the Max 1811 battery charger chip does not include an internal safety timer, the mi-
crocontroller must continuously monitor and regulate battery charging. The microcontroller
must provide safety timer functionality and disable charging once the battery has charged
for 5 hours.
10
www.maxim-ic.com
3.3.5 Battery Level Monitor

The battery’s voltage level will be monitored continuously by connecting the battery voltage
terminals to a microcontroller’s analog-to-digital input through a high-impedance voltage
divider resistor pair. Battery status will be calibrated in the device’s firmware and by exam-
ining figure 3.2 (battery discharge level curve). From the discharge curve, it can be seen that
the voltage range to monitor is between 2.8V and 4.2V. Since the MCU requires a minimum
of 3.3V, the voltage range to monitor changes to 3.3V to 4.2V, since a voltage below 3.3V will
cause system failure. The MCU’s reference voltage is 3.3V. The calculation for determining
resistor pair values:
A maximum leakage current of 50uA is defined and Vbat(max) is 4.2V.
V
Then Ileak(max) > (Rbat(max)
1 +R2 )
4.2
R1 + R2 > 10 × 10 > 84kΩ
−6
The voltage input range to the MCU’s A/D pin must be 0V to 3V.
R1
Thus: Va/d(max) = (R1+R2) × Vbat(max) = 3V
R2 Vbat(max) 4.1
1+ R1
= Va/d(max)
= 3
R2
R1
= 0.3666 , R2 = 0.3666 × R1
Choose: R2 = 33kΩ , then R1 = 90kΩ and R1 + R2 = 123kΩ > 84kΩ
3.3.6 Power Supply PCB

The PCB and schematic for the user interface module is available in appendix D. The crit-
ical power supply chips are all surface mount components, and most specify that external
components be placed as close as possible to the chip’s pins, therefore the PCB was mostly
designed for surface mount components. Additionally, connected ground planes must be used
as far as possible to reduce noise and avoid instability.
The manufactured PCB showed that PCB’s manufactured at the engineering faculty is
able to support components with 0.27mm pins and 0.23mm gaps between pads, which is
quite remarkable considering the manufacturing process used.
3.4 Chapter 3 conclusion

The result is a collection of stable and effective components that may be combined into a
complete system solution. Testing and integration of individual hardware components are
covered in chapter 5. It was attempted to find the best possible solution to a specific design
problem in all cases.
Chapter 4
Detail Software Design and Synthesis
Chapter 4 covers design and development of software components of the project. Both
firmware that run on the scanner device and application software is discussed in this chapter.
4.1 Database Table Design

One of the most important software design consideration is how data will be stored and pre-
sented in the database. This section covers the database tables integrated into the MyStudies
database by the attendance register system.
4.1.1 Attendance Table

This table represents a logged attendance of a student during a specific instance of a class.
The attendance table contains the following fields:
• ID - Primary Key, Auto Increment.
• UserCode - An indexed field linking to a MyStudies user in the user table.
• classInstanceId - An indexed field linking to a specific instance of a class in the classin-

stance table.
• Time - An optional field specifying the time of the logged attendance.
4.1.2 ClassInstance Table

This table represents every instance of a class. For example, if a class occurs once every week
for 10 weeks, there will be 10 entries in the classinstance table for the class. The classinstance
table contains the following fields:
• courseCode - An indexed field linking to a MyStudies course in the course table.
• typeID - Indicating the type of class, links to the classtype table.
27
CHAPTER 4. DETAIL SOFTWARE DESIGN AND SYNTHESIS 28
• noteID - Optional field indicating the type of class. Links to the notes table.
• startTime - The start time of this class.
• length - The length of this class.
• topic - An optional string representing the topic of this specific class instance.
• date - Day of class instance.
• year - Year of class instance.
4.1.3 Notes Table

This table holds notes added to specific class instances by lecturers. The notes table contains
the following fields:
• noteString - A string representation of the note.
4.1.4 classtype Table

This table holds strings for the different types of classes The classtype table contains the
following fields:
• typeString - A string representation of the class type.
4.2 Memory Map

The EEPROM’s memory map is also an important software design consideration. Care must
be taken to ensure a dynamic memory environment is created so that available memory
space is used effectively.The following graph represents the memory layout of the EEPROM:
1 2 3 4 5
Segment 1
Used for device configuration such as its device ID(2 bytes), device password(6 bytes), and
device administrator codes(18 bytes). Also reserved 14 bytes for counters and future use.
Segment 2
12 Courses are represented in this area, with 2 bytes storing a course code, and 8 bytes
storing a short-hand course name. Therefore this section must be at least 12x8 = 96 bytes
long. It is padded to 120 bytes.
Segment 3
Stores the class instances for every day of the week(7 days). Each day requires a start address
offset(1 byte) for the memory space of the specific day’s first class instance, and number of
class instances for that day(1 byte). Therefore this segment is 2x7 = 14 bytes. it is padded
to 20 bytes.
Segment 4
This segment holds information for specific class instances for the week. The start addresses
for the class instances are stored in the startadroffset register for each day at a specific byte
in memory. Every class instance requires the following data: The courseID(1 byte - an offset
in segment 2 of the memory), the start address of student numbers logged for this class
instance(2 bytes). The number of student numbers logged for this class instance(2 bytes).
And the time of logging in hours (1 byte). Therefore this segment requires 6 bytes for every
class instance of the week.
Segment 5
This segment holds logged student numbers. The start address of logged numbers for a
specific class instance on a specific day is determined by segments 3 and 4, therefore this
address space is entirely dynamic and student numbers can easily be added or removed from
memory. Every student number requires 3 bytes of memory to be logged.
4.3 LCD Layout

The LCD layout will be as follows:
MM DD HH:00 CS 212
HELLO 14543109 —b38%
Where ’MM DD HH:00’ represents the current date and time, ’CS 212’ represents the current
class module, ’HELLO 14543109’ represents a greeting to the logged student and —b38%
represents the current battery condition.
4.4 iWifi configuration website

The iWifi embedded webserver will serve three pages:
4.4.1 index.html
This page will present a login form and access to all configuration parameters on successful
login. Figure E.2 in appendix E shows a screenshot of the configuration page.
4.4.2 status.html
This page does not require authorisation and will return the status of the device.
4.4.3 sync.html
Logging into this page will cause the device to attempt synchronisation with the MyStudies
server via the twisted.web/SOAP interface. The source code for a configuration website
prototype is available in Appendix F.
4.5 Lecturer Administration GUI

The administration GUI allows for new class instances to be added to a timetable and for
changing class instance types and class note information. Figure E.3 is a screenshot of the
administration GUI before a new repeated class instance is added to the database. The
GUI communicates with the MyStudies server via SOAP and pushes data over the SOAP
protocol to be inserted into the database. The GUI component was designed using VisualWX
for visual design of WxPython applications.
4.6 Wifi to MyStudies interface Server

The Wifi device can push data to, and retrieve data from the MyStudies server by means of a
webserver interface. For transmitting data to the MyStudies server, the Wifi device connects
to the interface server and performs an HTTP POST with the transmission data. The
interface server parses the POST data and converts it into a form suitable for transmission via
SOAP. A SOAP request is then sent to the MyStudies server with the applicable information.
A reply is also sent back to the wifi device indicating a successful transaction.
For retrieving data from the MyStudies server, the wifi device connects to the interface
server and performs an HTTP POST request with the variables it wants to retrieve. The
interface server then retrieves the data from the MyStudies server via SOAP and pass it
along to the wifi device.
The interface server must make use of SSL encryption to prevent packet sniffing of user-
names, passwords and data.
The source code for a secure interface server implemented in python twisted.web1 is
available in Appendix F. A screenshot of the server’s initialisation together with a prompt
for the SSL PEM key can be seen in figure E.4.
4.7 Thin Clients

The use of a ’thin client’ was investigated. A thin client is a graphical user interface that
contains no business logic code, but rather extracts GUI component code from a database.
This approach could work well with the MyStudies framework as python makes serialisation
1
http://twistedmatrix.com/
of classes and object trivial. Unfortunately, a thin client implementation is outside the scope
of this project.
Chapter 5
Testing and Integration
The hardware testing strategy used is a ’bottom-up’ approach where the leaf-nodes of the
tree-level diagram are first tested individually, and then integrated into its parent branch
when all leaf-nodes of a specific branch is tested. The subsystem branches are then tested
and integrated into their parent subsystem branches until all components are integrated
into the completed system. When all hardware components are integrated, a full system
diagnostic is performed followed by a final field test of the device. The most important
individual components were tested first.
5.1 Testing Hardware Components

5.1.1 Wifi Module
As this is one of the most critical (and expensive) components of this project, the wireless
module was tested first.
Testing Method:
Test1: Connect the ConnectOne iWifi module to a computer via a UART to USB/RS232
circuit, which is connected to a computer’s USB port. Supply the iWifi module with
3.3V. Set the computer’s COM port to 38400 bps baud rate. Send ’AT+I’ + RETURN
to the iWifi. The iWifi must respond with ’I/OK’.
Test2: Set up an ad-hoc wireless network with a laptop. Configure the iWifi to connect to
the ad-hoc wireless network. Ping the iWifi using the windows ’ping’ command. The
iWifi must respond to all ping requests.
Test Results:
Test1: Passed.
Test2: Passed.
32
CHAPTER 5. TESTING AND INTEGRATION 33
Revisions:
None.
5.1.2 RFID Scanner

Testing Method:
Connect the RFID scanner to an LTC1306, RS232 to UART interface chip in its correct
configuration. Supply the RFID scanner with 5V and the LTC1306 with 3.3V. Connect the
LTC1306’s UART output is to a UART to USB circuit, which is connected to a computer’s
USB port. Set the computer’s COM port to 19200 bps baud rate. Scan a student card with
the RFID scanner. A 26 byte string, which includes the card’s student number, must be
displayed on the computer screen.
Test Results:
Test Passed.
Revisions:
None.
5.1.3 Printed Circuit Boards

This project uses three printed circuit boards, one for the wireless scanner device’s power
supply, one for its user interface module and one for its processing and communications
module. All three printed circuit boards are tested in the following way:
Testing Method:
1. The board is inspected for defects and compared to the original schematic to verify all
tracks are properly connected.
2. All tracks and vias are tested with a continuity tester for broken tracks
3. Through hole components are inserted (but not soldered) into their positions to ensure
all holes line up.
Test Results:
Power Supply PCB: Passed all tests.
Processing and Communications Module: Passed all tests.
User Interface Module: Passed only tests 1 and 2. Failed test 3.

Problem Diagnosis and Solution:

It was determined that the 24-pin header for connecting the user interface module to the
processing and communications module is mirrored relative to a standard floppy drive ribbon
cable. One of the two connecters of the ribbon cable was removed and each wire was connected
to the header pins on the PCB in a mirrored fashion.
Revisions:
The 24-pin header on the user interface module must be mirrored.
5.1.4 Microcontroller
Testing Method:
Load firmware onto the chip that generates a 20 Hz square wave on one of the timer output
pins. Connect an LED to the pin through a 50ohm resistor to Vcc in series. Supply the
MCU with 3.3V. The LED must blink at 20Hz.
Test Results:
Passed.
Revisions:
None.
5.1.5 LCD
Output is vital in debugging and diagnostics of other components, therefore the LCD test
was conducted before all other components apart from the Wifi module, RFID scanner and
MCU.
Testing Method:
Connect the LCD to the MCU with 8 data lines and 2 control lines as indicated in the
schematic in figure D.3 available in appendix D. Load firmware on the MCU that displays:
the quick brown fox-

jumps over lazy dog.
This text was designed to fill up all 20x2 characters of the LCD and represents most alphabet
characters. Supply the LCD with 5V. Supply the MCU with 3.3V.
Test Results:
Failed. Some characters did not display correctly.

It was determined that the character ’b’ displays correctly, but printing the character ’c’
resulted in a ’b’ being displayed. The binary values of these characters are: b - 01100010
, c - 01100011 . The only difference between the two characters is in the least significant
bit. It was deduced that the PCB track of the least significant bit may form a short circuit
with ground, thus forcing it to 0 when it should be 1 as in the case of the character ’c’. A
continuity test was performed and it was confirmed that the least significant bit track was
connected to ground. It was discovered that the LCD’s cover caused the short circuit as it
was simultaneously touching the least significant bit track and the ground plane. The LCD
cover was isolated from the tracks and the LCD test was repeated and passed.
Revisions:
Isolate LCD cover from tracks.
5.1.6 Touchpad
Input is also vital in debugging and diagnostics of other components, therefore the touchpad
test was conducted right after the LCD test.
Testing Method:
Supply the touchpad controller with 3.3V. Touch one of the touchpad buttons. Measure the
button’s corresponding output channel for a 1.
Test Results:
Failed. Touching one button resulted in several output channels returning 1 instead of 0.

It was determined that the ground plane between the buttons caused the touchpad controller
to register button presses on multiple buttons when one button is pressed, due to its capacitive
sensing sensitivity. The ground plane was removed and the buttons covered with 1.5mm
transparent Perspex, which solved the problem of false button presses.
Revisions:
Remove ground plane between buttons.
5.1.7 Voltage Rails

The testing method for the 3.3V and 5V voltage rails were identical.
Testing Method:
Connect a 120 ohm resistor between the output of the regulator and ground to simulate
power-save conditions. Supply the regulator with 3.3V to 3.6V. Measure the voltage drop
across the 120 ohm resistor with a multi-meter and verify it is within 0.2V of the regulator’s
expected output (3.3V/120ohm = 27.5mA, 5V/120ohm = 42mA). Repeat the test with a
12 ohm resistor for the 3.3V regulator and 20 ohm resistor for the 5V regulator to simulate
maximum load conditions (3.3V/12ohm = 275mA, 5V/20ohm = 250mA).
Test Results:
3.3V regulator: Passed. (Measurements and oscilloscope outputs available in section 6.1.3)
5V regulator: Failed. The 5V regulator made a hissing sound and became extremely hot.

The 5V regulator chip was removed and it was verified that the PCB connections and com-
ponents are exactly as specified in the 5V regulator’s datasheet. The continuity test was
redone on all tracks to eliminate the possibility of short circuits. A new 5V regulator chip
was soldered and it was again verified that the PCB connections and components are correct.
A continuity test was repeated again to ensure no short circuits were present. The above
testing method was redone and the new chip made a hissing sound and became extremely
hot. It was decided that a different 5V regulator chip be used, and the Maxim-IC MAX 682
was chosen from table 3.7 because it has a fixed 5V output.
Unfortunately, the new PCB for the MAX 682 was not available in time for testing and
results to be published in this report.
Revisions:
The MAX 682 replaces the TPS 61120 as 5V regulator.

Testing Method:
Insert a battery into the battery clips of the power supply module. Connect the power supply
module to a computer’s USB port with a USB cable.Connect the battery charger’s charge
enable pin to ground and verify battery charger’s CHG pin is not 0. Connect the battery
charger’s charge enable pin to the USB input voltage and verify the battery charger’s CHG
pin is 0. With charge enabled, verify the voltage across the battery is approximately 4.1V.
Test Results:
All tests passed.
Revisions:
None.
5.1.9 Other Components

The Bus expander, Memory Module and Real Time Clock were tested by writing data to
these devices and reading data back. The returned data was displayed on the LCD and
verified. All other components passed testing.
5.2 Integration of Hardware Components

The hardware components of the individual branches were integrated into their individual
subsystems first and tested.
5.2.1 Processing and Communications Unit

The Processing and Communications unit was completed first. The MCU, Wifi module,
EEPROM, Bus expander and Real Time Clock were tested together with no problems.
5.2.2 User interface module

Next the user interface module was completed. The keypad started registering false key
presses when the RFID scanner was mounted on the PCB. Engineering science was applied
in the diagnosis and solution of the problem. It was speculated that the false key presses were
as a result of electromagnetic interference from the RFID scanner. An Aluminium shield was
designed and inserted between the RFID scanner and the rest of the PCB. Once the shield
was in place, the keypad no longer registered false key presses.
The user interface module was connected to the processing and communications module
and the diagnostic tests of each individual component were repeated within the integrated
systems. All tests were passed.
5.2.3 Power Supply module

As the 5V regulator of the power supply was burnt out, the power supply unit could not be
fully integrated. Unfortunately the replacement PCB was not available in time for writing
of this report and integration tests could not be fully completed.
5.3 Testing Software Components

The individual software components were tested as they were being developed. The only case
where an explicit test was designed was with the webserver/MyStudies interface server. A
client that simulates an iWifi HTTP POST request was quickly written in python to simulate
data POST events and verify that the interface server worked correctly.
5.4 Integration of Software Components

The main components were designed from the ground up to be compatible with the MyStudies
server, therefore a level of integration was maintained from the start. Unfortunately there
was not enough time to fully integrate the administration GUIs with the MyStudies client,
but it will be trivial to do so.
Chapter 6
Measurements and Results
Measurement of hardware and software’s non-functional parameters is important in deter-

mining the effectiveness of the system. From measurements, estimates can be made in terms
of things such as operating time, operating range, number of users supported, and ultimately
the successfulness of the entire system. Current consumption measurements were taken with
a standard multi-meter, output graphs were obtained from digital oscilloscopes available in
the engineering faculty’s labs, and distance measurements were either estimated in cases of
long distances, or measure with a ruler in cases of short distances.
6.1 Hardware Measurements

6.1.1 iWifi
Current Consumption:
• Power save mode: 7.6mA @ 3.3V
• Transmit mode: 243mA @ 3.3V
Operating Range:
The following reception distance measurements were taken using a laptop , ad-hoc network
and the windows ’ping’ tool:
• Line of sight: 150m
• No line of sight: 50m (Due to weak laptop wifi card)
• MatiesWifi reception: Everywhere
Conclusion:
Measurements indicate expected results as specified in the component’s datasheet.
39
CHAPTER 6. MEASUREMENTS AND RESULTS 40
6.1.2 RFID Scanner

Current Consumption:
• 63mA @ 5V in idle mode.
• 102mA @ 5V when a student card is scanned.
Operating Range:
1.6cm
Conclusion:
The device’s current consumption in idle mode is two times less than expected. This will
significantly increase expected battery life.
6.1.3 3.3V Voltage Rail

The 3.3V rail was first tested by putting the device in sleep mode and measuring input and
output currents for an input voltage range of 3.3V to 4.1V. Next, the device was operated in
full operating maximum power mode and the same measurements were taken.
Table 6.1 lists the results of the low-power mode tests.
Input Voltage Regulated Out- Current Output Output

put Voltage from Source Current Voltage
Ripple
3.3V 3.29V 23.9mA 22mA 80mV
3.6V 3.4V 24mA 21.6mA 160mV
4.1V 3.32V 22.3mA 20.9mA 280mV
Table 6.1: Measurements taken at different input voltage levels for low-power operation.
Figure 6.1 shows the digital oscilloscope outputs for low-power operation with input
voltages of 4.1V and 3.3V.
(a) Low-power regulation with 4.1V in- (b) Low-power regulation with 3.3V in-
put put
Figure 6.1: Low-power operation regulated output with max and min input voltage.
Table 6.2 lists the results of the full-power mode tests.
Input Voltage Regulated Out- Current Output Output

put Voltage from Source Current Voltage
Ripple
3.3V 3.24V 293mA 270mA 40mV
3.6V 3.36V 302mA 272mA 80mV
4.1V 3.4V 286mA 269mA 240mV
Table 6.2: Measurements taken at different input voltage levels for full-power operation.
Figure 6.2 shows the digital oscilloscope outputs for full-power operation with input volt-
ages of 4.1V and 3.3V.
(a) Full-power regulation with 4.1V in- (b) Full-power regulation with 3.3V in-
put put
Figure 6.2: Full-power operation regulated output with max and min input voltage.
Conclusion:
The 3.3V regulator performs as expected, at greater than 90% efficiency and low enough
output voltage ripple.
6.1.4 5V Voltage Rail

Unfortunately, the 5V regulator failed before measurements could be taken. The replacement
PCB and chip was not available for measurement at time of writing this report, however the
exact same method of measurement as for the 3.3V regulator will be done.

The output voltage of the battery charger was measured with a multi-meter as 4.12V when
the charger is enabled. The current consumption was dependant on the state of the battery.
6.2 Total Power Consumption

The total current consumption for the 3.3V and 5V rails were measured for normal operating
conditions using a multi-meter and a power source as a replacement for the 5V rail. The
following normal-mode measurements were made:
• Processor and communications board + keypad: 189mA @ 3.3V
• LCD+RTC+RFID scanner: 69mA @ 5V
The average estimated current that must be sourced from the battery can be calculated
as follows:
3.3 5
Ibat = I3V 3 × Vbat
/0.9 + I5V × Vbat
/0.7
Ibat = 0.189 × 0.916/0.9 + 0.069 × 1.388/0.7
Ibat = 0.192 + 0.137 = 0.329mA
The estimated battery lifetime at constant normal operating conditions is then: t =

2400mAh/329mA = 7.29hours
Where 0.9 is the estimated efficiency of the 3.3V regulator and 0.7 the estimated efficiency
of the 5V regulator, and Vbat = 3.6V .
However, battery life can be greatly extended by putting the Wifi module in sleep mode
and shutting down the 5V regulator until a wake-up event occurs.
6.3 Software Measurements

Software tests were mainly done in determining the responsiveness of the administration
GUIs. The lecturer administration GUI was tested with the following results:
Adding one class instance to the database

The GUI component was used to add one class instance to the database. The function
executed in under 2ms.
Adding the maximum amount of class instances to the database

The GUI component was used to add the maximum amount of class instances to the database(53).
The function executed in under 2ms.
Chapter 7
Conclusion and Recommendations
The aim of this project was to develop a full automated class attendance register solution.
A mobile Wifi-enabled RFID scanner device was designed and built and controlling soft-
ware was developed. Prototypes for a full application software suite were implemented. All
hardware requirements for the development of such a system were addressed. Most software
requirements were addressed, although only partial prototypes were written in some cases
due to time constraints.
Testing and integration results show that the developed modules satisfy the objectives
of this project, and are suitable for a practical application. The hardware developed can be
used as-is in the field if placed in a suitable enclosure.
The modular tree-level approach taken in synthesis and design of components allows
components to be interchanged if upgrades or superior alternatives become available. This
approach also allows for the system to be easily extended and additional functionality added
if required.
Additional time may still be spent on refining and polishing the system in order for it to
be introduced for use at the engineering faculty of Stellenbosch in 2009.
The design objectives of this project were completed successfully.
7.1 Achievements
This section can be used as a reference for new projects to be developed. It includes findings
and functionality that worked notably well and can be recommended for future solutions.
The following hardware components performed remarkably well:
• The ConnectOne iWifi module. With more functionality than similar modules that is
twice its cost, this device is perfect for adding Wifi capability to a mobile system. The
iWifi was released in the third quarter of 2008.
• The IQS221 capacitive sensor IC from Azoteq. Allowing the creation of custom touch-
pads and sliders, with minimal operating current, the IQS221 provides a perfect user
input solution with no mechanical components that are subject to wear and tear.
• The MAX1811 USB Li-Ion charger IC from Maxim-IC. Minimal external components
required for an effective USB powered Li-Ion battery charger.
44
CHAPTER 7. CONCLUSION AND RECOMMENDATIONS 45
The following software components were critical to the development of this project:
• Python. Python is a powerful and versatile language suitable for high- and low-level
application development.
• Python Twisted. The twisted.web web server methodology is superior to alternative

web server solutions and provides many advantages over systems such as Apache.
• For web based interfaces, it is recommended that Python Nevow and Athena be inves-
tigated.
7.2 Recommendations
This section includes recommendations for extending the existing system, and enhancing
system design.
Use of Surface Mount Components: The processing and communications module was
designed for surface-mount only components as the manufacturing for surface mount
components and their availability was not clear. However, the manufacturing processes
at the engineering faculty are sufficient for surface mount component utilisation, and
the use of surface mount components is recommended.
Battery Temperature Monitoring: Additional functionality for monitoring battery tem-

perature can be implemented.
’Thin’ Clients: The use of ’thin-clients’ must be investigated for application software GUIs.
This refers to minimal client code that extracts and presents GUI information from a
central database.
Access Control: This project can easily be adopted for use in an effective wireless access
control system.
Bibliography
[1] Inc., C.E.: Lithium ion battery discharge graph. Available at:
http://www.buchmann.ca/, [2008, October 27], 2008.
[2] BITKOM Radio Frequency Identification (RFID) Project Group:

Rfid white paper. technology, systems, and applications. Avail-
able at: http://www.rfidconsultation.eu/docs/ficheiros
/White_Paper_RFID_english_12_12_2005_final.pdf, [2008, October 27], 2005.
[3] Reinhold, C. and Scholz, P.: Efficient antenna design of inductive coupled rfid-systems
with high power demand. Journal of Communications, vol. 2, no. 6, 2007.
[4] Nohl, K.: Cryptanalysis of crypto-1. Available at:

http://www.cs.virginia.edu/~kn5f/pdf/Mifare.Cryptanalysis.pdf, [2008, Octo-
ber 27], 2008.
[5] LionPrecision: Capacitive sensors - an overview. Available at:

http://www.lionprecision.com/capacitive-sensors, [2008, October 27], 2005.
[6] ConnectOne: Mini socket iwifi data sheet ver. 1.1. Available at:
http://www.connectone.com/media/upload/Mini_Socket_iWiFi_DS.pdf, [2008,
October 27], 2008.
[7] Strangio, C.: The rs232 standard. Available at:

http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html, [2008,
October 27], 2006.
46
Appendix A
Project Planning Schedule
Table A.1 represents a weekly schedule for the planned completion of different aspects of this
project.
Week Start Schedule

Date
1 21 July System analysis and planning
2 28 July Find important component solutions: Wifi module, battery
charger, batteries, regulators, touchpad.
3 4 Aug Request quotation for Wifi module and place sample orders for
components.
4 11 Aug Analysis review and further planning.
4 18 Aug Find and order secondary component solutions: MCU, memory,
bus expander, RTC, RS232 interface
5 25 Aug Obtain and test RFID scanner. Test Wifi module. Begin with
software development.
6 1 Sept Test Week.
7 8 Sept Design and manufacture Processing and Communications module.
Software integration with MyStudies tests.
8 15 Sept Design and manufacture of user interface module. Software
database layouts and design.
9 22 Sept Test processing and communications module and integrate module
components. Software GUI design.
11 29 Sept Test user interface module and integrate module components. Con-
tinue software developement. Firmware development.
12 6 Oct Design and manufacture power supply module. Continue software
development. Software GUI development.
13 13 Oct Complete final integration of all hardware components. Software
integration.
14 20 Oct Measurements and report writing.
Table A.1: Project Planning Schedule
47
Appendix B
Project Specification
The project specification as derived from the original project proposal by H.R. Gerber.
B.1 Functional Requirements

B.1.1 Hardware
• Use an RFID scanner to obtain a studentcard’s student number.
• Use non-volatile for logging card and timestamp data.
• Provide user input by means of a keypad or touchpad for device administration.
• Provide user feedback by means of an LCD, displaying current module data and ad-
ministration information.
• Provide a buzzer and LEDs for device status feedback.
• Provide an 802.11b wifi component with a microcontroller for wireless transmission of

logged data.
• Provide a power supply for the mobile wireless scanner device.
• Provide a USB battery charger for charging the power supply battery.
B.1.2 Software and Firmware

• Provide a basic administration interface via the keypad and LCD for setting up Wifi
network parameters.
• Provide an extended administration interface via an onboard webpage accessible via

Wifi for setting extended parameters such as security, logging and log-in information.
• Provide an appropriate authentication system to validate configuration via the keypad

or webpage interfaces.
48
APPENDIX B. PROJECT SPECIFICATION 49
• Interface with MyStudies via SOAP
• Log attendance records in permanent database.
• Provide sufficient database structures for user/timetable and Wifi device control.
• Generate detailed per-user/per-module/per-class/etc statistics from database data.
• Provide real-time feedback of scanned cards.
• Provide a personalized calendar of each student’s timetable, including information on

lectures attended and missed.
• Provide a means for different lecturers to post information about the work that will be
or has been covered in a specific lecture.
• Provide appropriate authentication, log-in and security mechanisms in order to validate

data pushed from the device and data posted by users (lecturers).
• Provide a sufficient administration interface for admin of timetables and students
• Provide a sufficient administration interface for admin of Wifi Scanners.
B.2 Performance
The system must adhere to the following non-functional requirements, or performance char-
acteristics:
• Card data must be scanned and processed as fast as possible.
• The system must be easy to use and configure.
• The system must be secure. Data transmission and configuration must be secured.
• The system must be able to handle many users logged in at once.
B.3 Interfaces
System user interfaces include:
• Physical user input and feedback via the user interface hardware module.
• The iWifi’s embedded webserver configuration webpage.
• Student and lecturer configuration GUIs.

Inter system interfaces include:
• A ribbon cable connects the processing and communications unit with the user interface
module.
APPENDIX B. PROJECT SPECIFICATION 50
• Wires connect the power supply module with the processing and communications unit.
• The device communicates with a webserver for transmitting data via HTTP POST.
• The received HTTP POST data is parsed and passed to the MyStudies server via
SOAP.
• The MyStudies server provides an interface between the database and other client
software.
Appendix C
Outcomes Compliance
The following list shows the ECSA level outcomes for this project, and a cross reference for
where specific requirements are met within this document.
1. Problem Solving
Demonstrate competence to identify, assess, formulate and solve convergent and divergent
engineering problems creatively and innovatively.
The problem definition is stated explicitly in section 1.2 on page 1. The scope of the
problem is formulated in section 1.3 on page 2. The divergent engineering problem of system-
level design is discussed in Chapter 2 on page 4, and the component design problems are solved
in a convergent manner in Chapter 4 and 5.
2. Application of scientific and engineering knowledge

Demonstrate competence to apply knowledge of mathematics, basic science and engineering
sciences from first principles to solve engineering problems.
Knowledge of the scientific phenomenon of ’capacitive sensing’ was applied as described
in section 3.1.3 on page 12. Mathematics was applied from first principles in the calculation
of various components and in power consumption calculations. These calculations are avail-
able on pages 24, 26, 42 and 23. Engineering science was applied to solve the problem of
electromagnetic interference in section 5.2.2 on page 36.
3. Engineering Design
Demonstrate competence to perform creative, procedural and nonprocedural design and syn-
thesis of components, systems, engineering works, products or processes.
The tree-level diagram of figure 2.2 on page 6 is an example of a recursive, non-procedural
design process. The detail level design of individual components in chapters 3 and 4 is a more
procedural approach. The touchpad as shown in figure E.1 in appendix E is an example of
a creative solution to the problem of user input.
51
APPENDIX C. OUTCOMES COMPLIANCE 52
4. Investigations, experiments and data analysis

Demonstrate competence to design and conduct investigations and experiments.
In chapter 5, tests were designed for individual components and then execued. For ex-
ample, the hardware tests formulated on pages 33, 34 and 35. Failed tests lead to structured
diagnostic investigations as formulated, for example, on pages 35 and 36. Other experiments
performed include investigation of the effect of an aluminium shield on electromagnetic in-
terference, as shown in section 5.2.2 on page 37.
5. Engineering methods, skills and tools, including

Information Technology
Demonstrate competence to use appropriate engineering methods, skills and tools, including
those based on information technology.
Use of engineering measuring equipment such as multi-meters and oscilloscopes are demon-
strated in Chapter 5 and 6. Figures 6.1 and 6.2 on page 41 are examples of digital oscilloscope
measurements. In terms of information technology, the internet was used extensively for re-
search, and various information technology based communication resources were utilised such
as e-mail, Internet Relay Chat and instant messaging.
6. Professional and technical communication

Demonstrate competence to communicate effectively, both orally and in writing, with engi-
neering audiences and the community at large.
This document itself is an example of effective written communication. The professional
typesetting application, LaTeX, was used in the creation of this report. An oral presentation
will be delivered with the aid of slides and a demonstration of the mobile scanner device.
9. Independent learning ability

Demonstrate competence to engage in independent learning through well-developed learning
skills.
The study of RFID technology in section 2.2 on page 7 is an example of independent
learning ability. Other examples of independant learning include:
• Use of an SQL database.
• Use of SOAP.
• Knowledge of RFID technology.
• Knowledge of Wifi 802.11b/g networks.
• Knowledge of capacitive sensors.
• Use of LaTeX.
Appendix D
Circuit Diagrams and PCB layouts
53
APPENDIX D. CIRCUIT DIAGRAMS AND PCB LAYOUTS 54
Figure D.1: User Interface Module Schematic

Figure D.2: User Interface Module PCB

Figure D.3: Processing and Communications Unit Schematic

Figure D.4: Processing and Communications Unit PCB

Figure D.5: Power Supply Schematic

Appendix E
Photos and Screenshots
Figure E.1: Photo of user interface ontop of processing and communications unit.
59
APPENDIX E. PHOTOS AND SCREENSHOTS 60
Figure E.2: Screenshot of wifi configuration page.
Figure E.3: Screenshot of administration GUI.

APPENDIX E. PHOTOS AND SCREENSHOTS 61
Figure E.4: Screenshot of secure interface webserver.

Appendix F
Source Code
F.1 Secure Interface Webserver Prototype

"""
@author: Carel van Wyk
@contact: cpjvanwyk@gmail.com
@since: 14-10-2004
@revisions:
"""
import __version__ #Package Versioning information

import logging
from twisted.web import server, resource

from twisted.internet import reactor, ssl
import SOAPpy
#Set up logging:
logging.basicConfig(level=logging.DEBUG,
format=’%(asctime)-25s %(levelname)-8s %(message)s’,
filename=’secure-webserver.log’,
filemode=’a’)
console = logging.StreamHandler()
console.setLevel(logging.DEBUG)
formatter = logging.Formatter(’%(asctime)-25s: %(levelname)-8s %(message)s’)
console.setFormatter(formatter)
logging.getLogger(’’).addHandler(console)
class SecureWebInterface(resource.Resource):
isLeaf = True
def render_GET(self, request):
self.host = "127.0.0.1"
self.port = 9080
self.client = "127.0.0.1"
###
try:
logging.debug("Info: Connecting to " + self.host+":"+str(self.port))
self.headerdata = {"username": "8001", "password":"aaBB33", "client":self.client}
self.__header = SOAPpy.headerType(data = self.headerdata)
self.server = SOAPpy.SOAPProxy(self.host+":"+str(self.port), header=self.__header)
self.server.status()
logging.debug(’Info: Connected successfully to SOAPProxy @ %s:%s’ % (str(self.host), str(self.port)))
return "<html>Worked</html>"
except Exception, why:
logging.error(’Error: connect error: ’ + str(why))
62
APPENDIX F. SOURCE CODE 63
return False
###
return "<html>Hello, world!</html>"
def render_POST(self,request):
print request.received_headers
print request.content.readlines()
print request.args
print request
return "<html></html>"
site = server.Site(SecureWebInterface())
try:
sslContext = ssl.DefaultOpenSSLContextFactory(’keys/ca.key’,’certs/ca.cer’)
reactor.listenSSL(8080, site, contextFactory = sslContext)
logging.debug("Starting server and waiting for connections...")
reactor.run()
except Exception, why:
logging.error("Unable to start server: %s" % (str(why),))
F.2 iWifi configuration page

<html>
<head>
<title>Device Configuration Page</title>
<link REL="stylesheet" TYPE="text/css" href="style.css">
</head>
<body>
<div class="top">
<img src="img/logo.jpg" alt="Logo"/>
<div class="title">Wifi Scanner Device Configuration</div>
</div>
<div class="borders">
<div class="content">
<div class="heading">Device settings:</div>
<table>
<tr><td>Device ID:</td><td><input type="text"/><input type="submit" value="update"></td></tr>
<tr><td>Admin Username:</td><td><input type="text"><input type="submit" value="update"></td></tr>
<tr><td>Admin Password:</td><td><input type="text"><input type="submit" value="update"></td></tr>
</table>
<br/>
<div class="heading">Network settings:</div>
<table>
<tr><td>Device IP Address:</td><td><input type="text"/><input type="submit" value="update"></td></
<tr><td>Server IP Address:</td><td><input type="text"><input type="submit" value="update"></td></t
</table>
<div class="heading">Time:</div>
<table>
<tr><td>Year:</td><td><input type="text"/><input type="submit" value="update"></td></tr>
<tr><td>Month:</td><td><input type="text"><input type="submit" value="update"></td></tr>
</table>
</div>
</div>
</body>
</html>
F.3 RFID and iWifi Communcations Handling

Module
#include "sfr_r827.h"
#include "uart.h"
#include "lcd.h"
#include "rfid_scanner.h"
char dataReceived;
char data;
/**Initializes the USB-RS232 serial interface.*/

void uart_init(void)
{
//**************************************
// UART 0 Setting - iWifi
//**************************************
//Set TXD0 pin to output port direction, set RXD0 pin to input port direction
//Poll for the status of Ri(Receive complete flag) in your UART 0 routine to check whether reception has completed
smd0_u0mr=1;smd1_u0mr=0;smd2_u0mr=1; //UART mode transfer data 8 bits long selected(u0mr bit 0, 1 and 2)
ckdir_u0mr=0; //Internal clock selected(u0mr bit 3)
stps_u0mr=0; //1 stop bit selected(u0mr bit 4)
prye_u0mr=0; //Parity disabled(u0mr bit 6)
clk0_u0c0=0;clk1_u0c0=0; //BRG count source f1 selected(u0c0 bit 0 and 1)
uform_u0c0=0; //Transfer LSB first(u0c0 bit 7)
u0brg=32; //Setting UART0 baud rate generator(max 255). Calculated value is round to th
te_u0c1=1;
re_u0c1=1; //Reception enabled(u0c1 bit 2)
u0rrm_u0c1=0;
u0c0 = 0x00;
s0tic=0x00; //Set UART0 transmit interrupt piority level 0(s0tic)

s0ric=0x03; //Set UART0 receive interrupt piority level 2(s0ric)
//dataReceived = 0;*/
//**************************************
// UART 1 Setting - RFID READER
//**************************************
//Set TXD1 pin to output port direction, set RXD1 pin to input port direction
//By default, TXD1 is at P0_0 pin, RXD1 is at P3_7 pin
//Set uart1sel0 and uart1sel1 of pinsr1 register and u1pinsel, txd1sel and txd1en of pmr register to change TXD1 and R
//Poll for the status of Ri(Receive complete flag) in your UART 1 routine to check whether reception has completed
//Set up control pin (default low - disable transmit)
uart1sel1 = 0;
uart1sel0 = 0;
u1pinsel = 0;
txd1sel=0;
txd1en=0;
smd0_u1mr=1;smd1_u1mr=0;smd2_u1mr=1;//UART mode transfer data 8 bits long selected(u1mr bit 0, 1 and 2, pmr bit 5)
ckdir_u1mr=0; //Internal clock selected(u1mr bit 3)
stps_u1mr=0; //1 stop bit selected(u1mr bit 4)
prye_u1mr=0; //Parity disabled(u1mr bit 6)
clk0_u1c0=0;clk1_u1c0=0; //BRG count source f1 selected(u1c0 bit 0 and 1)
uform_u1c0=0; //Transfer LSB first(u1c0 bit 7)
u1brg=64; //Setting UART1 baud rate generator(max 255). Calculated value is round to the
te_u1c1=1;
re_u1c1=1; //Reception enabled(u1c1 bit 2)
s1tic=0x00; //Set UART1 transmit interrupt piority level 0(s1tic)
s1ric=0x04; //Set UART1 receive interrupt piority level 2(s1ric)
}
void ch0_handle_input()
{
char received;
received = u0rb;
lcd_write_char(received);
}
void ch0_output_char(char msg)

{
while(ti_u0c1 == 0);
u0tb = msg;
}
/**Writes a string the to the UART0 channel.*/

void ch0_output_string (char * msg_string)
{
char i;
// This loop reads in the text string and puts it in the UART 0 transmit buffer
for (i=0; msg_string[i]; i++){
while(ti_u0c1 == 0);
u0tb = msg_string[i];
}
}
/**Function is called when data is received on UART1 channel called due to interrupt.*/
void ch1_handle_input()
{
char received;
received = u1rb;
//while (ri_u1c1); //Wait while data is read
rfid_handle_received(received);
}

Wifi RFID Scanner

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Wifi RFID Scanner

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSITEIT•STELLENBOSCH•UNIVERSITY

jou kennisvennoot • your knowledge partner

Carel van Wyk

Report submitted in partial fulfilment of the requirements of

Supervisor: H.R. Gerber

Copyright ° c 2008 Stellenbosch University

Die doel van hierdie projek is om ’n volledige klasbywonings-register stelsel te ontwerp en te

List of Figures viii

2 System Analysis and Design 4

3 Detail Hardware Design and Synthesis 10

3.1.4 Interface PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Detail Software Design and Synthesis 27

5 Testing and Integration 32

5.1.8 Battery Charger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Measurements and Results 39

7 Conclusion and Recommendations 44

A Project Planning Schedule 47

D Circuit Diagrams and PCB layouts 53

E Photos and Screenshots 59

2.1 Design decision flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Calibrated LCD resistor values. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

D.1 User Interface Module Schematic . . . . . . . . . . . . . . . . . . . . . . . . . 54

E.1 Photo of user interface ontop of processing and communications unit. . . . . . 59

3.1 Student Identification Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 11

A.1 Project Planning Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1.2 Problem Definition

1.3 Scope and Aims of Project

The aims of this project are, in order:

• Provide a wireless interface between the scanner and database server.

1.4 Introduction to Other Chapters

System Analysis and Design

Can System be Yes Identify functional

Does the component adhere

Figure 2.1: Design decision flow chart

2.1 System and Design Overview

2.1.1 Technologies Utilised

Figure 2.2: Tree-level diagram

2.2 Study of RFID technology

2.2.1 General concept

Figure 2.3: Airgap Interface between card and scanner

• To enable a layer of communication, information must be modulated on the wave.

2.2.4 Stellenbosch University Implementation

2.3 Design Constraints

Limited availability of passive components: Even though surface-mount resistors, ca-

2.4 Chapter 2 Conclusion

Detail Hardware Design and Synthesis

3.1 User Interface

• Approximately 120mA @ 5V according to datasheet.

• RS232 receiver @ 19200 bps baudrate

Name Description Advantages Disadvantages

• Approximately 10mA @ 5V operating current + 20mA @ 5V backlight current.

• 8+2 General Purpose I/O lines directly to the MCU

Figure 3.1: Calibrated LCD resistor values.

3.1.3 Keypad or Touchpad

• When a button pad is touched, a binary 1 is immediately output on the corresponding

’Capacitive sensors use the electrical property of capacitance to make measure-

• 190uA operating current @ 3.3V

3.1.4 Interface PCB

3.2 Processing and Communications Unit

3.2.1 Wireless Communications Module

Name Description Advantages Disadvantages Price

• 250 mA @ 3.3V for transmit, 8 mA @ 3.3V in power save mode

• One UART channel