Difference between revisions of "S14: Smart Planter"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Conclusion)
(→‎Project Source Code)
 
(67 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
=== Grading Criteria ===
 
−
<font color="green">
 
−
*  How well is Software & Hardware Design described?
 
−
*  How well can this report be used to reproduce this project?
 
−
*  Code Quality
 
−
*  Overall Report Quality:
 
−
**  Software Block Diagrams
 
−
**  Hardware Block Diagrams
 
−
**:  Schematic Quality
 
−
**  Quality of technical challenges and solutions adopted.
 
−
</font>
 
−
 
 
== Project Title ==
 
== Project Title ==
 
Smart Planter
 
Smart Planter
−
[[File:Plantproject.jpeg|200px|center|frame|Smart Planter Set-Up]]
+
[[File:CmpE146_S14_CompleteSmartPlanter.png|200px|center|frame|Smart Planter Set-Up]]
  
 
== Abstract ==
 
== Abstract ==
−
Most people just don’t have the time in the day to remember to water a garden and when they do they over-water, wasting resources and hurting the plant. The solution is a system that takes in data on the moisture of the soil, the temperature, and the humidity of the environment and pumps the necessary water accordingly.
+
Most people don’t have the time in the day to remember to water a plant. When they do have a moment to water the plant, they over-water therefore wasting resources and hurting the plant. The solution is a system that takes in data on the moisture of the soil, temperature, and humidity of the environment to decide when to pump the necessary water resource accordingly.
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
−
This system will be achieved using two different types of sensors: the first will be soil hygrometer inserted into the bottom of the planter to detect the amount of water the plant currently possesses in its soil. This will be the highest priority in determining whether the plant needs additional water. The second sensor is a combination humidity and temperature sensor attached to a peg (for security and to keep the wires safe) that will relay the data back to the SJSUONE board. In order to conserve energy, the system will collect data twice a day (8 am and 3:30 pm) and determine how much water needs to be added. A real-time clock along with an Alarm timer will be used to determine when to trigger the sensors and collect data. In addition, a push-button was implemented as a alternate way to activate the sensors to check if the plant needs to be watered. It will only water the plant if the algorithm determines that the plant needs to be watered to prevent drowning the plant. A drip system was chosen because this method has shown it is the most effective in not wasting water as opposed to a spray sprinkler system that loses more water to evaporation. Finally, information including the last time checked, whether the plant was watered at this time, and the temperature at this time will be displayed on an LCD screen for the user to view. The LCD displays the last time watered, the temperature of the air, the soil moisture level, and the current time, each on their own line.
+
This system will be achieved using two different types of sensors: the first will be a soil hygrometer inserted into the bottom of the plant to detect the amount of water the plant currently possesses in its soil. This will be the highest priority in determining whether the plant needs additional water. The second sensor is a combination of humidity and temperature sensor attached to a peg (for security and to keep the wires safe) that will relay the data back to the SJSUONE board. In order to conserve energy, the system will collect data twice a day (8 am and 3:30 pm) to determine how much water needs to be released. A real-time clock along with an alarm timer will be used to determine when to trigger the sensors and collect data. In addition, a push-button will be implemented as an alternate way to activate the sensors to check if the plant needs to be watered. It will only water the plant if the algorithm determines that the plant needs to be watered to prevent drowning the plant. A drip system was chosen because this method has shown it is the most effective in not wasting water as opposed to a spray sprinkler system that loses more water to evaporation. Finally, information including the last time checked, the temperature at this time, soil moisture, and the watered time will be displayed on an LCD screen for the user to view.  
  
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
 
*  Carissa Labriola
 
*  Carissa Labriola
−
** Driver Development for sensors, Peripheral Device Hardware Integration, Software Layout
+
** Driver Development for sensors, Peripheral Device Hardware Integration, Software Layout, Wikipedia Documentation
 
*  Sovist Thou
 
*  Sovist Thou
−
** LCD Driver Display, DC Motor Control, Physical Layout, Circuit Board Design  
+
** LCD Driver Display, DC Motor Control, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
 
*  Leeladithya Avala
 
*  Leeladithya Avala
−
** FreeRTOS Software Design, Physical Layout, Circuit Board Design
+
** FreeRTOS Software Design, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
  
 
== Schedule ==
 
== Schedule ==
Line 40: Line 28:
 
| 3/23
 
| 3/23
 
| Research and order parts
 
| Research and order parts
−
| A total of 6 hours were spent just researching which parts would fit into the project such as the right DC motor, a dependable hygrometer (many corrode too quickly), an accurate temperature sensor, an LCD screen that isn't too big and doesn't need more than 12V, etc.  
+
| A total of 6 hours were spent researching which parts would fit into the project such as the right DC motor, a dependable hygrometer (many corrode too quickly), an accurate temperature sensor, an LCD screen that isn't too big and doesn't need more than 12V, etc.  
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
Line 55: Line 43:
 
| 4/13
 
| 4/13
 
| Finish drivers and FreeRTOS environment
 
| Finish drivers and FreeRTOS environment
−
| LCD screen, DHT22 drivers complete
+
| LCD screen, DHT22 drivers, DC motor control complete
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
Line 69: Line 57:
 
! scope="row"| 7
 
! scope="row"| 7
 
| 5/10
 
| 5/10
−
| Final Testing
+
| Continue Testing
 
| Moving to on-board temperature sensor, compiling individual modules into main environment, implemented push button logic
 
| Moving to on-board temperature sensor, compiling individual modules into main environment, implemented push button logic
 +
Troubleshooting of protoboard connections
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
Line 119: Line 108:
 
| $25.00
 
| $25.00
 
| $25.00
 
| $25.00
−
| New Heaven
+
| http://www.newhavendisplay.com/lcd-character-4-x-20-characters-c-2_87.html
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
Line 148: Line 137:
 
| $7.00
 
| $7.00
 
| http://amzn.com/B00CDHH3WQ <br />
 
| http://amzn.com/B00CDHH3WQ <br />
 +
|-
 +
! scope="row"| 9
 +
| Protoboard
 +
| 1
 +
| $5.00
 +
| $5.00
 +
| RadioShack
 +
|-
 +
! scope="row"| 10
 +
| Misc Components (And gate SN1708, DC Jack, Power Regulator LM7805, N-Channel MOSFET NTD5865N)
 +
| 1
 +
| $5.00
 +
| $5.00
 +
| HSC
 +
|-
 +
! scope="row"| 11
 +
| SJSUONE Board
 +
| 1
 +
| $80.00
 +
| $80.00
 +
| HSC
 
|-
 
|-
 
! scope="row"|
 
! scope="row"|
−
|
 
 
|
 
|
−
| Total
+
|
−
| $79.00
+
|
 +
Total
 +
| $160.00
 
|
 
|
 
|}
 
