Embedded Systems 2016

On Closure

This past Monday we were able to print our board using the CNC machine. I drove the machine this time and it refreshed all of my knowledge on the software. Dr. Jadud and I updated the instructions to make them easier to follow when controlling the machine. On Wednesday, we soldered together all of  the components as a group with Michael leading us. When all of the components were soldered, we tested the connections with the multimeter to make sure only things that were supposed to be connected were. We corrected all of the short circuits (caused from soldering) that we found). We left class on Wednesday ready to alter the code and test our board.

Today (Friday) we (the fritzing team) got together with the architecture group to upload the code to our board. We planned on testing each of the sensors and then the wifi chip to make sure that they were all working. Unfortunately, the sensors were failing to read. At this point, we connected back to the breadboard setup and tried to recreate our scenario of using a digital pin to power the sensors. While the breadboard was working when we used VCC to power the sensors, it was not working when we powered it from pin 8.

At this point, we pulled out our handy multimeter to test the voltage that each pin was giving off. The actual power pin (VCC) from the arduino read at about 4.8 volts, the digital pin that had been written high was giving off around the same. This didn’t make any sense to us because it should work in theory. Defeated, we did what any computer scientist would do and googled the issue. We came upon an arduino forum that said that even though the pin seems to be reading that high, it cannot actually provide that amount of current. This means that our new board will not work. We would have to connect the power pins to the actual VCC pin on the arduino.

This is a setback since today is the last day of class. Fortunately, the architecture group was able to get the code working correctly between all of the components. We will continue to work on the board (if we have the exam time). If not, we have all of the documentation emailed to the person in charge and it should be relatively easy for anyone to pick up where we left off.

Not the Final Fritz

In the last blog I expressed wishful thinking in that the board that we printed would just work. As the norm is with hardware, that was not the case. The board that we printed had several issues. The main being that we had designed the board in fritzing as if we were plugging components into the bottom (copper) side of the board. This means that the entire board was flipped (in the y direction) to what it should be. The way to fix this will be to flip the board using the tool inside the CNC machine software. Fritzing gives no easy way to do this, so the CNC software will be much more effective.

The other problems were that we had incorrectly placed our resistor. The correct placement of the resistor is between the power pin and the readout pin on the DHT sensor, so that the resistor can act as a pull up resistor to the power. We are planning on writing a digital pin HIGH to send the voltage to the sensor. Therefore, instead of the sensor power being connected to the VCC pin on the arduino, it will be connected to a digital pin and controlled through the code. The sensors were also wired opposite of each other, so we need to make them consistent for our sanity.

Lastly, there was some issues for the Wifi chip. There were questions about which way that it was connected to the board (orientation wise), and although RX, TX, VCC, and GND were correct, the other pins (GPIO_0, GPIO_2, and CH_PD) were all question marks to us. It turns out that these pins should all be connected to power to avoid floating pins (although they can be left floating, it is better to have them written HIGH).

We have redesigned our board to accommodate all of these changes (barring the flipped board because we will have to do that when we print the board). The way that I did it was by only working in the PCB tab of fritzing rather than the breadboard, and deleting any ratsnest wires in the schematic tab. It makes so much more sense now as I can explain each and every one of the connections. The only concern that I have is that we have not tested whether or not a sensor can be powered from a digital pin. In theory, there should be plenty of current for the sensor, however, since we do not have a working prototype this worries me.

In the meantime, we have created and presented our posters for the Service Learning Expo at Berea. We did not make a Fritzing poster because it is such a small part of the project. Instead, I focused  on the WiFi poster (which was my original group). This allowed me to talk about both the ESP8266 and the PCB because I was  able to stand in front of the “generic” poster for the PCB. It was a great experience overall and I am excited to reprint and test our board and see whether or not it will work.


The Final Fritz

Today we were able to cut our circuit board (YAY). We had to download the software onto a computer that Nick had set up before class. Dr. Jadud was then able to walk us through the setup of the CNC, and we uploaded our gerber files that needed to be cut. We watched as the machine routed our connections and drilled the holes for each of the components. We declined to do a rubout because our board had such clean cuts that we didn’t want to risk ruining it (since this is the first time that the CNC has been ran since the last machine running it died). This meant that we would have to solder in our connections very carefully.

