1. Equipment Digital Logbook
Patrick Brown, Jesse Caldarola, Tyler Hughes, Michael Langevin
Department of Electrical & Computer Engineering
University of Alberta
Edmonton, Canada
Abstract— This project’s aim was to prevent forgetful
(or unscrupulous) researchers from erroneously logging
their hours of use in the existing equipment logbooks at the
National Institute of Nanotechnology (NINT). To
accomplish this task our device was designed to block
signals vital to the operation of laboratory equipment.
These signals were only allowed to pass when a user had
signed in using a valid NINT Radio Frequency
Identification (RFID) security card. The logged times
were then recorded for billing purposes.
Keywords—Equipment Digital Logbook; Data Logger; RFID
I. INTRODUCTION
A. Project Motivation
The National Institute for Nanotechnology (NINT) is home
to several state-of-the-art electron microscopes. These million-
dollar instruments are used to conduct nano-scale materials
science research. Operating and maintaining these precise
instruments is incredibly costly; as such, users of the
equipment are billed according to their usage time. The system
currently relies on a traditional pen and paper logbook which
is prone to inaccuracy and can be exceedingly tedious to
maintain. To overcome this problem our design team created a
digital logbook which can be directly interfaced with
equipment in the NINT labs to restrict access to authorized
personnel. With our device connected, only users who have
authenticated using a NINT issued radio frequency
identification (RFID) card will be able to use the equipment.
The time between login and logout is then automatically
recorded, eliminating the tedium of manual tracking while
simultaneously improving accuracy.
The Canadian National Research Council (CNRC) operates
many laboratory facilities similar to NINT, many of which
currently face this same tracking problem. Ensuring our
project can be generalized to other facilities is an important
secondary goal.
B. System Basic Operation
The Equipment Digital Logbook implements access
control by restricting the flow of data between a lab device
and its peripheral controller or display. A user with valid
NINT security clearance can verify their identity by scanning
their RFID security card and selecting a project code. Once
verified by the digital logbook, the link between a lab device
and its peripheral unit is re-established and the user is notified.
The amount of time the user has been logged in, as well as the
user’s RFID and the project number associated with the
session are then displayed on the LCD screen. The date and
the user’s session length are saved to an SD card along with
the selected project code and user-specific RFID code. This
allows the administrator to bill users for equipment usage
efficiently and accurately.
C. Principle Specifications
• Utilize existing security tags: Identify users via
standard issue NINT RFID security cards.
• Project based billing: Associate up to 3 projects with
each user.
• Necessity of authentication: Block use of connected lab
equipment whenever there is no active user session.
• Track session length: Record and store the length of
each session along with the user and project credentials
used to authenticate.
• Ease of setup: Utilize a simple file structure to make
initialization and maintenance of the system straight
forward for the administrator.
D. System Overview
The digital logbook is controlled by the ATmega32-16PU
microcontroller which contains the system firmware and
coordinates operations between all of the subsystems. As can
be seen in Fig. 1, the digital logbook contains 5 subsystems:
The RFID scanner, LCD Display, keypad input device,
switching relay, and the SD card shield. The system is
powered from a standard North American wall outlet (120V,
60Hz) and uses a wall-wart power supply to provide the more
manageable DC working voltage (9V, 0.8A). The 9VDC is
regulated down to 5VDC which powers all of the subsystems.
The LCD Display and Keypad serve as the user interface of
the device, allowing users to view and interact with the
various menu options.

