Memorandum 

Date:               March 30, 2014

To:                  Professor David G. Michelson

From:              EECE 380’s L2D4 Group

Subject:          Update on Orbcomm Design Project

The focus of this week was the completion of the electro mechanical sensor, power source, a multiplexer and various aspects within the coding.

Software

The week we focused on saving the sensor data in the event of satellite being out of range. This was achieved by writing the data line by line into a text file inside the modem. In order to do this was used functions such as FFS_WRITE and used FFS_READ to read that file into an array in order to send those saved messages in the event the satellite is back in range. We have 5 analog signals coming in and there are only 2 analog ports in the modem, thus we needed a multiplexer. The next challenge was to use the digital ports of the modem and configure them as outputs in order to control the multiplexer. This was achieved with various DIO functions.

Hardware

With the assembly of the solar panel we realized a DC buck converter was necessary. Input is 9V and 15mA from the solar cells and the output from the converter is 4.5V 25mA, and it conserves 90% of the power. This is being used to power all the sensors. We also made the wind speed sensor using a brush less DC motor attached to an apparatus on the top which catches the wind and thus spins the motor generating voltage. After testing the voltage we noticed that the output of the motor is too low for the modem to accurately display. Thus we used a simple non-inverting amplifier that amplifies by 100 to give the modem a reading it can actually use.

The goals of this week were achieved. The goals for next week are to assemble the project together and debug it. Also calibrate the sensors for accurate measurements.

Memorandum 

Date:               March 23, 2014

To:                  Professor David G. Michelson

From:              EECE 380’s L2D4 Group

Subject:          Update on Orbcomm Design Project

This week we were working on the sensors and the Orbcomm programming. The hardware group had most of the sensors working well and the software group kept learning about the Orbcomm system following the lab tutorials. The goals of this week were building the sensors and familiarizing the Orbcomm system.

Software

This week we kept learning about the Orbcomm system. We worked on the flash file system and bash scripting. From the lab sections, we learned that the DemoAppFFS gets GPS location and stores that position in FFS. We modified the code in DemoAppFFS with Orbcomm specific commands to save inputs and send emails. Moreover, we created an email filter in our Gmail account, created a ‘.forward+orb file’ in the home directory and aggregated mail using Bourne shell. The goals of this week were achieved and we will keep working on the Orbcomm system next week.

Hardware

This week we purchased sensors, solar panels and some other electronic components. We had most of the sensors working properly. Specifically, the air temperature sensor, the water temperature sensor, the rain sensor, the pressure sensor, and the solar panels function well. Moreover, we built two timer circuits with variable resistors that control the frequency of a pulsing led. This way, we could have the buoy flash the led depending on the depth and distance from the coast they are. The tasks of this week were completed and we will be work on the wind sensor next week.

The goals of this week were achieved. The goals for next week will be working on the wind sensor, the multiplexer and Orbcomm system.

Memorandum 

Date:               March 17^th, 2014

To:                  Professor David G. Michelson

From:              EECE 380’s L2D4 Group

Subject:          Update on Orbcomm design project

This week we were still familiarizing ourselves with the Orbcomm programming. The first two modules were quite simple and we have the satellite send an email. We also have the Orbcomm working in conjunction with an ADC. We were given details on what our project had to do and decided to once again divide the team into a software and hardware group. Keith, Colin and Rushil will be on software, while Milind and Martin will be on hardware this week.

Software

This week we have plans to continue learning about the Orbcomm system. This is an integral part of our project and we require more practice with the system. We will be focusing on the upcoming modules building on solid knowledge of previous modules. We were given the task of controlling sensors related to water. Our team has decided the best way to do this is simulate a buoy and have different sensors on the buoy giving out readings.

The challenges for this week will be integrating readings into the Orbcomm system and having it send an email with the sensor readings as a message. We will be planning to have this done by March 22^nd the Friday and planning an extra session in between our lab sessions since this project has a tight deadline we need to make sure we are on top of everything.

Hardware

