F12: Android Controlled MP3 - Revision history

Preet: /* Project Source Code */

2013-02-04T22:02:50Z

‎Project Source Code

Anthony f12: /* Schedule */

2012-12-20T13:15:22Z

‎Schedule

Anthony f12: /* Schedule */

2012-12-20T13:15:03Z

‎Schedule

Anthony f12: /* Implementation */

2012-12-20T13:13:13Z

‎Implementation

Anthony f12: /* Software Design */

2012-12-20T13:10:41Z

‎Software Design

Anthony f12: /* References */

2012-12-19T07:20:26Z

‎References

Anthony f12: /* Hardware Design */

2012-12-19T06:45:23Z

‎Hardware Design

Anthony f12: /* Schedule */

2012-12-19T06:45:10Z

‎Schedule

Anthony f12: /* Parts List & Cost */

2012-12-19T06:42:13Z

‎Parts List & Cost

Anthony f12: /* Android Application Sending and Receiving Issues */

2012-12-19T05:43:33Z

‎Android Application Sending and Receiving Issues

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

@@ Line 102: / Line 102: @@
 </td>
 <td>
-* Complete
+* Completed
-* Complete
+* Completed
 </td>
 </tr>
@@ Line 116: / Line 116: @@
 </td>
 <td>
-* Complete
+* Completed
-* Complete
+* Completed
 </td>
 </tr>

@@ Line 103: / Line 103: @@
 <td>
 * Complete
-* In Progress
+* Complete
 </td>
 </tr>
@@ Line 116: / Line 116: @@
 </td>
 <td>
-* In Progress
+* Complete
-* In Progress
+* Complete
 </td>
 </tr>

@@ Line 391: / Line 391: @@
               serverMessage = in.readLine();
-              if (serverMessage != null && mMessageListener != null && mRun) {
+              if(the serverMessage is not empty && a message is received && the client is connected to the socket)
-−
+             {
-                  //call the method messageReceived from MyActivity class
+                  //add the received message onto the list
+              }
               serverMessage = null;
+          }

@@ Line 266: / Line 266: @@
 Setting up an EditText in the java file:
 <pre>
-EditText IP; //create an editText called "IP"
+EditText IP;                              //create an editText called "IP"
 IP = (EditText) findViewById(R.id.etIP);  //set "IP" to the editText created in the xml file
-IP.getText().toString();  //get the information that the user typed into the editText
+IP.getText().toString();                  //get the information that the user typed into the editText
 </pre>
@@ Line 286: / Line 286: @@
 Setting up a Button in the java file:
 <pre>
-Button play; //create a button called "play"
+Button play;                               //create a button called "play"
 play = (Button) findViewById(R.id.bPlay);  //set "play" to the button created in the xml file
 play.setOnClickListener(new View.OnClickListener() {

← Older revision		Revision as of 07:20, 19 December 2012
Line 476:		Line 476:
	[5] Android Developer Website: http://developer.android.com/develop/index.html<br/>		[5] Android Developer Website: http://developer.android.com/develop/index.html<br/>
	[6] Android Tutorials from The New Boston: http://thenewboston.org/list.php?cat=6<br/>		[6] Android Tutorials from The New Boston: http://thenewboston.org/list.php?cat=6<br/>
−
−	~~=== Appendix ===~~
−	~~You can list the references you used.~~

← Older revision		Revision as of 06:45, 19 December 2012
Line 162:		Line 162:

	=== Hardware Design ===		=== Hardware Design ===
−	~~Discuss your hardware design here. Show detailed schematics, and the interface here.~~

	To power the wifi module, it requires an average 3.3V to operate and can take a maximum voltage of 3.7V and a minimum voltage of 3.0V. The power pin from the LPC2148 supply a steady 3.3V and can be used to power the wifi module. The wifi module can be connected to the LPC2148 through UART. This requires two pin from both component, Tx and Rx. The following table shows the pin descriptions and figure 1 shows the pin connections.		To power the wifi module, it requires an average 3.3V to operate and can take a maximum voltage of 3.7V and a minimum voltage of 3.0V. The power pin from the LPC2148 supply a steady 3.3V and can be used to power the wifi module. The wifi module can be connected to the LPC2148 through UART. This requires two pin from both component, Tx and Rx. The following table shows the pin descriptions and figure 1 shows the pin connections.

← Older revision		Revision as of 06:45, 19 December 2012
Line 17:		Line 17:

	== Schedule ==		== Schedule ==
−	Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

	<table class="wikitable">		<table class="wikitable">

@@ Line 130: / Line 130: @@
 <td>
-LPC2148 Microcontroller
+LPC2148 Microcontroller interfaced with MP3 Development Board
 </td>
 <td>

@@ Line 423: / Line 423: @@
 Many Wifi Connection issues were encountered such as network problem and Adhoc Mode. One problem was that we didn’t know the WiFly module had to be connected to a network to be used. It wasn't mention in the user manual (not sure if it should've been expected). This problem was resolved by asking the professor for information regarding the WiFly module, since he had previously used one. Another problem was using Adhoc Mode because it made it simpler, but after setting up Adhoc Mode, we couldn't figure out why the android device couldn't connect to the adhoc network.  By searching Google, we found that Android cannot read adhoc networks unless the device is rooted. Since we did not want to root our android device, we used a router to setup a wifi network for the WiFly module and Android Device.
-===Android Application Sending and Receiving Issues===
+===Android Application Communication Issues===
 A problem was encountered when attempting to allow the Android application to receive data. Once the code for receiving data was added, the application would crash every time a connection was made. We found out that this was due to GUI thread was being overused. Everything was being handled in one thread. Since the code for receiving data constantly waits for data to be received, the GUI became unresponsive because it would be stuck in the loop that waits for data. The solution for this problem was to create another class to handle all the TCP functions, such as sending, receiving, and connecting. This class would then be handled by another thread using AsyncTask. This solved the problem of the application becoming unresponsive and eventually crashing.
 Once we solved the issue of receiving, we encountered another problem. The expectation of the Android application is that it will send a command to the MP3 board and the MP3 board will send back a message indicating the command it received, which will be displayed on the application. However, the expected results were not achieved when the MP3 board with the WiFly module and the application were tested. When sending commands from the application, either the MP3 board was not able to execute the desired actions or nothing was sent back from the MP3 board through the WiFly module. The problem was with the way the coding was done for each component. BufferedReader was used in the Android application to read messages received. The way BufferedReader works is that it will put all messages in a buffer and read the buffer when a newline is received. The way the MP3 board was coded is that it will see if what it received matches a predefined string, execute the command if it is valid, and  send back what was received. This is where the problem occurred. When the command was sent without a newline at the end, the MP3 board will see the match and execute the command. But, since a newline was not received, the MP3 board will not send back a newline and everything the MP3 board sends back will remain in the buffer and never displayed on the application. If a newline was sent after the command, the expected message will be received and displayed on the Android application, but the command will not be recognized. Originally we decided to send the command to the MP3 board and then send a newline after waiting a certain amount of time. This way, the command will be recognized and a message will be displayed on the Android application. However, this causes extra delay between the time the command is executed and the time the message is displayed. In the end we decided to manually send the newline from the MP3 board, which will be sent along with the message once the command is received. There is still a delay from sending the message to the application, but is not as long compared to the original method.