|}
−
 
−
//ADIYTHA, ADD THE PARTS
 
  
 
== Design & Implementation ==
 
== Design & Implementation ==
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
The hardware for the project is broken down by the needs of the different sensors. To have the design function as expected, the team required circuitry to provide the appropriate power to each peripheral as well as the CPU. The Basic System Design, shown in the Figure below, shows how each component will be laid out onto the base board. The LCD, SJSUONE board and prototype board will be set inside a clear box to protect the circuitry from any water spills as well as allow for the user to view the embedded design. The prototype board was used to build the circuitry, including the power unit for the system so that there could be a 12V and 5V power line supplied by a 12 DCV wall supply, a ground line, and a 3.3V line supplied by the SJSUONE's Vout pin. The water supply includes of a submersible DC water pump that will be sitting at the bottom of the bucket since it is not self-priming and needs to be completely submerged. The silicon tubing will be coming out of the bucket and will be fed to the plant' s soil as a drip system. A single push button was also added to allow the user to check the parameters at any given time in the day while not allowing them to over-water the plant.  
+
The hardware for the project was broken down by the needs of the different sensors. To have the design function as expected, the team required circuitry to provide the appropriate power to each peripheral as well as the microcontroller. The Basic System Design, shown in the figure below, shows how each component was laid out onto the base board. The LCD, SJSUONE board, and prototype board is set inside a clear box to protect the circuitry from any water spills and allows viewing of the embedded design. The prototype board was used to build the circuitry, including the power unit for the system so that there could be a 12V and 5V power rail supplied by a 12 DCV wall supply, a ground rail, as well as a 3.3V rail supplied by the SJSUONE's Vout pin. The water supply includes a submersible DC water pump that sits at the bottom of the bucket since it is not self-priming and needs to be completely submerged to avoid damage. The silicon tubing coming out of the bucket is fed to the plant' s soil as a drip system. A single push button was implemented to allow the user to check the parameters at any given time in the day while not allowing them to over-water the plant.  
  
−
[[File:DIAGRAM.jpg|300px|thumb|center|frame|Basic System Design]]
+
[[File:CmpE146 S14 BoardSystemDiagram.jpg|300px|thumb|center|frame|Basic System Design]]
  
  
−
The Figure below shows the circuit design for our system. As mentioned above, majority of this of will be enclosed inside the box, to keep it away from water.  
+
The Figure below shows the circuit design for our system. Not shown in the circuit box is the DC motor.
  
−
[[File:System Block Diagram.png|300px|thumb|center|frame|Circuit System Design]]
+
[[File:CmpE146_S14_BoardSystemSchematic.png|100px|thumb|center|frame|Circuit System Set-Up]]
−
//SOVIST, PLEASE UPDATE CIRCUIT
+
 
 +
 
 +
[[File:CmpE146_S14_ImplementedCircuitBox.png|300px|thumb|center|frame|Circuit System Design]]
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
−
Each of the peripherals utilized a different type of BUS communication. The soil hygrometer works by sending voltage through the pegs, measures the resistance between them, a value dependent on the moisture level, and translates this information into an analog output. Therefore, the pin is attached to one of the analog to digital pins on the board in order to translate the signal into a number that will determine the appropriate level. While the original intent for the project was to use the DHT22 temperature/humidity sensor, the protocol was more complicated than initially anticipated so the sensor was exchanged for the on-board I2C sensor. Since significant strides were made in the development of the DHT driver, its description has been included. The DHT22 utilizes a custom single-line open collector communication BUS connected to +5v and ground and a 10kohm resister connected from voltage to the communication pin to pull it high. The sensor waits for the microcontroller to pull the line low for 1-20ms, the pull the line actively high for 20-40us. The microcontroller then needs to switch to an input to receive the acknowledge signal followed by 40 bits. The bits are determined 0 or 1 by the length of how long that segment of data is high or low. The sensor needs to wait 2s in between reads and critical read times need to be protected from being interrupted in order to be successful.
+
Each of the peripherals utilized a different type of BUS communication. The soil hygrometer works by sending voltage through the pegs, measures the resistance between them, a value dependent on the moisture level, and translates this information into an analog output. Therefore, the pin is attached to one of the analog to digital pins on the board in order to translate the signal into a number that will determine the appropriate level. While the original intent for the project was to use the DHT22 temperature/humidity sensor, the protocol was more complicated than initially anticipated so the sensor was exchanged for the on-board I2C sensor. Since significant strides were made in the development of the DHT driver, its description has been included. The DHT22 utilizes a custom single-line open collector communication BUS connected to +5V, ground,  and a 10kohm resister connected from voltage to the communication pin to pull it high. The sensor waits for the microcontroller to pull the line low for 1-20ms, then pulls the line actively high for 20-40us. The microcontroller then needs to switch to an input to receive the acknowledge signal followed by 40 bits. The bits are determined 0 or 1 by the length of how long the particular segment of data is high or low. The sensor needs to wait 2s in between reads and critical read times need to be protected from being interrupted in order to be successful.
−
[[File:SensorWaveform.jpg|400px|center|frame|DHT22 Sensor Waveform for acknowledge]]
 
  
−
The on-board temperature sensor utilizes a I2C communication which has two data lines: SDA for the address, acknowledge, and data and SCL for the clock to time the information. The read temperature class has the microcontroller acting as the master and reading from the slave device, the temperature sensor. The clock is provided by the master device to the slave so that the communication can be in sync. The connections for this device are internal and can be seen below:
+
[[File:CmpE146 S14 SensorWaveform.jpg|400px|center|frame|DHT22 Sensor Waveform for acknowledge]]
−
[[File:Temperature sensor.JPG|200px|thumb|left|I2C Temperature Sensor Set Up, Credit to SJSUONE_V2 Schematics]]
 
  
−
The DC motor is a food-safe motor that takes 10-12DCV and has two inputs: the voltage and a signal that needs to be ~3-5V to activate. This system was set up by attaching an output GPIO pin on the board that when the motor needs to be activated is driven high, passed through SN1708 AND gate with a high on the other input so that the output is high enough to activate the motor. The AND gate logic was added when the pin was not providing enough voltage to activate the motor and the AND outputs a higher output signal.  
+
The on-board temperature sensor utilizes an I2C communication which has two data lines: SDA for the address, acknowledge, and data while the SCL line is used for the clock to time the information. The read temperature class has the microcontroller acting as the master and reading from the slave device, the temperature sensor. The clock is provided by the master device to the slave so that the communication can be in sync. The connections for this device are internal and can be seen on the right:
 +
