The team spent the week combining the various components of the spectrum analyzer and integrating the hardware and software sub components. The members working in the respective teams  helped in the integration process. The team was also involved in calibrating the components that were integrated and functional, further different parts of the report were assigned to team members based on their responsibilities.

Hardware:

The hardware sub-team was heavily involved with understanding UltiBoard and designing a PCB to hold our switch IC. This involved becoming conversant with the software and understanding industry standards for amount of copper, drill sizes etc. The hardware sub team completed a design for the PCB and combined it with 3 other teams to take advantage of the flat price offered by CCI. However due to the long turn around time, the team agreed to use the back up PCB provided by the teaching staff and soldered and tested the switch IC. A major challenge in this process was to solder the chip with the solder iron in the lab, it required a lot of patience and de-soldering.

The hardware team also realized an issue caused by the 8Mhz crystals. The low center frequency of these crystals meant that 104 MHz and 88 MHz, both within our range, are 8 MHz away from 96 MHz which is also in our range therefore we don’t know which of these frequencies gives us the 8 MHz difference. This was corrected by using crystals with higher center frequency i.e. 18Mhz that made sure that 2 frequencies did not give us the same difference in our range. The new crystals were an efficient fix for what could have been a very difficult issue to debug in LabView.

Software:

The software team continued to better the user interface that was created last week. The markers and traces that were implemented last week were debugged and new controls such as center frequency and span as well as start stop frequency were also implemented. The sub team also debugged and troubleshooted the inputs and outputs from the DAQ and programmed the remaining analog input to control a mux to control the switch. Further, the sub team implemented added functionality that was deemed necessary. The frequency modulation index calculation was implemented via Carson’s rule and testing of the software with input from the hardware was also started. The team has also automated one of the markers to find the peak and display it, the team will continue to make efforts to completely mimic the lab machines but the integration and testing  of the components is more important at this point.

The team has now spent 2 weeks considering the various blocks involved in building the spectrum analyzer. The team mates were assigned different tasks based on their skills.

Hardware:

The goal of the hardware sub-team this week was to finalize the resolution BW filters and the peak detectors as well as determine what amplification is necessary. The resolution BW filters were constructed by using crystal oscillators which were centered at 8 MHz. Two filters needed to be built and so two BWs were decided upon while considering the standard conventions for spectrum analyzers. In order to “flatten” the bandpass region, the gain of the filter was sacrificed. Minor adjusting is still needed however as the BWs are not equal to what was planned.

The design for the peak detectors was finished and circuiting of these designs started this week. Due to faulty breadboards however, the peak detectors were not finished this week.

A test BJT amplifier was constructed to simulate the amplification of signals with very low dBm. The amplifier does not work within the required operating range and thus some adjusting is still needed.

Next week will focus on finishing the peak detectors, video filters and amplifiers as well as adjusting the resolution BW filters. Once this is complete, the hardware components can be integrated and tested as a whole.

Software:

The software sub team worked towards achieving the design specifications. The sub team implemented the user interface for the spectrum analyser after designing the ramp to ouput the right voltage range. The user interface includes traces and markers to help the user to compare different signals and to find the magnitude of signals.

The team used LabView to build a signal diagram to send the ramp input to the VCO and to use the input from the hardware sub team to create x-y plots. Further, the team implemented controls to change sweep time and to switch between traces. Control for the markers was also implemented, this allows the user to measure the magnitude of the signal at different frequencies.

The team had to research ways of displaying multiple graphs on the same plot and to enable/disable each graph separately to allow the user to pause graphs and interpret the data. We used the array builder to combine the signals from two xy graphs and plot them in Lab View.

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.

The team completed the Orbcomm SCADA project during the weekend of Mar. 1. The remainder of the week was split into completing the report for the first project and getting used to the Spectrum Analyser. We also incorporated Dr. Michelson’s inputs into the presentation slides and report. The team got together to edit and format the report during our scheduled team meetings for rotation 1.

After the briefing for the second project, the team assigned hardware and software roles. This allowed team members to focus their research efforts on specific goals. Our team started work on the first lab tasks, to get familiar with the equipment. We were able to complete all the tasks in one lab session as we were to demo in the second lab session of the week. Team members became conversant with the use of lab view.

The team is looking forward to the reflection activity with Dr. Michelson and look back on the lessons learnt from  the first project and how we can implement what we learnt in the second rotation.

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.

Tasks Completed:

During the week the coding sub team tested and coded a PWM signal that was capable of reaching a frequency of 500 Hz and have its duty cycle regulated. The actuator states were finished as well so that when an email is received by the modem, the code will determine what outputs to send to the actuator. The bash script was also coded to recognize the format of incoming emails and parse them for particular values and keywords.

The shaft for the wind-direction sensor was built which contained a threaded axle and three plates that were cut in specific patterns so that they could be used to describe the wind’s direction in 3 bits using gray code and infrared sensors.

Tasks to be completed:

The housing for the wind direction sensor as well as a shaft to allow easy rotation still needs to be built. The wind direction sensor also requires a static shaft to mount the infrared sensors, this will also have to be built. We also need to assemble and solder the circuit for the gray code detector. The final steps also include integrating the completed hardware with the software and making sure inputs can be read. We will also need to calibrate input data to display meaningful information.

