Monthly Archives: January 2014

Jan. 30 Weekly Update

Objectives of Lab 3:

• Compile DemoAppFFS, run to ensure correct file

• Modify DemoAppFFS to save an analog input and send an email of the value that was inputted

• Modify DemoAppFFS with Orbcomm specific commands

Process:

During the lab time our team decided to split the workload by assigning the DemoAppFFS to the coding sub-team while the sub-teams in charge of the actuator and weather sensors focused on research and designing their appropriate components. The DemoAppFFS was straightforward and it was easy to implement the necessary functions from DemoAppFFS into our code that we intend to use for the project.

The weather sensor sub-teams determined two possible approaches for implementing a wind speed sensor. Our first design was to utilize a low resistant (to torque, ie easy to turn) dc motor that would be connected to the shaft of the wind speed sensor. When the shaft rotated, a voltage would be generated by the dc motor that is dependent on the speed of rotation. The second design was to implement a specific hall-effect sensor (non-latching, analog). A metallic gear would be attached to the shaft so that when the shaft rotated the magnet imbedded in the hall-effect sensor would detect the gears rotation. From this, the frequency of rotation can be determined which could be translated to wind speed. The wind sensor shaft is driven by an array of cups.

Wind direction is a secondary goal for our project however the design to implement the sensor was discussed so that it could be easily added once the wind speed sensor is functional. The design is not finalized but our team suggested that it could be implemented by means of potentiometer and a wind vein.

Challenges:

A challenging part of the DemoAppFFS was to extract the voltages and send them in an email. This could be done easily by selecting each value in the voltage array. However, we wanted to utilize a for loop to make our code cleaner and easier to debug. In order to do this the strcat function was needed; however, it kept causing a stack overflow. Eventually, the code was fixed after we found the error.

Other problems involved time delays in the modem. The emails sent out sometimes took over 10 minutes to be received. This is most likely due to errors that our out of our control but we are still trying to figure out how to time our emails to increase efficiency.

Additional Updates:

Our coding sub-team was able to figure out how to configure the digital ports to either be outputs or inputs. Functions for printing timestamps and changing the subject of the email were also determined. Another function that was implemented was how to decipher emails that were sent to the modem. So far we are able to receive the emails and store the body of the message in a string. Therefore, all that is left is to determine how we want to process the string.

A trip to Lee’s Electronics was conducted to search for possible sensors that they sell there and certain specs of each device.

Team Meeting Summary:

The team meeting was held Monday January 27th and all members were able to attend. The scope of the project and the components that need to be completed were discussed. From this, the relative tasks were delegated to sub-teams. Our team decided the best approaches to implement the weather sensors and the actuator. Deadlines were also decided to ensure that the project is finished ahead of schedule in case of any emergencies.

 

 

Standard

Jan. 20 Weekly Update

Lab 1:

Objectives:

  • Introduction to the Q4000
  • Begin working through Quake Programmer Guide
  • Complete Hello World modification
  • Add group email to Orbcomm system
  • Send a message via satellite and verify in group inbox

Process:

We began to work towards the given objectives by reading the related sections in the Q4000 programmer guide. At the same time we installed and set up the software we would require for this project. The team then compiled and ran the DemoAppGSM provided by Orbcomm. Once we were certain that we had a live connection to the Q4000 and could load applications successfully, we began work on modifying the C code to add “Hello World!” to the display terminal. We identified a part of the code that was already writing to the display terminal and added a printf function to make the modification.

The team then began to understand what each of the functions in APL.c, the provided code, accomplished. We then tried to narrow down our search to the function responsible for sending emails and what part of the code needed to be commented to bypass GSM/GPS routines.

Challenges:

When modifying the DemoAppGSM, it took longer than expected for the team to get accustomed the new programming interface in IAR. Once we understood which files were compiling and where they were being compiled to, we were able to successfully complete the Hello World modification.

A small degree of trial and error was required to discern which pieces of demo code should be commented out in order to send a message via satellite. By the end of the first lab, our group was able to consistently receive text files in our email account containing a 7 character message.

 

Lab 2:

Objectives:

  • Continue working through the Quake Programmer Guide
  • Run the DemoAppADC
  • Build a circuit to send voltages to the Q4000
  • Modify DemoAppADC to read from the circuit

Process:

The team worked in pairs to design the circuit required to feed voltages to the Q4000 and at the same time to work on streamlining the e-mailing process from Lab1. Once the circuit was deemed operational, we ran DemoAppADC to read the voltage values on the display terminal. We had to change the proportionality constant to improve the correlation between the values on the display terminal and the actual voltages being input. The next step was to send these values via email. We used snippets of code from DemoAppGSM, edited in Lab1, and combined it with DemoAppADC to achieve this.

Challenges:

When running the original DemoAppADC, there was initially some confusion configuring the COMM ports which communicated with the Q4000. After the settings were properly adjusted, the demo ran correctly.

There were a number of issues with the serial port communication hardware. When loading the programs onto the Q4000, the transfer would fail halfway through and we would have to repeat the process. Switching to a USB connection seemed to fix the issue for the remainder of the lab.

 

Acquired Skills:

After completing this first week of labs, the team gained important insight and practice with the equipment we will be using for the remainder of the project. By running and modifying a few of the DemoApps in IAR, we learned critical steps to troubleshoot the Q4000, which will undoubtedly be useful when testing our own code on the machine. The labs have also given us an understanding of what professional code looks like and how best to write function prototypes so that the code is readable by a third party.

Project Progress:

Although specific project requirements have not been released yet, we expect our group’s completion of the demo tasks will be useful for the final product. In particular, we have learned to successfully send ourselves an email via orbcomm which includes a subject line, voltage read from the Q4000, and text of our choice.

Standard