[[File:CmpE146 S14 Temperature sensor.JPG|200px|thumb|right|I2C Temperature Sensor Set Up, Credit to SJSUONE_V2 Schematics]]
  
−
//SOVIST, PLEASE ADD INFO ON THE LCD SCREEN
+
 
−
The LCD screen utilizes SPI communications...
+
The DC motor is a food-safe motor that takes +10-12DCV and has two inputs: the voltage and an active high signal that needs to be ~+3-5V to turn on the motor. This system was set up by attaching a GPIO pin located on the SJSUONE board to the input of a SN1708 AND gate with a high signal on the second input. This results in the AND gate outputting a high signal of +5V which is enough to activate the motor.  An important note for the hardware implementation of the motor control is the use of zener diode 1N4001 to regulate feedback current to protect the MOSFET from blowing out. When the DC motor powers down, a high reverse voltage spikes back and could potentially damage the mosfet.
 +
 
 +
The LCD screen has an onboard controller or "backpack" that is capable of selecting different communication protocols (UART, I2C, and SPI). For this project, SPI (Serial Peripheral interface) was chosen as the appropriate communication for its simplicity and speed. To use the LCD in SPI mode, the SJSUONE board acts as a master providing SCLK (clock), display data to the LCD through MOSI data line, and SS (chip select). The chip select is used to start and end a transmission frame while in the process enabling the writing of data to the LCD. The LCD acts as a slave and only reads data sent by the microcontroller. Though the SPI bus works as an exchange protocol where a data byte is sent to receive a data byte, the MISO (slave output data) was ignored since the data sent by the LCD are not of interest.
  
 
=== Software Design ===
 
=== Software Design ===
−
The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed a semaphore but since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken, the standby was run automatically. The standby task reads as follows:
+
The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows:
−
while (1)
+
 
 +
while (1)
 
  get current time
 
  get current time
 
  send the last time plant was watered to first line of LCD
 
  send the last time plant was watered to first line of LCD
Line 194: Line 207:
 
  delay loop for 50ms
 
  delay loop for 50ms
  
−
The check reading task, when activated, updates the temperature and soil moisture and fetches the current time. If the moisture level, which ranges from ~14-50 is below 20 or the temperature is above 90*F, then the motor is activated for three seconds and the time last watered is updated. The motor is activated for two seconds is the temperature is between 80*F and 90*F or is the moisture level is less than 30. The motor is activated for one second if the temperature is between 70*F and 80*F or the moisture is below 40. If it does not fit into these parameters, than the plant is deemed to not need water and the power is not powered nor is the time watered updated.  
+
The check reading task, when activated, updates the temperature, soil moisture, and fetches the current time. If the moisture level, which ranges from ~14-50, is below 20 or the temperature is above 90*F, then the motor is activated for three seconds and the time last watered is updated. The motor is activated for two seconds if the temperature is between 80*F and 90*F or if the moisture level is less than 30. The motor is activated for one second if the temperature is between 70*F and 80*F or the moisture is below 40. If it does not fit into these parameters, than the plant is deemed to not need water and the power is not powered nor is the time watered updated.  
  
 +
The individual drivers for the peripherals will be described in the implementation section.
 +
[[File:CmpE146 S14 StateDiagram.png|left|frame|State Diagram]]
  
−
//SOVIST, PLEASE DESCRIBE HIGH LEVEL FOR THE LCD SCREEN
+
=== Implementation ===
 +
Since the overall system code has already been detailed, this section will be focusing on the software implementation of each of the peripherals.
  
−
[[File:State Diagram.jpeg|left|frame|State Diagram]]
+
Temperature/Humidity Sensor: The temperature/humidity sensor DHT22 utilizes the tri-state properties of the open collector to operate. The microcontroller must first set up a single pin as an open collector GPIO with an output pulled high. Only when the user requests data does the pin pull low for 20ms the pull high actively for 40us. The pin then needs to switch to being an external interrupt pin activated on both the falling edge to capture the start of the acknowledge as well as start a protected time from the interrupts of the FreeRTOS. When the edge is triggered, a timer will start counting such that if the rising edge trigger is not found within 100us then there is a timeout on the acknowledge indicating an error. Else the interrupt again looks for the incoming 40 bits that represent 16 bits of humidity, 16 bits of temperature, and 8 bits of check sum. The counter for the bits is such that at the positive edge of a high the count is started and ends when the negative edge is triggered. If the counter is 26-28us, then the bit is considered a '0'. If the counter is 70us, then the bit is considered a '1'. The bits are concatenated accordingly for the humidity, temperature, and check sum and if the data compared appropriately with the check sum then the read is considered successful. If called, the data for the temperature can be converted into *F since it comes as *C.
  
