Status Update – Week 4

**Important Note for Clarification

            For this update and all future documentation, we will use consistent names to discuss which part of the project we are referring to. The “key” device refers to the hand-held device which includes the accelerometer. The “key” device is what will be moved around to enter passcodes to unlock the “lock” device. In initial designs, the “key” device was said to be a phone or Bluetooth key chain and the “lock” device was said to be a smart house lock.  

 

Goals for this past week:

  • Establish a Bluetooth connection in which the “key” device can tell the “lock” device the motion in which it was moved
  • Finalize details of UI, including improved screen transitions and corrected counters
  • Further improve accuracy of accelerometer
  • Begin to create a finalized design, integrating code for a “key” device and a “lock” device, and begin the process of making a final product to be used

 

Work Completed this week:

  • Craig
    • Developed a more reliable and accurate algorithm to correctly detect which direction the “key” device moves. The device now relies on current and past locations to create a variable bias point, based on when the user makes significant motion
    • Assisted in the debugging of now-outdated accelerometer code as well as small errors in the initial Bluetooth set-up
    • Separated the code for the “key” and “lock” devices

 

  • Rachel
    • Integrated the new accelerometer algorithm into the code for the “key” device
    • Successfully achieved a Bluetooth connection between two PIC32s, demonstrating a Bluetooth connection sending data from the master to the slave. Note: This Bluetooth connection was successful due to assistance and guidance from Jack Plumb.
    • Successfully sent values corresponding to the recorded horizontal and vertical movements as sent and collected from the “key” device to the “lock” device
    • Updated schematics and began to draft an initial design for the deliverable “key”device

 

Current Challenges:

Our biggest challenge is going to be making sure there is a smooth integration of parts while trying to complete the project, including all documentation and deliverables, by the fast-approaching deadline. While all major components are essentially built, some aspects have not been fully integrated with all parts of their respective devices (ie the key or the lock). The only potential setback we see would be if integration hits a snag, whether that be having pins being used for two different elements (something we have tried to consider and kept in mind while programming other elements) or having code conflict where one protothread blocks all others from continuing their respective functions. Overall, we believe that these small obstacles should not prevent us from completing this project by the demonstration on Friday.

 

Goals for upcoming week:

  • Craig
    • Connect the “key” device to a battery pack, thus making it mobile since it will no longer rely on the USB for power
    • Finalize all UI for the “lock” device LCD screen
    • Maximize accuracy of accelerometer readings, achieving accurate results with the minimal amount of movement
  • Rachel
    • Verify correct Bluetooth communication between the devices and accurate processing of received data
    • Finalize integration of devices
    • Update all schematics and diagrams of system elements as well as preparing documentation for the project demo and/or project report
  • Both partners
    • Create a deliverable / presentable “key” device, which currently is still on a breadboard, which is powered by a battery pack and able to be held while used
    • Commenting of all code

Status Update – Week 3

Goals for this past week:

  • Configure UI, including a main menu and the following features, through the use of the LCD screen and multicolor LEDs
    • enter new password
    • lock device
    • unlock device
  • Have accelerometer more accurately identify the horizontal and vertical directions of motion (left or right / up or down)
  • Begin pattern recognition, having the PIC identify whether or not the inputted pattern matches the stored password
  • Ability to set and reset a password, storing the new pattern in place of the existing password
  • Make further progress on Bluetooth in hopes of having it set up to transmit simple data

Work Completed this week:

  • Craig
    • Developed a user interface which instructs users on what task they are completing (lock, correct password, incorrect password)
    • Ability to store and reset password
    • Device can now be both locked and unlocked using directional input (currently buttons as accelerometer is still being improved)
    • Lock device can now determine whether or not the inputted pattern matches the password stored in the PIC
  • Rachel
    • Hooked up master bluetooth chip to the “key” device, ensuring the chip has proper firmware to act as a master
    • Further work on the bluetooth capabilities, adding header files and source code to progress towards data transmission
    • Scaling and functionality of accelerometer, making it have more accurate directional readings

Current Challenges:

Our challenges this week were bluetooth, which seems to be the constant challenge, and time. This past week was thanksgivingbreak, thus with both students out of the lab it was hard to get much work accomplished. With bluetooth, a general confusion over what steps need to be completed in order to have it work have set us a bit behind schedule. We believe that since the bluetooth is the only major feature still not complete we will still be able to complete the project on time.

