History Part 4

This is my fourth and final post summarizing the work I did on the SharkDuino project before the creation of the blog, the first three parts can be found here.

This post will cover the work I did during the fall semester of 2015 and winter break. This post will be a little a shorter than the previous ones since this project went on a small hiatus during the fall semester for me to focus on school work. At the beginning of this semester we decided that we should start to create prototype sensors to begin getting preliminary data with. To do this we needed to create versions of the system off of the breadboard. To save money we decided that we would remove the pins on the set of components we had been working with so that we could reuse them in the prototype sensors. This sounds easy enough in theory but in practice it is difficult to desolder to remove the pins of the breakout board and ended up taking me quite a long time to do. Once I finished desoldering I then tested the components to find out if I had broken them during the process. I did end up ruining the micro SD reader while desoldering by accidentally removing the solder plates needed to make new connections to the board. Overall this process was long and painstaking, and worth it for some of the pricer components, such as the pressure sensor, but for the cheaper components I should not have bothered and just bought fresh ones.

Once all the components had the pins removed it was time to solder them together with wires. To do this first board I simply layed out all of the components on a piece of cardboard and cut holes in it, essentially creating a solderless breadboard. I then connected the components together with wires, splicing when I wanted multiple components to connect to the same pin on the Arduino. The results of this can be seen below, it’s not pretty but it worked.

The first version of the device

The first version of the device

After I finished soldering the device together everything did not immediately work. I started by first uploading a blank sketch the the Arduino to confits that it could connect to the computer. I then ran code to test all of the components individually and found that the accelerometer and temperature sensor were working, but the SD reader and RTC were not. After some long hours going over all the connections with a multimeter I was able to eventually identify some cold solder joints and repair them, once I did this the SD card began to work the RTC still was acting funny. After a little bit more troubleshooting I found that the battery one the RTC had died, I replaced that then got more normal behavior from the RTC when it was used alone.

Now with the hardware working it was time to get to work on the software. I found that all of the components would not work together properly. The SD would work with the accelerometer and temperature sensor, but once the RTC was added the SD card would break. The cause of this problem and my solution to it are the topics of my first weekly update.

This brings me up to when this blog began and I began posting weekly about the nitty gritty of the project. In this series I tried to give an overview of the work done without getting too bogged down in the details, but in doing so I am sure I left out some important information. If anything else of importance comes to mind, or I find some lost notes I will be sure to post about it. Regardless I hope this series has been informative about my early work on this project and provides useful context to the work being done now.

History Part 3

This is the third part of my ongoing series outlining the work done on this project before the creation of this blog, the first part can he found here, and the second part can be found here.

In the last post I left off when I was about to move from the Arduino Uno R3 to the 3.3V Arduino pro mini. This went springing smoothly. I soldered pins onto a pro mini, then plugged it into the breadboard and rerouted the wires from the Uno to the pro mini. I then uploaded test code for each individual component to the pro mini to make sure everything was wired correctly and working independently, and it all worked. I then tried code that used everything other than the RTC together and that worked as well.

The next step was to add a new RTC into the system. As I said in the previous post the RTC I was using previously would not work with the pro mini, because it needs 5v and the pro mini is a 3.3v device. Instead of fixing this problem when I noticed it I decided to kick the can down the road, and this is when I caught up with it. Previously I was using an I2C RTC, but unfortunately 3.3V I2C RTCs are hard to come by, so I replaced it with a SPI RTC.

This introduced a lot of problems into the system. First it was difficult to find good libraries for this new RTC, and once I did it still did not work in the system. After a while I was able to identify that the RTC and SD card reader were not able to work together, and after a while longer I figured out that I was running into SPI mode problems. If you have been reading the weekly updates then this probably sounds very similar to a problem that I recently dealt with at time of writing, and it is. The SD card and RTC need to have use different SPI modes to function, and this necessitates switching between SPI modes in the body of the code and tracking that the device is set to the right mode at the right time. I developed a way to do this at this point in the project, but later it stopped working and I had to change it in a subtle and annoying way.