2. Fig. 1. System Block Diagram: RFID Digital Logbook
The RFID scanner reads the facility and user codes off
scanned cards in order to determine whether or not a user is
authorized to operate the connected lab equipment. An SD
card reader and a Real Time Clock Calendar are housed on a
separate circuit board (the SD Card Shield). The final
component of the digital logbook is a switching relay circuit
which is used to either block or pass the I/O signals from the
BNC and USB connectors. This switching relay is normally
open thus blocking signal transmission, closing only during
active user sessions.
II. HARDWARE ANALYSIS
A. Power Circuitry
The power supply circuitry was designed to provide 5V to
the user-interface peripherals, and 3.3V to the SD card reader.
In order to maintain stable operation of the digital logbook, a
sufficient supply was required that could handle the power
draw of our large LCD display and data-logger. The 120V
60Hz to 5VDC 0.8A conversion can be seen in Fig. 2 and is
made up of an AC-DC centre-positive wall-wart, Single-Pole
Single-Throw (SPST) rocker switch, blade fuse, forward-
biased diode, decoupling capacitors and a 5V voltage
regulator. It was determined that a battery option would not be
implemented as the client did not require the device to be
mobile but did require the device to have long, continuous
operation. The HEA-48-090080-1 9VDC 0.8A wall-wart was
chosen as it had substantially low no-load power consumption
(300mW) and ensured our voltage regulator did not reach
Fig. 2. Power Circuitry
excessive temperature levels [1]. A 0.8A current rating was
chosen because the projected maximum current draw of the
digital logger exceeded 0.5A but was well below 0.8A. The
SPST rocker switch was rated at 16A and 12V DC which
ensured full suppression of internal arcing at the open switch
contacts. The power circuitry was fused using a standard
automobile terminal open (ATO) blade fuse and blade fuse
mount, rated at 1A and with a minimum opening time of
100ms at 200% fuse rating [2]. An ATO blade fuse was
chosen due to its low cost, ready availability and because a
more responsive fuse was not essential to our design. The
1N4007 diode prevented any reverse current into the fuse or
wall-wart adapter and the decoupling capacitors ensure a
smooth signal was sent through the boards. The LM7805 1A
positive voltage regulator shifted the 9V input down to 5V
which was required by the remaining circuits in the main
board and the RTCC in the SD Card Shield. A 2.2V green
LED limited by a 330Ω resistor was also included in the
power circuitry as it was used as a power “ON” indicator for
the user.
B. RFID Scanner
An HID Proxpoint Plus RFID Scanner, provided by our
client, was used to read users’ security cards during the
authentication process. This scanner is set up by default to
output data using the Wiegand protocol, however converters
are available which can be used to interpret Wiegand signals
and output a serial signal in the RS232 format. We considered
both options but ultimately chose to work with the Wiegand
protocol as this was the less expensive option (eliminated the
need to purchase an RS232 converter). Wiegand protocol
relies on two data lines which are both held at +Vcc until data
is ready to transmit. During transmission one line is used to
send logic 1s and the other to send logic 0s [3],[4]. When a
line dips low (to ground) this is to be interpreted as a bit of its
respective line value being transmitted. In order to read this
properly we programmed the microcontroller to poll both
lines. When the microcontroller sees one of the lines drop to
ground, it waits for that line to return to +Vcc and then records
either a 1 or 0 based on which line (data 1 or data 0) it
detected the change on. The bits are transmitted in reverse
order (from MSB to LSB) so we then reverse the sequence and
begin multiplying each bit by the base 10 value of its bit
position. This results in the reconstruction of the base 10
numbers associated with each card’s facility and user codes.
The microcontroller then stores these values as unsigned
integers for comparison and record keeping purposes.

3. Fig. 3. Wiegand Protocol
C. Microcontroller
The microcontroller unit (MCU) chosen for the device was
the Atmel ATmega32-16PU commonly referred to as the
ATmega32. A controller with a high pin-out number and
support for Inter-Integrated Circuit (I2
C), Serial Peripheral
Interface (SPI) and an operating voltage around 5V was
required for our design. The ATmega32 provided support for
all of the aforementioned protocols at a cheap cost and was
easily accessible from the available laboratory supplies. The
AVR Atmel online community also played a factor in
selection, as there is a vast number of coding resources
available for the Atmel family. Finally, the low power
characteristics of the ATmega32 were desirable as the logbook
was to be capable of operating uninterrupted over days if not
weeks at a time [5]. The decision to use the ATmega32-16PU
rather than a microcontroller with lower power consumption
(operating voltage of 3.3V) was primarily influenced by the
choice of RFID Scanner and LCD unit. Both of these
peripherals required a minimum of 5V and were essential to
meeting the client’s specifications. Although the ATmega32-
16PU is capable of operating at a maximum frequency of
16MHz, the microcontroller firmware was designed to operate
the microcontroller at 8MHz. The decision to use 8MHz
instead of 16MHz was based on the fact that the device did not
require any quick response operations except for printing to
the LCD screen smoothly. By running the microcontroller at
8MHz we minimized power consumption without sacrificing
fluidity.
Fig. 4. Main Board Schematic (power and relay circuit removed)