−
=== Implementation ===
+
I2C Temperature Sensor: The I2C sensor had the driver pre-written and verified to be working, but we had to have a working understanding of how it works. The particular process needed for this sensor was a read command. For this command to work, the microcontroller, acting as master, sent a start signal over the data line with the slave address. Using the SCLK to stay synchronized, the sensor sent back an acknowledge signal. The start signal was sent again with an off address and after the second acknowledge was confirmed the read signal was sent, which places the sensor's data into a buffer. The buffer was then sent in a 16-bit package over the line back to the master, converted into degrees in Celsius and then converted again into Fahrenheit degrees.
−
//This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation. //
 
  
−
Temperature/Humidity Sensor: The temperature/humidity sensor (officially named the AM2302) utilizes the tri-state properties of the ...
+
Hygrometer: The majority of the hygrometer data is processed through the hardware, since the analog signal is put into the Analog to Digital converter pin. Therefore, the pin must be set to it's ADC setting as an input pin. When the pin needs to be read, the BURST bit is set to start communications, a while loop waits until bit 31 is set to indicate transfer complete, and the data is transferred into an declared integer.
  
−
Hygrometer:
+
RTC: The Real-Time Clock needs to be set in order for the alarms to be effective. Therefore the RTC header needs to be included in the main program, the initialize function called, and there needs to be a declaration of type rtc_t so that the program has it's own time parameters that can update the clock time and date for the local program and the actual RTC.
  
−
DC Motor: The DC motor is a submersible food-grade water pump that is placed at the bottom of the water basin instead of needed to be primed. The output is attached to a silicon tube that then transports the water to the plant. The inputs for the motor are ground and power, which have been placed through a mosfet in order for the microcontroller to be able to control the power through an output GPIO pin. ...
+
DC Motor: The DC motor involves setting a pin to be a GPIO, setting it to be an output and pulling the line low. When the motor is to be activated, the pin is driven high, taking in as input the amount of time to delay in milliseconds before pulling the line low again.
  
−
LCD Screen:
+
LCD Screen: To operate the LCD, the LCD data sheet details commands that can be deciphered by the LCD controller to perform specific functions such as a write to line one of the LCD. To perform this write to line one of the LCD, the following must take place in software: 1) Chip select is turned on to select the device. 2) Send the function command to the LCD. In this case a write of hex 0xFE followed by 0x45 and 0x00 sets the cursor position to line one of the LCD. 3) Send the text to be displayed to the LCD. 4) Deactivate chip select to complete an operation. The controller reads character commands therefore the text and the command itself is sent to the LCD through a character byte exchange function. In the project software design each line of the 4 line LCD has its own unique write function and message created with the procedure described. The function receives input information from the real time clock and sensors then displays the information in real time.
  
 
== Testing & Technical Challenges ==
 
== Testing & Technical Challenges ==
Line 216: Line 231:
  
 
=== Temperature Sensor Issues #1 ===
 
=== Temperature Sensor Issues #1 ===
−
The first issue encountered was in writing the driver for the temperature and humidity sensor. The DHT22 works off of a single line for data transfer using the tri-state of an open collector to send start and acknowledge signals back and forth between the microcontroller and the device. The timing for sending the data is down to the microseconds so the driver timing has to be very precise or data would be missed. Hours were spent debugging a delay-based version that would hang while waiting for the end of the acknowledge from the  
+
While the documentation for the DHT22 temperature sensor says that the minimum voltage level is 3.3V and the board is supposed to output 3.3V, in reality this does not work. This was found to be a combination of the sensor really needing +5V to work properly and the board was found to only output 3.2V (tested using a multimeter). The fix for the issue was to alter the power line portion of the circuitry such that we now have the initial +12V set up to drive the DC motor then a +5V line for the microcontroller and the temperature/humidity sensor to connect to for power.
 +
 
  
 
=== Temperature Sensor Issues #2 ===
 
=== Temperature Sensor Issues #2 ===
−
While the documentation for the DHT22 temperature sensor says that the minimum voltage level is 3.3V and the board is supposed to output 3.3V, in reality this does not work. This was found to be a combination of the sensor really needing +5V to work properly and the board was found to only output 3.2V (tested using a multimeter). The fix for the issue was to alter the power line portion of the circuitry such that we now have the initial +12V set up to drive the DC motor then a +5V line for the microcontroller and the temperature/humidity sensor to connect to for power.  
+
The first issue encountered was in writing the driver for the temperature and humidity sensor. The DHT22 works off of a single line for data transfer using the tri-state of an open collector to send start and acknowledge signals back and forth between the microcontroller and the device. The timing for sending the data is down to the microseconds so the driver timing has to be very precise or data would be missed. Hours were spent debugging a delay-based version that would hang while waiting for the end of the acknowledge from the sensor. In the end, time was running out for the DHT22 module was abandoned in favor of the I2C based temperature sensor on the board.
 +
 
 +
 
  
 
=== Hygrometer Issue #1 ===
 
=== Hygrometer Issue #1 ===
Line 225: Line 243:
  
 
=== LCD Issue #1 ===
 
=== LCD Issue #1 ===
−
//Sovist Input//
+
Initially, when sending a byte of data  (command functions) to the LCD, the byte would be displayed on the LCD in ASCII representation rather than performing the operation such as setting a cursor on. This was noticed when a closer look was taken at the binary representation of the displayed character within the data sheet. The byte was taken as a literal write data rather than actually being read as a hex command. This was an occurrence that was unexplained online when researching for a solution.  In search of a solution, multiple experiments with the LCD were conducted. It was found that while sending the clear hex command in a loop, the hex command at some point reads as an operation and clears the screen rather than be displayed as a literal. After consulting a generic LCD data sheet, it was soon discovered that in most cases an LCD controller needs a delay of 100ms after the chip select is on to synch the transmission frame for SPI. Once this delay was placed inside the software a simple clear command would take place. The following issue was how to send long messages written in continual byte streams rather than single byte characters.The solution was to create a function that would leverage our single exchangeByte function with another function that could write the Byte as a string.
 +
The lesson of this issue is to always buy products that are well documented.
  
 
=== DC Motor Issue #1 ===
 
=== DC Motor Issue #1 ===
−
//Sovist Input//
+
During the initial implementation phase of the motor control on a breadboard, the input signal voltage to drive the MOSFET to activate the DC motor was +3.3V. The DC motor control software was tested multiple times to validate the correctness of the software. However, when a final implementation of the DC motor control circuit was made on a prototype board, the DC motor would not turn on with the same software. After multiple tests, the DC motor would not function consistently until it no longer activated completely. After thorough testing with a multimeter and monitoring the voltage levels of the MOSFET, it was found out that the mosfet needed +5V to drive the DC motor. This posed an issue as the microcontroller GPIO pin can only output +3.3V max. As a solution we used an AND gate as a signal driver, using its output logic at +5V to drive our DC motor. The troubleshooting for this issue was an incredible task as the issue was neither in software nor hardware implementation but an internal change in the MOSFET that was not seen to the testers.
−
 
 
−
=== Protoboard Issue #1 ===
 
