**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