4. D. Relay Connections and Solenoid Switch
Two sets of input/output connection pairs are located at the
rear of the digital logbook enclosure. One pair supports
Bayonet Neill-Concelman (BNC) while the other supports
USB connections. A single-pole single-throw normally open
(SPST NO) 2200 series reed relay from Coto Technology was
used to connect the path between the input and the output as
seen in Fig. 5. We chose the 2200 series reed relay due to its
small footprint, magnetic shielding, and particularly because
of its low dynamic contact resistance (200mΩ) [6]. This relay
is only closed when a control signal is sent by the
microcontroller indicating an active user session. The control
signal is used to switch on a transistor (BJT) current driver
which guarantees that the solenoid receives enough current to
hold the relay in the closed position. For standard USB 2.0
technologies there are two data lines, +Vcc, and GND. We
chose to directly connect the grounds and data lines while
passing the +Vcc line through the relay as seen in Fig. 4. The
advantage of this setup is that it guarantees the device cannot
operate (since it has no power) by disabling only one line. If
we were to disable only a single data line devices might still
operate; however, they would likely behave oddly due to a
portion of their signal being blocked. For the BNC connectors
there are only two lines, one signal line and one shield-ground.
We passed the signal line through the relay and connected the
shield-grounds directly from input to output. Use of a
transistor relay was considered however for the BNC it was
determined that sensitivity to noise, as well as variation in
signal voltage and frequency, would make this a poor choice.
If the device were designed solely for USB, a transistor relay
would be viable as the line is always held at a constant 5V.
E. SD Card Shield
To store the administrator configuration files and session
logs an SD card was chosen due to its small physical footprint.
The compact size allows it to occupy minimal space in the
device, and makes transportation to and from the
administrator’s personal computer simple. The RTCC was
also necessary for generation of the date and time stamps
which are stored along with each user session. In order to
allow for flexibility in the physical layout of components
within the enclosure it was desirable to have the SD card
reader on a secondary circuit board. The Adafruit Data
Logging shield [7] was chosen to fill this role. While this
shield was designed for use with an Arduino, it was easily
adaptable to function with our device as both an Arduino, and
Fig. 5. Relay Circuit
our ATmega32 rely on 5V power supplies. Additionally, this
data logger has a built in 5V to 3.3V regulation circuit to
produce the correct voltage to power the SD card reader.
Additionally, the shield uses I2
C protocols for communication
with the RTCC, and SPI protocols for communication with the
card reader. We had planned to use these protocols from the
outset and so this device was the perfect choice for use as our
secondary board. An added advantage of this choice is that
replacement of the secondary board does not require re-
milling or printing of a secondary PCB, merely the
replacement of a part which is readily available to order.
F. Enclosure and User Interface
The enclosure selected to house all of the components was
the Hammond 500-0940. This enclosure was large enough to
hold all of our internal circuitry and mounting brackets while
also providing a sleek, professional look for the user. The top
light-gray panel seen in the enclosure front view of Fig. 6 was
partially sloped at 30º in order to allow easier interfacing and
is made of 0.064” aluminum [8]. The dark-gray casing seen in
the rear view of Fig. 6 is made of 0.05” steel [8]. A 3D model
of the enclosure was created in the SolidWorks CAD program
for the purpose of generating precise drawings (seen in both
views of Fig. 6). These drawings measured the required drill
holes in the enclosure in order to mount all components
including the main and secondary circuit board (not shown in
Fig. 6). The drawings were submitted to an in-house machine
shop for drilling.
The user interface components include an RFID scanner, a
backlit 4x20 LCD screen and a 12 button matrix keypad. The
RFID scanner provided an authentication periphery for users.
The LCD screen displayed menu options and guided users
through the login process. A 4x20 display was used because it
allows the user to view all 3 project codes associated with
their profile without the need for scrolling. The matrix keypad
used only 7 I/O pins and provided 12 distinct input buttons, as
seen in Fig. 4 as “KEYP1”. A matrix keypad was selected as
an input method because it provides a large number of inputs
while consuming a relatively small number of I/O pins on the
microcontroller.
Fig. 6. SolidWorks Model

