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 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.

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.