Greenhouse Climate Monitoring System
Team 305
Team Member Names:
Mark Alvarez, Aaron Karsten, Kevin Hays, Tristan Dunton
Last Rev.: 26-Feb-23
ASU EGR-314: Embedded Sys Design Project II
Travis Kelley
Spring 2023
Table of Contents
| Section # | Links |
|---|---|
| 0.0 | Introduction |
| 1.0 | Team Organization |
| 2.0 | User Needs and Benchmarking |
| 3.0 | Product Requirements |
| 4.0 | Design Ideation |
| 5.0 | Final Selected Design |
| 6.0 | Final Component Selection |
| 7.0 | Final Block Diagram |
| 8.0 | Final Hardware Implementation |
| 9.0 | Final Software Implementation |
| 10.0 | System Verification |
| 11.0 | Lessons Learned & Recommendations |
| 12.0 | Presentation Videos |
| 13.0 | Appendicies |
| 14.0 | Other Links |
Table of Figures
Introduction
EGR 314 Students were given the task of working in groups of four to develop a mobile weather station that will be displayed at the Innovation Showcase on April 28, 2023. Each team had the flexibility to select a minimum of two serial sensors and a minimum of one actuator that uses an I2C or SPI-based interface. The possible serial sensors many include temperature, humidity, light, atmospheric pressure, and wind speed. Solar panels, fan controllers, and humidity control.
To design a reliable weather monitoring system that can meet user needs and class requirements - Team 305 began the project by setting broad goals. The primary goals of Team 305 are to meet the requirements of EGR 314, while also working towards improving our skill sets and learning new skills. Although selling the final product would be great, it is not the primary focus of the team. Team 305 has established that the finished product is non-competitive and is purely an academic exercise for the purposes of EGR 314.
In summary, Team 305’s weather monitoring system is unique and uses solutions that utilizes the latest technology to produce accurate and dependable data, while being cost effective. The weather monitoring system designed utilizes two serial sensors and a motor controlled actuator that communicate using I2C/SPI protocols. The product designed is fully operational and cost effective. Overall the original goals of the project were met - which included creating a functional product, improving the aesthetics of the finished product, meeting EGR 314 goals and requirements, enhancing each team member’s skills, encouraging skill development, and implementing a cost effective design.
1.0: Team Organization
Team Charter
The vision of Team 305 is to develop a weather monitoring system with the ability to monitor its environment, record & transmit data, and withstand environmental stresses. The project will be completed successfully by meeting the requirements for EGR 314. Additionally, it is Team 305’s main objective to improve our skill sets and encourage the development of new skills - rather than create a product that can be sold. If that ends up being accomplished - fantastic - however that is not Team 305’s primary goal.
This product will be unique by utilizing two serial sensors and a motor-controlled actuator communicating through I2C or SPI. A successful project will be fully functional, simplistic in design, reliable, and cost effective.
See Team Organization for goals and mission statement.
2.0: User Needs and Benchmarking
After establishing Team 305’s mission and charter, the group moved onto product research establishing user needs and requirements for the product. Team 305 was able to gather user comments and needs directly from the competition by products that are currently available. From these needs and those generated by team members, a clear list of users needs was identified and organized.
These organized needs and the course requirements allowed for Team 305 to develop a clear perspective of the overall product requirement needed. Specifications and aspects for Team 305’s concept were developed by identifying critical requirements specified by users and our own ideas about what features should be included. For example, almost every user specified explicitly that the weather station was easy to use. With this kind of information Team 305 was able to make a clear list of the product requirements.
3.0: Product Requirements
The current product is designed to sense temperature and light using I2C protocol. A motor is used to move the sensor array while readings are being taken by the sensors. Power is provided with a 120V AC to 9V DC adapter - the logic of the MCU and sensors utilize 3.3V provided by a switching regulator (9V DC to 3.3V DC). Two PCBs were manufactured; one for the microcontroller and another for sensor array. The microcontroller is housed in a custom 3D printed protective enclosure.
4.0: Design Ideation
From the generated user needs and product requirements, Team 305 was able to begin design ideation and concept generation. Each member contributed equally to idea generation, though due to time constraints it was completed individually rather than as a group. The first iteration of ideas was completed using a “shotgun” approach, where any and all ideas were placed into a list - as long as they were relevant to the group charter and mission statement. There was no need to brainstorm once the list was approaching ~100 ideas.
From there, ranking, organizing, and idea recombination was possible. It was completed by creating a ranking system and placing the rank on each sticky note. A rank of 5 was deemed to be most important, while a rank of 1 was decided to be least important. The ranks allowed each group member to take the highest ranked features and group them into a concept “bin”. Each bin was then sketching into a concept. Concept 1 was sketched by Aaron K., Concept 2 was sketched by Kevin H., and Concept 3 was sketched by Tristan D.
5.0: Final Selected Design
Following the Design Ideation phase, Team 305 determined that a modular temperature sensing rail was the best approach to sense light an temperature. Since I2C was the chosen form of communication for the sensing units, this would allow multiple sensors to be physically connected to the MCU. For the purposes of this project, only two sensors have been depicted in the rendering found in Section 5.0.
6.0: Final Component Selection
Team 305 determined the components needed by comparing the pros and cons of the different components. For each component needed - three options were compared. From these options only one component was selected by each team member. A justification as to why that specific component was the best choice is also provided in this section. For more information about the component selection and microcontroller selection processes, please see Appendix B: Component Selection and Appendix C: Microcontroller Selection.
7.0: Final Block Diagram
This block diagram provides a clear and concise representation of Team 305’s subsystem organization and how they are interconnected. It is a valuable tool for system design and troubleshooting - but serves to depict how the different forms of communcation interact with the microcontroller. The microcontroller, I2C sensors, motor/controller, WiFi, and power subsystems have been included.
8.0: Final Hardware Implementation
A hardware schematic was created by Team 305 once the components were selected and the block diagram was completed. Individual subsystem schematics were combined and modified to show how each subsystem is powered and how each communicates with the microcontroller. Team 305’s schematics will serve as a reference for hardware, communication, and downstream PCB design.
9.0: Final Software Implementation
A UML software diagram was created by Team 305 once the functionality of the climate monitoring system was decided and finalized. The software proposal outlines the complete software flow and design of the climate monitoring system in easy to follow steps. The software diagram will serve as the guideline and template for how all of the climate monitoring system’s code is written and formatted.
10.0: System Verification
See System Verification for details.
Lessons Learned & Recommendations
Lessons Learned
- Choosing a microcontroller that has lots of features is not necessarily a good thing. It complicates the verification process, makes it difficult to de-bug, and increases the chances of the MCU not functioning as intended.
- Verifying each subsystem independent of each other is the best way to make sure the design will function as intended.
- Ordering enough parts is really important - along with getting the part orders submitted correctly. Having backup PCBs for each subsystem is important in case something goes wrong during testing.
- Working as a team is really important - verifying another group member’s subsystem can help everyone learn.
- Saving a functional version of software early in the project can provide a structure for development later; when subsustems are tested together.
- PCB designs are better when completed as a group; it ensures that each subsystem’s needs have been included (aprropriate headers, test points, additional ground connections, etc).
- Verify that the PCB was manufactured correctly before soldering components on the board. Continuity checks for each trace - along with continuity checks for vias - will prevent failures in testing.
- Minimize the design features as much as possible - without compromising the functionality of the final product. If something breaks (which usually happens during testing) it will be easier to fix. An example of this can be seen with the Team 305’s selection of a MCU. Checking 64 pins was a lot to verify during the harware validation process.
- Communicate with your group on a regular basis to ensure everyone stays on task. Make sure that there is plenty of group time to collaborate as one, instead of working independent of each other.
- Using an oscilloscope to verify SPI or I2C protocol functionality is a fantastic way to show that sensors are working as intended. It is a very powerful tool that can be used to identify problems in hardware and software implementation.
Recommendations for Future Students
- Order lots of extra parts, something always breaks and hardware orders take a long time to re-submit.
- Do not choose small components (if possible) and make sure they have leads (ex. contact pads on the bottom of a sensor is a poor choice). Make sure all components share the save logic level before deciding on what parts to use.
- Communicate with group members on a regular basis. Ensure that each member is contributing to assignments and implementing selected designs.
- Verify subsystem functionality using an oscilloscope - especially for sensors.
- Save functional versions of code after a succesful test. Work as a group to incorporate this code into the final software ddesign.