5. III. FIRMWARE ANALYSIS
A. Main Program Overview
The following section will delve into the topic of the
firmware developed for the assembled project. The ATmega32
comes with 32 registers categorized into four ports: A, B, C,
and D, with each port containing eight of the registers. Some
of these ports have unique functionalities but they are all
capable of operating as general I/O data pins. For the purposes
of this project, the only specialized pins used were port B’s
SPI pins and port C’s I2
C pins [9]. The high level of versatility
with the pins made the ATmega32 a strong choice for
integrating project firmware. The ATmega32 was
programmed through the JTAGICE MKII (or “JTAG”)
programmer using Atmel studio.
As illustrated in the flowchart in Fig. 7, the code begins
with the initialization of the I2
C protocol, SPI protocol and the
LCD. Once initialized, a message is displayed on the LCD
prompting the user to scan in using their RFID card. If the
card matches with a card number existing in the database, then
the user will be prompted to choose from a list of projects that
are attached to their RFID number. These project codes may
differ from card to card as projects can be unique to a single
user, or assigned to a group of users. These project codes are
often long and complex making them hard for the user to
remember; this selection list eliminates the need to memorize
the exact details of each code. Once the user has selected the
project they wish to work on, a timer will start and the relay
will be closed, allowing them access to their device. There is
an automatic timeout after two hours to prevent excessive
billing in the event that the user forgets to clock out (the
length of this time-out window is a parameter that can be
edited by the administration). In the event that they do clock
out, the timer will stop and the relay will close resulting in the
equipment becoming inaccessible. All the users’ details (RFID
number, project number, date and duration) are written to an
SD card for the administrator to allocate charges accordingly.
B. SD Card Code
The base code for the SD card was taken from CC
Dharmani’s open source Atmega32 data logger project [10].
The base code was then modified to fit the needs of this
project. The main functions utilized were the writefile and
readfile functions. As the names suggest, the writefile function
is used to write information to the SD card in a .csv format
and the readfile function is used to read that data.
The writefile function works on the premise of writing
each piece of information to a 512 byte string denoted as
“datastring” and then writing that string into a sector on the
SD card. A sector is the smallest physical storage unit on a
device. This unit is usually 512 bytes long. So if there was an
800 byte file that needed to be written to the card, two sectors
would be occupied [11]. “Datastring” is defined as a character
and thus all information written to it must be in ASCII format.
An ASCII decoder is used to make the information viewed off
the SD card readable. As Fig. 8 illustrates, each piece of
Fig. 7. Main Code Flowchart
information is separated by a comma, with the last entry
followed by a comma, a newline feed and carriage return. This
is done to maintain the .csv format. The order that the data is
stored in the CSV file is the same as the order in which the
strings were appended to the “datastring” (Fig. 9).
Fig. 8. Variable Datastring 1 and .CSV Log File

