Sharkduino is my honors research project, so I had to write a report about the work I did on it over the last semester. For the curious here is a copy of the report:
This is the last blog post for the semester. I will start by talking a little about the work I did over the last week, and then talk a little about the semester as a whole.
This week I tried to assemble three more Sharkduino V2.2s, and ran hardware tests on all the existing Sharkduinos. The Sharkduino assembly was a failure. I was careless and rushing so I messed up the batch. This is the down side of batch assembly, if I have a bad day I don’t just mess up one Sharkduino. This pushes us outside what I feel is an acceptable failure rate for assembly so I am thinking about how to prevent this from happening in the future. First I think that I will only assemble two at a time, doing three is too much for one session. I will also make sure I dedicate the needed time to assembling them, and not feel rushed by deadlines and other commitments. Finally I will review my assembly procedure checklist to see if I can make any improvements to the process. Also this batch may not be a total loss, some of the Sharkduinos may be repairable. I tried to repair one and broke it further, but I am going to try to repair some of the other ones before the summer.
The next thing I did this week was test all the existing Sharking with the help of the rest of the team. We did this to make sure we would not accidentally put defective hardware on an animal over the summer. Through our tests we found that all the devices were fully operational except for one V2.0 that had a broken RTC battery backup, and one V2.2 that had a defective gyroscope.
The problem with the V2.0 was that the power in pin on the IC from the battery backup was shorted to a unconnected pin. A picture of this from the microscope can be seen below. This is interesting because this is the same error that I tried to fix on one of the V2.2s, and led to me fully breaking the V2.2. When I went to repair this V2.0 I was able to use what I had learned from the failed V2.2 repair attempt and fixed this one successfully.
Repairing the V2.0 was a reassuring way to end the semester after the failed V2.2 batch. While that failed batch is a minor setback it does not detract to much from this being a pretty good semester for Sharkduino. We were able to create two new iterations of the hardware, V2.1 and V2.2, that make the system more power efficient. We developed an easy and cheap waterproofing technique for tank deployments. We were able to better diagnose a lot of the issues we have been having with the tag. We repaired some of these, while others, like the LiPo charger, we have a good roadmap for fixing going forward. Finally we were able to build a lot of new Sharking. This both taught us a lot about PCB assembly, will allow us to get a lot of good data over the semester.
We have a lot of exciting plans for next semester. I will make sure to keep updating this blog with them as we do them. I may also post an update or two over the summer if I get anything for the project done. I have an internship this summer but the project will be continued by two other researchers who will be at William and Mary working on Sharkduino.
The semester is winding down, so everything is getting a little crazy. I spent the last week working on my midterm report and midterm presentation. Also I worked on assembling more Sharkduino V2.2s. I haven’t really had a chance to do any new work around that so there is not much for me to write about this week. Next week will be my final post for the semester and I will try to go over what I did this semester and what I hope to achieve next semester.
The first thing I did this week was begin a Sharkduino battery test. I connected a V2.0 to a 850mAh battery with the latest code for that system. As of time of writing (04/18/17) the tag is still on and recording data. This is great and means that our battery life on the 850mAh battery is better than the 1 week we expected.
The next thing I did this week was assemble three more Sharkduino V2.2s. I did all three at the same time for these. I am experimenting right now to see if I can decreases the time to build each tag by building multiple at once. This seems to be going great, I have gone from 2-3hr per tag to close to 1-1.5hr per tag by doing multiple tags together. On this set of three I did make a mistake on one of the tags and break the battery slot for the RTC coin cell. I am going to try to jerry rig a fix. That tag will not be fit for deployment however, and we will use it for code development. I will continue working on assembling more V2.2s in the coming week in an attempt to have 10 ready for deployment over the summer.
The next thing I did this week that took a lot of time was countered work on my honors midterm report. It is coming together well and I should have it done next week.
Finally this week we did a code hardening sprint. This is when we stop developing new features for the code and test it extensively to find and fix all bugs in it. We did this so that we can insure that we will be getting good data and the tags will work over the summer. This is extremely important because the summer is the only time we have access to live animals. We need to insure that we can collect good data during this time period so we have more realistic data to analysis over the coming semesters.
This code hardening took a long time as we have 3 version of the code to support. One version for the Sharkduino V1.0s, one for the V2.0s, and one version for the V2.1s and V2.2s. The hardware differences between the V2.1s and V2.2s are minor and have not been utilized in the code yet so these two version can run the same code. The process of hardening the code was long and tedious. There are a lot of steps in the code, first tag configuration, then the data taking code, then the parser, and then the importer to R and the basic R analysis. We were not trying to harden the R analysis this week but we still needed it to test the other portions. Every time we found a bug in the code we would then need to test every step that came after it again to make sure both that the bug was fixed and that we did not accidentally introduce a new bug further down the line. After nearly 10 hours of work with the team we did finish hardening all the needed code, so we are now ready to take data over the summer. I will however be doing another battery of hardware tests once I finish assembling the V2.2s
I did a lot of work on the project over the last week, but not tons that will be very interesting to write about.
First off all the parts for the Sharkduino V2.2s came in. I invented everything and started assembly. Since I need to build so many of these I am experimenting with more batch assembly. The problem is even though making more than one board at a time decreases the time per board, it still increases the total time I spend working on them. This makes it harder to fit board assembly into my schedule. I am still doing some things that have really speed up board assembly. The first is that I have been soldering the uSD card onto the boards on different days then I do the rest of the components. This both splits up the assembly time, and gives the oven more time to cool, which gives a more regular heating curve and better solder joints. Also I am getting better at using the solder stencil, that combined with the new steel solder stencil is helping a lot. Finally the Sharkduino V2.2s just have fewer components on them because they don’t have the charging circuit, and perhaps more importantly it has fewer different components. I have found that switching between placing components has a much larger impact on the assembly time then just the raw number of components on board.
In addition to the Sharkduino V2.2 work we had a phone call with an engineer at NASA. We talked about IMUs and analysis techniques. We learned a lot of great information that will really help to move the project forward.
Finally I am still working on my midterm report which is due near the end of the semester.