Smart[er] Irrigation

In my last post I talked about the irrigation controller I have been working on for my parents farm.  The project is still a work in progress due to having problems getting a reliable cell signal out on the farm.  I’ll definitely be writing a post soon that gives more detail about where that project currently is at.

While working on the irrigation controller, I was thinking that the system could be greatly improved by using soil moisture as a metric for watering.  With the current design where a remote user is able to dynamically schedule waterings, the user must also pay attention to weather conditions to make informed schedules.  Getting real time data back to the user would help aid in schedule making.  Ideally, the user wouldn’t even need to worry about scheduling, instead specifying a rule-based system where waterings occur until all sensors are in a nominal range.

One of the classes I decided to take for my last semester is Electronic Systems Design (EE 333) taught by Dr. Gary Tuttle.  For this class we are able to choose two projects to work on over the semester, creating a schematic and placing it on a board.  The first project is an analog soil moisture sensor, which I’ll write a post about once the boards arrive and are populated.

The second project is for EE 333 is much more challenging and the main subject for this post.  I decided to tackle creating a soil moisture that fits the application I described above.  To make a successful sensor, I determined it must be completely wireless.  This means the communication must be through some wireless protocol and the device must also be charged with solar energy.  I have been a long-time fan of the ESP32, so it only seemed like the natural choice for this project.  I have used the ESP32 before with MicroPython installed on the Pycom FiPy dev board.  I wanted to go lower level this time, so I decided to use the ESP32-WROOM module and use the ESP-IDF to program the board in C.  One of the highlights of the ESP32 that makes it a great fit for the MCU is ESP-MESH, which is a mesh network API Espressif has developed.  ESP-MESH is built on top of WiFi and seems pretty straight forward to work with.

For the first project, the circuit measures the resistivity of the soil with two electrodes placed on the bottom of the board.  While this method works, the electrodes will become corroded after prolonged use and would require the whole board to be replaced, which would be costly.  I have done some research and found that capacitive soil moisture meters are longer-lasting and potentially more accurate.  Capacitive soil moisture sensors work by measuring how the soil’s dielectric permittivity affects the fringe field created by a capacitor traced out in the circuit board.  Since the traces are insulated from the soil, the sensor won’t corrode or oxidize.

Back to the ESP32.  One of the other highlights of the ESP32 is the capacitive touch pins.  Basic testing I conducted showed that the capacitive touch pins can be used to measure the permittivity of soil.  In the picture above you can see my test environment, which consisted of an ESP32 DevKitC, which I have been prototyping with, and a crude capacitive soil probe.  The soil probe is two insulated copper plates placed on each side of a wooden steak, with one wired to ground and the other wired to a touch pin.  There was a noticeable difference in the value of the pin as I placed it in wet soil vs dry soil.  If the difference is enough to accurately measure moisture content is still a question, but it looks like I will definitely be able to calculate an approximate level.

This week I started developing the schematic and writing the code for the ESP32.  I also created a page on  I will be posting there more often with updates and will write another post for this website once the project is finished, or at least at the end of the semester.  The circuit schematics will be posted on the hackaday project page and the code can be found on my GitHub account.

GitHub Page Page

Smart Garbage Management

This fall I became involved with a team of four other computer engineers and one electrical engineer to begin development on a project for our senior design class, the final test of our engineering skills before graduation.  Our project is to design a smarter way to collect municipal garbage.

The standard model of garbage collection has not significantly changed over the past decades.  Most residents have one set day of the week where they leave their garbage bin on the curb and a collection service empties the bin into a garbage truck.  This is repeated for a set route of houses before the truck is full, where the truck then travels to the dump and empties its contents.

With Americans in the United States generating 252 million tons of trash in 2013, we want to design a system that can create a paradigm shift for garbage collection.  What we have proposed is to develop a smart sensor that can be quickly retrofitted to the standard ~90 gallon municipal garbage container.  This sensor will be able to keep track of the garbage levels inside the garbage bin, which will then be relayed over a low power wide area network (LPWAN) to a central server where the each resident’s garbage levels are stored.  This will allow the garbage company to generate optimized collection routes where trucks can be filled in the minimum amount of distance, thus maximizing collection efficiency.

This project involves full-stack development of an Internet of Things (IoT) solution.  I have assumed the role of embedded systems software development in the project.  The lone electrical engineer involved in the project is in charge of the hardware design for the sensor package.  I also am working closely with another member on the team who is in charge of the networking of the IoT devices.  The other three members are in charge of the database, application, and algorithm development.  I am excited to see what we end up using for the route optimization algorithm as the computational complexity is equivalent to the infamous traveling salesperson problem.

Our final prototype for this project is expected to be delivered in December.  Keep checking on this website to see future updates on this project.

Single Cycle and Pipelined MIPS Processors

The Computer Organization & Design class I took at Iowa State was without a doubt the hardest lab-based class I have taken at Iowa State University.  That is not to say that the material taught was difficult to learn, but that the labs were incredibly complex and required a lot of time and effort to complete.

