Mostly logistics this week
by on with No Comments

Most of the work I’ve done this week has been with the logistics aspect — calendars, flights, accommodations, etc. Charlie and I met on Monday to start working on the calendar for the months until our trip. We are trying to set dates for when we want specific projects completed — Field Day, soil sensors, flights booked. I can’t remember everything we talked about in that meeting (we wrote the calendar on the white board in hopper), but I’ll transfer that to the Drive calendars soon.

We decided that accommodations, flights and vehicles should all be done before spring break starts, but it turns out they need to be done now. I started working on booking our accommodations this week. I’ve booked the first two places and the last one. It turns out almost everywhere on the south coast is booked for the days we need, or they only have one room with one bed available. Starting for the next trips, we’ve put down that we need to book hostels as soon as we know the dates and the number of people. I’m still looking for a place on the south coast, but it’s looking like we’re going to have to stay in two different places. One place for the first two nights and another place in the southeast for the second two (most likely).

Back in the posting game!
by on with No Comments

Given a crazy schedule and general laziness I haven’t posted in far too long. That changes now! Over the passed few weeks I have been focusing on the energy survey, drone potential, and the android app.

I’ll start with the android app. There is now a stable naming system using the Gradle to number the APK’s accordingly. This naming scheme is probably going to changes as soon to use a tagging system as soon as Charlie, Kristin and I are able to decide on the best nomenclature. This naming system is then going to work directly with the field science blog! I have been figuring out a custom file system for wordpress that will allow us to have specific areas for upload and update that can then be automated by a script! The script is fairly straight forward and I test run has worked for uploading a test apk but I haven’t been able to configure the file system the way I would like for it to work yet. This seems like a simple but time consuming test so I hope to get to it soon.

The next thing is the drone system and potential in use. The potential is absolutely there for it and the more we look at it we realise that there is hardly any downside to one. What we have been looking at is the flight time, speed, charge, and hack-ability. How hackable the system is seems to be the deciding factor as it would allow us for the most customisation and possible use in other projects. Currently we stand deciding between the DJI phantom 3 advanced and the 3DR solo. Both entry level drone systems.

 

With the energy survey I will write an individual post detailing the findings and updates!

Not much to report…
by on with No Comments

I haven’t done much in the last week, to be honest. It was kind of a crazy week for me so I had to focus on some Admin things. I’m still looking at the best method for threads in Android and thinking about the Notepad/Lab Notebook/Checklist aspect of Field Day and the best methods and classes to implement it. If there’s anything that could improve the Notepad from Seshat. That uses a Navigation Drawer but to my knowledge, that has been deprecated in the new APIs, so more research is to be done.

Mid-January to mid-February, 2016
by on with No Comments

After being distracted during the break by a downstream software project (Mothur, 16S analysis tool) I have spent most of my time organizing the pieces, making lists, thinking about the Icelandic Field Studies program, and looking for money. We have sent proposals to the Natural Science Summer Research fund, the Dean, and the office of sponsored research (Institutional Advancement). Our “Sanity Check” email will be sent soon. I setup Anna and Katie with the tools and materials to work on the soil pH sensor platform.

We’re in irregular contact with Oli, hopefully some of the loose ends associated with our work at Skalanes will be addressed. The biggest question is which projects will we pursue there.

Next is developing the pre-departure calendar with Kristin, working on list management (Kanbanchi), and ultimately getting back to the BLE Android interface.

Best method for threads in Android
by on with No Comments

The past week I worked on making the classes that pertain to sensor sampling platforms more generic. Previously, I had been working on just getting them working using the Built-In sensor sampling fragment. The Built-In fragment uses the built in android sensors on the hardware device which uses the Android Sensor class. The aSensor class and other similar classes that we are going to use for all sensor platforms (Database reading and writing, sensor sample fragment frame, and the list adapter) were using Android Sensor class methods. I worked on getting rid of those methods and replacing them with more generic methods that can be used for all sensor sampling types.

I have also been researching the best method for creating a thread in android classes. The SQLite work I’ve been doing is almost finished except it’s writing to the database too quickly which is making my primary keys fail. I am looking for best practices for writing to a database in a thread. In Seshat (our old application), we had a feature where the user could select how often they wanted to write to the database (in seconds). I plan to move this feature to Field Day but I want to research the best approach. In Seshat, we used a runOnUiThread method. This may be the best approach but there are other options to consider — Service, AsyncTask, Handler, Runnable, etc.

Soil platforms update
by on with No Comments

So far this semester I have been working on creating spectral standards for the near-mid IR range, using soils of known composition, and the Chemistry department’s FTIR spectrometer. These standards will be used to calibrate the SCIO for field use. The FTIR’s range is significantly farther out in the IR range (smaller wavelengths) than the SCIO. We will compare the SCIO and FTIR spectra by looking for correlated peaks in the respective regions using something like partial least squares regression or support vector machine regression. The SCIO doesn’t make its raw spectral data open, but the SCIOlab software does create a plot of the data. I am going to try to extract the data from the plots using a software called engauge that Kristin has just installed on hopper. Engauge traces the lines in images of plots and outputs the data to csv. It’s all very sneaky.

I am also working on altering the design for the field soil platform flask in OpenSCAD (the field platform will measures temperature and moisture) to be slightly larger and more robust in order to accommodate a BLE shield. It will also need a small cylindrical housing with a cap for the IR temperature sensor.

The organic content transmission laser sensor rig is under construction. I am working with Charlie (and possibly Nic) to prototype it in LEGO. I encourage anyone who likes building things or LEGO to work on this with me, because I am relatively inexperienced with all things LEGO.

I have decided that the BNC sensors for pH and conductivity that I worked on restoring last semester are a lost cause (they are old models, no longer supported or well documented). Charlie is suggesting we reconsider using the lusterleaf with a few small hacks. I am also planning on using pH strips. We can automate the comparison of the measured color to color standards for PH with the RGB platform we will have on hand for measuring the Munsell color profile of the soil.

The Munsell color platform could be part of the same platform as pH and conductivity (science in a box) or could be stand-alone, depending on if we use the Luster Leaf are not. It will basically consist of an RGB color sensor and connected to an Arduino and a python program that converts the RGB values to Munsell values (a linear transformation).

Gitlab fixed, back on track
by on with No Comments

After my last post, I decided to dive into our Gitlab setup and see if I could fix the problem. In case you’ve forgotten, the problem was the latest pushed code was broken. So, our master branch was pointing to code that was not working when pulled and deployed. The pushed code had changes to the gradle and build setup, not java code, so that’s why it was pretty broken. None of us know git all that well (but let’s be honest, who does?) so it has taken us a little while to remedy our setup.

I dove in and fixed it learning a lot about git in the process. I basically had to create a bunch of temporary branches with my current working code and rewrite history — basically making it look like the last changes had never happened. I set the origin/master branch to my working code with changes.

After this debacle, we decided that we should be using branches more often, keeping the origin/master branch for production, working, thoroughly tested code.