Design Week 14 : 11/22/24 - 11/29/24
Total Hrs - 14 + X
Group (6 Hours)
The group met in person as usual to continue making any last minute adjustments needed to refine the NurtureNest functionality. Bugs in the code continued to be addressed as we strive for better touchscreen sensitivity and responsiveness as well as physical safety measures to ensure there is no accidental overlap between any of the electrical and fluid components. The group continued working on the report filling in missing sections from the submitted soft draft. Plants were also put in the NurtureNest to demonstrate functionality and potential growth rate during the upcoming presentation.
Deven (8 Hours)
This week we got the NurtureNest functional with the backplate secured on and I was finally able to plant inside the NurtureNest. Our original plant was to go with tomatoes, radishes, beets, and carrots but as the group has been crunched for time with end of project report due and presentations upcoming I have instead places green onions, mint, and radishes in the planting trays. Green onions and mint were used as they are quick growing and much of their growth is immediately visible above ground. This means the results can be easily observed without having to dig up each plant and examine the biomass of the roots to measure growth. Radishes were used even though most of their growth is underground as they are one of the fastest growing crops and our best bet on getting tangible results before the presentation.
Additionally I continued work on the report and as always updated portions of the website to keep them current with the groups weekly progress.
Jon (XX Hrs)
Design Week 13 : 11/15/24 - 11/21/24
Total Hrs - 32.5
Group (10 Hours)
Deven (12 Hours)
This week the group focused on solving problems in the code, completing the frame construction of the NurtureNest, and writing the final report. The group got together multiple times over the course of the week to worn on the back panel, make small modifications to locations of sensors to get more accurate data, and debug glitches in the code related to the TFT display and NPK sensor.
My goals this week were to get the back of the NurtureNest attached to the rest of the frame and reinforce it to be able to hold the weight of the full water buckets. Originally the idea was to use cold weld epoxy to attach the backplate and provide a secure hold for the weight of the water buckets but it quickly became apparent the epoxy did not have the necessary strength to resist the shearing forces the buckets placed on it.
​
The alternative idea was to use nuts and bolts to secure the backplate. Initially corner guards were bolted to the existing side plates of the frame and then the backplate bolted into the corner guards but that provided a flimsy hold. To reinforce the backplate wooden blocks were added at each corner where the backplate could be screwed into to create a stronger hold. Additional support was added along the bottom back edge of the frame through a wooden block and additional screws to prevent crumpling of the sheet metal on the bottom as the weight of the buckets pressed down on it.
Additionally I worked on the soft draft of the report, writing extensively in chapter 3 about the hardware components, construction, and integration of the NurtureNest while my partner focused on the software aspects of the project.
​
Finally as always, portions of the website were updated to keep them current with the groups progress.
Jon (10.5 Hrs)
This week, my main focus was on resolving timing issues between the NPK sensor, DHT sensor, motor controls, and the user interface. Our main obstacle was due to the use of the delay() within the code. The use of delay() creates a blocking behavior that halts the entire program during its execution, which not only disrupts the motor but the entire code and touch display functionality. If a user attempted to interact with the touchscreen while the system was delayed, the input would often be missed. To overcome this, I implemented a non-blocking approach using millis() function. This method allows the program to measure elapsed time without stopping other operations. By maintaining a record of when a task was last performed and comparing it to the current time, I ensured that each task executes at its required interval without interfering with the rest of the code. The logic was structured by the current time using millis() and compare it against the previous time a task was executed. A conditional statement was used measure the difference exceeds a specified threshold, allowing simultaneous processing.​ Here is the logic I employed:
Implementation of millis() delay alternative
After addressing the timing issues, I began resolving a critical conflict caused by the DHT sensor library. The default library created delays, similar to delay(), and interfered with the NPK sensor and motor control. This inclined me switch to switch to the Adafruit DHT sensor library, a more efficient alternative. This library utilizes precise timing mechanisms that allow the program to gather temperature and humidity data without freezing other processes. By using this library, the system could maintain continuous motor movement and display updates. Below is an example of the updated code:
Implementation of DHT11 (Non-Blocking)
Once the timing and library conflicts were resolved, I moved on to fine-tuning the NPK sensor. During testing, the NPK sensor initially failed to provide reliable readings. I experimented with different baud rates and discovered that a baud rate of 4800 worked best. Additionally, I found that moistening the soil improved sensor responsiveness, as dry soil impeded accurate conductivity measurements. This led to consistent and meaningful data collection from the sensor.
With these improvements, I integrated the sensors and motor controls into the system. The final setup allowed the lights and pumps to respond to manual commands, while the display provided real-time feedback. Resolving the library and timing issues was a significant step forward, ensuring the system operated smoothly without interruptions. By the end of the week, the NPK sensor, DHT sensor, and motor were fully operational, marking a major milestone for the project.
Lessons Learned
This week's work showed the importance of non-blocking code in arduino code, especially when handling multiple components like sensors, motors, and user interfaces. Relying on delay() caused significant issues, such as missed touch inputs and unresponsive behavior, demonstrating the need for efficient timing solutions. Implementing millis() showed a way to manage tasks asynchronously, improving responsiveness and efficiency. Switching to the Adafruit DHT library showed the value of choosing appropriate tools for specific requirements. The library's non-blocking design allowed sensor measurements to integrate seamlessly with other processes, avoiding conflicts that previously caused system freezes. This reinforced the lesson that carefully selecting libraries can simplify code while maintaining functionality.
Design Week 12 : 11/08 - 11/14
Total Hrs - 25
Group (11 Hours)
This week the group spent a considerable amount of time getting the NPK sensor functional and putting all the individual parts of the project together. The group made the decision to switch to the Arduino Mega as the NPK sensor was not compatible with the Uno R4. Once the decision was made to switch the microcontroller the group got together and wired all the parts together and troubleshooted software bugs until each part worked individually as part of the whole system. Finally once functionality of all parts was confirmed we planted seeds to start collecting data on how the NurtureNest will perform compared to more conventional growing methods.
Deven (15 Hours)
This week I worked on the hardware aspects of the NurtureNest. Once we had functionality of the NPK sensor confirmed I could attach it to the vertical movement ball screw and attach both those components to the horizontal movement ball screw (shown below).
Previously the home position of the sensor was floating at the end of the horizontal ball screw but the NPK sensor manual advises to not leave the sensor exposed to air while powered for extended periods of time. To keep in line with the recommended use case the new home position of the NPK sensor is submerged in tray 1 soil.
​
The fluid tubing was also all connected and confirmed waterproof. As shown in the video below tubing leaves each of the water tanks, connects to a 2:1 Y split then a 1:3 X split. This allows all fluid from the tanks to travel through a single tube to each tray significantly cutting down the amount of tubing required.
Finally all the wiring for the components was connected to the Arduino Mega. The wiring is very messy but each of the wires was labeled as it was assembled so they can be easily rewired to tidy up the build. An access panel was cut in the back behind the MCU housing box to allow all wires from inside the NurtureNest to flow to the back of the frame and up to the microcontroller.
Jon (14.5 Hrs)
The arrival of the new EC sensor was very important for the sake of the project. Excited to test it, I immediately connected the sensor to the system. Initially, the sensor failed to provide any data despite trying multiple provided code examples and experimenting with different libraries. This led me to test every variable as I could control. I adjusted baud rates, rechecked wiring, and swapped power supplies to rule out external factors. Still, there was no response from the sensor. Frustrated, I examined the testing environment itself and noticed the soil sample I was using was completely dry. To get a better reading, I lightly moistened the soil to simulate realistic conditions, and suddenly, the sensor began to respond. success! This was our first indication that the sensor was functional. Despite that, I observed that the soil absorbed the water, the sensor's EC readings gradually declined. This led me to hypothesize that the sensor might primarily be measuring the conductivity of the water within the soil rather than the soil’s intrinsic properties. To verify this theory, further testing and calibration will be required.
EC Sensor Code
Building on this success, I researched how to calculate nutrient levels like nitrogen (N), phosphorus (P), and potassium (K) using the sensor's EC data. I discovered a formula that relates the difference between the EC of fertilizer and water to nutrient concentrations, scaled by a reference value:
​
N ppm=(EC of fertilizer−EC of water (reference) / N ppm)×100
​
Although promising, these calculations need precise calibration of the sensor and known reference data to ensure accuracy, which remains seemed unrealistic for our purposes but could be a possibility if the new NPK sensor doesnt work . Later in the week, the new NPK sensor arrived. Excited to finally test the sensor specified in the manual, Devon and I worked together to incorporate it into the system. Initially, the sensor failed to provide readings, repeating the challenges we faced with the EC sensor. We experimented with different codes, libraries, and baud rates without success. Then, based on our previous experience, we moistened the soil sample and changed the baud rate to 4800, which finally yielded results. The NPK sensor started providing consistent data for nutrient levels in the soil. This allowed us to gather data directly relevant to the project’s goals.
​
Integrating the NPK sensor into the system had additional issues. I discovered conflicts between the NPK sensor code and the display library, which caused one or both components to freeze in functionality. After extensive debugging, I identified that the issue stemmed from library conflicts over serial communications. To resolve this, I bypassed virtual serial communication software and utilized the Arduino’s onboard serial communication ports. This change was necessary make sure the display and NPK sensor could coexist without interruptions.
​
Finally, I programmed the lights and pumps to respond to manual controls and integrated these functionalities with the NPK sensor and stepper motor. This required the components could operate simultaneously without interfering with one another. After extensive testing, I successfully achieved a fully operational system where all components—NPK sensor, display, motors, and actuators—worked together seamlessly. These advancements have brought the project closer to its final goal of automated, plant monitoring and management.
NPK Data
NurtureNest Display Functionality
Lessons Learned
This week showed the value of persistence and problem-solving in tackling challenges in hardware and software. From my work on the display, I learned the importance of user specific design used to increase the touch areas for manual controls significantly improved the interface's responsiveness. Debugging the graphical issue taught me how important proper data-rendering logic is for ensuring usability in real-time displays.The successful response from the new EC sensor highlighted the impact of environmental conditions, such as soil moisture, on sensor functionality. This emphasized the need for thorough testing under realistic conditions to resolve our issues.
Design Week 11 : 11/01 - 11/07
Total Hrs - 25
Group (5 Hours)
This week, our group concentrated on resolving ongoing technical issues and making progress on new features for our senior design project. While the NPK sensor troubleshooting continued, we expanded our focus to include the development of a mobile and web companion app to enhance usability and data access for users. We opted to use Blynk as our platform, given its compatibility with the Arduino R4 and the convenience of remote data access it provides. Although we faced setbacks with the NPK sensor, the integration of Blynk for real-time sensor and pump data display opened new possibilities for the project, keeping us on track with our planned milestones.
Deven (10 Hours)
The major task I worked on this week was fine tuning the linear actuator to stop in the correct positions over the trays accurately. First I had to make sure the trays would be in the same position so when the NPK sensor stops and dips down it is above a tray without having to guess where it is every time. This was accomplished by evenly spacing the trays in the frame, marking their locations, and creating guiderails for the trays.
The guiderails were placed on each side of the tray and at the back of the tray to act as a stop. This lets the user slide the trays in and out as needed.
Now that we know the trays will be in the same place every time we can calibrate the motors to stop above the trays. As shown in the code below, to drive the motor we must define the amount of steps it moves and the delay between the steps. Through trial and error I have determined the required amount of steps from the starting position to the first tray, between the trays, and back to the starting position.
As shown in the video the sensor will stop above each tray to allow the sensor to dip into each tray before it moves onto the next one and resets to its final position.
In last weeks meeting Professor Notash also suggested we allow holes for the fluid tubing in the side of the water buckets reducing the amount of tubing needed in the system. Similar to how the slits for the water level sensors were created I heated a metal tool and used it to puncture a hole slightly smaller than the fluid tubing.
I also continued work on the report, writing more of chapter 3 detailing the challenges, failures, and successes we have experienced through this project.
Finally as always, portions of the website were updated to keep them current with our weekly progress.
Jon (10 Hrs)
This week, I dedicated substantial time to resolving the issues surrounding the NPK sensor while initiating development of our project’s companion app for real-time data monitoring. After extensive troubleshooting with the Arduino R4 in previous weeks, I obtained an Arduino Mega from school resources to see if an alternative microcontroller might improve the sensor's performance. I tested the NPK sensor using all available codes and libraries that had previously failed on the R4. Unfortunately, after systematically testing each configuration, the sensor continued to return incorrect data and now producing "FFFFFFFFF" values for every reading, which suggested that the sensor itself might be damaged or was faulty from the start. Although this was disappointing, the new sensor we ordered last week is expected to arrive soon, so I decided to pause further troubleshooting until it arrives.
​
With the NPK sensor set aside for the time being, I shifted my focus to developing the companion app, which is designed to display sensor and pump data on both web and mobile interfaces. We chose to use Blynk, a cloud-based IoT platform, because it offers both real-time communication with the Arduino R4 via WiFi and a user-friendly setup for app creation. I began by setting up an account and configuring the initial template in Blynk, then integrated the provided firmware configuration into our Arduino code, enabling communication between Blynk and the R4. I created gauges in Blynk for each sensor to display values between 0 and 100, providing a comprehensive data overview.
Blynk Firmware Configuration Code
Once I established the connection to Blynk, the system began communicating seamlessly with our Arduino. The online status indicator in Blynk confirmed that our Arduino was actively sending and receiving data, and I set up the web dashboard to display the current values and sensor statuses alongside manual controls for the lights, fans, and pumps. The interface on the web browser replicated the layout of our physical display attached to the frame, ensuring consistency between the two platforms. This setup allows users to view and control the system remotely from a web interface, a valuable addition for those who may not always be near the physical setup.
Blynk Web Browser (NurtureNest)
After configuring the web interface, I downloaded the Blynk app and logged in using the account I initially created. All the data streams I set up via the web dashboard were saved and readily available, so I quickly assigned each data stream to corresponding widgets in the app, matching the layout I had established on the web. This provided us with a mobile-friendly version of the interface, mirroring the data and controls available on both the web dashboard and our primary user display. [I have attached a picture of the app interface here].
One limitation I encountered was the lack of a scheduling feature in the current version of Blynk. Although we had initially planned to include scheduling options for automated controls, such as setting specific times for the pumps and lights, it appears that Blynk no longer supports this functionality. Implementing a scheduling feature may require additional research or alternative approaches to work around this limitation, potentially by exploring external APIs or embedded timing mechanisms within our code.
Blynk Mobile App (NurtureNest)
Overall, this week marked a significant step forward in improving the user experience and expanding the functionality of our project through Blynk, even as the NPK sensor issues remain unresolved. Next steps will include further troubleshooting with the new NPK sensor once it arrives, along with researching scheduling options to enhance automation within the app.
Lessons Learned
This week taught me the importance of adaptability in both hardware and software troubleshooting. Testing the NPK sensor with an Arduino Mega after compatibility issues on the Arduino R4 showed that switching hardware can offer insights, but also complicate diagnostics, leading me to conclude that the sensor itself may be faulty. Setting up Blynk for our companion app was a major improvement, allowing web and mobile interfaces to display real-time data, though the lack of scheduling features reminded me to account for changing software capabilities. Devon’s work on aligning the motor for smoother NPK sensor transitions across trays and re-routing water tubing to the tank’s base showed how even small mechanical adjustments can enhance system efficiency. These combined experiences emphasized the value of testing, flexibility, and iterative improvement across all project components.
Design Week 10 : 10/25 - 10/31
Total Hrs - 42 Hours
Group (7 Hours)
This week the group got together and continued working on the combined functionality of all the individual pieces. Deven had been testing the water level sensor and stepper motors and Jon was testing the TFT display and GPIO expansion board. We were able to get the water level sensor to work in our water tank with hot glue acting as a sealant, the NPK sensor dip sequence to function correctly with the stepper motors, and the GPIO expansion board to send consistent signals with enough current to activate the necessary relays.
Deven (12 Hours)
I worked on getting the NPK dip sequence with the motors running. Last week we got the stepper motor to run but that was accomplished by using a C++ library that was conflicting with some of the other libraries we were using for our data collection sensors. The goal this week was to get the motors to run without the library. Last week the motors were unable to run as fast or as long as needed either, both problems which were solved this week.
As shown in the video above, the motor controlling the ball screw will move the NPK sensor horizontally to the first tray then wait as the smaller stepper motor responsible for vertical movement of the sensor dips the sensor down, takes a reading, then resets to the top of the track. The ball screw moves the sensor horizontally to the next tray, the dip sequence is repeated, and finally the movement is repeated one more time for the third tray before the ball screw and linear rail are reset to their original positions.
The code accomplishing this without the library is highlighted below. The motors move direction depending on the coil activation sequence. Previously we were using a library to determine the necessary sequence but that library was conflicting with other parts of our code and had limitations on the number of steps and step delay possible. To eliminate the need for the library we created our own coil activation sequence to step the motor forward or backward. The high/low signals in the matrices determine which coils are activated and as the coils cycle through each of the four steps in the sequence a full cycle is completed. The forward step sequence activates all the coils in clockwise order and the backwards step sequence activates them in counterclockwise order.
Another problem the group had been facing is with the water level sensor. Our water tanks were too large and the sensor not long enough to span the entire depth of the tank meaning the user would get a “low water level” alert while there was still an adequate amount of water in the tank. To remedy this a slit was cut in the tank and the water level sensor inserted horizontally instead of vertically, then the slit was sealed with hot glue. This was then tested and confirmed none of the electronics were damaged during the sealing process.
Finally as always, portions of the website were updated to keep them current with the groups progress (progress log, time and effort table, weekly minutes).
Jon (23 Hrs)
This week, I dedicated myself to exploring every possible approach for obtaining reliable data from the NPK sensor, a process that has proven to be more intricate than initially anticipated. To start, I scoured several online forums and resources, collecting insights on how others had configured similar sensors and experimenting with various example codes shared by other users. After testing multiple codes and configurations, I finally managed to get a response from our NPK sensor, which was an encouraging breakthrough. However, as I dug deeper, it became apparent that the manual included with our sensor did not align with the actual specifications of the hardware. This mismatch created a host of problems—most notably, the CRC addresses listed in the manual were incorrect and needed modification, leading to inconsistent readings until I corrected these addresses.
​
After customizing the addresses, I tried a revised code (included as an image separately) and received a partial data response from the sensor. While promising, the data output itself was ambiguous, with readings that were difficult to interpret accurately. Based on what I read in forums, these values are reportedly "open to interpretation," which raised questions about the reliability of our readings. My next step was to determine whether the issue stemmed from a faulty sensor or from a software misconfiguration that could be resolved with alternative approaches.
C++ Code for NPK Sensor & Result
To improve connectivity and data accuracy, I ordered a Waveshare USB-to-RS485 adapter, a device that would allow us to establish a more stable communication channel with the sensor. Once the adapter arrived, I carefully followed wiring instructions sourced online and attempted to install the recommended RS485 serial software. Frustratingly, the software was supposed to come bundled with the sensor package, which we hadn’t received. Additionally, the download links I found on various forums were broken, leaving me without the dedicated software solution. Faced with this obstacle, I turned to a third-party serial monitoring software called Serial Monitor Device Tool. Since I was unfamiliar with this tool, I conducted additional research to understand its features and functionalities, gradually experimenting with sending and receiving commands over Modbus.
Serial Monitoring Software
To improve connectivity and data accuracy, I ordered a Waveshare USB-to-RS485 adapter, a device that would allow us to establish a more stable communication channel with the sensor. Once the adapter arrived, I carefully followed wiring instructions sourced online and attempted to install the recommended RS485 serial software. Frustratingly, the software was supposed to come bundled with the sensor package, which we hadn’t received. Additionally, the download links I found on various forums were broken, leaving me without the dedicated software solution. Faced with this obstacle, I turned to a third-party serial monitoring software called Serial Monitor Device Tool. Since I was unfamiliar with this tool, I conducted additional research to understand its features and functionalities, gradually experimenting with sending and receiving commands over Modbus.
​
​After a series of tests, I began to see some consistent responses that matched the output observed through the Arduino setup. The similarities between the data received via the RS485 adapter and Arduino suggested that I might be on the right track, though I’m still working to rule out coincidences and confirm whether the sensor is fundamentally operational. As it stands, further investigation will be needed next week to verify if our sensor is indeed functional or if we’re dealing with a defective unit. My goal is to exhaust every possible troubleshooting option before considering replacement.
​
In addition to the NPK sensor troubleshooting, I also focused on resolving a conflict with our PCF8574 expander board. The initial issue arose when I discovered that the PCF library was conflicting with our DHT11 temperature and humidity sensor library, likely due to both libraries attempting to access Arduino’s interrupt functions simultaneously. When the conflict occurred, either the PCF or the DHT11 would operate successfully, but not both at the same time. To overcome this, I tried various adjustments within the code. After some trial and error, I discovered that calling the PCF.begin() function after each DHT11 measurement enabled both components to function without interference. This approach essentially reinitializes the PCF8574 board after each temperature or humidity reading, allowing both devices to coexist on the same setup.
​
To test the PCF8574’s functionality, I connected it to the smart outlet device Devon developed and ran a series of tests. First, I programmed the board to set the output pin to HIGH, hold it for four seconds, and then set it to LOW. This caused the connected light to flicker as planned, demonstrating successful communication and control over the expander board. Attached are the results showing the PCF’s successful operation with the smart outlet, including screenshots of the HIGH and LOW outputs during testing.
PCF8574 configuration & Test
Overall, this week involved intense troubleshooting and problem-solving across multiple fronts, from NPK sensor compatibility issues to establishing reliable function within our expanded setup. Moving forward, I plan to continue refining our sensor system to ensure accurate and consistent data readings, as well as build upon the stability of the PCF expander integration for broader system controls.​
Lessons Learned
This week underscored the importance of flexibility, persistence, and resourcefulness when working with complex hardware and software systems. My deep dive into troubleshooting the NPK sensor highlighted that device manuals may sometimes be unreliable, and that addressing such issues often requires extensive research across various online communities. Through this process, I learned that code customization, such as adjusting CRC addresses, can sometimes reveal device-specific requirements not listed in official documentation. This experience reinforced that thorough troubleshooting—testing multiple solutions and verifying output consistency across setups—is vital to ensure accurate results, especially when device reliability is uncertain.
I also learned the value of adaptability in problem-solving when working with incompatible software and library conflicts, as seen in the PCF8574 and DHT11 sensor integration. By experimenting and refactoring code to reinitialize certain components at strategic points, I was able to maintain both devices’ functionality on the same setup. This taught me that small, iterative code adjustments can sometimes offer solutions without significant structural changes to the codebase, which is often more efficient than switching hardware or adding new components.
This week the group got together to continue building and debugging the NurtureNest. Last week our ball screw assembly was damaged so we had to get a replacement and confirm its functionality. Through further testing we also found two components not working properly, the L298N Motor Driver and the Arduino GPIO extension board. A new motor driver was ordered and the GPIO extension board was replaced with another already in our possession. While together the TFT display was also debugged and responsiveness was improved, reducing the delay between user touches and visual updates on screen.
Design Week 9 : 10/17 - 10/24
Total Hrs - (40) Hours
Group (10 Hours)
Deven (17 Hours)
This week I assembled the new ball screw assembly, fitted a linear railing to the ball screw bearing to stop it from rotating as it traveled along the path, watered the plants and recorded their progress, constructed a third smart outlet, and continued working on the wiring of the NurtureNest.
Originally each end of the ball screw assembly was position on blocks to allow enough space for the floating NPK sensor to move unimpeded by the floor below it. Once we mounted the stepper motor on its bracket the motor and ball screw were misaligned as the motor was sitting slightly higher. To remedy this a new block was cut and an additional layer of wood placed on top to create a level surface between the stepper motor and ball screw edge, as shown above.
​
Once the components were level we could begin testing the motor configurations and determine the correct wiring pairs necessary to drive the motor forward and backward. After testing multiple configurations we determined the wiring setup with the L298N motor driver shown below to be the correct one.
With the motor driver setup we can run the stepper motor and observe the behavior of the ball screw. As seen in the video below the ball screw housing spins as the railing rotates and must be held in place to allow movement along the railing.
In order to combat the spinning a makeshift railing was placed behind the ball screw housing preventing rotation and allowing movement across the railing.
Now that the larger ball screw assembly was functional and the correct wiring configuration was determined for the motor driver the smaller ball screw, responsible for the vertical NPK sensor movement, was tested and functioned correctly as well.
With these two components functioning correctly we now have the capability to run the NPK soil testing cycle in between waterings to determine if clean or fertilized water should be pumped to the trays.
​
I also constructed an additional smart plug to allow us to control the two pumps separately from each other. Now one plug controls both lights, and each pump has their own respective plug allowing them to be turned on and off with a simple high signal from the Arduino. Detailed instructions of the smart plug build are included in previous weeks progress logs. Pictured below is the relay wiring configuration for the third plug.
The watering schedule of the NurtureNest plants and the control group is also detailed below. As the plants mature and above soil growth is visible pictures will be included as well.
Finally as always, portions of the website were updated to keep them current with the groups progress (progress log, time and effort table, weekly minutes).
Jon ( 23 Hrs)
This week, I devoted substantial time to tackling the NPK sensor integration, which has proven complex due to its tendency for unreliable data output. Multiple technical forums and journal articles indicated that NPK sensors are often problematic. They seem to perform better with older Arduino models due to long-standing compatibility issues, and troubleshooting discussions suggest they tend to struggle on newer boards. However, we decided to proceed with the Arduino R4 due to its Wi-Fi capabilities, which are essential for our project’s planned data-sharing functions.
​
One major obstacle has been the lack of compatible libraries for the R4 model, especially for handling serial communication. The AltSoftSerial library, commonly recommended for facilitating NPK sensor communication, unfortunately, doesn’t support the R4. I spent several hours testing alternative libraries and configurations to achieve accurate data readings, yet the sensor output remained inconsistent and often incomplete, yielding fluctuating or static values rather than the expected nutrient readings.
​
Further research indicated that each NPK sensor comes with a unique CRC (Cyclic Redundancy Check) address, detailed in the manufacturer’s user manual. The CRC address allows the sensor to perform error-checking and ensure data integrity. I attempted to replace the generic CRC addresses, which I found in online examples, with the specific addresses provided in our sensor’s manual. This required modifying the code to integrate these new addresses, but despite these adjustments, the sensor continued to produce erratic data. The addresses can be seen below.
CRC Addresses
The sensor’s manufacturer provides diagnostic software designed to test the sensor’s functionality. However, using this software requires a USB-to-RS485 dongle to establish communication with a computer. Once this adapter arrives, I’ll be able to connect the sensor directly to the software, which should clarify if the problem lies in the sensor hardware itself or if it’s related to the libraries and code on the R4 board. This testing step should be highly beneficial in diagnosing the root issue, as it will help isolate whether it’s a sensor fault or a communication problem caused by the Arduino R4.
In parallel, I began researching potential alternative sensors in case the NPK sensor cannot be made to work reliably. One promising option is an Electrical Conductivity (EC) sensor, which can measure similar parameters with fewer compatibility issues on newer boards. I’ll continue to evaluate this alternative in case our diagnostic testing does not yield a workable solution with the NPK sensor.
NPK Sensor Software & Dongle Credit: https://forum.arduino.cc/t/problem-with-npk-sensor/1118733/6
In addition to the sensor troubleshooting, I dedicated time to refining the graphical data display and improving the interface’s responsiveness. I found that the data graph was not updating accurately. Each time the code looped, my indexing and sensor average values were mistakenly set to zero, which reset the data displayed and resulted in an inconsistent graph. By thoroughly debugging this part of the code, I identified the root cause of the issue and modified the code to retain accurate values across each iteration, leading to a stable and correct graphical representation.​
NurtureNest User Interface Graphical Data
The display responsiveness was another challenge. It turned out that the motor control library was introducing delays, causing a lag in the interface's response time. The library’s default settings included a built-in delay that was interfering with the fluidity of data display updates. By adjusting these delay settings, I was able to reduce the lag, resulting in a noticeably smoother and faster response on the display.
NurtureNest User Interface Manual Controls
Another major task this week was testing the PCF8574 I/O expander board to handle multiple I/O tasks effectively. The board was initially inconsistent, and it didn’t respond reliably to input and output commands. I attached an LED light to one of its ports to monitor its response visually. However, the light sometimes flickered or turned off if the board was slightly moved or adjusted, indicating that it might have a faulty connection.
​
To rule out the possibility of a defective board, I swapped it with another PCF8574, hoping for a more stable response. Unfortunately, the same issue persisted with the replacement board, so we began investigating whether the problem could stem from wiring, connector issues, or even the breadboard or pins we’re using for testing. It seems likely that there could be a weak or intermittent connection somewhere in the circuit, and I plan to systematically inspect each component to pinpoint the source of the problem.
This week presented numerous challenges that required a lot of in-depth troubleshooting. The main issues revolved around the NPK sensor’s compatibility with the Arduino R4, the accuracy of graphical data updates, and the responsiveness of both the interface and I/O expander board. While the diagnostic dongle should shed light on the sensor issues, I'm also exploring alternative sensors to ensure the functionality of our design is not compromised. Additionally, further inspection of the PCF8574 connections will be a priority next week to resolve the intermittent connectivity issues.
The progress made on the graphical display has improved the data presentation significantly, and it should enhance the user experience once other features are fully functional. I look forward to continuing testing and fine-tuning to ensure robust and reliable performance across all components of our system.
Lessons Learned
This week’s challenges highlighted several critical insights into working with new hardware and troubleshooting complex systems. First, compatibility issues with the Arduino R4 underscored the importance of carefully considering library and hardware support before fully committing to newer components. Many third-party components and libraries are slow to update for new board models, which can lead to significant compatibility challenges later on. Testing these elements as early as possible would help ensure smooth integration.
​
Additionally, I found that thoroughly consulting manufacturer documentation and resources can be invaluable when troubleshooting. The CRC addressing issue on the NPK sensor, which required specific values only available in the user manual, emphasized how manufacturer-provided tools and guides can clarify essential details often overlooked in community resources. Having access to diagnostic tools from the beginning can also streamline troubleshooting, helping avoid guesswork when components don’t perform as expected.
This week the group met over discord to discuss what times we could meet in person and what we hoped to accomplish this week. After meeting online we went to Deven's apartment where the frame is being constructed and worked on getting the linear actuator moving with the stepper motors. We also combined many of the individual components and got the sensor data to display on the TFT display and send signals to the various outputs such as the pumps and grow lights. We also discussed wiring and how to shorten the excessively long wires being used currently in order to reduce clutter inside the frame.
Design Week 8 : 10/10 - 10/16
Total Hrs - 43 Hours
Group (10 Hours)
Deven (11 Hours)
This week I was focused on getting the system ready to plant so we would have enough time to allow plants to grow and collect sufficient data to see our results against the control group. The first thing I needed to do was get the fluid piping and pumps connected to the microcontroller. I used one of the previously constructed smart plugs in conjunction with data from the moisture sensors to get the water system functional. The pump was placed inside the water tank and fluid piping was connected from the pump to a 1:3 splitter then sent to each planter. Once moisture levels drop below a certain threshold the pump will turn on for 6 seconds and water each tray.
The next necessary piece to get ready for planting are the grow lights. Similar to the pumps these were connected to another smart plug. As a default setting the lights will run for 12 hours then turn off for 12 hours, a common light split when growing indoors. The user will have the ability to override the default settings through the TFT display.
Additionally the temperature and humidity sensor was setup on the inside of the frame right below where the MCU will be housed. This data will be used to control the fans. As temperatures/humidity rises above a certain threshold the fans will turn on to help inhibit fungal growth and increase stem thickness as they simulate the winds effects on the growing plants.
With the lights, fluid, and temperature working I planted tomato, beet, and carrot seeds in their own trays then planted a control group outside in red solo cups (the method I usually use to start plants in my personal garden). With a month until the design has to be fully operational I believe this will be enough growing time necessary to collect sufficient data and compare the effectiveness of the NurtureNest compared to conventional methods.
Finally as always, portions of the website were updated to keep them current on a weekly basis.
Jon ( 23 Hrs)
This week, I focused on a complete overhaul of the user interface (UI) based on the recommendations from Professor Notash during our last meeting. One of the main goals was to optimize the layout so that all critical sensor data is immediately visible to the user without requiring multiple clicks. On the left side of the screen, I positioned the real-time sensor data, including moisture, water level, temperature, humidity, and NPK values. This layout allows the user to monitor essential information in a glance, without having to navigate through different screens, which enhances usability.
​
On the right side of the display, I organized the manual controls for the system’s fans, lights, and pumps. Each sensor now has its own section, which includes the current data, operational status, and a gauge for easy visualization. This clear division between data and controls simplifies the user experience and ensures that all necessary information is accessible in an intuitive way.
​
During this process, I identified and resolved a significant issue affecting the UI's responsiveness. The delay() function in the code was causing delays in the touch screen responsiveness. Every time the delay was executed, it interrupted the loop() function, which caused slow response times when a user tried to interact with the system. To fix this, I rewrote parts of the code, removing unnecessary delay() calls, and implemented a more efficient approach to handling time-based functions, allowing the UI to respond to touch inputs in real time.​
Updated Interface Screen
​In addition to the UI redesign, I made several improvements to the graphical data presentation. Now, when a user clicks on any sensor, a detailed graphical data screen appears, showing the most recent data recorded for that sensor. However, as I was implementing some last-minute changes, I inadvertently introduced a bug that prevents the correct graphical data from appearing. Additionally, the pump countdown timer is currently not displaying properly, an issue I’ll need to resolve next week.
​
Another critical part of my work this week was implementing a safety feature to prevent potential flooding or over-fertilization. The professor had suggested that there should be limits on how long the pumps run, so I created a feature where users can set a specific duration for the pumps to operate. I designed this with a separate screen that allows the user to choose from predefined durations. Once selected, the duration appears in the lower left of the pump control section, and when the pump is activated, the countdown timer begins. Once it reaches zero, the pump automatically shuts off, ensuring that excess water or fertilizer is not applied. While I added this feature for the pumps, I chose not to include a timer for the fans or lights, as these components can safely run continuously without any risk.​
Safety Feature Countdown Timer and Duration Selection (Code)
Despite the bug I introduced, the overall progress on the user interface has been substantial. I have increased the system’s functionality and usability, and while a few issues remain, I’m confident they will be resolved in the coming week. The safety features and UI layout enhancements bring us closer to a fully operational system, with a focus on both ease of use and system integrity.
Lessons Learned
Over the past week, I’ve gained valuable insights into the importance of balancing functionality with user experience in a design project. One major takeaway is that clear and intuitive UI design is essential for ensuring smooth user interactions. By reorganizing the sensor data and manual controls into separate sections, I realized how critical it is to prioritize accessibility and ease of navigation. Another key lesson involves the responsiveness of the interface. The delays caused by the delay() function in the code were a significant issue, as they interrupted the main loop() and led to slow system responses. From this, I learned the importance of optimizing code for real-time interactions, especially in systems that rely on user input. Removing or minimizing blocking functions like delay() is critical to ensuring that touch inputs are processed immediately, which, in turn, enhances the overall functionality of the project. The introduction of a bug while making last-minute changes highlighted the importance of thorough testing and version control. While trying to quickly implement final changes, I inadvertently caused issues with the graphical data display and the pump timer functionality. This experience taught me that rushing through code modifications without properly testing each step can lead to new problems, even when the intention is to improve the system. Lastly, I learned the value of implementing safety features in automated systems. Adding the pump duration control feature to prevent over-watering or excessive fertilizer use reminded me that automation requires safeguards to prevent potential failures or user errors. While I focused on setting timers for pumps, I realized that the safety aspect of the project needs careful attention to avoid unintended consequences.
In conclusion, this week has reinforced the importance of thoughtful UI design, real-time system responsiveness, thorough testing, and building in fail-safes to ensure both usability and reliability. These lessons will guide me in future stages of the project, helping to maintain a balance between user experience and functional integrity.
This week the group met over discord to discuss issues with the linear actuator and how to get it working with the motor driver as we were having difficulty running both motors from a single L298N. We also discussed issues with the NPK sensors data collection and interpretation as the library used for data collection has not been updated for the newest versions of Arduino software. Hurricane Milton prevented the group from meeting in person.
Design Week 7 : 10/4 - 10/10
Total Hrs - 35 Hours
Group (5 Hours)
Deven (12 Hours)
This week I began by constructing the top box of the frame where the microcontroller will sit. In our proposed design the MCU is isolated from the rest of the components in a chamber on top. I cut a piece of sheet metal in 4 equal rectangles and used L brackets and epoxy to connect them together. The sharp corners will be covered with edge guards, the same ones used on the corners of the larger frame.
I also continued work on the stepper motors that will be drive the linear actuator. Originally I believed one L298N motor driver would be able to control both motors but it appears that in order to use the bi-directional functionality we must pair one motor to one motor driver. After wiring both outputs of the motor driver to the stepper motor we were able to get the larger motor driving the linear actuator working.
I also went and updated portions of the website that were lagging behind from previous weeks, such as the weekly meetings with the professor tab and the time & effort table.
Unfortunately the rest of the week was disrupted by preparation and recovery from Hurricane Milton.
Jon ( 18 Hrs)
I started this week by working on the rendering and updating the designs on our project website. Initially, we planned to add two extra custom-built stand legs to support the additional 4 inches of sheet metal extending from the back of the frame, where the water tank is positioned. However, after some physical testing, I concluded that the frame was sturdy enough without the extra legs, and keeping them would only add unnecessary costs and work. So, we decided to simplify the design and focus on the four stand legs that came with the off-the-shelf frame. This change streamlines the construction and allows us to allocate more time and resources to addressing other critical issues. Given that we are behind schedule, we decided to prioritize functionality over aesthetics, particularly getting the system ready to record data.
Updated Design Rendering
Jon dedicated the majority of his efforts this week to advancing the motor control system, which is crucial for enabling the movement of the railing that will carry out various tasks for the plant-growing system. The primary goal was to get the motors functioning smoothly with the ability to move in both directions (clockwise and counterclockwise). This required integrating motor drivers, specifically h-bridges, into the system to control the motor’s rotation and direction.
Jon initially faced a mechanical challenge: the coupler, which connects the motor to the railing system, did not fit as expected. This was a setback, as the motor couldn't be fully connected to the structure, halting any real-world testing of the motorized movement. To address this, Jon promptly ordered the correct coupler and had to wait for its arrival. While waiting, Jon didn’t waste time. He turned his attention to testing the motors through code using the Stepper library. He configured the stepper motor to perform 200 steps per rotation, with the wiring set up for two motors and two motor drivers. The code Jon implemented defines specific pins for controlling the motors:
Stepper Motor. Code & Tutorial
This allowed Jon to successfully run the motors through simulated steps, ensuring that, from a software perspective, the motors were functioning correctly. However, he could not perform the full tests to see how the motors interacted with the railing until the new coupler arrived. Once the part is delivered, the next step will be to install the motors onto the frame and test the movement of the railings for both stability and accuracy. This will be a significant milestone for the project since it will enable the system to begin automated movement, a core functionality for planting.
​
Finally, I spent time troubleshooting the NPK sensor communication issue that Devon had been facing. After analyzing the code and wiring, I discovered missing communication protocols in the code, which prevented the NPK sensor from transmitting data correctly. I fixed this by adding the necessary code, which restored proper sensor functionality and enabled the sensor to transmit data along with other environmental metrics. Although there are still issues with the sensor's accuracy, I’m continuing to research solutions online to get reliable readings from the soil.
​
Aside from the motor work, Jon also took on the challenge of diagnosing a persistent issue with the NPK sensor. The sensor, which measures soil nutrient levels (Nitrogen, Phosphorus, and Potassium), was outputting invalid values when placed in the soil. After consulting various forums and technical articles, Jon discovered that many users have faced similar issues with these sensors. Notable sources included the Arduino forums and a tutorial from How2Electronics, which explained that some models of NPK sensors often provide unreliable or inaccurate readings. These findings suggested that the issue may not be entirely related to the code or wiring but rather could be a problem inherent to the sensor itself.
To further investigate, Jon ran additional tests and examined the sensor’s response under different conditions. While it’s possible that the sensor in use is defective, Jon is still exploring potential coding adjustments and calibration methods that might mitigate the problem. He is determined to find a solution, either through troubleshooting the sensor's performance or considering the need to source a more reliable model. At this stage, he’s weighing all possibilities but has not yet ruled out hardware issues. Bleow are the links used in my research:
​
https://how2electronics.com/measure-soil-nutrient-using-arduino-soil-npk-sensor/
​
https://forum.arduino.cc/t/problem-with-npk-sensor/1118733
​
https://forum.arduino.cc/t/6-in-1-jxct-multi-parameter-soil-sensor-using-arduino-nano/1137034/69
NPK and Expander Board Code
This NPK sensor code is designed to measure the nitrogen, phosphorous, and potassium levels in soil, using a PCF8574 I/O expander to control the sensor's communication pins. The code begins by including the `PCF8574.h` library, which allows the microcontroller to expand its pin count for interfacing with the sensor. Four pins—`npk_RE` (Receiver Enable), `npk_DE` (Driver Enable), `npk_RO` (Receive Output), and `npk_DI` (Data Input)—are defined and used to manage the communication with the NPK sensor, ensuring proper data transmission and reception.
​
To enable communication, the PCF8574 pins are set to output mode, and the code sends commands to the sensor to retrieve nitrogen, phosphorous, and potassium data using three separate functions: `nitrogen()`, `phosphorous()`, and `potassium()`. Each function works by first enabling the communication pins, then sending a command to the sensor (stored in the arrays `nitro`, `phos`, and `pota`), and reading back the sensor's response. The sensor’s data is read byte by byte using a Modbus communication protocol, with the relevant nutrient value stored in the `values[4]` array position and printed via the serial monitor. Debugging information is printed in hexadecimal format to assist in troubleshooting the sensor communication.
​
A major issue encountered in this code is the use of the `AltSoftSerial.h` library, which is necessary for handling serial communication with the NPK sensor. Unfortunately, this library is only compatible with the Arduino Uno R3 and is not supported on the Arduino Uno R4, which poses a problem for anyone using the newer R4 model. This incompatibility complicates the use of the NPK sensor with the R4 and forces the developers to either switch to an R3 board or find an alternative serial library that works with the R4. This is currently one of the key challenges that need to be addressed in the project to ensure reliable sensor data acquisition. Below is the reference video used to wire and code the expander board to the Arduino.
Lessons Learned
Throughout this phase of the project, I encountered several key challenges and gained valuable insights that have helped shape the direction of our work. First, the rendering and design adjustments proved to be a significant learning experience. Initially, I focused on adding custom stand legs to support additional sheet metal. However, after physical testing, I realized that this modification was unnecessary. This highlighted the importance of balancing design choices with functionality and cost. It also reinforced the need for flexibility in design decisions, as overengineering can lead to wasted resources and time. Prioritizing the main functionality, such as data recording, became essential to keep the project on track.
Another important lesson came from the technical hurdles we faced with the motors and the NPK sensor. The delay caused by the wrong motor coupler showed the importance of verifying component compatibility early in the project. While waiting for the correct part, I was able to advance testing using the stepper motor library. This experience reinforced the value of parallel tasking and staying productive despite delays. On the coding side, I learned that minor oversights like the incorrect motor coupler or potential sensor malfunctions can cause significant setbacks. Therefore, meticulous planning and regular testing of hardware components are critical to avoid bottlenecks.
​
This week the group reconvened after meeting with Professor Notash to discuss solutions to potential problems that were highlighted in the meeting. After a discussion period we agreed to further research our proposed solutions to determine the best path forward in the upcoming week. The group also met in person and constructed parts of the frame together as well as made final decisions on the placement of components such as the floating NPK sensor, the fans, the water reservoirs, and fluid tubing.
Design Week 6 : 9/27- 10/3
Total Hrs - 32 Hours
Group (6 Hours)
Deven (10 Hours)
This week began with researching fluid tubing and solenoid options to allow the trays to be watered individually. The group has the ability to order and implement a valve, such as the one pictured below, that is normally open but closes when powered by a 12V signal.
Electric Solenoid Valves
This allows the microcontroller to determine which trays will allow water to pass through and prevent overwatering if an extreme moisture balance occurs between trays. This problem was brought up in regards to the concern that different plants require different watering needs, but research indicates the greatest factor in soil moisture retention is the amount of (sun)light the soil receives. Since all trays will be under the same intensity of grow light and all plants were chosen because of their similar watering requirements individually watering the trays may not be necessary but could be an improvement in future designs of similar projects.
The floating NPK sensor's mobility mechanism will be two linear actuators. A large actuator spanning the width of the frame responsible for the horizontal movement, and a smaller actuator with 4 inches of movement that will raise and lower the NPK sensor. In order to fashion the two actuators together the same cold weld epoxy used for the sheet metal frame was used to attach metal faces to each actuator, then they were attached to each other, allowing movement in the X and Y axis dependent on the microcontrollers instructions.
Combined Linear Actuators
A problem the group ran into is the rotation of the ball screw nut housing as it traverses the horizontal rail. The ball screw nut housing is usually held in place by a linear railing to prevent rotation but the group overlooked the need for one so now we are working on fashioning our own. I tested using a metal rod as a guiderail but the rod was not strong enough to resist the force of the rotation without bending. After additional brainstorming I believe a wooden beam can be used as a railing as a cheap option that can be custom built to our required dimensions and will be sturdy enough to resist the rotational force of the ball screw housing as it moves horizontally.
Picture of Proposed Rod Solution
While the issue of the rotation still needs to be solved. The placement of the linear actuators were finalized. A 2x4 wooden beam was cut to length, sanded down, and spray painted black. This will act as the support shelf for the mobility sensor. Additional room was needed between the linear actuator ball screw rail and its shelf below it so supports were added on each side of the actuator allowing it to float a few inches off the shelf. The beam was secured into place by screws on either side of the sheet metal, and the linear actuator will be secured to the wooden beam by screws when all modifications are complete.
Picture of Linear Actuator on Wooden Shelf
Picture of Screws Securing Shelf in Place
Squares for each fan were cut in the side of the frame as depicted in the renderings. The fans were measured and squares were cut slightly smaller than each fans dimensions. This was intended so the fans could be glued to the inside of the frame around the edges, but cutting the sheet metal precisely proved more difficult than imagined and the squares were cut uneven, too large, and with sharp edges. This will later be remedied by using additional metal to cover any sharp edges, but there was now an issue on how to attach the fans. I found some magnets laying around my house and realized they were a potential solution to our attachment problem. I used a screw and nut to secure each magnet to the corner of a fan and then attached them to the inside of the frame.
Pictures of Fans Attached with Magnets
Additionally, the fans were oriented in such a way such that one side is sucking air into the unit and the other is blowing air out of the unit.
​
Finally, corner guards were added to the back corners to protect users from sharp edges and they will be used as a guide to place the back panel when the build is being finalized, and L brackets were added to the back corners to increase stability of the few inches that extends past the bottom of the off-the-shelf frame . The group also decided on placements of various sensors and tubing that will be shown in the pictures below. Most notably the moisture sensors will sit in the soil at the back of the trays, the temperature and humidity sensor will sit in the top left of the main housing unit allowing close access by the microcontroller in the chamber above it, and the fluid tubing will feed into the bottom watering tray of the planters as opposed to overhead drip irrigation. The planters were designed to be watered from the bottom and will use soil capillary action to wick moisture up from the tray to the plants roots.
Corner Guards and L Brackets
Temperature and Humidity Sensor Placement
Fluid Tubing Bottom Watering Planter
Jon ( 16 Hrs)
This week, Jon focused heavily on implementing the graphical data display for the project, which proved to be a complex task. The primary challenge he encountered was getting the graphical data to refresh properly on the screen. Initially, the code failed to clear the previous data once it reached the end of the display, causing the visuals to overlap and become unreadable. After experimenting with different approaches, Jon found a solution that reset the graphical display at the correct intervals. This allowed the data to scroll smoothly and loop back to the beginning of the screen once it reached the end, ensuring continuous, readable updates.
Another key issue Jon addressed was integrating the NPK sensor data into the display. At first, the display was configured to show data from three moisture sensors, but the professor pointed out that this was redundant. Jon decided to remove the second and third moisture sensor data from the primary graphical view, replacing them with the critical NPK data. To maintain accessibility to the moisture data, Jon reprogrammed the interface so that clicking on the Moisture Sensor 1 data would reveal the readings from all three sensors. This kept the graphical interface clean while still providing access to all necessary data points.
NurtureNest Display Version 2 & Graphical data
In addition to graphical adjustments, Jon refined the manual control system for the project's fans, pump, and light. Before, a brief accidental touch on the screen could activate or deactivate these systems, which posed a risk during testing and operation. Jon improved the controls by requiring users to hold down the control buttons briefly before the system would respond, reducing the chance of inadvertent inputs.
Manual Display Controls
Lastly, Jon worked closely with Devon to resolve an issue with the NPK sensor communication. Devon had encountered problems when trying to get the sensor data to interface correctly with the Arduino, resulting in errors or no data being displayed. After troubleshooting, Jon identified the missing communication code that was needed for the sensor to send data reliably. With this code added, the NPK sensor was able to function properly, transmitting data to be displayed along with other environmental metrics. Jon’s problem-solving and coding expertise played a crucial role in advancing the graphical interface and ensuring the smooth operation of key sensors.
NPK Sensor Circuit Layout
Lessons Learned
From Jon's work this week, several key lessons emerged. The first is the importance of thorough testing and iteration when implementing graphical displays. Initially, Jon faced issues with the display failing to refresh correctly, which highlighted how small oversights in code logic can have significant impacts on functionality. Through persistent troubleshooting, Jon learned the value of experimenting with different approaches and refining his solution until the desired result was achieved. The process of integrating the NPK data into the display also underscored the need for effective data management. By simplifying the interface and making it more intuitive—removing redundant moisture sensor data and consolidating information—Jon realized how critical it is to balance technical detail with user experience. His work on refining the manual controls further reinforced this lesson, as his improvements ensured reliability by mitigating accidental inputs. Finally, his problem-solving approach to the NPK sensor’s communication issues demonstrated that often the simplest fixes, such as adding missing code, can solve seemingly complex technical challenges. Overall, Jon's progress highlighted the importance of patience, problem-solving, and a user-centered approach in developing both software and hardware systems for the project.​
Design Week 5 : 9/20- 9/26
Total Hrs - 36 Hours
Group (8.5 Hours)
This week the group got together to continue construction on the frame and map out the placing of components. We also mapped out the wiring and wire placements. The group went to the store to find and test parts that would be used in the frames construction such as legs for the extension and corner guards for sharp edges. Each group member had individual parts they were working on so this meeting was an opportunity to exchange parts and help one another troubleshoot the problems we were facing. The group also worked on the report together as well as updated portions of the website.
Deven (15 Hours)
Last week the sheet metal was cut to the appropriate dimensions so this week began with attaching the sheet metal to the off-the-shelf frame extending it to the dimensions required in our proposal. A cold weld epoxy was used to secure the metal to the frame as that was decided as the better option than using additional hardware to affix it around the existing frame or attempting to drill holes through the bars and and sheets and attaching it through those.
NurtureNest frame with sheet metal extensions
The grow lights are a crucial component that rest at the top of the frame pointing downward. The height level they are placed at is important as we must give adequate room for the light to spread to the whole chamber. Enough vertical space must also be given between the lights and the growing plants as if they get too close the heat could be too intense and result in burned leaves harming the plants growth potential. The lights came as two individual frames, they were first affixed together with zip ties then held in place to the top of the frame with additional zip ties. The placement below the frame bars instead of above allows room for the grow light power cables to be hidden from the top view without obstructing the topside sheet metal extension.
LED grow lights individual and attached to the NurtureNest frame
After cutting the sheet metal I was left with a considerable amount of scraps. After discussing with Jon we agreed those scraps would be useful to create alignment frames for the rectangular planters, ensuring they do not move and allowing the NPK sensor to move to the exact locations it knows the planter boxes will be. These will be added to the bottom of the frame next week.
I also conducted considerable research on the construction of the mobility arm and its various aspects. The NPK mobility arm will be driven by a linear actuator, allowing the rotational movement of the stepper motor to translate to linear movement. We purchased the necessary components and I was able to construct one of the two linear actuators we will need to complete the project. The inspiration for our mobility mechanism came from the video below with slight modifications. The video shows construction of a 3 dimensional arm but we only require 2 dimensions of movement for the NurtureNest.
The completed linear actuator pictures above allows room for the stepper motor to connect to the gray cylinder on the right side of the picture. In our construction we will use a NEMA 17 Stepper Motor as it is bipolar, rotating in two directions instead of one. Additional we used a stepper motor instead of a traditional DC motor as we will require precise movements to ensure the NPK sensor always reaches the desired destination, where a planter box is waiting. The stepper motor cannot be connected directly to a power source, it must be used in tandem with a motor driver. We have chosen the L298N motor drive as it is an inexpensive and easily attainable component. The L298N motor driver will be powered by a 12V power source and allows us to control the speed and direction of the stepper motor through the frequency and sequence of pulses respectively.
Linear actuator components and construction
Mobility mechanism inspiration
L298N Motor Driver Pinout
One driver will allow us to control two motors which is convenient if we decide to use a second stepper motor to control the vertical movement axis. As of right now the group believes a standard DC motor should suffice for the vertical movement as it does not need to be as precise as the horizontal movement of the sensor and a second stepper motor would be cost prohibitive, but the option to run a second stepper motor from the drive is invaluable if the group decides to go in that direction.
​
I also continued work on the first few chapter of the final report due at the end of the semester, as well as continuing to update the websites progress log, time and effort table, weekly minutes, and other pages as we progress through the semester.
Jon ( 12.5 Hrs)
This week, I continued working on the design of the user interface, focusing on enabling the touch functionality and adding graphical data as specified in our design requirements. The user interface is meant to display real-time sensor values and allow users to control fans, pumps, and lights, with additional features like graphical data of sensor values over time. One of the main challenges I encountered was enabling the touch feature of the RA8875 display. The RA8875 library's touch() function returns raw x and y values, which are not automatically scaled to match the screen’s dimensions. To resolve this, I manually identified the maximum and minimum x and y values by pressing in the corners of the screen and recording the results. I then used the map() function, as documented on Arduino’s website, to scale the touch inputs to the display coordinates. This step was critical for ensuring the touch feature accurately corresponded to the user’s interaction with the screen.
Wait For Touch Event Code
Another challenge was the pixel-by-pixel management required to print, update, and erase elements on the screen. Designing the graphical page involved overlaying a box on top of the real-time sensor data when a touch event was detected. Exiting the graphical page required reprinting the entire monitoring interface, which involved duplicating the monitor data code into the touch event handler. This solution works, but it has drawbacks, such as potential memory overload if we're not careful. The Adafruit GFX library, while functional, forces me to handle every pixel and redraw data in real-time, which can strain the limited memory resources of the Arduino. Below is the code to print the graphical for a specific sensor.
Sensor Line Graph Code
For displaying sensor data over time, I researched ways to make use of the Arduino’s millis() function, which starts incrementing from the moment the system powers on. Since this is the primary timing function available, I had to creatively work around it to record and store sensor values over a specific timeframe. I decided to average the sensor values over set intervals and store them in an array, allowing the data to be accessed later when a user interacts with the display to view historical data. Setting up the array was straightforward, but integrating the data into the graphical display posed more difficulties. To graph the data, I needed to draw lines corresponding to each sensor reading over time. Since the Adafruit library lacks built-in functions to draw angled lines with varying thicknesses, I found a helpful YouTube tutorial that provided a method to draw lines between points. Implementing this solution made it easier to plot a line graph showing the sensor values, but despite this progress, there are still some bugs in the code that prevent the graphical data from being displayed accurately. I’ll need to troubleshoot these issues further to ensure the data plots correctly.
User Interface Touch Results
In addition to working on the UI, we received and tested the 12V fans that will be integrated into the system. Interestingly, these fans can automatically adjust their speed based on input from a temperature sensor, which aligns well with our design’s goals. This feature could be useful for automating fan control without needing constant user intervention.
Overall, I made significant progress this week, but there are still some challenges to address, especially with memory management and ensuring the graphical data is displayed accurately. With more testing and refinement, I’m confident these issues can be resolved in the coming weeks.
12V DC fans Circuitry
Lessons Learned
This week was very informative on lessons in both the mechanical and software aspects of our project. On the mechanical side, Devon’s work with the frame and grow lights showed the importance of choosing practical attachment methods, like cold weld epoxy, which saved time and effort compared to mechanical fasteners. We also learned that careful placement of grow light is crucial to prevent plant damage from overheating, while the use of zip ties for easy adjustments and cable management was both resourceful and effective. Repurposing leftover sheet metal for planter alignment frames for grow tray holders added benefits of recycling resources. On the software side, Jon’s work on scaling touch inputs using the `map()` function reinforced the need for precise calibration in user interactions. Managing memory proved challenging as pixel-by-pixel updates for real-time data became intensive, teaching us the importance of reducing code redundancy. The implementation of graphical data representation further emphasized the need for system optimization to prevent memory overload. Additionally, testing the 12V fans revealed their automatic speed adjustment feature, showing us that components have more functionality than expected, reinforcing the importance of thorough testing. Overall, these lessons will help us improve efficiency and avoid future issues as we continue to refine the project.
Design Week 4 : 9/13 - 9/19
Total Hrs - 50
Group ( 12.5 Hours)
After meeting with our professor, we discussed how to prioritize our tasks for the week. The top priorities were constructing the project’s frame, getting the TFT display operational, and beginning the integration of individual components into the frame. As a group, we focused on building the frame based on the approved extension plan, using sheet metal to match the original dimensions. This was a crucial step in ensuring that all components would fit properly and function as expected during later stages of the project.
Jon ( 25.5 Hrs)
This week, my primary focus was on tackling the task of getting the RA8875 driver and TFT display up and running, as these components is an important components of the user interface (UI) for the project. The first step involved desoldering and soldering connections to the RA8875 driver. This process was very delicate. Ensuring clean connections was crucial, as even a minor error in soldering could have led to issues with the display’s functionality or communication with the Arduino. After successfully reworking the connections, I was able to get the TFT display functioning properly.
RA8875 Soldering & TFT Display
With the hardware in place, I turned my attention to the design and implementation of the user interface. The initial UI design included several key user components: a title block, a demo button, and various sensor readouts for moisture (3 grow trays), temperature, humidity, and controls for the fan, pump, and lights. Each of these components needed to be positioned on the screen in a way that was first easily readable and second easy to access. One of the challenges I encountered early on was the limited graphical capabilities of the Adafruit library. While the library provides basic functions to create shapes and display text, it lacks advanced graphic features due to the constrained RAM on the Arduino. This meant I had to work creatively within these limitations, finding ways to make the UI visually appealing without overloading the system. I spent a lot of time researching solutions through documentation and online forums, exploring different methods to resolve the graphical issues of the display without reducing performance. The following websites were used as reference in resolving issues:
​
https://github.com/adafruit/Adafruit_RA8875/tree/master
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
https://adafruit.github.io/Adafruit_RA8875/html/class_adafruit___r_a8875.html
Implementing a bitmap in the Adafruit GFX Library presents several challenges, primarily due to the limited memory available on most Arduino boards and the complexity of working with pixel data. One of the main difficulties is that bitmap images must be stored in a specific format. I found an online image to bitmap converter called Image2Cpp to turn standard images into arrays that the GFX library can read. The converting of large or high-resolution images can quickly exceed the available RAM. Additionally, loading bitmaps onto a TFT display through the GFX library involves managing pixel-by-pixel drawing, which requires a lot of trial and error. The resources I found, such as the Adafruit GFX guide (https://learn.adafruit.com/adafruit-gfx-graphics-library?view=all) and [his forum discussion (https://forum.arduino.cc/t/problems-with-bitmaps-on-tft-display-using-gfx-library/524977/14), described issues with slow image rendering and memory overflow. The videos like this one (https://www.youtube.com/watch?v=7ER1fbDoc20) and tutorials like this bitmap tutorial (https://educ8s.tv/arduino-bitmap-graphics-tutorial/) provided helpful insights but did not describe the fact that working with large bitmaps or complex graphics is a challenging task, particularly when optimizing for both speed and memory efficiency. For the sake of time I will revisit increasing the appeal of the user interface by adding graphics.
Bitmap Implementation for TFT Displays
Working with individual pixels to ensure symmetry and alignment required a lot of trial and error. Since the TFT display operates at a high resolution relative to the Arduino’s processing power, even small misalignments could make the interface look unprofessional or confusing to the user. I meticulously adjusted the pixel placements of each UI element, to display a clean and organized interface. I prioritized that each sensor readout was clear and easily readable, even manual controls for the light, fans and pumps conditions. One of the standout features I implemented was the demo button, which was added specifically for presentation purposes. This button allows the project to seamlessly transition into a demonstration mode, showcasing the system's capabilities without requiring manual input from the user. During the demo, all the sensor values, moisture, temperature, and humidity, will update in real-time, while the controls for the fan, pump, and lights remain interactive. This feature is designed to make the system easier to showcase during presentations and evaluations. Some of additional challenges I faced when it came to the touch capabilities of the TFT display have still not been resolved. Despite extensive testing, the touch input is not yet functional, which limits the interactivity of the user interface. This is a key feature and a will hopefully be resolved the following week. Research into how to properly integrate touch functionality within the current framework is ongoing, and I plan to continue deeper research, documentation and forums. The complexity of the touch interface lies in managing the precise calibration and coordination between the display and the Arduino.
TFT User Interface & Sensor Data
Looking ahead, once the touch functionality is operational, I will implement graphical data representation for each sensor, displaying trends over a seven-day period. This feature presents its own set of challenges. The Arduino can only log time in milliseconds from the moment it starts, which means coding a solution for time-based logging and graphical plotting would require precise coding and management of the Arduino’s memory. Given the setbacks and ongoing technical challenges, I have made it clear that I will be doubling my efforts in the coming weeks to ensure that the project meets its deadlines. I will continue to work on resolving the touch interface issues, optimizing the UI interface, and researching the various methods of adding graphical data logging.
Deven (12 Hours)
This week I was focused on getting the physical parts of the frame together and ready for the final build. After discussions with the professor we agreed sheet metal would be the best material to work with to augment the off-the-shelf frame we had bought. The frame needed to be adjusted to fit the dimensions outline in our proposal phase of the project. We had agreed upon 24x36x36 inches LxWxH to be the set dimensions for the NurtureNest during the proposal phase but the frame we bought is 18.5x36x29.5 LxWxH. The main focus of the augmentations is to adjust the length of the frame to our desired 24 inches as that space is necessary to house the size of the planters we bought and the NPK mobility sensor.
The sheets were laid out and aviation tin strips, commonly used to cut sheet metal, were used to cut them to the correct dimensions. To affix the metal sheets to the frame cold weld epoxy was used and then left to cure for 24 hours. The corners on the sheet metal extensions are not perfectly aligned and are quite sharp after being cut so corner guards will be used to connect the corners and protect users from any sharp edges.
Sheet metal for frame extension
Corner guard for sharp edges
The NurtureNest also has 3 gallon tanks at the back where fresh water and fertilizer infused water will be held ready to be dispersed amongst the system once moisture levels are too low. I picked up some 3 gallon buckets and spray painted them black. The back plate has not yet been attached to leave open room for the rest of the components to be placed but once the back of the frame is closed these buckets will be attached to the NurtureNest and the water pumps will be placed inside.
3 gallon buckets for fresh and fertilized water
The system will also require a second microcontroller controlled plug. We built one previously for the grow lights so I followed the same steps and constructed a second one that will be used to control the water pumps when necessary. To summarize the construction process that was explained in greater detail earlier in the progress log, a power strip was repurposed and connected to an electrical outlet with a 5V relay allowing a signal to be sent from the microcontroller to the outlet/relay and letting current flow to the connected load.
Smart plug controlled by microcontroller signal and 5V relay
Finally I began work on the final report for the design phase of the project. Chapters 1 and 2 are rehashed from chapter 3 of the proposal phases report. The group will continue working on and updating the report week by week as the semester continues and we get closer to the due date.
Lessons Learned
This week’s work on the smart plug and NPK sensor provided valuable lessons in troubleshooting, patience, and the importance of detailed preparation. The construction of the smart plug began with careful mapping of the wires to ensure the correct connections for live, neutral, and ground, using a multimeter to verify each. This step was essential in connecting the wires to the relay properly, and it reinforced the importance of verifying each component before assembly to avoid mistakes and ensure safety. Another takeaway was understanding the power requirements of different components. The 5V relay used for the Arduino was straightforward, but the NPK sensor required a separate 15V power supply, emphasizing the need to confirm each component’s voltage needs before beginning work. Lastly, despite the setbacks, Jon was able to resolve issues with the moisture sensor, and significant progress was made in diagnosing the display issue related to the RA8875 driver and TFT display. Troubleshooting issues require persistence and patience when projects get complex or frustrating.
Design Week 3 : 9/6 - 9/12
Total Hrs - 35.5 Hrs
Group (5 Hours)
After last weeks meeting with Professor Notash the first focus of the group this week was to finalize the options for the frame to make sure it is more closely aligned with the renderings proposed in the previous phase of the project, and to determine the best option for the OLED TFT display that will convey system information to the user. After consideration the group determined we would use a prebuilt frame with sheet metal attached to create the chassis design that was previously proposed. We also decided for simplicity sake to have the temperature, humidity, water level and NPK values readily displayed on screen so that a user would not have to physically navigate to find each value. In addition, we discussed the implementation of the scheduling feature to allow users to manually schedule when to water or fertilize the plants.
Deven (17 Hours)
During this week Deven continued work on the NPK sensor and constructed the smart plugs that allow a wall outlet to be controlled by a microcontroller. The smart plugs are a necessary component as they will be the mechanism by which the Arduino will control the grow lights and water pumps.
​
Beginning with the construction of the smart plug, the first step in construction is to cut the cord off a power strip and determine which wire connects to each prong on the plug. By using the continuity checker functionality of a multimeter we can map each wire to one of the plug prongs and determine which wire is the ground, neutral, and live wire. These are necessary to map as it will determine which wires connect to the relay and how they connect to the newly constructed outlet.
As shown in the picture above, once the wire map is determined the last few inches of insulation from each wire can be stripped and the wires separated. The wires are then fed through the plastic outlet sheathing and we can move onto the relay. A new piece of wire is cut and a few inches from each end stripped, then one end is inserted into the NO terminal of a 5V relay. This wire will eventually be connected to the live side of an outlet and will allow power to flow from the wall plug to the outlet once the relay is activated. A 5V relay was chosen as that is the voltage output by the GPIO pins on an Arduino. VCC, ground, and a signal wire is attached to the other end of the relay so they may be connected to a microcontroller and the relay can be controlled by the microcontroller.
​
The hot wire from the electrical cord is connected to the common terminal of the relay and secured with a screw. Then the outlet can be connected to the rest of the wiring.
The left side of the outlet houses the terminals for the ground and neutral wire. Ground is connected to the green screw and neutral connected to the silver screws then tightened down. Then the hot wire extending from the NO terminal of the relay is connected to the gold colored screws on the right side of the outlet and tightened down. Once all the electrical connections can be made the relay and wiring can be pushed neatly inside the plastic housing and the outlet screwed down.
Finally a face plate is screwed onto the plastic housing, and with the VCC, ground, and signal wire extending from the outlet we have completed construction of a smart plug that will allow our components to be controlled by our microcontroller.
This week Deven also continued work on the NPK sensor, which is proving more challenging than previously expected. As shown in the previous weeks progress log there is extensive wiring between the sensor, interface module, microcontroller, and LCD display. This allows for many points of failure through incorrect wiring and makes troubleshooting a difficult process.
​
As of this moment the microcontroller connects to the display and can display the necessary information on the screen, but the sensor is not transmitting data to the MCU that can then be displayed. The NPK sensor runs off of a 12V-24V power supply so a 15V supply was cut then connected to the VCC and ground of the NPK sensor. A multimeter was used to confirm the connection and that 15V was flowing to the sensor. The multimeter was also used to ensure the correct 5V from the MCU was powering the interface module to eliminate the possibility that the errors lied in the powering of the components.
​
To determine whether the NPK sensor was sending signals to the Raspberry Pi the following test code was employed.
The test code shown above begins with establishing the GPIO pins the interface module is connected to. A command was run on the Raspberry Pi to determine the correct serial port location, /dev/serial0 in this case, and the location is inserted into the code so the Pi knows this is where the RS485 interface module is sending its information. The baud rate is taken from the sensor datasheet. The MCU then requests the nitrogen reading from the sensor, sets the DE and RE GPIO pins to read mode, reads the response, and outputs it to the terminal. This is where the problem lies as the terminal returns no response so we can determine the MCU is not receiving any information from the sensor.
​
Since we have already determined the components are being powered correctly it seems the most likely culprit is the wiring, but after rewiring to different GPIO pins multiple times and still getting no response the troubleshooting must continue. Next steps will include disassembling and carefully beginning the wiring from scratch as well as continuous code adjustments in case the error lies there.
This week Deven also updated portions of the website including the weekly minutes with Professor Notash, the progress log, and time and effort table. A running tally of the budget is kept between the group members and the table is updated with any unexpected costs that appear during construction.
Jon (13.5 Hrs)
This week, my primary focus was getting the capacitive moisture sensor to function correctly. Unfortunately, I encountered several challenges along the way. Initially, the sensor wasn’t providing any meaningful data despite being connected correctly, and after spending hours debugging the code and checking the wiring, no data was being outputted. I figured maybe it was a wiring issue, code issue, or the sensor was faulty from the beginning. At first, the moisture sensor seemed completely unresponsive. I checked the wiring and the sensor’s placement in the soil repeatedly. Each time, the sensor returned either no data or wildly inconsistent values that made no sense given the moisture levels. I tried swapping jumper wires to rule out a bad connection. I rechecked the code and inserted debugging statements to monitor the sensor readings. Nothing seemed out of place on the software side. I tested the sensor on multiple GPIO pins and even with a different microcontroller, but the same problems persisted. After struggling for a couple days, I decided the issue might be with the sensor itself and replaced the capacitive moisture sensor. I was on the verge of thinking the entire sensor type was incompatible with the system I was using. But after more digging and testing, I realized that the original sensor I had was, in fact, faulty from the start. Once the faulty sensor was identified and replaced, the new sensor started giving proper readings immediately, confirming that the sensor itself was the issue and not the wiring or software.
Capacitive Moisture Sensor
After resolving the moisture sensor issue, I turned my attention to setting up the RA8875 driver and the 7.0" TFT display. Unfortunately, this task brought its own set of challenges.
​
The first issue I encountered was physically connecting the 7.0" TFT display to the RA8875 driver’s bus connection. The connector was extremely snug, and I struggled to insert the cable into the port. After several attempts, I was able to connect it, but I noticed that the display cable got bent during the process. I suspect this might be the cause of the strange behavior I observed later, such as random flickering and poor display quality.
​
The RA8875 driver board came without pins soldered on, which meant I had to solder the pins myself to connect it to the breadboard. Soldering wasn’t too complicated, but I had to be extra careful to ensure that all the pins were properly connected and that no solder bridges formed between adjacent pins. After completing the soldering, I mounted the board on the breadboard and tested the connections. Everything seemed to check out, but I had yet to power up the display at this point.
​
After completing the physical setup, I powered everything up, but the display remained unresponsive. This was unexpected and frustrating since I had taken extra care during the connection and soldering processes. I began the troubleshooting Verified that the correct voltage was being supplied to the RA8875 and the display. Both were receiving the expected 5V power, but still no response from the display. I suspected that the bent display cable might be the culprit. The cable looked slightly damaged from forcing it into the snug connection, which could be why the display isn't turning on. I might need to replace or carefully realign the cable to ensure all pins are making contact. I checked the software setup for initializing the RA8875 driver and TFT display. My initialization sequence seemed fine, but I wasn’t getting any feedback from the display. It’s possible I need to revise my RA8875 driver code or check for updated libraries.​
RA8875 & TFT display Connection Port
I’ll disconnect and reconnect the cable, being careful not to damage it further. If this doesn't work, I may need to order a new cable or display to rule out hardware damage. I plan to test the driver with another display to verify that the issue is not with the RA8875 driver. I’ll inspect the soldering on the RA8875 pins to ensure that all connections are solid and no pins are loose. I’ll look into updating the RA8875 library or try a few different configurations for initializing the display.
Moisture and TFT Display Code
The complete setup up until this point including the Moisture, temperature/humidity, water level and display can be seen below.
Temperature/Humidity Sensor, Water Level Sensor, Moisture Sensor and Display configuration
Lessons Learned
This week’s work on the smart plug and NPK sensor provided valuable lessons in troubleshooting, patience, and the importance of detailed preparation. The construction of the smart plug began with careful mapping of the wires to ensure the correct connections for live, neutral, and ground, using a multimeter to verify each. This step was essential in connecting the wires to the relay properly, and it reinforced the importance of verifying each component before assembly to avoid mistakes and ensure safety. Another takeaway was understanding the power requirements of different components. The 5V relay used for the Arduino was straightforward, but the NPK sensor required a separate 15V power supply, emphasizing the need to confirm each component’s voltage needs before beginning work. Lastly, despite the setbacks, Jon was able to resolve issues with the moisture sensor, and significant progress was made in diagnosing the display issue related to the RA8875 driver and TFT display. Troubleshooting issues require persistence and patience when projects get complex or frustrating.
Design Week 2 : 8/30 - 9/5
Total Hrs - 25.5 Hrs
Group (6.5 Hours)
During this week the group met and discussed what our individual goals for the week would be and what we were expected to complete by our next meeting. Deven will work on building the frame and the NPK sensor and Jon would continue work on the moisture, water level, and humidity and temperature sensors and the code behind them. We also held a discussion on the mobility mechanism driving the NPK sensor and the details of its construction.
Deven (11 Hours)
During this week Deven completed the frame skeleton construction and began working on the NPK sensor but ran into some roadblocks. The construction of the frame was straightforward as it came with clear build instructions. The frame is built from heavy-duty steel which will prevent warping as the weight of the components rest upon it as it is rated to support over 600 lbs., well below the maximum 60 lbs. outlined in the design engineering requirements.
NurtureNest frame before construction (left) and after assembly (right)
Deven also continued work on the NPK sensor with the aim to have it fully functional and able to read the macronutrient levels in a soil sample and display them on an LCD display driven by the Raspberry Pi. First the LCD was tested with a sample message to confirm its functionality before moving to the NPK sensor. The wiring between the LCD sensor and the Pi are shown below.
Connection map between Raspberry Pi Model B and 16x2 LCD
Following the pinout above and running sample code to display the text "Raspberry Pi Model B" Deven was able to successfully confirm functionality of the display.
Wiring of Raspberry Pi Model B and 16x2 LCD
Next the NPK sensor must be connected to the MAX485 TTL to RS-485 interface module. The NPK Sensor has 4 wires, a 9-24V power supply, ground, data A, and data B. The MAX485 TTL to RS-485 interface module has a data input side and an output side. The data side header consists of a receiver output which should be wired to the serial RX pin on a microcontroller, and receiver enable line which is active low and when driven high will act as a data output. The data side header also has a driver input line which connects to the serial TX pin on a microcontroller.
​
The MAX485 TTL to RS-485 interface module output side consists of 4 pins, VCC which connects to 5V, Data B, Data A, and ground. The connections between the NPK sensor, the MAX485 TTL to RS-485 interface module, an Arduino Nano board, and a OLED display are shown below.
Connection map between Arduino Nano, OLED display, MAX485 TTL to RS-485 Interface Module, and NPK Sensor
The example map above uses a Arduino Nano and OLED display while the components Deven is using are a Raspberry Pi 3B+ and a 16x2 LCD display. The connection map between the Raspberry Pi and 16x2 LCD display were already established in earlier testing so only the connections between the MAX485 TTL to RS-485 interface module and the Raspberry Pi must be remapped. From the Raspberry Pi 3 GPIO pinout we can see the Receiver output will connect to GPIO15, Receiver Enable and Driver Enable can both connect to any of the GPIO pins and driven high, and the Driver Input pin can connect to GPIO14.
​
Once all the connections were made the code to interpret the data received by the sensor and display it onto the LCD display must be written. The above example with the Arduino Uno and OLED display came with source code to run the sensor but since we are using different components the code must be reworked. This is where Deven ran into roadblocks as he was unable to successfully rewrite the code to run on the Raspberry Pi.
​
Writing working code to successfully interpret the NPK sensor data and display the information on the LCD display will be the first priority going into the next week of the project.
Jon (8.5 Hrs)
For this week I was responsible for continuing to implement the necessary functionality to meet the criteria of our design requirements and specifications. While implementing the these functionalities, further research was done on the 7.0" TFT display listed in our budget. I was also responsible with implementing and coding the pumps and fans as they are scheduled to be delivered this week.
​
Due to shipping issues with the pumps, fans and moisture sensors, the components are still in transit and should arrive Saturday, Sep 7th. Although the pumps, fans and moisture sensor could not physically be tested this week, I was still able to write the code to have each of the components functioning. Once the components arrive, I will simply wire each to the Arduino and copy/paste the code directly into the IDE. The code shown below is a screenshot of code used to simulate the pump, fans and moisture sensor in Tinkercad.
Water Pump, Moisture, Fan, DC Motor Tinkercad Code
The simulated construction of the water pump, fans, moisture, and temperature sensor can be seen below. In the physical connections, not only will the relays be used, but a dc converter will be used to lower the voltage from the 12V source to a 9V 1.5A current and voltage flow. As simulated the relay should only pass current from the 9V source to the dc motors only when a 5V signal is received from the Arduino.
Tinkercad Pump, Fan, DC Motor, Moisture sensor Simulated connection
Alongside simulating the above components, I have done further research on the 7.0" TFT Display. In my research I have found that we have made a mistake in assuming the TFT display will connect directly to the Arduino. Our Arduino is capable of many things including operation of a TFT display for certain resolutions. That being said immediate research was done to hopefully find a component that can interface with a 7.0" TFT display. Little information can be found on integrating such a high resolution display. Usually Arduino can manage displays 10" and lower due to the refresh rate the Arduino would have to output to efficiently display graphics on the display. Eventually I came across a component called the RA8875, that is essentially a driver board for interfacing a 40 pin TFT display. For the same display size, Arduino's can be interfaced with shields that make it easy to interface with displays by connecting straight into a Arduino. For our purposes, a driver board would be ideal. The RA8875 seen below is capable of taking a 40 pin FPC cable straight to the board and wiring the SCLK, MISO, MOSI, DC, SS, and RESET to the Arduino. Each of these connections make up the Serial Peripheral Interface (SPI) and each are specifically wired to a designated pin on the Arduino.
Photo of RA8875 Driver Board from adafruit.com
To wire RA8875 to the Arduino, I found a helpful article on the proper wiring needed to communicate with the display. The article explains the following:
​
-
"3-5V Vin connects to the Arduino 5V pin
-
GND connects to Arduino ground
-
SCK connects to SPI clock. On Arduino Uno/Duemilanove/328-based, thats Digital 13. On Mega's, its Digital 52 and on Leonardo/Due/Metro M0/M4 it's ICSP-3 (See SPI Connections for more details)
-
MISO connects to SPI MISO. On Arduino Uno/Duemilanove/328-based, thats Digital 12. On Mega's, its Digital 50 and on Leonardo/Due/Metro M0/M4 it's ICSP-1 (See SPI Connections for more details)
-
MOSI connects to SPI MOSI. On Arduino Uno/Duemilanove/328-based, thats Digital 11. On Mega's, its Digital 51 and on Leonardo/Due/Metro M0/M4 it's ICSP-4 (See SPI Connections for more details)
-
CS connects to our SPI Chip Select pin. We'll be using Digital 10 but you can later change this to any pin
-
RST connects to our Reset pin. We'll be using Digital 9 but you can later change this pin as well.
-
INT connects to our Interrupt pin. We'll be using Digital 3 but you can later change this pin too."
​
After wiring the driver to the Arduino, a simple can be done through the Arduino IDE built tests. The first test that can be done will test to see is the board is correctly communicating with the Arduino by displaying the correct driver and resolution of the board. The second test will display various shapes on the display if done right. The following website and videos was used as reference to conduct the tests.
​
Lessons Learned
This week, Deven made progress by completing the frame construction and beginning work on the NPK sensor but faced challenges integrating the sensor with the Raspberry Pi. The instructions and sturdy materials for the frame highlighted the importance of good documentation and quality components. Testing the LCD separately before full integration showed the value of verifying individual components to simplify troubleshooting. However, Deven struggled with adapting code from an Arduino to a Raspberry Pi, emphasizing the complexities of porting code between different platforms. Jon experienced delays due to shipping issues but used simulations to develop and test code for pumps, fans, and moisture sensors. His research into the 7.0" TFT display revealed that direct Arduino integration was impractical due to resolution limits, leading him to find the RA8875 driver board as an alternative. This underscored the importance of thorough research, adaptability, and exploring alternative solutions in engineering projects.
Design Week 1 : 8/22 - 8/29
Total Hrs - 39.5 Hrs
Group (5 Hours)
During this week the group met and discussed who would be be responsible for the ordering and testing of which components. There was in-depth discussion on the pros and cons of myriad of options on which off the shelf frame to buy before ultimately settling on the option highlighted below. The team began working on the coding and testing of the sensors that will be used to monitor system conditions, and the website was updated to reflect the groups transition to the design phase of the project.
Deven (12 Hours)
During this week Deven worked on the functionality of the NPK sensor, water pumps, cooling fans, and updating the design tabs of the website. Deven also weighed different options for the housing unit after taking into consideration the review panels suggestions of purchasing a ready made unit instead of building one from scratch.
​
After visiting Skycraft, a local spare parts store, and finding no suitable option for a housing unit one was purchased online. The group decided an aquarium tank stand would be an adequate option as it fulfilled the Design Engineering Requirements (DER) outlined in the proposal phase. The key deciding factors were the size, shape, and weight of the stand. The chosen stands dimensions were close to what the group planned to build before considering an off the shelf option and was light compared to the other options on the market, weighing only 26 lbs. versus the often 35 to 45 lb. seen in comparable models.
40 gallon fish tank stand chosen to serve as the NurtureNest frame
Deven also acquired and tested the water pumps that will be used to irrigate the system with pure and fertilized water. The system will run the pumps for a set amount of time once the moisture levels drop below a threshold. Testing was required to determine the amount of time a pump would need to run to saturate the soil without releasing excessive amounts of water and flooding the system. To conduct this testing Deven took one of the trays intended to be used in the system and filled it with dry soil. Then a measuring cup was used to count the amount of cups required to fully saturate the soil.
Soil Saturation Testing
Once the amount of liquid required to saturate the soil was found, four cups, the flow rate of the pumps must be tested, then we could finally determine the amount of time a pump must run to properly irrigate a tray. The pumps were placed in water and the output led to a measuring cup so the flow rate could be visually determined.
Water Pump Flow Rate Testing
Deven's testing found that the pumps could output the necessary four cups of liquid in 30 seconds. This information will be untilized when coding the irrigation logic on the microcontroller.
​
Deven also received the NPK sensor package during this time. Once the RS485 component package is delivered testing of the NPK sensor will begin. Although the NurtureNest will be built around an Arduino Uno microcontroller, Jon is currently using it for testing his components. In the meantime Deven will use a Raspberry Pi 3 B+ and a 1602A LCD display to test the NPK sensor. The NPK sensor will output TTL signals to the RS485 which will then be interpreted by the microcontroller and finally be visualized on the LCD screen as shown in the example below.
EXAMPLE: Complete NPK Sensor Circuit
Credit: https://how2electronics.com/measure-soil-nutrient-using-arduino-soil-npk-sensor/
Deven's components are shown below, sans the RS485 that is still awaiting delivery. Also included in the components are the cooling fans that will be integrated into the system to simulate wind, promoting stem thickness in plants grown within the NurtureNest.
Deven's Raspberry Pi 3 B+, 1602A LCD, and Soil NPK Sensor
Deven also updated multiple website pages including the Design Engineering Requirements (DER) and Design Engineering Specifications (DES), the weekly minutes with the professor, the time and effort table, and the finalized budget.
Compilation of website pages updated this week
Jon (22.5 Hrs)
This Week I was responsible for wiring and constructing the Water level sensor, moisture sensor and updates to the dsenior design section of our website. To begin the the sensors were first simulated in a program called Tinkercad. Tinkercad is a Arduino based simulation program where you can wire various circuits and produce 3d models before physically constructing the circuit. For reference I found videos explaining how to wire, the moisture, temperature and water level sensors. Below is the video referenced to simulate the moisture sensor.​
Moisture Sensor Software and Configuration
Although research was done to implement the moisture sensor to the Arduino, physical constructing was halted due to a shipment problem. Despite the small setback, wiring and coding the moisture sensor to the board should be relatively simple because it does not require and extra libraries and outputting data can be done with a few lines of code. Similarly, the temperature sensor was also researched. The temperature sensor is similar to the moisture to output data but, the temprature requires the use of downloading a third party library. The temperature sensor is actually a 2 in 1 sensor, operating with a humidity and temperature sensor. Below is the information found on he temperature/humidity sensor.
Temperature Sensor Software and Configuration
From my research, I was able to simulate the moisture, temperature sensors and even the dc motors. The simulator also allows coding to completely test the functionality of each component. Tinkercad has various components to simulate at your disposal but it only provides you with the basic or most popular components. Since the program didn't have a component for a water level, I left it out of the simulation and simulated the moisture, temperature and dc motors. Although the water level sensor is not simulated in the Tinkercad, the sensor is relatively easy to physically wire and code as it does not require any extra libraries. To indicate when the moisture and temperature has reached a threshold to perform a certain action, I used LEDs as an output.
​
The dc motors were also simulated by using a H-bridge (L293D). The H-bridge acts as a controller for the dc motors and not only manages the speed but also manages the direction the dc motors are turning. In Tinkercad, they simply have a TTL L293D to use on a breadboard, but when physically constructing the dc motors, each will have PCB board motor controller that essentially uses a H-bridge to mangage the directions. Research was done to find out the proper way to implement to the H-bridge to the Arduino. Below is the information referenced for its simulation along with the results of simulating all three components.
Tinkercad Simulator and H-bridge configuration
Simulating code in Tinkercad works well when getting an overview of how each component outputs data. For components that dont require and extra libraries/dependencies, each can be easily coded using basic key words from the Arduino library itself. Seeing how some components like the NPK sensor require a specific library to output its data, its important to note for the rest of our sensors. The above tinkercad simulation is modeling a simply temperature sensor and does not need and libraries to output data. The code for the temperature and moisture sensor can be found below.
Tinkercad Moisture and Temperature Code
Now that the circuit has been simulated, I began constructing the circuit on the physical Arduino board. I wired both the temperature/humidity sensor exactly how I simluated it in Tinkercad. I first wired the Arduino 5V to the positive side of the breadboard, followed by the ground to the negative side. I then wored the positive and negative end of the moisture sensor respectively to the breadboard. The analog signal was wired to pin A5 of the Arduino. Similarly to the moisture sensor, the temperature sensor was wired to the breadboard respectively to the power and ground. the analog signal was finally wired to the pin A4 of the Arduino. Similarly to the Tinkercad code I copied and pasted it into the Arduino IDE. After double checking connections the board was connected to the computer and compiled. From the beginning there were error is the code. The moisture sensor was producing the correct values but the temperature sensor was not. I conducted further research to identify the problem and came across this information.
​
https://www.instructables.com/How-to-Use-DHT11-Temperature-Sensor-With-Arduino-a/
Temperature Sensor Configuration Blog Post
This website explained that I have a three prong model temperature sensor that has the capability to output humidity data. It also explains that this sensor requires a special library and a slightly different wiring configuration. In order to properly wire the specific temperature sensor model, I had to move the Analog signal pin A4 to input/ouput pin 2. I was also required to download a third party library/dependencies which can be found in the link provided above. This reference source was the third source that had a functioning library for the sensor. Below is the configuration and coding that was implemented to produce the results thus far.
Temperature and Moisture Sensor Configuration (Bench)
The moisture sensor when dipped in water provides a accurate output as the sensor is dips deeper in the water. The temperature sensor was a more challenging to code because the sensor outputs in celsius and needs to be converted. Using the equation F = (C *1.8) + 32 was used to convert the output value. Although the sensor is outputting data, it does not seem to be outputting the right values in reference to the Fahrenheit conversion. The resulting code and output of the moisture and temperature sensor can be seen below.
Arduino IDE Temperature and Moisture Sensor Code
Other than the wiring, coding and testing done on the temperature and moisture sensors, the team website was also updated. I was responsible for revising the proposal and design page tabs final proposed diagram/renderings, timeline & schedule and progress log. For the final proposed diagram/renderings I simple added the renderings and our dimensions.
Final Proposed Diagram/Rendering Revisions
For the timeline & schedule, revisions were necessary as instructed by Professor Notash. I edited the scheduled task by removing the Schematic designs task, Fixed the timeline to all weeks, fixed the corresponding dates for each task to reflect the deadlines given to us by the professor and lastly changed the color of the chart to match primary website color.
Timeline & Schedule Revisions
The time & effort table and progress log also needed revisions. The time and effort table were edited with the hrs worked per day for a given week and the progress log was updated with the total hrs respectively worked for a given week. Below are the results of the revisions.
Progress Log and Time & Effort Table Revisions
Lessons Learned
This week there were several important lessons about managing a project. First, it’s important to evaluate all available options before purchasing components. The team’s decision to choose an aquarium tank stand for the housing unit, rather than building one from scratch, was due to the size, weight, and cost. Additionally, using simulation tools like Tinkercad proved invaluable. These tools allowed the team to test and simulate designs before physical construction. It showed potential issues early, saving time by successfully simulating the moisture and temperature sensors. The integration of sensors and components highlighted the importance of ensuring compatibility with the microcontroller and required libraries. For instance, the temperature sensor needed specific wiring and a library, which required additional research to resolve. Testing was also critical; accurate performance of components, such as water pumps and sensors, needed to be accurate through testing sensor outputs to ensure the system functions correctly.