1. UNI V E R SI T EI T• S T E L L EN BO S CH•UNI V E R SI T Y
j o u k e n n i s v e n n o o t • y o u r k n ow l e d g e p a r t n e r
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 2008Acknowledgements
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

2. iDeclaration
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.
iiAbstract
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.
iiiUittreksel
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 projek maak
gebruik van ’RFID’ tegnologie en ’Wifi’ draadlose kommunikasie. Die werking van
’RFID’ is oppervlakkig ondersoek. Daar word gewys dat ’n effektiewe klasbywonings-register

3. 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 ”MyStudies”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.
ivContents
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

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

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

6. 5.1.6 Touchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.7 Voltage Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35CONTENTS 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

7. 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 . . . . . . . . . . . . . . . 63List 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

8. E.2 Screenshot of wifi configuration page. . . . . . . . . . . . . . . . . . . . . . . . 60
E.3 Screenshot of administration GUI. . . . . . . . . . . . . . . . . . . . . . . . . . 60
E.4 Screenshot of secure interface webserver. . . . . . . . . . . . . . . . . . . . . . 61
viiiList 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
ixNomenclature
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

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

10. 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 University, as
described in the previous section.
1CHAPTER 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

11. 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 communication
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 devices 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 MyStudies
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

12. 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 subsystems 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 overlaying 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.
4CHAPTER 2. SYSTEM ANALYSIS AND DESIGN 5
START
Can System be
broken up into

13. subsystems?
Identify functional
requirements.
Create new branch.
Yes
Create Leaf-Node.
Find suitable component
based on functional
requirements.
No
Does the component adhere
to non-functional requirements
and design constraints?
Use Component
Yes
No
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

14. 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.CHAPTER 2. SYSTEM ANALYSIS AND DESIGN 6
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.CHAPTER 2. SYSTEM ANALYSIS AND DESIGN 7
SOAP
SOAP is a protocol that allows exchange of XML-based messages over HTTP or HTTPS. It

15. is the main transport method of data used in the MyStudies framework and this project.
Python
Python
1
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
Twisted
2
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

16. 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/CHAPTER 2. SYSTEM ANALYSIS AND DESIGN 8
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 interface 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.

17. • 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 encodingCHAPTER 2.
SYSTEM ANALYSIS AND DESIGN 9
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 manufacturing 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 software 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

18. place while hardware components are being manufactured. Readily available components 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, capacitors 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 thousands 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 limited 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

19. scanner must be provided by the University’s access control department since it is preconfigured 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.
10CHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 11
• RS232 receiver @ 19200 bps baudrate
Name Description Advantages Disadvantages
RFID RFID chips embedded in all student cards.
Fast, Efficient,
Availability
Card may be
given to friend

20. for scanning.
Biometrics Finger print or retina scanner. Absolute positive identification
Very expensive,
Slow
Magstripe The magnetic strip on all student
cards.
Availability Slow, Wear and
Tear, Old technology, 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

21. 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 MCUCHAPTER 3. DETAIL HARDWARE DESIGN AND
SYNTHESIS 12
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 mentioned later) are
also examples of new and interesting technologies.
The ISQ221 proximity sensor chip from Paarl based company, Azoteq, provides a capacitive 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 Stellenbosch.
See below for a basic explanation of capacitive sensors. A photograph of the user interface’s custom
touchpad is available in appendix E, as figure E.1.

22. Capacitive Sensors
LionPrecision[5] describes capacitive sensors as follows:CHAPTER 3. DETAIL HARDWARE DESIGN AND
SYNTHESIS 13
’Capacitive sensors use the electrical property of capacitance to make measurements. 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. Otherwise, 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).CHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 14
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

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

24. 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.
1Dollar to Rand conversion done using R8 per $1CHAPTER 3. DETAIL HARDWARE DESIGN AND
SYNTHESIS 15
Name Description Advantages Disadvantages Price
Jennic
JN5121
(Zigbee
802.15.4) Used for
wireless personal
area networks
(WPANs). Simpler
than Bluetooth.
Low Power consumption, Compact, Simple, Combined wireless module and MCU
Low data rate, Short
Range (20m indoors),
Requires base station
hardware
R260
+
R800
Programmer
Bluetooth (802.15.1) Used

25. for Wireless Personal Area Networks.
Low power consumption, Compact, Universal hardware (laptops, PCs), AT command set interface
Low data rate, Short
range
R460
GSM (GSM 07.07)
Global System for
Mobile communications. Used for
data transmission
by mobile phones.
Universal hardware
(mobile phones,
laptops, PCs), AT
command set interface, Higher Datarate,
Very long range
High power consumption, Data transmission not free
R160
to
R930
RabbitCore
RCM5400W
(Wifi 802.11b/g)
Wifi enabled MCU
with 39 GPIO and
512K Flash memory

