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.