Hardware Implementation
Current Schematic
Figure 1: Picture of the Final Schematic
Here is team 207’s final itteration of the hardware implementation. Each major part was made separately according to each subsystem and then put together with one another in the final schematic. Many of the components were able to be imported from sites like Ultra Librarian, which helped to speed up the process, but some required custom symbols and footprints.
An in-depth look at each part of the schematic will be shown below.
Power Supply
Figure 2: The Power Supply Subcircuit
As the power supply’s existence is how every other circuit can function, it stands to reason that it should be discussed first. It will be getting power from a 9 V battery, which will be placed in a battery holder within the product. Then, to protect the circuit, it will first be going through a fuse. Then, it goes through to a bypass capacitor to ground, as well as providing 9 V to the motor. It then goes into our switching voltage regulator, which will regulate it down to 3.3 V for the rest of the circuit. The subcircuit itself is a direct recreation of the typical application circuit found on the datasheet. The group wasn’t sure if it was necessary to have a power switch, but that might be a feature later on that is implemented.
3.3 V Logic:
9 V Logic:
Microcontroller
Figure 3: The Microcontroller Subcircuit
The microcontroller is where every other part of the circuit communicates with one another, it’s next on the list. Here, it’s shown where each other part connects to it through the many ports shown. The programmer that the group will be utilizing will be connecting through a 5-pin header, as can be seen at the top. Also, note another bypass capacitor to further protect the circuit.
MCLR
Figure 4: The MCLR Subcircuit
The purpose of the MCLR circuit is to help reset the device without having to turn the entire device off by unplugging or disconnecting the power source. The subcircuit is directly from the microcontroller’s datasheet. Rather than a switch, a jumper was used because when the programming is finalized, it won’t be necessary to turn it on or off.
Debugging LEDs
Figure 5: The Debugging LEDs Subcircuit
For the sake of debugging, and seeing a visual cue as to when certain things are done, debugging LEDs were considered necessary for this project. The group decided on 1 set of RGB LEDs, and an extra green LED. In likelihood, each set of lights being on will be a signal for certain triggers (or lack thereof). They each connect to a different GPIO pin on the microcontroller and have a ballast resistor to help in not burning up.
ESP32
Figure 6: The ESP32 Subcircuit
The ESP32 is how the device will be connecting to WiFi. It will be transmitting and receiving data from the microcontroller through the pins shown, as well as showing data through an OLED, the pins of which can be seen at the top.
Motor Driver
Figure 7: The Motor Driver Subcircuit
The motor driver is responsible for transmitting data about the motor, as well as receiving data from the microcontroller to move the motor in a certain way. It is an SPI-based motor driver and utilizes the pins necessary for that method of serial communication. The circuit was found in the datasheet.
Humidity Sensor
Figure 8: The Humidity Sensor Subcircuit
The humidity sensor will transmit data that it gets from the soil to the microcontroller. It will be using I2C communication. The circuit was obtained from the datasheet.
Temperature Sensor
Figure 9: The Temperature Sensor Subcircuit
The temperature sensor will transmit data that it gets from the area to the microcontroller. It will be using I2C communication. The circuit was obtained from the datasheet.
Bill of Materials
Figure 10: The Bill of Materials