26. Universal hardware
(laptops, PCs, APs),
High datarate, Programmed over serial,
Standard external
antenna connector,
long range
Relatively high power
consumption, Expensive
R790
Ezurio
WISMC01
(Wifi 802.11b/g)
Wifi enabled MCU
with 12 GPIO, 2
10bit A/Ds and
UART
Universal Hardware
(laptops, PCs, APs),
High datarate, Programmed over serial,
Relatively Low power
consumption
No external antenna,
Shorter range than
other 802.11 modules,
Expensive

27. R1045
ConnetBlue
SPA311G
(Wifi 802.11b/g)
Wifi module only
with AT commandset. Requires controlling MCU.
Universal Hardware
(laptops, PCs, APs),
High datarate, AT
over UART interface,
External antenna connector, Long range,
Compact
Very expensive R1450
ConnectOne
Mini Socket
iWifi
(Wifi 802.11b/g)
Wifi module only
with AT commandset and onboard
web server. Requires controlling
MCU.
Universal Hardware
(laptops, PCs, APs),
High datarate, AT
over UART interface,

28. External antenna connector, Long range,
Compact
Relatively high power
consumption (but less
than some other wifi
modules)
R470
Table 3.2: Wireless Communications Module SolutionsCHAPTER 3. DETAIL HARDWARE DESIGN AND
SYNTHESIS 16
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 module. 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 Distributions
2
in Cape Town. Range tests are available in Chapter 6.
2
www.scoop.co.zaCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 17
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 I

29. 2
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
R8C/27
32 pin, 20Mhz general purpose MCU used in Design
E314.
Immediately available, 32 pin wide
DIP socket.
No Built-in RS232
Renesas
R8C/2B
62 pin general purpose
MCU. Advanced version of
the R8C/27
Faster than
R8C/27, More
flash memory
Surface
mount LQFP64,
Not immediately

30. available, No
built-in RS232
Microchip
PIC18F2550
28 pin general purpose
MCU.
Built-in RS232 interface
Unfamiliar platform
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.3VCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 18
3.2.4 Memory Module

31. 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 I
2
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
•I
2
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 I
2
C real time clock available from RS South Africa
3
in 8 pin DIP format,
the DS1307+ from Maxim-IC
4

32. , and it was chosen for this project. Any I
2
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
•I
2
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.comCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 19
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.

33. Since there are already two other components that make use of the I
2
C bus, the bus
expander will also make use of I
2
C. Any general purpose bus expander with 8 or more input
pins, an I
2
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
•I
2
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 Technologies

34. 5
and the MAX3222CPN+ from Maxim-IC
6
. 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
6maxim-ic.comCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 20
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. Implementing 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

35. 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.CHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 21
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

36. 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 DealExtreme
7
at R45 per cell
8
. 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
8At an exchange rate of R8 per 1 USDCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 22
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.

37. 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.CHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 23
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
Output

38. Current
Efficiency Input
Voltage
Texas Instruments
TPS62260
2.25Mhz high efficiency synchronous step-down converter
with low dropout. (Adjustable
version)
600mA 88 to 94% 2V-6V
Texas Instruments
TPS62056
High efficiency synchronous stepdown converter with low dropout
and low noise operation (Fixed
3.3V version)
800mA 90 to 9% 2.7V-10V
Linear
Technologies
LTC1879
High Efficiency Synchronous buck
(step-down) converter with low
dropout. (Adjustable version)
1200mA 93 to 95% 2.65V-10V
Table 3.6: Available 3.3V Regulators
The Texas Instruments TPS62056 was chosen for the following reasons:
• It provides the highest efficiency.

39. • 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.CHAPTER 3. DETAIL HARDWARE DESIGN AND
SYNTHESIS 24
• 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
Output
Current
Efficiency Minimum
Input
Voltage
Texas Instruments
TPS61120
High Efficiency Synchronous
boost (step-up) converter. Adjustable version.
600mA 94 to 95% 1.8V
MaximIC
MAX682
Compact charge-pump (step-up)
regulator with minimal external
components. Fixed 5V version.