The team is working under a software sub team and hardware sub team. The software team is tasked with creating the code based back bone of the project while the hardware sub team works on the actuators and sensors.

Accomplished:

• Prepared code for reading all the planned weather sensors (temperature, wind direction and wind speed). After calibration, the conversion factors will be implemented and then the sensor component will be complete besides soldering.
• Finalized the email format so that it is easy to implement with the bash scripting
• Prepared test code for the alarm system of the actuator. It theoretically should pulse a timer that will allow the alarm to have varying rates depending on the emergency.
• Still need to determine if a PWM signal can be generated so that a servo can be used for actuation, otherwise an array of LEDs will be used to indicate the direction the windmill should face
• Improved the bash script which retrieves and sorts emails from the Orbcomm
• Implemented process to run the script at set intervals
• Implemented conditional statements in the script to send various tasks to the actuator via email
• Created excel file which will automatically update with data from text files as new emails from the Orbcomm arrive
• Created housing for the wind speed sensor, and designed and built the cups and shaft for the same
• Designed shaft for wind direction sensor

Challenges:

The challenges faced mostly involved the design of an algorithm that will sample all the sensor inputs and will choose an appropriate actuation based those inputs and the remote user’s email. Learning and implementing bash scripting had a steep learning curve. This meant slow progress at the outset but after more experience with the process, the team is making better progress.

Next Step:

• Build the appropriate parts for the wind direction meter that utilizes gray code to divide the direction of the wind into 3 bits
• Calibrate wind direction meter, temperature and wind speed
• Build the housing for the actuator
• Solder any circuitry

Lab 3 + 4:

Objectives:

• Complete modifying DemoAppFFS
• Completed coding timer functions (wait functions)
• Wrote code to receive time from satellite and display it
• Received and parsed incoming Email (in progress)
• Bash scripting to create text file
• Designed and built wind speed sensor
• Designed and tested temperature sensor
• Proved concept  of operation for wind direction sensor

Process:

The team continued to work as sub-teams, one dealing with actuators and sensors and the other working on the lab and the software component. This allowed us to cover more ground towards project completion and maximize each members productivity. The software sub-groups modified the AppFFS to read in our voltage level from the analog input and save it in the crumbs variable structure under longitude. Once the voltage was stored it was then read from flash memory and sent via email to our gmail account.

Our coding sub-team finalized the receiving email code so that the remote user can now send emails to the modem in order to change the state of the actuator. This process still needs to be automated by means of scripting; however, the template has already been written for that part of the code. Functions for parsing the receiving email were used to decipher the email in order to change the outputs to the actuator. A polling sequence was also built which cycles through the multiplexer selects in order to sample all the inputs from the weather sensors. Timing for this component still has to be fixed so that each email of the voltages of the various sensors is in sync with the readings.

The hardware sub-team implemented two different approaches to measure wind speed. The first approach was to use a optical sensor and a spinning 4-tooth gear on the rotating shaft to give the optical sensor pulses of different frequencies depending on the rpm of the shaft. This approach had the benefit of being near friction less as the shaft we used was from a VCR drum. However, this approach required a frequency to voltage converter and the turn around time to buy and implement that chip was very long. Our second approach, and the one we will be using, was to drive a DC motor as a generator via the rotating shaft. This approach was easily implemented and could be calibrated very quickly. We have both approaches on the sensor and we will reconsider the optical sensor closer to the deadline.

The temperature sensor was very easily tested. We used the LM335 chip, which acts as a voltage divider and the resistance of the chip changes with temperature. We acquired the chip and tested it on a breadboard to check its temperature dependencies. It performed admirably and the next step in this direction will be to calibrate the sensor to a temperature scale.

The wind direction sensor is an added feature the team is considering. We want to find a highly cost and time effective way of implementing the sensor. We are considering a multi turn potentiometer to be used as a voltage divider, this will be very straight forward to implement. We understand that there are some limitations to this approach, mainly that the potentiometer will move out of its range of operation after 10 revolutions. Based on the wind direction prevalent in Vancouver, we can see that wind direction often follows a very reliable daily and seasonal pattern. Therefore, it will be a considerable amount of time before the wind direction sensor stops functioning and will need maintenance. Also this maintenance will not be very time or cost intensive and can be done locally on site. Further more, the sensor itself will be very simple and resilient to the elements.

Challenges:

Debugging and troubleshooting the code takes a large portion of lab time as it relies on satellite communication. Due to this, testing a new version of the code can take a long time. The modem also seems to get a “backlog” of emails that are going to be sent out. This will most likely be fixed by just decreasing the time each email is sent out and to ensure that no more emails are sent until the current one has been received by the remote user.

Team Meeting Summary:

The team met on 3rd February to discuss the sensors and actuators we wanted to implement and how we wanted to implement them. There was also a discussion about how we would implement them in the code. It was also a time to set deadlines for various deliverables and assign them to responsible parties.

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 27^th 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.

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.