After it was cut, it was pretty much the end of class, but I was so excited to get this working that I stayed an extra 2 hours and soldered all of the connections. At this point I realized how incredibly difficult it is to solder inside of a tiny diameter circle. I had to then pull out the multimeter and figure out exactly what was connected that was not supposed to be (and it was a lot). At this point I took an exacto knife and was able to separate the connections from one another until everything was only connected to what it was supposed to be connected to. i put headers in for everything so that we could plug in and remove components.

I am extremely excited to test out the circuit board but also worried because nothing ever works on the first try. However, I was recently informed that since all of the code was combined in the classes, it has not been working correctly. This means that we cannot test the board until we are able to get the code working.

Here is an image of the board being cut:


The Fritzing Continues

Today in class we finished all of the breadboard connections in Fritzing and we finished organizing the connections in the PCB tab. This means that we are ready to print the board as soon as we get a machine that runs the CNC up and running. The main thing that differed in the setups from the groups was that for the sensors (the DHT11 and DHT22) we connected their power to pins on the arduino mini because they use such little power that writing a pin high is more than enough for power them to be able to work.

The breadboard setup looks like this. We had to use headers instead of the sensors and instead of the wifi chip. They are all on separate breadboards because this makes it easier for us organizationally, and the PCB view only sees it as one breadboard which is helpful for us. The sensors each have a 10k current limiting resistor. The wifi chip no longer has a pull up resistor because we are able to control the amount of power that it is getting.


The PCB tab is a little bit more discreet in its connections. However, it is the same as the breadboard view, but neatly organized so that we can use it as an outline to cut our actual board.


You can see that we have one jumper and we are also using one of the resistors as a jumper. The placement of the sensors is going to be important (each being on the end) when designing the case that this sensor will be inside. The last thing that we need to do is cut the board.

The Fritzing Begins

Since the wifi group is in the process of wrapping up our work, I figured that it was a good time to join a new group, the Fritzing group. Our job is to take the mess that is the breadboard setup of all the components and neatly condense it onto something resembling an arduino shield. A few summers ago I had a brief experience with working to create printed circuit boards, and it was so rewarding to see through to completion. There is just something intriguing about untangling connections and then actually seeing the board being printed.

Fritzing is an open source tool that you can download to create breadboard diagrams, schematics, and the blueprints to a PCB. Dr. Jadud has a CNC machine in the lab and the software that runs it accepts gerber files, which is an option when exporting files in Fritzing. This makes it an optimal solution for students wishing to create printed circuit boards. It is also relatively easy to use, coming with many predefined parts and allowing you to create your own if necessary.

You can get started by connecting all of the components in the Breadboard tab. You can add resistors, batteries, arduinos, wifi chips, sensors, almost anything that you can find online (on a website like adafruit). After you have made the appropriate connections, you can go to the PCB tab and begin to solidify the connections and their placement on the board. Today in class we begin by gathering the exact connections from each of the groups (wifi and sensing) and began to model them in the Fritzing software. Next class we will begin untangling the mess of connections.

Pine Mtn Cancelled

There was sad news on Friday that the trip to Pine Mountain was cancelled for the third and final group. This was a combination of the van not being available due to brake problems (even though it was reserved months ago), and there has been an outbreak of forest fires near Pine Mountain due to the dry weather conditions. Since the group had already reserved their time for the field trip, Dr. Jadud asked that they consider coming in on Saturday to do work sprint and see if they could try and pull the components of the sensor closer together.

Unfortunately I was unable to go to the work sprint (as I was in PMSS group 2 and I already had plans for Saturday). However I did talk to Javier and he told me what was accomplished. The work was focused mostly on creating classes for each of the components, and Javier contributed to the wifi class which can be found on Kye’s github. The next steps are going to be to integrate the class into the main code functionality and see if we can get all of the components working together. It seems that the wifi group’s tasks are slowly coming to a close and the last thing that we will have to do will be to focus on a poster and help contribute to the project as a whole integrating each specific part.

ESP8266 “Get Request”

The last time that I wrote, the wifi team had been struggling with where and how to send our data since we were no longer using dweepy. We had just launched our flask app on a raspberry pi that modeled a web server that we could send data to. The code that we were interested in using for the arduino was from an instructables and it was using an http post request instead of a get request. This was our main problem. Javier and I stayed after class today to work with Dr. Jadud and try and sort out the issues that we were having.