Goals for upcoming week:

  •  Both partners
    • Establish a bluetooth connection in which the “key” device can tell the “lock” device the motion in which it was moved
  • Craig
    • Finalize details of UI
      • Dummy proof UI (avoid crashes)
      • Easier ability to switch between screens (be able to cancel inputs that were not intended)
      • Include incorrect attempts counts
    • Determine a set encoding to send, where numerical values represent a direction or input
      • i.e. single click = 1, double click = 2, holding = 3, up = 4 …
  •  Rachel
    • Further improve accuracy of accelerometer
    • Establish a bluetooth connection in which the “key” device can tell the “lock” device in which motion it was moved
    • Begin to sketch a container for the finalized product, hopefully creating a wooden prototype by next lab

Status Update – Week 2

Our Goals for this week:

  • Begin interfacing Bluetooth or at least get a better understanding of what needs to be done to make it functional
  • Work on user interface, including multicolor LED lights to show status of device operation, as well as LCD display to show important things such as the lock status
  • Accurately and consistently detect motion

Work Completed this week:

  • Craig
    • Full integration of button press interpretation (hold, single press, double press)
    • Programmed multi-color status LED which will change color based on button input (including timers and interrupts to trigger based on input)
    • Soldered through-hole pins into accelerometer
    • Assisted with initial calibration of accelerometer
  • Rachel
    • Background research and initial testing of Bluetooth devices
    • Scaling and functionality of accelerometer
    • Beginning to work with accelerometer to make it detect and identify direction of motion

Current Challenges:

One of the biggest challenges we faced was understanding and working with the Bluetooth devices. We are currently sharing the devices with Jack and Greg, who will be ordering another set this upcoming week. We realized that one of the devices has a faulty power LED and has trouble communicating with the computer via USB. For this week we decided to work more on the accelerometer than initially planned, having that aspect advance further to offset the lack of progression with Bluetooth. We hope to have the Bluetooth issues worked out in this week’s lab so it does not set us back any further.

Goals for upcoming week:

Since we do have a holiday break this week, we are unsure of how much of our list will be complete by the beginning of next Tuesday’s lab, but below is what we hope to have completed. If either partner happens to have all of their tasks complete before lab, or faces an obstacle that prevents them from making adequate progress on a task, they will try to assist the other partner and/or begin working on the user interface, including LCD lock and instructional LEDs (if device is on, processing motion, or accepted a valid pattern).

  • Craig
    • Configure the barebones of the UI. This includes:
      • Lock screen – Shows “lock” and failed attempts counter
      • “Main Menu” upon unlocking – Ability to set a new password or lock device
  •  Rachel
    • Have accelerometer accurately identify the horizontal and vertical directions of motion (left or right / up or down)
    • Begin pattern recognition, having the PIC identify multiple motions and acknowledge whether or not it matches the given password. For this step, the password will be hard-coded into the system since the functionality to store motion as a password is not yet complete.
  • Both Members
    • Further work on Bluetooth together should the issues not be resolved in this week’s lab

Status Update – Week 1

Week In Review

This past week our group had a few small victories. We reviewed our final parts list and even got some of our parts delivered, we also began discussing the user interface. Both group members sat down to review the initial design proposal, more concretely divide up responsibilities, and figure out what the next goal is to ensure that we are meeting our schedule.

Goals For The Week

  • Begin interfacing Bluetooth
  • Start User Interface
  • Receive Accelerometer

Stretch Goals

  • Get Bluetooth interface communicating completely
  • Develop system to recognize distinction between holding a button, single, and double clicks

Challenges

Currently, neither Rachel nor Craig have any prior experience with Bluetooth communication. While there is plenty of documentation both online and from groups last year, it is still an unfamiliar form of data communication to us. We believe this could pose as the biggest threat as we do not want to burn all of our time interfacing Bluetooth communication. Furthermore, we do not have all of our parts yet which will delay our progress. The most inconvenient part about the lack of parts is that we are missing the accelerometer which is the crux of our project.

Task Breakdown

  • Rachel – Begin reviewing documentation on Bluetooth interfacing from last year
  • Craig – Begin reviewing documentation on Bluetooth interfacing from online
  • Rachel & Craig – Begin implementation of Bluetooth interface
  • Rachel – Begin CAD model for final product
  • Craig – Begin button press interpretation (hold, single click, double click)