F12: Android Door Lock - Revision history

Preet: /* Project Source Code */

2013-02-04T22:04:37Z

‎Project Source Code

Rosemary f12: /* Implementation */

2012-12-20T19:00:41Z

‎Implementation

Rosemary f12: /* Conclusion */

2012-12-20T18:59:14Z

‎Conclusion

Rosemary f12: /* Testing & Technical Challenges */

2012-12-20T18:58:07Z

‎Testing & Technical Challenges

Rosemary f12: /* Website Design */

2012-12-20T18:56:22Z

‎Website Design

Rosemary f12: /* Design & Implementation */

2012-12-20T18:54:36Z

‎Design & Implementation

Rosemary f12: /* Parts List & Cost */

2012-12-20T18:49:07Z

‎Parts List & Cost

Rosemary f12: /* Schedule */

2012-12-20T18:48:37Z

‎Schedule

Rosemary f12: /* Introduction & Features */

2012-12-20T18:47:10Z

‎Introduction & Features

Rosemary f12: /* Testing & Technical Challenges */

2012-12-20T09:38:55Z

‎Testing & Technical Challenges

@@ Line 507: / Line 507: @@
 === Project Source Code ===
+*  [http://sourceforge.net/projects/sjsuf12/files Project source code is available at SourceForge]
 == References ==

← Older revision		Revision as of 19:00, 20 December 2012
Line 414:		Line 414:

	=== Implementation ===		=== Implementation ===
−	This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

	====User Interface Task====		====User Interface Task====

@@ Line 491: / Line 491: @@
 == Conclusion ==
-Conclude your project here.  You can recap your testing and problems.  You should address the "so what" part here to indicate what you ultimately learnt from this project.  How has this project increased your knowledge?
 <p>From the developer of the Android application point of view, this project required some dedication and careful thinking in order to come up with a working system.  The Android application should be working without crashing when connected to other physical devices.  If crashed, the whole system would not work.  The initial goal of the team to do the assigned tasks together so that everybody could learn the three main topics of the Android Door Lock:  Android programming, embedded system programming, and web development.  Unfortunately, the tasks were divided according to each team member's programming expertise; this way would bring higher quality to the Android Door Lock project.  I think that the two most important coding part was how to create a Socket connection and Java Singleton.  Unfortunately, the Java Singleton did not work properly when physically connecting the devices.  I focused only in the Android programming part because of some design issues I had trouble with; therefore, it took some time to design a working Android application for the Door Lock project.  Below is the concluding point of view for the team member who developed most of the embedded system coding for the microcontroller.</p>
@@ Line 504: / Line 504: @@
 === Project Video ===
 http://www.youtube.com/watch?v=Do2Ir67mjfM&feature=youtu.be
 === Project Source Code ===
-Send me your zipped source code and I will upload this to SourceForge and link it for you.
 http://www.socialledge.com/sjsu/index.php?title=File:CmpE146_F12_Android_Door_Lock_LPC2148.zip

← Older revision		Revision as of 18:58, 20 December 2012
Line 438:		Line 438:

	== Testing & Technical Challenges ==		== Testing & Technical Challenges ==
−	~~Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?~~
−	~~Make a smooth transition to testing section and described what it took to test your project.~~
−
−	~~Include sub-sections that list out a problem and solution, such as:~~
−	~~<b>LPC2148 Microcontroller</b>~~
−
−	~~<p>For the LPC2148 LPC microcontroller, it was tested with Hercules being a client. By manually sending the data from Hercules, Hercules should show the right expected result.~~
−	~~</p>~~

	<p><b>Android Application</b></p>		<p><b>Android Application</b></p>

@@ Line 377: / Line 377: @@
 To design the front end, the main concern is usability and aesthetics. A flat HTML interface will not suffice, hence PHP, CSS, and jQuery were used. There are many online resources that will assist in creating the interface. The lock management system utilized jQuery UI, a javascript library, to help with the theme of the website. The sidebar and tabbed structure were drawn from one of the jQuery UI themes. In addition to jQuery UI, TableSorter 2.0, a jQuery plug-in, was used to further enhance the interface.
 <center>
-<gallery widths = 800 heights = 311>
+<gallery widths = 800 heights = 311 perrow="1">
 Image:CmpE146_S12_T8_admin_home.PNG | Figure 14. jQuery Accordion and Tabs
 </gallery>

@@ Line 209: / Line 209: @@
 == Design & Implementation ==
 === Hardware Design ===
 ====Wireless Module====
@@ Line 278: / Line 276: @@
 === Hardware Interface ===
 ====SPI Bus====
@@ Line 297: / Line 294: @@
 === Software Design ===
-Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
 ====Tasks====
 '''User Interface Task'''

@@ Line 146: / Line 146: @@
 == Parts List & Cost ==
 <table class="wikitable">
-<th>Parts</th> <th>Cost</th>
+<th>Parts</th> <th>Cost*</th>
 <tr>
@@ Line 207: / Line 206: @@
 </table>
-<p>Cost excludes shipping and handling</p>
+<p>*Cost excludes shipping and handling</p>
 == Design & Implementation ==

@@ Line 36: / Line 36: @@
 == Schedule ==
 <table class="wikitable">
 <th width = "150">Week Number</th> <th>Scheduled Items</th> <th width = "75">Actual</th>
@@ Line 144: / Line 142: @@
 </center></td>
 </tr>
 </table>

@@ Line 9: / Line 9: @@
 * MP3 player that plays customizable tunes when the door is unlocked.
 * Filing system to stores all the log times that the door has been accessed.
 === Team Members & Responsibilities ===

@@ Line 457: / Line 457: @@
 </p>
-<p><b>Android application</b></p>
+<p><b>Android Application</b></p>
 <p>For the Android application, testing was performed in two modes.  First, using the Hercules software as a TCP server since the Android application acts as a client application.  Second, using physical devices such as a router, the WiFly, the LPC2148 chip, and Hercules software as a serial connection.  The reason we used these two modes is because we wanted to make sure that all features of the Android application worked well with other physical components of our project. One of the main issues was the removal of the <i>automatic log-in</i> feature, it was tested successfully in Hercules TCP Server but it wasn't sending data properly when tested with Hercules as serial connection using the WiFly as physical device.</p>
 <p>
@@ Line 478: / Line 478: @@
 </p>
 === Problems Encountered ===
-Many Wifi connection issues were encountered.
+Many WiFi connection issues were encountered.
 <p>In the Android side, there was an issue in the <i>automatic connection</i> feature that we were designing.  Through a <i>Java Singleton</i>, data were able to send to <i>Hercules TCP Server</i> but not to the actual WiFly and LPC2148 board, only the manually punched in <i>Android Intention</i> was able to send data while the <i>automatic connection</i> feature was able to make a connection but not send data.  Changing the design by removing the <i>Java Singleton</i>, the same result happened, both <i>Intents</i> were able to make a connection but only one <i>intent</i> was able to successfully send data.  Because of this issue, we had to eliminate the <i>automatic connection</i> feature and implement a more basic version that would allow successful data sending.</p>
@@ Line 492: / Line 501: @@
 <p>
 Another issue that we encountered was getting the door lock to work. Rosemary initially wrote the code out for an LED to test before the door lock arrived in the mail. However, unlike the LED, the door lock requires a low signal to unlock and a high to lock. The led requires a high to turn on and a low to turn off. Although switching the bit out may seem simple (it certainly looked simple to me), it turned out to be quite frustrating as some of the functions were broken due to unfavorable methods of bit comparisons.
 </p>