−
//Adithya Input//
 
  
−
=== Water container ===
+
=== Water container #1===
 
The plastic water container for the project needed to have two holes drilled in for the silicon tubing and the wires for the DC motor. While the sealing for the silicon tubing held up, the wires produced a small leak, which became a hazard around all of the electronics. The solution for this issue was to add more hot glue whenever a drip was noticed and to seal both sides of the hole for extra support. As a result the container is now successfully sealed.
 
The plastic water container for the project needed to have two holes drilled in for the silicon tubing and the wires for the DC motor. While the sealing for the silicon tubing held up, the wires produced a small leak, which became a hazard around all of the electronics. The solution for this issue was to add more hot glue whenever a drip was noticed and to seal both sides of the hole for extra support. As a result the container is now successfully sealed.
  
 
== Conclusion ==
 
== Conclusion ==
−
The Smart Planter utilized a breadth of knowledge acquired in the embedded systems course to become successful. This included implementing I2C, SPI, GPIO, FreeRTOS, interrupts, Real-Time Clock alarms, analog-to-digital conversions, single line communications, and DC motors. Clean hardware implementation was reinforced as well as proper use of voltage regulators, MOSFETs, and setting up power lines. In the software portion of the project an understanding of interacting tasks and being conscious of the real-time operation was invaluable to the success of the project. How to troubleshoot problems across software and hardware modules was also in important learning lesson in this project. Being able to identify a problem, such as why the time function isn't updating on the LCD screen, and follow the logic of the code to discover the RTC gettime function was not properly implemented is an important skill to cultivate in engineering since the ones encountered in this project are minor compared to industry issues. All of this technical experience was combined with the soft skills of division of labor, communication across a team, time management with other on-going projects, and verbal and written explanation of technical concepts. A few improvements could have been made: for example, a water level sensor could have been added to the water tank so that if the water level got too low then the user could be warned, especially since the motor is damaged if it tries to run without water. A battery for the RTC would also be nice since currently it is reset to a specified time and date every time it loses power. Had there been more time, a wireless connection to receive weather predictions from weather.com would have been a nice addition for the plant that the tea did not have time to implement as an extra. Overall, this project was abundant in learning opportunities for the entire team so while the concept of the project was simple there was still plenty of valuable knowledge to gathered and problem solving to be had.
+
The Smart Planter utilized a breadth of knowledge acquired in the embedded systems course to become successful. This included implementing I2C, SPI, GPIO, FreeRTOS, interrupts, Real-Time Clock alarms, analog-to-digital conversions, single line communications, and DC motors. Clean hardware implementation was reinforced as well as proper use of voltage regulators, MOSFETs, and setting up power lines. In the software portion of the project an understanding of interacting tasks and being conscious of the real-time operation was invaluable to the success of the project. How to troubleshoot problems across software and hardware modules was also an important learning lesson in this project. Being able to identify a problem, such as why the time function isn't updating on the LCD screen, and following the logic of the code to discover the RTC gettime function was not properly implemented, is an important skill to cultivate in engineering since the ones encountered in this project are minor compared to industry issues. All of these technical experience was combined with the soft skills of division of labor, communication across a team, time management with other on-going projects, and verbal and written explanation of technical concepts. A few improvements could have been made: for example, a water level sensor could have been added to the water tank so that if the water level got too low then the user could be warned, especially since the motor is damaged if it tries to run without water. A battery for the RTC would also be nice since currently it is reset to a specified time and date every time it loses power. Had there been more time, a wireless connection to receive weather predictions from weather.com would have been a nice addition for the plant that the tea did not have time to implement as an extra. Overall, this project was abundant in learning opportunities for the entire team so while the concept of the project was simple there was still plenty of valuable knowledge to gathered and problem solving to be had.
  
 
=== Project Video ===
 
=== Project Video ===
Line 243: Line 259:
  
 
=== Project Source Code ===
 
