Group SD0609
From ECE Department Wiki
Contents |
Team Members
Students
Advisor
- Contact Information
- College of Engineering & Architecture
- North Dakota State University
- 1300 Centennial Avenue
- Fargo, ND 58105 - USA
- Office: CEA 103
- Phone: (701) 231-7403 Fax: (701) 231-8677
Abstract
With the increasing age of the current card key system and the escalation in theft within our ECE department, an improved card key security system is required. The available options presented by the Physical Plant here at NDSU and what was available commercially were found to be prohibitively expensive. Our senior design group has designed an equivalent yet significantly more cost effective and user friendly system. The design will allow our ECE department to cut cost dramatically when implementing card key access to every room. The project is based on three separate systems: the individual card reader unit, a central server database/power distribution unit, and a key controller graphical user interface. The design incorporates both TCP/IP protocol for transmission as well as Power over Ethernet (PoE). A Rabbit Semiconductor RCM2200 microprocessor converts data from a Tri-College swipe or proximity card and packages the NAID number into a TCP/IP packet to be transmitted back to the central server for validation. The central server comprises Linux, Apache, PHP, and a MySQL database which is controlled by the key controller via the graphical user interface. With ease of use in mind, the user interface allows the key controller to add/remove users to the database with ease, granting specific students access to individual rooms as permitted. Students can be limited to just one or a specified number of rooms and can be removed automatically at the end of the day, semester, or immediately by the key controller. Upgradeability and maintainability are addressed by making the systems modular and choosing widely used components. Overall our system is intended to serve as a user friendly, highly adaptable, and cost effective way to increase the security level of our department.
Initial Project Description
Introduction
Problem
Current Card Key System in ECE
- System is 20+ years old
- Cannot be expanded to more doors
- Increasing security concerns in the department
- Campus replacement solution prohibitively expensive
Solution
Senior Design Project
- Harness ECE student brain power
- System can be modular and easily adaptable
- Tailored to ECE faculty operation
- Cost effective solution
Our team has been tasked with building a replacement cardkey access system for the ECE Department.
Requirements
- Able to read Tri-College cards
- Check out ECE equipment
- Computer account creation
- Modular design
- A simple interface for audit and control
- Simple and stable design
- Use off the shelf hardware
- Components readily availabe in case of replacment
- Maintenance is minimal
Hardware
Card Reader Unit
Card Reader Component Overview
- Magnetic Swipe (Omron)
- Proximity (HID)
- RCM2200 Microprocessor (Rabbit Semiconductor)
- 48 – 5 V Converter (TI) x2
- PCB Board with integrated switch for door lock
- Door Lock (TBA)
Magnetic Swipe Card Reader
- Low Cost
- Industry Standard
- Low Power CMOS
- 5 V Operation
- TTL Logic
- Data Stream
- Card Load
- Clock (per track)
- Data Sheet
HID Proximity Card Reader
- Industry Standard
- Low Power CMOS
- 5 V operation
- TTL Logic
- Data Stream
- Card Load
- Clock
- Access Indication
- LED and Beeper
- HID ProxPoint Plus Data Sheet
Rabbit Semiconductor RCM2200
- Low Cost
- 26 I/O ports
- 10BaseT Ethernet
- 22.1Mhz processor
- Dynamic C
- Highly adaptive
- Large Libraries
- Dynamic C Libraries
- Dynamic C TCP/IP Libraries
- 5 V, 134mA draw
- RCM2200 Data Sheet
- RCM2200 Schematic
- RCM2200 User Manual
Reader Unit Power Conversion
- 48 - 5 V Converter
- Rabbit RCM2200
- Magnetic Card Reader
- Proximity Card Reader
- 48 – 5 V Converter
- Current Door Lock Mechanism on RM233
- 1.2A draw
Card Reader PCB
- Modular Design
- Surface Mount Components
- ZIF socket for RCM2200
- Through-hole capatability for DC/DC converters
- Design and Testing Considerations
- Header for each RCM2200 pin
- Test points for quick and easy diagnosis
- Circuit descriptions
- Power Circuit
- Power for RCM2200
- Power for door lock solenoid
- LED indication
- Power indicator
- Network Activity indicator
- Network Connectivity indicator
- Door Lock Circuit
- Use transistor to replace mechanical relay
- Supplies power to door lock solenoid
- Power Circuit
Central Controller
Central Controller Overview
- Choice: Ethernet with TCP/IP
- Allows Power-Over-Ethernet (POE)
- Inexpensive and meets fire code
- No runs more then 100m in building
- Allows for secure closed system
- Follows modular design requirement
Power Requirements
Card Reader Component Power Specifications
- Rabbit: 5V DC with 5% tolerance, 134mA
- Swipe Reader: 5V DC with 5% tolerance, 20mA
- HID ProxPro: 5-16V DC, 75mA @ 5V
- Door Lock: 12V DC, 300mA
- Total Power needed: 229mA @ 5V 300mA @ 12V
Approximately = 4.745 W total draw per reader
- If all 12 doors were being used at the same time, the power being drawn would be approximately = 56.94 W
- We went with 3 48 W 120VAC - 48VDC Power Supplies to power the doors
- Each Power Supply will power 4 doors, which allows one to fail without total power loss to the doors
Power Distribution
- Outlet~120 V AC
- 500W 1000VA UPS back-up
- 120VAC - 48VDC Power Supply for POE
- 48V - 12V voltage converter for Door Lock
- 48V - 5V voltage converter for Rabbit, Proximity and Swipe reader
- 120VAC - 48VDC Power Supply for POE
- 500W 1000VA UPS back-up
Power Distribution Flow Chart
Software
LAMP (Linux, Apache, MySql, PHP)
From The Wikipedia Article...
The acronym LAMP (or L.A.M.P.) refers to a set of free software programs commonly used together to run dynamic Web sites or servers
- Linux, the operating system;
- Apache, the Web server;
- MySQL, the database management system (or database server);
- Perl, Python, PHP, scripting/programming languages.
To be precise, it is an open source Web platform.
Though the originators of these open source programs did not design them all to work specifically with each other, the combination has become popular because of its low cost and because of the ubiquity of its components (which come bundled with most current Linux distributions particularly as deployed by ISPs). When used in combination they represent a solution stack of technologies that support application servers.
For this project we found a LAMP setup to be a perfect fit. It's free, there is a wealth of documentation and help available and many tools exist to reduce the work required.
Network Server (Java)
- App listens on certain port for incoming authentication request.
- Receives request and passes on to mysql to see if it's valid.
- Gets Response and sends back a yes or no.
Status Check Routine (Java and Bash)
- App listens on a certain port for incoming status check messages.
- Whenever it gets one put an entry in a table. Bash script checks this every X minutes.
- Table is cleared every X minutes.
Status Check Program (Bash Part)
- Check table every X minutes, if it isn't there, send an alert email.
- Once a reader has been determined not to be operating correctly keep checking for it but don't send an alert email for that particular unit. Once it comes back up start over and send an alert email if it isn't there again.
C Code on Rabbit
Scheduled for 405 this fall we will be implementing a Dynamic C program within each card reader unit. This program will be able to:
- Read data from a Magnetic Swipe Reader
- Data stream on PB2
- Card Load on PB3
- Clock on PE0
- Read data from an HID Proximity Reader
- Data stream on PA2
- Card Load on PA3
- Clock on PE0
- Parse unwanted characters in the data stream
- Banking reference never transmitted
- We will only be using NAID Number
- Residual characters never transmitted
- Convert Information into TCP/IP Protocol Packet
- Possible conversion of characters
- Possible code appended to packet for security
- Packet encapsulates:
- IP Address of reader
- Student NAID
- Typical Protocol information
- Sends TCP/IP Packet
- Information sent to Central Server on a secure, closed circuit IP network.
- Closed system ensures security and reliability
- Rabbit then waits for feeback
- Central Server looks in the database
- Grants/Denies access into a room
- Account Creation
- Equipment Checkout
- LED Indication
- Central Server looks in the database
- Special case considerations
- Multiple swipes
- Time limits
- Invalid Cards/reads
Testing and Design Modifications
Transmission Line Effects
- Problem: Drop in voltage due to solenoid in-rush current
- Solution: 220uF capacitors to correct current lag as well as variable t-line length.
- Problem: Pinout for RCM2200 on PCB is incorrect.
- Solution: Traces cut and jumper connections replaced
- Problem: Pads for door lock circuit incorrect.
- Solution: Transistor remount and jumper connections replaced
ID Card Issues
- Problem: Unit tries to read every card
- Solution: Only Tri-college swipe/prox card identified and EMPLID data validated. All other cards ignored and data is never collected. (i.e. Debit, Credit, PetSmart Rewards, etc.)
- Problem: Timing issue with send/recieve from server
- Solution: Wait statements replace printf statements in method to speed up response time.
- Problem: No fail-over response from server
- Solution: Card reader tries to validate ID number from server database. If no reply after two seconds - resends the data. If no response again, sends to fail-over server database. This will help our 100% up-time goal.
Installation and Trial Period
Replacing ECE CardKey System
Replacement started out by removing the outdated and now inoperative CardKey system housed in Rm233 in the ECE building. The image shown on the right compares the amount of hardware required for each system. The old CardKey was limited to four doors with the pictured hardware. Our project is circled on the far right and is currently capable of guarding access to 16 doors with the possibility of supporting up to 24 doors total. Additionally the old system required a seperate power and communication line. Using a concept called Power over Ethernet our design is able to supply a data transmission line as well as supply the neccessary power to each unit, requiring only one hardline connection per door.
Installing our CardKey System
Installation of our senior design project was quite simple. First and foremost we were tasked to replace the existing hardware from the old system and enable card access to the current four doors. Our system was designed for this purpose in mind; to use the original door locking mechanisms. The only matter left at hand was to run a new ethernet cable from the central server through the false ceiling to the card reader unit. This task proved to be quite simple and our system was operational in a matter of hours. The initial card reader unit was placed on Rm233 because it housed the central server and was the most logical door to operate the system on a trial basis. Our initial tests confirm its intended operation, noting the lag time between card swipe and door access to be quite acceptable.
More doors will follow including Rm 225, 237, and 239.
Documents
- Requirements Capture (403)
- Options Considered (403)
- Presentation (403)
- Updated Requirements Capture (405)
- Abstract (405)
Timeline
Gantt Chart Updated 05-05-06
Keywords
- RFID
- Rabbit Semiconductor
- RCM2200
- MySQL
- PHP
- Linux
- TCP/IP
- Magnetic Swipe Reader
- HID Proximity Reader
- Network
- Embedded System
- Dynamic C
- Account Creation
- Door Access
- Security
- Power over Ethernet
- Power Conversion
- DC-DC Converter
- Senior Design
- Spring 06
- Summer 06
- Fall 06






