6. Fig. 9. SDcard Write Code
The readfile function works in a very similar way to the
writefile function. In this function, the program searches for
the first sector that contains information. Once found, that
sector is “dumped” into a 512 byte string known as “buffer”.
This string, when viewed through a debugger, contains
information in an ASCII format. The format of buffer is
exactly the same as the format of “datastring”; each column in
the CSV file is separated by a comma which can be viewed in
“buffer” as decimal 44. Each row is separated by a ‘r’ and ‘n’
whose ASCII representations are “13” and “10” respectively.
Fig. 10 illustrates this point.
In order to pull the required values from the buffer, a loop
was created to scan each byte in “buffer” until detection of a
“44” (comma). Since the RFID card codes are five digits long,
the counter variable would be subtracted by six, in order to
point at the byte preceding the RFID code. If this byte was a
“10” (n) this guaranteed that the bytes between the “10” and
“44” referred to an RFID code. This approach assumed that all
the RFID codes were organized in the first column of the CSV
spreadsheet. Once the RFID card code was found, the counter
pointing to the comma would be shifted over by a specified
value to allow the corresponding project codes to be read into
variables. The CSV file must follow the prescribed layout as
seen in Fig. 10 for this approach to work. When tested through
the Universal Asynchronous Receiver/Transmitter (UART),
all variables were read and utilized appropriately.
Fig. 10. Variable Datastring 2 and .CSV Log File 2
IV. TESTING
A. Hardware
Tests began on a part-by-part basis. Each component was
circuited on a breadboard and tested for working operation
using simple LED tests with the exception of the LCD, RFID
scanner and SD card shield. The LCD was connected to the
ATmega32 and after initialization, was tested by printing lines
and adjusting the potentiometer for optimal contrast. The
RFID scanner was tested first by probing the D0 and D1 lines
with an oscilloscope on falling-edge triggering. Once a card
was scanned, the lines could be read together as a 35 bit code,
converted to decimal and finally compared with the assigned
card number to ensure proper operation. The SD card shield
testing will mostly be discussed in the software section of
testing, and included the use of the UART, ATmega32, JTAG
MKII and physical SD card.
Subsystem tests were made up of 3 particular tests. The
first test was to ensure minimal noise and amplitude reduction
of BNC and USB signals passing through the relay. It was
found that there was less than ±0.1% error between a signal
sent from a function generator (via BNC) and the resulting
measured signal after passing through the closed relay. This
test was repeated after full PCB implementation to ensure
signal integrity.
The second subsystem test involved the ATmega32, RFID
scanner and LCD screen. A card was read by the scanner,
processed by the ATmega32, and finally printed to the LCD.
This test was selected because the final firmware would
require the ATmega32 to store the RFID card code in its
registers for later comparison with the SD card data. The LCD
was included for an easy check on the ATmega32 registers. It
was found that the card code was read and stored accurately
upon every scan once the C++ code was properly written.
The third subsystem test involved the power circuitry
efficiency. Using the circuit in Fig. 2, we expanded the load at
the 5V DC side such that the power supply was running at an
estimated full-system load (~650 mA, 5.85 W). After 3 hours
of continuous operation it was found that the voltage regulator
was slightly hot to touch but well within accepted
temperatures. This was because the enclosure was designed to
allow enough air-flow for extended use.
B. Firmware
Incorporating the debugging functionality of the JTAG
programmer, all software tests were done using a "burn-and-
learn" approach. Once the code had been written, it was
compiled to ensure no errors were found and that the program
would not corrupt the microcontroller. Upon an error free
compilation, the code was programmed onto the ATmega32
and run in real time. If the code did not work as expected,
breakpoints were set to step through the program line by line
allowing exact pinpointing of the code that gave unsatisfactory
results. This approach was followed throughout the entire
project until the final weeks of design when the hardware was
integrated onto the PCB. Upon hardware integration, real time