=== Project Source Code ===
−
Send me your zipped source code and I will upload this to SourceForge and link it for you.
+
*  [https://sourceforge.net/projects/sjsu/files/CmpE244_SJSU_S2014/ Sourceforge source code link]
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
−
Any acknowledgement that you may wish to provide can be included here.
+
Thank you to Carlos Fernandez-Martinez for providing parts and advice,
 +
Professor Ozemek for changing our lifestyles, and to
 +
Preet for providing a solid background in FreeRTOS and drivers so we could complete everything!
  
 
=== References Used ===
 
=== References Used ===
−
List any references used in project.
+
 
 +
Humidity Sensor AM2302 Datasheet
 
http://www.adafruit.com/datasheets/Digital%20humidity%20and%20temperature%20sensor%20AM2302.pdf
 
http://www.adafruit.com/datasheets/Digital%20humidity%20and%20temperature%20sensor%20AM2302.pdf
  
 +
Humidity Sensor AM2302 / DHT22 Usage Reference
 
http://blog.ringerc.id.au/2012/01/using-rht03-aliases-rht-22.html
 
http://blog.ringerc.id.au/2012/01/using-rht03-aliases-rht-22.html
  
−
=== Appendix ===
+
LCD Datasheet
−
You can list the references you used.
+
http://www.newhavendisplay.com/specs/NHD-0420DZ-FSB-GBW.pdf
 +
 
 +
DC Motor Control With MOSFET Reference
 +
http://bildr.org/2012/03/rfp30n06le-arduino/
 +
 
 +
LPC1758 User Manual
 +
 
 +
LPC1758 Hardware schematics
 +
 
 +
Socialledge I2C tutorial

Latest revision as of 00:00, 7 August 2014

Project Title

Smart Planter

Smart Planter Set-Up

Abstract

Most people don’t have the time in the day to remember to water a plant. When they do have a moment to water the plant, they over-water therefore wasting resources and hurting the plant. The solution is a system that takes in data on the moisture of the soil, temperature, and humidity of the environment to decide when to pump the necessary water resource accordingly.

Objectives & Introduction

This system will be achieved using two different types of sensors: the first will be a soil hygrometer inserted into the bottom of the plant to detect the amount of water the plant currently possesses in its soil. This will be the highest priority in determining whether the plant needs additional water. The second sensor is a combination of humidity and temperature sensor attached to a peg (for security and to keep the wires safe) that will relay the data back to the SJSUONE board. In order to conserve energy, the system will collect data twice a day (8 am and 3:30 pm) to determine how much water needs to be released. A real-time clock along with an alarm timer will be used to determine when to trigger the sensors and collect data. In addition, a push-button will be implemented as an alternate way to activate the sensors to check if the plant needs to be watered. It will only water the plant if the algorithm determines that the plant needs to be watered to prevent drowning the plant. A drip system was chosen because this method has shown it is the most effective in not wasting water as opposed to a spray sprinkler system that loses more water to evaporation. Finally, information including the last time checked, the temperature at this time, soil moisture, and the watered time will be displayed on an LCD screen for the user to view.

Team Members & Responsibilities

  • Carissa Labriola
    • Driver Development for sensors, Peripheral Device Hardware Integration, Software Layout, Wikipedia Documentation
  • Sovist Thou
    • LCD Driver Display, DC Motor Control, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
  • Leeladithya Avala
    • FreeRTOS Software Design, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation

Schedule

Week# Date Task Description
1 3/23 Research and order parts A total of 6 hours were spent researching which parts would fit into the project such as the right DC motor, a dependable hygrometer (many corrode too quickly), an accurate temperature sensor, an LCD screen that isn't too big and doesn't need more than 12V, etc.
2 3/30 Write drivers for peripherals and environment Initial FreeRTOS environment complete, peripherals started
3 4/6 Finish hardware set up, continue peripherals Hardware set-up for individual modules, LCD screen progress,
4 4/13 Finish drivers and FreeRTOS environment LCD screen, DHT22 drivers, DC motor control complete
5 4/20 Test and Edit environment DHT22 still experiencing issues, hygrometer complete, Motor module complete, adding modules to FreeRTOS
6 5/3 Continue Testing DHT22 still experiencing issues, assembly of protoboard begins
7 5/10 Continue Testing Moving to on-board temperature sensor, compiling individual modules into main environment, implemented push button logic

Troubleshooting of protoboard connections

8 5/17 Final testing and set up All modules added to environment and protoboard, last fine tuning of software and hardware
9 5/21 Demo Complete

Parts List & Cost

Item Description Qty Unit Cost Total Cost Source
1 Hygrometer 1 $6.00 $6.00 http://www.amazon.com/gp/product/B00CKWMLC6/
2 7mm Silicon Tubing 1 $8.00 $8.00 http://www.amazon.com/gp/product/B0094FZCIW/
3 Submersible Water Pump 1 $15.00 $15.00 http://www.amazon.com/gp/product/B007XHZ25G/
4 LCD Screen 1 $25.00 $25.00 http://www.newhavendisplay.com/lcd-character-4-x-20-characters-c-2_87.html
5 Plant Pot 1 $2.00 $2.00 Orchard Supple Hardware
6 Water Basin 1 $4.00 $4.00 Target
7 Plant 1 $3.00 $3.00 Trader Joe's
8 Temperature And Humidity Measurement Sensor 1 $7.00 $7.00 http://amzn.com/B00CDHH3WQ
9 Protoboard 1 $5.00 $5.00 RadioShack
10 Misc Components (And gate SN1708, DC Jack, Power Regulator LM7805, N-Channel MOSFET NTD5865N) 1 $5.00 $5.00 HSC
11 SJSUONE Board 1 $80.00 $80.00 HSC

Total

$160.00

Design & Implementation

Hardware Design

The hardware for the project was broken down by the needs of the different sensors. To have the design function as expected, the team required circuitry to provide the appropriate power to each peripheral as well as the microcontroller. The Basic System Design, shown in the figure below, shows how each component was laid out onto the base board. The LCD, SJSUONE board, and prototype board is set inside a clear box to protect the circuitry from any water spills and allows viewing of the embedded design. The prototype board was used to build the circuitry, including the power unit for the system so that there could be a 12V and 5V power rail supplied by a 12 DCV wall supply, a ground rail, as well as a 3.3V rail supplied by the SJSUONE's Vout pin. The water supply includes a submersible DC water pump that sits at the bottom of the bucket since it is not self-priming and needs to be completely submerged to avoid damage. The silicon tubing coming out of the bucket is fed to the plant' s soil as a drip system. A single push button was implemented to allow the user to check the parameters at any given time in the day while not allowing them to over-water the plant.

Basic System Design


The Figure below shows the circuit design for our system. Not shown in the circuit box is the DC motor.

Circuit System Set-Up


Circuit System Design

Hardware Interface

Each of the peripherals utilized a different type of BUS communication. The soil hygrometer works by sending voltage through the pegs, measures the resistance between them, a value dependent on the moisture level, and translates this information into an analog output. Therefore, the pin is attached to one of the analog to digital pins on the board in order to translate the signal into a number that will determine the appropriate level. While the original intent for the project was to use the DHT22 temperature/humidity sensor, the protocol was more complicated than initially anticipated so the sensor was exchanged for the on-board I2C sensor. Since significant strides were made in the development of the DHT driver, its description has been included. The DHT22 utilizes a custom single-line open collector communication BUS connected to +5V, ground, and a 10kohm resister connected from voltage to the communication pin to pull it high. The sensor waits for the microcontroller to pull the line low for 1-20ms, then pulls the line actively high for 20-40us. The microcontroller then needs to switch to an input to receive the acknowledge signal followed by 40 bits. The bits are determined 0 or 1 by the length of how long the particular segment of data is high or low. The sensor needs to wait 2s in between reads and critical read times need to be protected from being interrupted in order to be successful.

DHT22 Sensor Waveform for acknowledge

The on-board temperature sensor utilizes an I2C communication which has two data lines: SDA for the address, acknowledge, and data while the SCL line is used for the clock to time the information. The read temperature class has the microcontroller acting as the master and reading from the slave device, the temperature sensor. The clock is provided by the master device to the slave so that the communication can be in sync. The connections for this device are internal and can be seen on the right:

I2C Temperature Sensor Set Up, Credit to SJSUONE_V2 Schematics


The DC motor is a food-safe motor that takes +10-12DCV and has two inputs: the voltage and an active high signal that needs to be ~+3-5V to turn on the motor. This system was set up by attaching a GPIO pin located on the SJSUONE board to the input of a SN1708 AND gate with a high signal on the second input. This results in the AND gate outputting a high signal of +5V which is enough to activate the motor. An important note for the hardware implementation of the motor control is the use of zener diode 1N4001 to regulate feedback current to protect the MOSFET from blowing out. When the DC motor powers down, a high reverse voltage spikes back and could potentially damage the mosfet.

The LCD screen has an onboard controller or "backpack" that is capable of selecting different communication protocols (UART, I2C, and SPI). For this project, SPI (Serial Peripheral interface) was chosen as the appropriate communication for its simplicity and speed. To use the LCD in SPI mode, the SJSUONE board acts as a master providing SCLK (clock), display data to the LCD through MOSI data line, and SS (chip select). The chip select is used to start and end a transmission frame while in the process enabling the writing of data to the LCD. The LCD acts as a slave and only reads data sent by the microcontroller. Though the SPI bus works as an exchange protocol where a data byte is sent to receive a data byte, the MISO (slave output data) was ignored since the data sent by the LCD are not of interest.

Software Design

The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows: 

while (1)
get current time
send the last time plant was watered to first line of LCD
send the last temperature read to the second line of the LCD
send the last soil moisture read to the third line of the LCD
send the current time to the fourth line of the LCD
delay loop for 50ms

The check reading task, when activated, updates the temperature, soil moisture, and fetches the current time. If the moisture level, which ranges from ~14-50, is below 20 or the temperature is above 90*F, then the motor is activated for three seconds and the time last watered is updated. The motor is activated for two seconds if the temperature is between 80*F and 90*F or if the moisture level is less than 30. The motor is activated for one second if the temperature is between 70*F and 80*F or the moisture is below 40. If it does not fit into these parameters, than the plant is deemed to not need water and the power is not powered nor is the time watered updated.

The individual drivers for the peripherals will be described in the implementation section.

State Diagram

Implementation

Since the overall system code has already been detailed, this section will be focusing on the software implementation of each of the peripherals.

Temperature/Humidity Sensor: The temperature/humidity sensor DHT22 utilizes the tri-state properties of the open collector to operate. The microcontroller must first set up a single pin as an open collector GPIO with an output pulled high. Only when the user requests data does the pin pull low for 20ms the pull high actively for 40us. The pin then needs to switch to being an external interrupt pin activated on both the falling edge to capture the start of the acknowledge as well as start a protected time from the interrupts of the FreeRTOS. When the edge is triggered, a timer will start counting such that if the rising edge trigger is not found within 100us then there is a timeout on the acknowledge indicating an error. Else the interrupt again looks for the incoming 40 bits that represent 16 bits of humidity, 16 bits of temperature, and 8 bits of check sum. The counter for the bits is such that at the positive edge of a high the count is started and ends when the negative edge is triggered. If the counter is 26-28us, then the bit is considered a '0'. If the counter is 70us, then the bit is considered a '1'. The bits are concatenated accordingly for the humidity, temperature, and check sum and if the data compared appropriately with the check sum then the read is considered successful. If called, the data for the temperature can be converted into *F since it comes as *C.

I2C Temperature Sensor: The I2C sensor had the driver pre-written and verified to be working, but we had to have a working understanding of how it works. The particular process needed for this sensor was a read command. For this command to work, the microcontroller, acting as master, sent a start signal over the data line with the slave address. Using the SCLK to stay synchronized, the sensor sent back an acknowledge signal. The start signal was sent again with an off address and after the second acknowledge was confirmed the read signal was sent, which places the sensor's data into a buffer. The buffer was then sent in a 16-bit package over the line back to the master, converted into degrees in Celsius and then converted again into Fahrenheit degrees.

Hygrometer: The majority of the hygrometer data is processed through the hardware, since the analog signal is put into the Analog to Digital converter pin. Therefore, the pin must be set to it's ADC setting as an input pin. When the pin needs to be read, the BURST bit is set to start communications, a while loop waits until bit 31 is set to indicate transfer complete, and the data is transferred into an declared integer.

RTC: The Real-Time Clock needs to be set in order for the alarms to be effective. Therefore the RTC header needs to be included in the main program, the initialize function called, and there needs to be a declaration of type rtc_t so that the program has it's own time parameters that can update the clock time and date for the local program and the actual RTC.

DC Motor: The DC motor involves setting a pin to be a GPIO, setting it to be an output and pulling the line low. When the motor is to be activated, the pin is driven high, taking in as input the amount of time to delay in milliseconds before pulling the line low again.

LCD Screen: To operate the LCD, the LCD data sheet details commands that can be deciphered by the LCD controller to perform specific functions such as a write to line one of the LCD. To perform this write to line one of the LCD, the following must take place in software: 1) Chip select is turned on to select the device. 2) Send the function command to the LCD. In this case a write of hex 0xFE followed by 0x45 and 0x00 sets the cursor position to line one of the LCD. 3) Send the text to be displayed to the LCD. 4) Deactivate chip select to complete an operation. The controller reads character commands therefore the text and the command itself is sent to the LCD through a character byte exchange function. In the project software design each line of the 4 line LCD has its own unique write function and message created with the procedure described. The function receives input information from the real time clock and sensors then displays the information in real time.

