Abstract

The key was designed so that it could be easily changed should future students, inventors, or tech nerds decide they want to peruse our code to either enhance or alter our current functionality. The key is the main crux of our project as it not only determines the direction the user moved the key itself in, it also acts as the master device in our Bluetooth communications system.

Bluetooth Communications

Bluetooth provided us with a reliable and sturdy connection after the two devices were paired. The communication channel was rather simple as we decided we wanted to minimize any confusion that may or may not result regardless of what the user does. Not only did it make it easier for us to code and communicate, it also allowed us to decrease the number of user errors. The list of codes that could be sent over the Bluetooth communication channel are as listed below.

enum ActionCodes {
OFF,
SINGLE,
DOUBLE,
HOLD,
SOUTH,
NORTH,
WEST,
EAST
};

As you can see, there is a relatively low number of different codes we can expect from the user. Off is rather self-explanatory as to it’s function, single, double and hold correspond to button actions, and the cardinal directions correspond to the user’s interactions with the device itself. The communication is one way, so there is no confirmation unfortunately that the lock truly received the code.

Click Interpretations

The device begins by debouncing clicks, starting with a single click detected, and then waiting a certain timeout period. If it see’s another single click before that timeout is reached then we register it as a double click. If there is not another single click then we register it as a single click. If there is not another single click, but the button is held at the end of the timeout then we register it as a button held. This method creates a small delay as the user could single click but is forced to wait the entire timeout before their click is registered. We do not feel this is a problem for 2 reasons. First, this seems relatively intuitive to us, second the timeout is 300 ms so if anything it should only seem like a Bluetooth lag.

Accelerometer Readings

The accelerometer itself could be a little finicky at times but all and all it performed very well. The predictions generated from the accelerometer data was calculated with a heavy lean on the side of caution. By this we mean our system is almost guaranteed to give you a correct direction if you are not misusing it. If it is unsure it will not give you any answer whatsoever. The reason for this is quite simply, it is safer this way. Since we can not be 100% certain of the direction and we recognize our system is not the most optimal, it is much better to give no response than an incorrect response. Part of our rationality was also due to the fact that these codes would be processed on the display and cause an immediate response so continually imprecise codes we decided would be more frustrating than not getting a reading at all. To aid in measurements, the device has some skew detection so the accelerometer does not take it’s readings until it senses a deliberate motion. It is at this point that it will set the relative values for processing. For a quick demo on how to use the device hop on over to the How To page!

Difficulties

The toughest aspects of this project were without a doubt the actual Bluetooth connection along with the direction mapping. It was a challenge in itself to get the Bluetooth working, and quite often when we would go to test the motion aspects of things, the Bluetooth device would disconnect ever so slightly, thus causing us to lose our connection and be forced to restart. Once that was resolved, tuning the actual accelerometer was the next biggest pain.

Code Archive

The entire key archive can be accessed by clicking on the conveniently placed link right here -> Key_Archive.zip This will provide you with all ‘*.h’ and ‘*.c’ files. The file with our commented code is labeled ‘key.c’.