The majority of the week was spent understanding the individual blocks needed to build the spectrum analyzer as well as familiarizing ourselves with Labview.

VCO

The VCO was first tested by applying a DC voltage to the Vtune pin. The VCO outputted a signal with a constant frequency according to the voltage supplied to Vtune. Therefore, by using the calibration curve, the desired frequencies could be chosen. A ramp generator was then connected to Vtune which effectively swept a range of frequencies based on the offset and amplitude of the ramp.

RF Amplifier

The gain of the RF amplifier was tested by inputting a -40dB signal and measuring the output with a spectrum analyzer. This gain was recorded for future use.

Band-pass filters

The frequency response of the two band-pass filters was tested by utilizing the tracking generator of the spectrum analyzer. The frequency response provided some useful information on the bandwidth and gain of these two filters.

Mixer

The VCO was also tested with the Mixer and a 50 MHz signal. The 10.7 MHz band-pass filter was attached to the output in order to filter out the desired frequency. The Vtune pin of the VCO was then swept until the spectrum analyzer measured a signal from the output of the mixer. The mixer would produce two signals; one at a frequency of the sum of the two inputs and one at a frequency of the difference of the two inputs. Since the band-pass filter was connected to the output of the mixer, one of the two frequencies had to be within the filter’s range. By adjusting the settings of the various inputs, the tuning range of the VCO needed for this project was determined.

Peak detector

The peak detector was designed and built by implementing a high pass filter with a schottky diode. After the circuit was built, it was tested with a 10 MHz signal and the power limits of the peak detector was determined. The transfer function was also found by utilizing the tracking generator of the spectrum analyzer.

LabView Coding

To begin understanding the functionality of LabView, the group members working on software familiarized themselves with the platform by stepping through the starter tutorials online. Next, the team implemented the Ramp voltage output function to be later integrated with the VCO. In the upcoming week, the software functions will be expanded to allow user interface and processing of input signals from the hardware.

As the demonstration deadline neared, the team worked hard to complete the final components of the project. The majority of this week was spent integrating the hardware and software components of our machine.

Accomplishments:

• Finalized the bash script which sorts emails and replies with tasks for the orbcomm
• Improved the excel file which displays processed data from the orbcomm and presents statistics about wind and weather conditions
• Prepared demonstration files to present the functionality of the system
• Calibrated the temperature, wind-speed, and wind direction sensors
• Soldered, connected, and tested the LED display actuator
• Soldered, connected, and tested the alarm speaker actuator
• Built the housing to hold all circuitry and connected buses for power and digital logic transmitting

Calibration Methods:

Wind Speed

     The team split off into a sub team of 4 to test and calibrate the wind speed sensor. Our method was to mount the sensor to the top of a vehicle and drive down the road on a windless day measuring vehicle speed and sensor voltage. Land speed was measured using the vehicles digital speedometer and voltage was measured using a portable voltmeter. Our sensor was powered using 12volts from a laptop battery and using a logic voltage of 3.5 volts from a pack of AAA batteries. Our Wind speed sensor works by creating a pulse as wind rotates a shaft that is fed into the frequency to voltage converter, which ultimately the Q4000 microprocessor reads using an analog voltage pin. We carried out 6 tests in all from 10km/h to 60 Km/h at 10km/h intervals. The test was a success and a linear frequency to voltage relationship was produced.

     Temperature

     The temperature sensor was calibrated by taking a series of voltage output measurements at various temperatures (measured with a digital thermometer). Using this collection of information, we created a voltage to temperature relation and applied it to the output code to send real temperature data to the satellite.

 Challenges:

•  Calibrating the wind-speed required some creative engineering to make our anemometer mobile, however in the end it was successful.
• The alarm actuation hardware worked in initial testing, however once integrated with the Q4000 modem it ceased being functional. Thus far our team has determined the problem to be a lack of current output from the modem, but we have not been able to find a solution to this issue yet. We’re continuing to test and debug the issue, and are otherwise on schedule to present the project on Tuesday.

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.