Testing & Technical Challenges

For testing this project, each of the sub-modules was completed individually and then compiled together to work in unison. The temperature/humidity sensor required the majority of the debugging time since it utilizes microsecond-precision in transferring the data. Across the board, the team found that when testing that making a separate project folder just for testing sub-modules made the debugging process more efficient. The team's procedure was to write the drivers for each of the devices with their own test code then one by one start to integrate each one into a main test program. Starting with the hygrometer being placed into the FreeRTOS frame, a button interrupt was integrated. Once this procedure was successful, the temperature sensor's input was added in. This was followed by the integration of the motor pump and lastly the LCD screen. The issues that were encountered along the testing procedure can be seen below:

Temperature Sensor Issues #1

While the documentation for the DHT22 temperature sensor says that the minimum voltage level is 3.3V and the board is supposed to output 3.3V, in reality this does not work. This was found to be a combination of the sensor really needing +5V to work properly and the board was found to only output 3.2V (tested using a multimeter). The fix for the issue was to alter the power line portion of the circuitry such that we now have the initial +12V set up to drive the DC motor then a +5V line for the microcontroller and the temperature/humidity sensor to connect to for power.


Temperature Sensor Issues #2

The first issue encountered was in writing the driver for the temperature and humidity sensor. The DHT22 works off of a single line for data transfer using the tri-state of an open collector to send start and acknowledge signals back and forth between the microcontroller and the device. The timing for sending the data is down to the microseconds so the driver timing has to be very precise or data would be missed. Hours were spent debugging a delay-based version that would hang while waiting for the end of the acknowledge from the sensor. In the end, time was running out for the DHT22 module was abandoned in favor of the I2C based temperature sensor on the board.