After this was sorted I was now at the point I was at before moving to the 3.3V pro mini, that is the accelerometer, temperature sensor, pressure sensor, and RTC would all read data and write it to the SD card. The next step I began was to start to develop ways to decrease the power consumption of the device. I started by making a physical alteration to the Arduino, the Arduino had two LED indicator lights on it, on for power and one connected to pin 13 for general debugging purposes. I decided that when the device would be deployed and underwater that there would be no one to see the LEDs, so they did not need to be turned on. Unfortunately there is no way to turn off the power indicator LED from software so I disabled it on a hardware level. To do this I started by doing research into how other people solved this problem and found that you can just cut the lead wires on the board leading to the LED. This sounds easy enough but the Arduino is a small, printed PCB board so the wires in it are difficult to get to. I ended up just spending a lot of time under a magnifying glass carefully cutting into the board with an exacto knife until the connections were severed. Luckily I was able to do this without accidentally cutting any other wires and the Arduino still functioned after these modifications.

Next I began to try to minimize power usage on the software side by trying to the put the Arduino in an extreme low power state. In this state it would draw micro amps of power, as opposed to the milliamps in normally pulls. Before I began this though I connected a Lipo battery and ammeter to device so that I could get accurate current measurements of current. I also broke out the FTDI chip so that I could control what pins it was using when. With this hardware setup I then began development of the low power version of the code.

My notes on the exact process I went through to develop this code is vague at best but, in the end I had working code that would shut down every conceivable part of the Arduino, and then wake it up every minute with an alarm from the RTC. When the device was woken up it would read form all the sensors, write to the SD card, and then reenter the extreme low power mode. This was a very effective system form a battery life perspective, I never left the device running long enough to drain the whole 400maH battery. The longest it ran for was about 8 days and was going strong when I removed the SD card to look at the data.

This about sums up the work I did over the summer. There will be probably only one more post to sum up the work I did over last semester and winter break.

History Part 2

In the last history post I described how I got involved in this project, and the initial prototyping on the Arduino Uno board. In this post I will finish describing the Arduino Uno prototyping stage of the project.

The next step I took after connecting the micro SD chip and the accelerometer to the Arduino Uno was to connect a real time clock (RTC). At this point in the project I was using an I2C real time clock that worked well but, I had to end up changing it later in the project because it only worked at 5V.

The reason I was using this chip at all was because of a mistake I made reading the data sheet associated with the chip. Even though the Arduino Uno is a 5v devices, I knew the final version of the sensor would only be 3.3v so I was trying to get only 3.3v chips, and level shifting between them and the higher voltage Arduino, as I described in the last history post. When I looked at the data sheet for this I2C RTC I thought it said that it worked at 5v or 3.3v, but I only later realized that it could only be read at 5v, and would simply continue to track time with 3.3v from it’s internal battery (all RTCs basically have watch batteries in them so that they can continue to function even if the device they are connected to is powered down). I did not realize this mistake until I connected the chip through 3.3v to the Arduino and then was confused why it would not read the time. Even after realizing the mistake I continued to use the 5v RTC for the Arduino Uno prototyping, with the knowledge that I would have to get a different RTC when I switched to the 3.3v Arduino Pro Mini.

After realizing my mistake with the RTC and deciding that I would deal with it later I moved on to add the temperature sensor to the system. This was another I2C sensor and once wired into the Arduino was able to be read and then have its data be written to the Arduino with no problems. I then moved on to add the final device to the system.

The last devices I add the Arduino Uno system was a pressure sensor. The pressure sensor I am using has the option of being used with either the I2C or SPI protocol. At this point I had the SD chip connected with SPI and the accelerometer, RTC, and temperature sensor connected through I2C. I chose to connect the pressure sensor with I2C since it uses fewer wires, had been working well with the other devices, and the protocol was designed to easily have multiple sensors connected through the same wires. This turned out to a wise choice in the long run, as later in the project having multiple devices connected through SPI caused a lot of problems. However shortly after I made this decision I regretted its and seriously considered changing.

