Weekly Update 3-23-16 to 3-29-16

This week I finished assembling the second device. Pictures can be seen in below. As the pictures show this device is much more compact then the previous iteration, and is built as 3 dimensional, some of the components are stacked ontop of eachother. This allows all the of the ports to be accessible from one point so the device can be mounted in an enclosure that has only on point of access in it. All components of the device work right now and all that is left to do with it is to clean it up a little bit and attack heat shrinking to the solder joints. FInishing this device constituted the bulk of the non administrative work this week, but I also did look at power usage on the oscilloscope.

Partially assembled device

Partially assembled device

Fully assembled device, but it still needs some finishing touches.

Fully assembled device, but it still needs some finishing touches.

The oscilloscope is a device that looks at voltages  versus time. By putting a small resistor with known value in the ground line from the device I was able to connect the scope probes across the resistor and look at the voltage vs time, and thus through ohms law the current vs time. A picture of the scope screen can be seen below. In this picture the small ticks in the voltage correspond to the accelerometer reading data, and the giant spikes corresponded to reading from the RTC and temperature sensor, and then writing to the SD card. The reason this peak is so large is because the SD draws a lot of current in order to write data, that is why we work so much to minimize the number of times it writes. The goals going forward with regards to the power usage of the device is to get the base line when the device is doing nothing to be lower and to narrow the width of the SD card write peaks. In other words we cannot change how much current is needed for the sensors or the SD card, but we can change how much current the device draws between reads and how long it takes to write data to the SD card.

DSCF2012

Picture of the voltage vs time of the device. The small ticks correspond to reads off the accelerometer, the large ones are data dumps to the SD

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.

Weekly Update 3-16-16 to 3-22-16

This week I worked on getting current draw data of the device, building another device, and reviewing some of the relevant literature about what I this tag should look at and how other people have done it. Additional I continued on the training I started last week.

Getting current draw data from the device was not easy. I wanted to look at the current drawn from the battery over time by the device, to both estimate the total battery life of the device at this time and to try to see what processes are causing the most current draw. Additionally I wanted to establish a baseline to see if future developments are helping or hurting the the battery life of the device. The reason this was difficult is because current data needs to be taken in series. This means that the wire has to have a break and the digital multimeter (DMM)needs to connect the two part of this wire. This is impractical because I would like the device to work both with and without a DMM in it. A way around this problem is Ohms law which says that voltage= current x resistance (V=IR). Voltage is measured in parallel so the wire connecting the battery to the device would not need to be broken to measure it. The problem with this is that ideally the resistance of a wire 0, and thus the voltage drop across the wire is 0. Luckily (for this at least) I do not have ideal wire. The resistance in the wire is low but non zero, the next problem was to find this resistance. When I googled the wire I was using google helpfully told me that the wire has a resistance of approximately 16.14ohms per 1000ft. This means that the wire I want to look at should have a resistance of approximately 4.7mohm. This is low, and leads to a voltage drop that is too small to look at accurately with the normal DMMs I have. So I have fallen back to plan B.

Plan B is to look at the current pulled from the laptop when the device is powered by the FTDI chip which is used to program the device. This gives less accurate data then looking at the current drawn from the battery but it is better than nothing. To try to improve the data I broke out the FTDI chip so that I had access to each of the lines individual. This allowed me to disconnect everything but the power lines between the computer and the device. A picture of this can be seen below.

DMM with the device

From this data I found that the device pulls approximately 4.2ma of current, with spikes up to 16ma when writing to the the SD card. This means that the device should roughly have 3 or 4 days of battery life at this stage. This was somewhat confirmed by another test I did, which was to charge the battery, and then leave the device running over the weekend. When I came back and looked at it on tuesday I found that it had run from Friday afternoon until monday evening, so roughly 3 days.

Addition to looking at the power usage of the device this week I spent time assembling another device. This one will have the same components as the current one, but they will be arranged in a slightly more compact argument. The purpose of this second device is so that both Ben and I can work with the device at the same time, and to be able to deploy one for preliminary data taking while continuing development on the other. A picture of how this second device is coming along can be seen below. Even though it is not much to talk about or look at right now this is what I spent majority of my time working on.

Soldering in Progress

Finally I read some literature detailing experiments using accelerometer data loggers on a variety of underwater animals. Since this weekly update is already on the long side I will not outline what I learned here, but I may in a dedicated post or another weekly update.

Weekly Update 3-9-16 to 3-15-16

I did not do very much direct work on the sensor this week, the week was mostly dedicated to more administrative tasks. At the beginning of the week I worked a little bit on trying to fix the bug on the real time clock where the year is set as 1916. I did not make a lot of progress on that front and will continue to work on the problem, with help from Ben, in the coming weeks.

On that note I spent most of the week getting Ben up and running on the project, and working with him on his coding. This led to a big step forward in the project by setting up data caching on the device. This is detailed in his update. With this step done we are nearly ready to start using the device to take data. All that is left to do on the front is to run some tests on battery life and power consumption, which I will do this week.

Finally this week I started some training that will be necessary to work with animals, and to allow people to carry the device in order to get test data.