This week we were given details on what we need to supervise and control through the Orbcomm system. We were told our project had to be related to water, and as a group we decided a weather buoy is something we would like to design. The buoy is applicable to BC’s geography and will have different sensors on it. We have a preliminary idea on what should be measured, including air temperature, pressure, and whether the sun is out or not. We also need to power the modem on the buoy using solar power which will need to be decided by the sun sensor. A list of parts required for this week so we are able to start constructing the buoy is listed below.

1. $10.29 – Pressure Sensor, 5 PSI: 2-37KPI, 2S MPP-02
2. $11.00 – Rain Sensor: Produch ID: 109193
3. $8.00 – humidity and outdoor temp sensor: DHT11
4. $10.50 – waterproof (water) temp sensor: DS18B20

Optional

5. 2 x $6.80 – 2 x Solar Panel, 5.5 V, 70 mA 79mm x 38 mm

This is a total cost of $53.59 and a good start to our design. This week’s goal will be to have the sensors working with the ADC and input into the Orbcomm.

Memorandum

To: Professor Michelson

From: EECE 380 L2D4 Group

Subject: Review of the Previous Week

Date: March 10th, 2014

This week marked the start of our second project, where we will communicate with a satellite to obtain information about weather, temperatures or other factors. Our group has split the tasks and has began the software component of the project. We have also been able to communicate with the satellite and are getting custom to the new requirements and factors of this communication system.

Milind and Martin will be responsible for the creation of the hardware components, including any mechanical structures that will respond to certain factors, the actuators. This seems like a wise task allocation since both members have experience in this domain and were the expert for this sort of responsibilities in the previous project.

Colin, Rushil and Keith will be responsible for the task of the software development of the ORBCOM project. All three members gained experience from the last project, and their software skills will come in handy to complete this new system.

For the first class of the Orbcom module, the software team communicated to the satellite through the use of emails, which will be the medium of communication between us and outer-space. The satellite will come in handy to provide us with useful information that will help our project run fluidly.

The hardware team began the construction of circuits that will likely be used in the future, such as a temperature sensor, a led-driver, and the completion of an operational amplifier circuit that can amplify certain signals that are too weak.

Memorandum  5

Date:               March 2^nd, 2014

To:                  Professor David G. Michelson

From:              EECE 380’s L2D4 Group

Subject:          Weekly Memo for Week 5

This week the group focused on compiling all the parts together and testing the project by inputting a RF signal between 50-54 MgHz with power level varying between -60dbm to -20dbm.Upon testing we came upon few unforeseen issues within the software which we are currently working on.

Hardware Sub-group

The goals of the team for the week were

• All the goals for the hardware sub group have been completed.

Cascaded Common Emitter Amplifier

Upon testing with a range of signals it was decided that the current quality and quantity of the amplifiers are sufficient.

 Precision Peak Detector

 The peak detector works within the full range of power, -60 to -20 dbm. Previously we had issue with detecting the signal at -60dbm but with further adjustments we can now detect the signal at that power.

Video Filter

 From the feedback of our previous tests we have incorporated the video filter within the lab view architecture.

One issue we had last week was the transportation and movement of all the different parts of the project. This week we constructed an enclosed box to contain all the wires and circuits so that the project remains connected and operational thus increasing the efficiency. Also now the project can be transported without any interference.

 Software Sub-group

The goals of the team for the week were

• Calibrate the frequency domain on the display so it displays the correct RF frequency.
• Calibrate the power domain on the display so it displayed the correct RF power.

Display

We have resolved all the previous issues with the display but upon testing the full project it was discovered that the frequency being displayed differed by some unknown factor from the test signals frequency. To resolve the issue we have started to calibrate the frequency on MyDaq by recording the values at numerous test points onto an excel file. By drawing a graph of this data we can calculate the relationship between the actual frequency and the frequency being displayed on MyDaq.

Video Filter

 The video filter is completed by using a design block Butterworth filter and setting it to be a low pass filter. The high cut-off frequency we choose is 1.1MHZ. Testing of the video filter will be performed in the next week.

Logarithmic Amplifier

 We had the same display issue with the logarithmic amplifier as well. The power being displayed differed from the power being inputted. To resolve this issue we took the same approach as before. We recorded numerous values at various test points in order to calculate the relationship between the power and its display error.