Electronic Keypad Controlled Alarm

EE331 – Design Project

Electronic Keypad Controlled Alarm

Steven Hansen, Joe Bourassa, Trevor Paschke

INTRODUCTION

This project for our group meant that we finally had a chance to put our knowledge of computer and electrical systems. For us this was the first time we have worked with these kinds of systems and with assembly code. It was also the first time we built a project from the ground up. As such there was a lot to overcome and I think that overall we were successful. Our project may have changed over the course of the term but in the end we all put over 20 hours into this project making it a lengthy but rewarding experience.

In the end we were able to finish our project with most of the functionality we initially wanted to be in it. We were missing the motor which would have been the main piece of our project and that was disappointing for us but we chose a direction that allowed us to not only create something that we are proud of but allowed us to still learn a lot about how MCU’s work and how to create a system that works together.

Overall I would just like to say that this project, while challenging and more time consuming that I would have imagined was actually a very great learning experience and it was actually practical experience that I believe was very crucial for the program that I am in. My only regret is that I did not have more time to put into this project in order to make it even better.

ORIGINAL PROPOSAL

Description

Our project proposal is to design and implement electronic keypad controlled lock. This would be similar to locks found on safes. Receiving correct input from the keypad would retract a deadbolt. There would also be an alarm system where if 3 wrong inputs are input, an alarm will sound. There is also a 13 digit master code for changing passwords. There is also an LED indicator for correct input.

MCU

We will be using the PIC16F886 because of its availability and it being recommended for the projects. The scope of this project does not require lots of pin inputs or any overly specific tool or resources, so the simplicity of this chip works well.

Design Challenges

The most challenging aspect will most likely be controlling a retracting deadbolt. Another consideration is creating a tamper-resistant system.

Members

Steven Hansen – leader, and working on the alarm and tamper-resistant part

Joe Bourassa – programming the keypad and controls

Trevor Paschke – deadbolt motor and other peripheral control

Timeline

1 Week – Prep and research; rough draft (Oct. 21)

2 Weeks – Design/prototype; programming at least 50% complete (Nov. 4)

1.5 Weeks – Bridge gap between program and hardware (Nov. 15)

1.5 Weeks – Polishing, testing and finishing report (Nov. 24/25)

This was the original proposal that we handed in back in October. It was an important starting off point, however, we were quite naïve to what we were getting ourselves into but that is part of the learning process.

BLOCK DIAGRAM

REPORT

2. After starting this project we had to decide what MCU to use and why. At the original point of time we didn’t really know much about MCUs and which one would be able to help us out the most. After doing a little bit of research we decided to go with the recommended PIC26F886. Not only did this MCU allow us to have 28 pins to work with, it would be easy to program as it would work with almost all the code we had been provided thus far. Another key feature is it has 24 pins that we could use as inputs or outputs. PORTA, PORTB, and PORTC all had 8 pins each and this allowed us to have a lot of room to work with. While in the end we only used 12 pins we would have liked to use at least 16. Also we knew the limitations of this chip, which would mean we would have to supply our own clock, and we would need to make sure that we get a pickit to program it. Overall we believe that while there were many chips that would have worked for this project, this chip allowed us to not have to worry too much about figuring out if it would work or not.

3. Our design had a lot of thought put into it, not only on the hardware side but also on software side. The main thing on the hardware side is that it provides a 4X4 keypad, which would allow us to extend functionality if we were going to take this project further. Also on the code side we decided in the end that we should show that each button works by programming it once the circuit starts up. Another feature that we felt needed to be in there is the fact that it has two alarm states, one which gives you a chance to redeem yourself but if you fail twice then the alarm sounds.

4. The biggest challenges we faced while making this that the circuit board we were working on was having issues with losing its connection at different points in time. This meant that every once in a while power would not be reaching the circuit. To overcome this we were forced to rewire the circuit three times, but in the end it never did work perfectly. The biggest issue that this caused was that at different points in time it was hard to tell if the program wasn’t working or if power wasn’t reaching the circuit. But we were able to overcome this and still create a working model.

5. The biggest shortcoming of this project is that there is no motor in the hardware. This was half a time issue and half an issue getting our hands on a motor. If we had the hardware we would have created a subroutine that would be called at the proper time in order to either lock or unlock the deadbolt. Another big issue we found is that there is no way to tell how many buttons you have pushed. In order to fix this we would need 4 more LEDs and then we could keep track of the pushes and light them up. This really isn’t hard as we still had 4 open ports from PORTA that could be used for this output.

6. CODE IS IN A SEPARATE FILE ATTACHED

7. The breakdown of what everyone did is as follows:

a)STEVEN – as the group leader it was Steven’s job to organize the group and plan out the direction this project is headed. He also wrote the report and designed the circuit. He didn’t write much of the code but for the most part I went through the code the others wrote and made sure everything made sense.

b)JOE – Joe was the main programmer who led the design of the program. He was busier during the first half of making this project but in the end he spent the most late nights in the lab programming it and testing. Overall this project is the fruit of his labor.

c)TREVOR – Trevor had the main job of programming the functions for comparing code. He spent a lot of time on research that was imperative to the design of this project. He was also the person who ordered the parts we needed and took care of that end.

CONCLUSSION

In closing I would just like to say that this project was a lot of fun and I am happy with the outcome. In the future I believe that I would be able to take a project like this further than we got on this try.