40. 250mA 70 to 71% 2.7V
Linear
Technologies
LTC1306
High Efficiency synchronous
boost (step-up) regulator. Adjustable version
1000mA 83 to 87% 2.5V
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 × (
VO
VF B
− 1)
VF B = 0.5V, VO = 5V. The suggested range for R6 is 180kΩ.
Choose R6 = 200kΩ ,then R3 = 200000 × (
5
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

41. Linear Technologies
9
LTC 3567 is a high efficiency, next generation USB power manager plus
9
www.linear.comCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 25
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 I
2
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-IC
10
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

42. 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 microcontroller
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.comCHAPTER 3. DETAIL HARDWARE DESIGN AND SYNTHESIS 26
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 examining 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

43. 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.
Then Ileak(max) >
Vbat(max)
(R1+R2)
R1 + R2 >
4.2
10 × 10
−6 > 84kΩ
The voltage input range to the MCU’s A/D pin must be 0V to 3V.
Thus: Va/d(max) =
R1
(R1+R2) × Vbat(max) = 3V
1+
R2
R1
=
Vbat(max)
Va/d(max)
=
4.1
3

44. 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 critical 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 presented in
the database. This section covers the database tables integrated into the MyStudies
database by the attendance register system.
4.1.1 Attendance Table

45. 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 classinstance 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:
• ID - Primary Key, Auto Increment.
• courseCode - An indexed field linking to a MyStudies course in the course table.
• typeID - Indicating the type of class, links to the classtype table.
27CHAPTER 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:
• ID - Primary Key, Auto Increment.
• noteString - A string representation of the note.

46. 4.1.4 classtype Table
This table holds strings for the different types of classes The classtype table contains the
following fields:
• ID - Primary Key, Auto Increment.
• 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:
12345
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.CHAPTER 4. DETAIL SOFTWARE DESIGN AND SYNTHESIS 29
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

47. 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.CHAPTER 4. DETAIL
SOFTWARE DESIGN AND SYNTHESIS 30
4.4.2 status.html
This page does not require authorisation and will return the status of the device.
4.4.3 sync.html

48. 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 usernames,
passwords and data.
The source code for a secure interface server implemented in python twisted.web
1
is

49. 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/CHAPTER 4. DETAIL SOFTWARE DESIGN AND SYNTHESIS 31
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

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

51. 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.CHAPTER 5. TESTING AND INTEGRATION
34
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:

52. 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 foxjumps 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.CHAPTER 5. TESTING AND INTEGRATION 35
Problem Diagnosis and Solution:
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.

53. 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.
Problem Diagnosis and Solution:
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.CHAPTER 5. TESTING AND
INTEGRATION 36
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

54. 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.
Problem Diagnosis and Solution:
The 5V regulator chip was removed and it was verified that the PCB connections and components 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.
5.1.8 Battery Charger
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.CHAPTER 5. TESTING AND INTEGRATION 37

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

56. 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.CHAPTER 5. TESTING AND
INTEGRATION 38
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 determining 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:

57. 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.
39CHAPTER 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 Output Voltage
Current
from Source

58. Output
Current
Output
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.CHAPTER 6. MEASUREMENTS AND RESULTS 41
(a) Low-power regulation with 4.1V input
(b) Low-power regulation with 3.3V input
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 Output Voltage
Current
from Source
Output
Current
Output
Voltage
Ripple
3.3V 3.24V 293mA 270mA 40mV
3.6V 3.36V 302mA 272mA 80mV

59. 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 voltages of 4.1V
and 3.3V.
(a) Full-power regulation with 4.1V input
(b) Full-power regulation with 3.3V input
Figure 6.2: Full-power operation regulated output with max and min input voltage.CHAPTER 6.
MEASUREMENTS AND RESULTS 42
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.
6.1.5 Battery Charger
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:

60. Ibat = I3V 3 ×
3.3
Vbat
/0.9 + I5V ×
5
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.CHAPTER 6. MEASUREMENTS AND
RESULTS 43
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

61. 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 software 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 touchpads 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.

62. • The MAX1811 USB Li-Ion charger IC from Maxim-IC. Minimal external components
required for an effective USB powered Li-Ion battery charger.
44CHAPTER 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 investigated.
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 temperature 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.

63. [2] BITKOM Radio Frequency Identification (RFID) Project Group:
Rfid white paper. technology, systems, and applications. Available 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, October 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.
46Appendix A
Project Planning Schedule
Table A.1 represents a weekly schedule for the planned completion of different aspects of this
project.
Week Start
Date
Schedule
1 21 July System analysis and planning
2 28 July Find important component solutions: Wifi module, battery
charger, batteries, regulators, touchpad.

64. 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. Continue 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
47Appendix B
Project Specification
The project specification as derived from the original project proposal by H.R. Gerber.
B.1 Functional Requirements

65. 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 administration
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.
48APPENDIX 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.

66. • 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 characteristics:
• 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

67. 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 systemlevel
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 available 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 synthesis 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.
51APPENDIX C. OUTCOMES COMPLIANCE 52

68. 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 example, 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 interference, 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 demonstrated 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 research, 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 engineering
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:

69. • 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
53APPENDIX D. CIRCUIT DIAGRAMS AND PCB LAYOUTS 54
Figure D.1: User Interface Module SchematicAPPENDIX D. CIRCUIT DIAGRAMS AND PCB LAYOUTS 55
Figure D.2: User Interface Module PCBAPPENDIX D. CIRCUIT DIAGRAMS AND PCB LAYOUTS 56
Figure D.3: Processing and Communications Unit SchematicAPPENDIX D. CIRCUIT DIAGRAMS AND PCB
LAYOUTS 57
Figure D.4: Processing and Communications Unit PCBAPPENDIX D. CIRCUIT DIAGRAMS AND PCB
LAYOUTS 58
Figure D.5: Power Supply SchematicAppendix E
Photos and Screenshots
Figure E.1: Photo of user interface ontop of processing and communications unit.
59APPENDIX 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

70. @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"
###