We knew that our send data function would have to take in the data struct that would be sent to us from the sensing team. This struct contained a key, tag, and value that we would need to send to the server. After inspecting the post request Dr. Jadud realized that it would only take a slight change to make our code work. Since he was familiar with the structure of Get Requests (the protocol), we were able to make the changes necessary in order to actually send our data. Because we were manipulating the uri to send the data using a get request, we stored the data.key, data.tag, and data.value inside the uri in their respective cases. We were monitoring any “pings” from outside machines to our flask app on the raspberry pi. At first we were unsure of what we were seeing, but after we changed the values inside the uri, we could see that we were making connections with the raspberry pi every time that we ran the code (or sent the get request).

The main part of our code looks like this:

  • First we make sure that we have a TCP connection to our server
  • Then we define our uri from the data struct:
    • String uri = “/” + data.key + “/” + data.tag + “/” + data.value + “/”;
  • Then we define our get request based on the correct protocol
    • String getRequest =
      • “GET ” + uri + ” HTTP/1.1\r\n” +
      • “Host: ” + server + “\r\n” +
      • “Connection: close\r\n” +
      • “\r\n”;
  • Next we send an AT command stating that we will send data and of what length
    • String sendCmd = “AT+CIPSEND=”;
    • esp.print(sendCmd);
    • esp.println(getRequest.length() );
    • delay(500);
  • Lastly we use the println() function to execute the get request
    • if(esp.find(“>”)) { Serial.println(“Sending..”); esp.print(getRequest);

We also finally figured out the breadboard setup that we need to follow and Chris has designed a diagram in fritzing to show the connections. We connected tx and rx to specific pins instead of the tx and rx on the arduino because we want the arduino to actually communicate with them rather than us communicate with the chip through the arduino ide. The setup looks like this:




We were able to get the Flask app up and working on our raspberry pies, and we were able to access the url with different data using our laptops. This was done with the aid of Dr. Jadud who provided the code for us here.

To access the app on the raspberry pi that it was running you go to (data can be anything):


To access the app from a laptop you have to do an ifconfig to find the IP address:

Now the trouble is that we need to send data to this url.

The code that we have found to do this is a bit complex, but basically it starts a connection with the server, uses the esp.println() function to send the AT command that sends the data, and sees if there is a response from the server before closing the connection. The struggle for me is that I am not sure if we need to use the send data funciton if we are simply posting the data in the url. I guess, in short, I do not understand how accessing a url with different information in the spots for data is going to translate into using the AT “send” command.

There is an example of how to send data to a website at this instructables. We have been trying to follow this tutorial somewhat, but we have not had luck thus far. I was able to redownload the Arduino IDE and it will now connect to the Diavolino and upload sketches. However, we are setting up more of the breadboard connections that I posted a picture of in the last post, and that is proving to be troublesome as they don’t all work the same. Hopefully we can pull something together next week, as the next group is going next weekend.


The ESP8266; Exploration

We were able to communicate with the ESP8266 via a computer! We used the serial monitor on the Arduino environment to see if the chip would respond. The first command that we sent was AT? (which checks to see if you have communication), and the chip responded OK. Next, we were able to connect it to the internet using AT commands. One possible problem is that we are only going to be able to connect it to BereaGuest and not BereaSecure, because BereaSecure requires a username and a password, and there is no way to add both when connecting to the internet.

Our setup looked like this:


Sidenote: I am going to have to re-download the Arduino IDE because my computer refuses to connect.

The next thing that we tried was using the software serial library to connect:

#include “SoftwareSerial.h”
String ssid =”BereaGuest”;

String password=””;

SoftwareSerial esp(9, 10);// RX, TX

void connectWifi() {

String cmd = “AT+CWJAP=\”” +ssid+”\”,\”” + password + “\””;



if(esp.find(“OK”)) {



else {


Serial.println(“Cannot connect to wifi”); }


This allowed us to connect the chip to WiFi through our code. It was a really exciting moment. The Software Serial library is using the esp.println() function to actually send the AT commands to the chip. It then checks for the chips response with the esp.find() function.

The part that we are now stuck at is where to send our data. We are no longer using dweepy, and we need a place to send it. We talked to Dr. Jadud and he tried to explain to us that we want to send our data inside the URL:


This way, the dashboard group just unpacks the URL to receive our data. The next step is going to be to set up the flask app to actually send that data to.

Blog at

Up ↑