This was the first class that I had taken where I used VHDL.  We spent maybe two labs learning how to code in VHDL and then moved on to creating actual processor parts immediately.  For the second half of this class, in groups of two, we built two fully functional 32-bit processors that were designed to implement 45 instructions out of the MIPS ISA.  The first processor was a single-cycle processor, while the other was a pipelined processor.  Personally I thought both were very hard to build, but some of the difficulty may have stemmed from the fact that I coded 80-90% of the projects.

Both of these processors were completely built from scratch with VHDL.  The ALU was built by myself, which could shift, add, subtract, multiply, plus comparator & bitwise operators on both register values and an immediate.  The processor also had a separate ALU that was used exclusively for conditional branches.  I included a diagram of our completed processor below.

32-bit single-cycle MIPS processor

After building the single cycle processor, we moved on to breaking this processor up into modules that could be used with a pipeline processor.  Our pipeline processor was fairly similar, with the addition of registers between each stage in the pipeline that would hold values.  These registers were controlled with logic modules that would check for data hazards or stalls and make necessary adjustments if something was detected.  Most of the data hazards that we needed to prevent came from forwarding data from later stages to earlier stages if a new value for a register address was needed for an operation.  Due to the time needed to build the assignment and the project’s instructions, we were not able to implement forwarding and hazard detection for branching instructions, and would stall the processor instead.  A simplified diagram for this module is given below.

32-bit pipelined MIPS processor

Despite the difficulty of this class, I really enjoyed taking it and definitely would like to work with VHDL again in the future.  It really felt good to have a working 32-bit pipeline processor at the end of the semester that my teammate and I built from the ground up.  Even though these projects cost me many hours that I could have spent sleeping, I feel like building these processors was one of my greatest achievements at Iowa State.

Due to the fact that these projects are still being assigned at Iowa State, I’d prefer not to leave my code online.  However, if you are not a student at Iowa State, feel free to contact me by any means if you’d like to see my code!

IR Remote and Receiver

In EE230, Electronic Circuits & Systems, we were assigned two projects in the semester.  Both projects were centered around active and passive filters.

The first project involved designing and building a three-channel crossover network for audio.  The low-pass channel needed to have the ability for the user to be able to increase the amplitude of the signal, or drop the bass.

The second project was slightly more complicated, where we were asked to build an analog infrared transmitter and receiver that would be capable of sending two different signals.  In demonstrate the correct behavior of the system, each signal would light up an individual LED.

Our design was fairly simple.  For the transmitter we used two op-amps on an LM324 for two oscillators, with one oscillating at 1 kHz and the other at 20 kHz.  Two switches would output the signal from the oscillator through an infrared LED.  A circuit diagram of the transmitter can be seen below.

Infrared transmitter circuit

For the receiver, an infrared photo-diode was connected between an op-amp terminal and the negative voltage.  Because the output from the photodiode was very weak, one op-amp in the circuit acted as a preamplifier for the high and low-pass filters that separated the input for each LED. To determine what LED should be lit from input, we used a high-pass filter to block the 1 kHz signal to one LED, while a low-pass filter blocked the 20 kHz signal from the other LED.  The single-order active low-pass filter was designed with a corner frequency of roughly 2 kHz and a 0 Hz gain of 10 v/v.  The output from this filter was sent to an AC rectifier, where the DC output was passed to a small resistor and LED. For the 20 kHz signal we decided to build a second-order filter with an infinite frequency gain of 10 v/v and a corner frequency of 10 kHz. The output from the high-pass filter was passed to a non-inverting amplifier of 10 v/v before being output to the other LED and small resistor.

This was the second circuit class I have taken at Iowa State in a planned sequence of three.  Circuit design and analysis are two skills that I have really enjoyed learning.  The skills have proven to be very useful on personal projects and also in a past co-op.

A video of the final solution for the project is shown below…

Embedded Systems Robot

This is the start of a series of posts where I will write about past projects that I have worked on both through school and though my own free time.

I thought I would start with the final project from one of my favorite classes, Embedded Systems.  The structure for the labs in this class was really well done, where each lab gave my group experience working with each element of what would become our final project.

The robot we worked with was an iRobot Create with a custom microcontroller board developed at Iowa State University.  The iRobot was controlled by an ATMEL ATMega128 AVR processor.  The robot was coded by flashing C code to the processor with an AVRISP module.

Throughout the semester we learned how to use the features of the AVR processor to work with various components.  Some examples for our labs included controlling the movement of the roomba, controlling a servo with PWM, reading data from both an ultrasonic & infrared range finder, and communicating with serial over Bluetooth.  Most of our knowledge of the ATMega128 processor’s functions came from reading the processor’s datasheet, while the lectures discussed concepts, like how PWM works.

Completing all of our labs led us to our final project, which was to make the iRobot remotely traverse an obstacle course to park in a specific square area.  Our group was forbidden from looking at the course before the robot was placed in a random spot on the course.  Our only way to navigate the robot was by using the various on-board sensors.  One of the members in our group developed a custom GUI through visual studio that handled displaying the data collected from the robot.  The client interface also allowed us to control the robot with an Xbox 360 controller.  At the bottom of this post is a short video of our robot in action.