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