When I connected the pressure sensor to the system the accelerometer would stop working. I spent awhile trying to figure out what was causing the problem and was able to determine that both devices would work. separately but not together. This pointed to the conclusion that the two sensors were somehow interfering with each other, but I was not able to figure out why. Eventually through researching the problem I found that if two devices have a similar I2C address the Arduino can get them mixed up and not switch between them. However when I looked at the address of the two devices they seemed pretty different. Eventually though, I realized that the address are declared in the code as hexadecimal values, but communicated within the Arduino in binary. When I converted the two addresses to binary, I found that they were nearly identical, with only the last bit being different. With the problem identified I just need to find a way to fix it, I2C address are set by the manufacturer and can not generally be changed once the chip is produced. Luckily I discovered that the pressure sensor had a built in mechanism to address this problem. Its address can be changed by connecting two solder plates on the breakout board. When this is done the address increases by one in hexadecimal and this slight hexadecimal change was significant enough in binary that the Arduino was able to use both the accelerometer and pressure sensor without issue.

With the pressure sensor problem solved, all of the devices were working properly on the Arduino Uno. The next step was to make the change from the easy to use Arduino Uno, to the smaller and more lightweight 3.3v Arduino Pro Mini. I will talk about how I did this in the next history post.

History Part 1

This post is the first in a short series that will document the work I did on this project prior to the creation of this blog. I hope that these posts will provided useful background to the project and help show how it has evolved to this point. Also it is important to note that one of the biggest skills I have learned over this project is how to properly take notes and document my work, as such specifics from this very early period of the project are a little scant.

This project began for me when I was approached by Dr. Deconinck and asked if I would be interested in hearing about a proposed project to be taken up in the makerspace that would evolve creating a small sensor system to attach to large fish. I agreed to hear about it and subsequently met Dr. Kevin Weng from VIMS who gave a slightly more detailed overview of the desired functionality of the device. After hear this I decided to sign on the project, and filled a proposal with the W&M Small Hall Makerspace (referred to just as the maker space from here on out) to acquire a small amount of funding to begin the project. Upon approval I got to work

The first step I took was to begin learning Arduinos and the initial chips I had chosen to use. These initial chips were chosen mostly based on being easy to acquire, and sold preinstalled on break out boards that contained the necessary components to get the chip to work properly with the Arduino.

After gaining a very surface level understanding of what I was working with I began to try to test chips individually with an Arduino. For these initial tests I used an Arduino Uno R3 and a breadboard. I used the Arduino Uno initially because of its ease of use. The uno is the most commonly available and commonly used board. It is a larger board that runs at 5V and comes with headers pre-attached to all of its pins. Since it is the most common it also has the most resource and help materials online and is in general easier to use then the Arduino pro minis I switched to later in the project. The one problem with the Arduino Uno is the fact it runs at 5v, it does have pins that provide 3.3V out but not all of the data pins I needed to use had that functionality. As such I had to use resistors and level converter chips in order to connect the chips to the boards.
The first chip I tested was for the micro SD card, due to the fastidiousness of the micro SD card I had to use the level converter chip to connect it to the Arduino. Resistors would have add too much interference and noise to the signal.
After this I next add the accelerometer to the system and set it up to print its data to the SD card. This process was fairly straightforward, the example code that came with the accelerometer was easily adaptable, and the chip worked correctly out of the box. I used resistors between the chip and the Arduino uno to get the voltage to the correct level. A picture of the bread board at this point can be seen here, but be warned I took this picture with on my semi broken cell phone camera and was not planning to share it so it has a strange blue tint.

MicroSD reader and accelerometer connected to an Arduino Uno R3 (sorry for the poor picture quality I took this with a semi broken phone)

MicroSD reader and accelerometer connected to an Arduino Uno R3 (sorry for the poor picture quality I took this with a semi broken phone)

This was the first device I used that used the I2C protocol, and I found it very easy to use and reliable. This held true for the other I I2C protocol devices I used in this portion of the project. I will go into more detail about these other devices and talk about completing the Arduino Uno prototype in the next history post.