7. debugging became impossible due to not having space on the
PCB for the JTAG MKII and from that point onwards all
software tests were done by programming the ATmega32 on a
breadboard, transferring it over to the PCB, and running the
device. Determining where the errors in code arose was much
more difficult when using this approach and as a result
extensive troubleshooting was required.
Setting up the LCD consisted of wiring only 12 out of the
16 pins. A simple test was conducted after each group of pins
was wired to its designated input/output. To start, pins 1 and
16 were connected to a common ground, followed by pins 2
and 15 being connected to the 5V rail. A voltmeter was used
to assure that both the 5V and ground were received in the
correct locations. Lastly, pins 4 through 6 and 11 through 14
were connected simultaneously to the data ports on the
ATmega32. A final test was conducted by writing a small
initialization sequence that wrote some characters to the LCD.
This initialization sequence consisted of assigning the initial
states of the read/write pins to our ATmega32, assigning a
slave select pin, and loading a custom character library
(retrieved from the extreme electronics website [11].
It was essential to implement a working LCD beforehand
to ease the eventual debugging of the keypad. The seven pins
on the keypad were directly connected to pins 0 through 6 on
port A of the ATmega32 microcontroller. The pins on the
keypad represent the four rows and the three columns. A small
test was conducted at this point at assure that the three column
keypad pins were indeed resting at a high voltage of 5V.
When a key on the keypad is pressed a row pin and a column
pin is grounded, corresponding to the key pressed. The four
row pins are assigned as input pins to the ATmega32, while
the remaining 3 columns pins are assigned to output pins.
Code was written to essentially continuously scan the row and
column pins for any key presses, and returns “0xFF” while no
key presses were detected. After this code was written,
another test was conducted by outputting the result of the
returned character, determined by the interpretation of our
code, to the LCD. After every character on the keypad was
successfully outputting its corresponding character to the
LCD, we concluded that the keypad was successfully
implemented.
The relay was fairly simple to implement and test. Before
implementing it in our circuit we tested that the relay switch
was in fact working. We simply powered one of its inputs
with a 20mA and 1V DC source, and set the other to ground.
A voltmeter was used to read its output, while the other input
was connected to ground. We applied the required 5V to the
relay and observed the output switch from a grounded signal
to the 1V, 200mA signal. After the relay was installed in our
circuit, we conducted one last test in order to assure that the
ATmega32 could provide sufficient power through one of its
pins to force the relay to switch from one input to the other.
Code was written to power pin 7 on port A, which was
responsible for powering the relay. Our tests concluded that
the relay had been successfully implemented into our circuit.
In order to test the SD card read and write functions, and to
set the time and date of the RTCC, the UART protocol was
utilized along with a hyper terminal. By utilizing the
functionality of the UART, the source code provided by C.C.
Dharmani allowed for the time and date of the RTCC to be set
through the hyper-terminal in a very user friendly way. Once
the RTCC was configured, the read and write capabilities of
the source code could be tested for the SD card. The tests were
carried out by executing code to write to the SD card and then
display what was written in the hyper-terminal. Once the text
printed to the hyper terminal was found to match the data
written to the SD card, was considered successful. A similar
approach was followed for the read function. The contents of
the SD card sector were read into a separate variable and the
contents of that variable were then displayed to the hyper
terminal. Though this approach was tedious at times, it
provided extremely valuable insight into how the information
of the SD card was organized and could be manipulated.
These insights lead to the decision to structure our data in the
final format which is shown above in figures 8 and 10.
It was found during final system testing that the RTCC had
become damaged and was no longer functioning. We believe
this occurred due to contact between one of its circuit traces
and the epoxy used to mount the shield. This epoxy is
believed to have eaten away at the trace, damaging the RTCC.
As a stopgap measure on the prototype we implemented a
ticking clock based on the ATmega32 system clock frequency.
This “virtual clock” does not handle dates but is sufficient for
tracking and recording the length of user sessions.
V. FUTURE CONSIDERATIONS
The Digital Logbook, being a prototype, was designed for
a very specific purpose. This presents some restrictions for
expanding its use in the future. For example, the prototype
was requested to specifically control access to a Precision
Etching Coding System by gating a BNC connection.
Therefore, it can only gate BNC connection types (and USB
connections types, which we added as a bonus feature).
However, there are many connection types that could be added
in order to increase compatibility when controlling access to a
variety of devices. If we added gated access to high resolution
imaging connections (such as: VGA, DVI or HDMI) to the
already existing BNC and USB connections, the Digital Log
Book’s compatibility could be significantly increased.
Another feature to be considered in future work would be
to make some adjustments to the enclosure. Security would be
increased if the SD memory card could only be removed from
inside the Digital Logbook, through a locked latch perhaps,
where only the administrator would hold the key. This would
prevent the average user from simply removing the SD card
and adding their own credentials to the list of approved
credentials.
Lastly, upon completion of the prototype, we discovered
plenty of wasted space inside of the enclosure. Should the
prototype be mass-produced the enclosure could be redesigned
in order to eliminate wasted space, resulting in a smaller and
lighter device, increasing the variety of environments in which

8. it can operate. Reducing the size of the enclosure would also
reduce the total budget for the project.
VI. CONCLUSION
The Equipment Digital Logbook is a fully functional data
logger that can be utilized by an administrator in a lab
environment. A user’s lab session with a specific BNC or USB
controlled device can be successfully tracked provided the
administrator has the appropriate background pertinent to the
two required .CSV files. The interface is intuitive and allows
users to easily navigate through menus. Once a user
authenticates successfully, dynamic signals will pass through
the digital logbook with less than ±0.1% deviation. The digital
logbook prototype is designed to lie flat on a horizontal
surface; however wall-mounted versions with smaller
dimensions could be implemented using the same electrical
components. All primary design goals are satisfied by the
prototype, although the secondary specification of pulling date
and time from the RTCC was not met. To overcome this
problem (the RTCC being damaged) we wrote additional code
to simulate a clock (although it cannot handle dates as loss of
power means it stops “ticking”). The simulated clock was
implemented to track and record a user’s session length and
does its job admirably. As such we consider the logger to be
ready for implementation in the lab. The issue with the
RTCC can also likely be remedied in future models simply by
handling the SD card shield mounting with greater care.
Overall the project was very successful as all of the
features desired by the client were implemented. Additionally
many optional features such as the automatic timeout period,
support for USB technology, and the requirement for a “same
card” scan during logout were implemented. At the time of
this writing the device is fully ready to be implemented in the
lab for which it was designed.
VII. ACKNOWLEDGMENTS
Many talented people helped us during this lengthy design
process and we would like to express our gratitude to each of
them. Firstly, to Martin Kupsta, who afforded us the
opportunity to design this device from the ground up and was
always willing to share his expert knowledge of embedded
system design. Also to our lab technician, Alan Lim, for his
patience and unwavering (though often sarcasm laden)
guidance. Daniel Oloumi, our group TA who provided us
with a fresh perspective and always had the perfect software
recommendations to keep our plans organized and
professional looking. Finally, we would like to thank the
course coordinator, Loren Wyard-Scott, who taught us how to
take an idea and turn it into a finished product.
VIII. REFERENCES
[1] Hitron Manufacturing, “HEA-48 Datasheet”, [Online]. Available:
http://pdf1.alldatasheet.com/datasheet-pdf/view/287087/HITRON/HEA-
48.pdf
[2] Littelfuse, “Littelfuse_atof_datasheet”, [Online]. Available:
http://www.littelfuse.com/~/media/Automotive/Datasheets/Fuses/Passen
ger-Car-and-Commercial-Vehicle/Blade-
Fuses/Littelfuse_ATOF_Datasheet.pdf
[3] B. Antoniewicz, “Hacking the Wiegand Serial Protocol”, [Online].
Available: http://blog.opensecurityresearch.com/2012/12/hacking-
wiegand-serial-protocol.html
[4] IB Technology, “Magswipe Datasheet”, [Online]. Available:
http://www.ibtechnology.co.uk/pdf/magswipe_dec.PDF
[5] Atmel Corporation, “2503S”, [Online]. Available:
http://www.atmel.com/devices/atmega32.aspx/ATmega32(L)_Summary
.pdf
[6] Coto Technology, “2200 SERIES REED RELAYS”, [Online].
Available: http://cotorelay.com/product/2200-series-reed-relays/
[7] Adafruit, “Shield Overview”, [Online]. Available:
https://learn.adafruit.com/adafruit-data-logger-shield/shield-overview
[8] Hammond Manufacturing, “500-0940 Datasheet”, [Online]. Available:
http://www.hammondmfg.com/dwg16Steel.htm#30dA/500-0940.pdf
[9] Atmel Corporation, “ATmega32/L datasheet”, [Online]. Available:
http://www.atmel.com/images/doc2503.pdf
[10] C.C. Dharmani, “microSD Atmega32 Data-logger”, [Online]. Available:
http://www.dharmanitech.com/2011/05/microsd-atmega32-
datalogger.html
[11] LSoft Technologies Inc, “File Storage Hardware and Disk
Organization”, [Online]. Available: http://ntfs.com/hard-disk-basics.htm
[12] Extreme Electronics, “Using LCD Module with AVRs”, [Online].
Available:
http://extremeelectronics.co.in/avr­tutorials/using­lcd­module­with­avrs/