Hygrometer Issue #1

Programming the analog signal from the hygrometer sensor required a little research and debugging. Since this type of communication had not been experimented with before, it took a few hours completely of research to make sure that all of the correct bits were being set but ultimately this extra time spent double checking all of the inputs meant only a few trials on the board before it worked successfully.

LCD Issue #1

Initially, when sending a byte of data (command functions) to the LCD, the byte would be displayed on the LCD in ASCII representation rather than performing the operation such as setting a cursor on. This was noticed when a closer look was taken at the binary representation of the displayed character within the data sheet. The byte was taken as a literal write data rather than actually being read as a hex command. This was an occurrence that was unexplained online when researching for a solution. In search of a solution, multiple experiments with the LCD were conducted. It was found that while sending the clear hex command in a loop, the hex command at some point reads as an operation and clears the screen rather than be displayed as a literal. After consulting a generic LCD data sheet, it was soon discovered that in most cases an LCD controller needs a delay of 100ms after the chip select is on to synch the transmission frame for SPI. Once this delay was placed inside the software a simple clear command would take place. The following issue was how to send long messages written in continual byte streams rather than single byte characters.The solution was to create a function that would leverage our single exchangeByte function with another function that could write the Byte as a string. The lesson of this issue is to always buy products that are well documented.

DC Motor Issue #1

During the initial implementation phase of the motor control on a breadboard, the input signal voltage to drive the MOSFET to activate the DC motor was +3.3V. The DC motor control software was tested multiple times to validate the correctness of the software. However, when a final implementation of the DC motor control circuit was made on a prototype board, the DC motor would not turn on with the same software. After multiple tests, the DC motor would not function consistently until it no longer activated completely. After thorough testing with a multimeter and monitoring the voltage levels of the MOSFET, it was found out that the mosfet needed +5V to drive the DC motor. This posed an issue as the microcontroller GPIO pin can only output +3.3V max. As a solution we used an AND gate as a signal driver, using its output logic at +5V to drive our DC motor. The troubleshooting for this issue was an incredible task as the issue was neither in software nor hardware implementation but an internal change in the MOSFET that was not seen to the testers.

Water container #1

The plastic water container for the project needed to have two holes drilled in for the silicon tubing and the wires for the DC motor. While the sealing for the silicon tubing held up, the wires produced a small leak, which became a hazard around all of the electronics. The solution for this issue was to add more hot glue whenever a drip was noticed and to seal both sides of the hole for extra support. As a result the container is now successfully sealed.

Conclusion

The Smart Planter utilized a breadth of knowledge acquired in the embedded systems course to become successful. This included implementing I2C, SPI, GPIO, FreeRTOS, interrupts, Real-Time Clock alarms, analog-to-digital conversions, single line communications, and DC motors. Clean hardware implementation was reinforced as well as proper use of voltage regulators, MOSFETs, and setting up power lines. In the software portion of the project an understanding of interacting tasks and being conscious of the real-time operation was invaluable to the success of the project. How to troubleshoot problems across software and hardware modules was also an important learning lesson in this project. Being able to identify a problem, such as why the time function isn't updating on the LCD screen, and following the logic of the code to discover the RTC gettime function was not properly implemented, is an important skill to cultivate in engineering since the ones encountered in this project are minor compared to industry issues. All of these technical experience was combined with the soft skills of division of labor, communication across a team, time management with other on-going projects, and verbal and written explanation of technical concepts. A few improvements could have been made: for example, a water level sensor could have been added to the water tank so that if the water level got too low then the user could be warned, especially since the motor is damaged if it tries to run without water. A battery for the RTC would also be nice since currently it is reset to a specified time and date every time it loses power. Had there been more time, a wireless connection to receive weather predictions from weather.com would have been a nice addition for the plant that the tea did not have time to implement as an extra. Overall, this project was abundant in learning opportunities for the entire team so while the concept of the project was simple there was still plenty of valuable knowledge to gathered and problem solving to be had.

Project Video

Upload a video of your project and post the link here.

Project Source Code

References

Acknowledgement

Thank you to Carlos Fernandez-Martinez for providing parts and advice, Professor Ozemek for changing our lifestyles, and to Preet for providing a solid background in FreeRTOS and drivers so we could complete everything!

References Used

Humidity Sensor AM2302 Datasheet http://www.adafruit.com/datasheets/Digital%20humidity%20and%20temperature%20sensor%20AM2302.pdf

Humidity Sensor AM2302 / DHT22 Usage Reference http://blog.ringerc.id.au/2012/01/using-rht03-aliases-rht-22.html

LCD Datasheet http://www.newhavendisplay.com/specs/NHD-0420DZ-FSB-GBW.pdf

DC Motor Control With MOSFET Reference http://bildr.org/2012/03/rfp30n06le-arduino/

LPC1758 User Manual

LPC1758 Hardware schematics

Socialledge I2C tutorial

Retrieved from "http://socialledge.com/sjsu/index.php?title=S14:_Smart_Planter&oldid=9511"