Mid-January to mid-February, 2016

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

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

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

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.

Late December, 2015 and January, 2016

with No Comments

Worked with K, E, G, N, and D to develop an Icelandic Field Studies Wilderness Program proposal. The GLI has given it a light blessing, currently the Dean is considering our funding request (~$28K plus a course release in the fall) for this summer’s development costs.

Worked with Tara on pH sensors and NIR devices. After purchasing a SCiO device we will probably return it (no way to read the raw spectrum data) and we are now looking at the TellSpec unit.

Next up is putting together a sample budget for IFS and sending that for review (the “sanity check”) and working on the Android<->BLE<->Arduino. I also want to learn Kanbanchi well enough to sketch-out the IFS program with it (May, travel, Fall).

Back to Android and SQLite

with No Comments

Since the beginning of the semester, I’ve been working on Field Day again and somewhat sorting out git. At the end of last semester, we were having trouble with git and we’re still trying to figure that out. We’ve decided that we’re all going to stick on the same Android Studio version and upgrade at times we decide as a group. Nic has the most updated version 1.5, so we’re all going to stick to that.

The latest code push was code that broke my Field Day setup, so all of the code I’ve been working on hasn’t been pushed yet. I’ve started a new branch of our git repo called SQLite work that I’ve been committing my changes to. As a result, I’ve been learning a lot of git and branching and I think this may be the way to do so we don’t end up with broken code in our ‘master’ branch.

The part of Field Day I’ve been working on is the SQLite database. Previously, we wrote all of our readings to a CSV file but that gets quite messy. So, in this new application we’ve decided to go to SQLite. I’ve written a class called ReadingsDatabase which is a SQLiteOpenHelper class. This is used to create, delete, upgrade, update, query, etc the database. I’ve also written an interface that will be used to communicate between the Sensor Fragment classes and the main activity. I’ve been using the ‘Built-In Sensors’ fragment to test because we haven’t created any of the other sensors to test yet. I believe it is working, but the problem I’m running into is the class is writing to the database too quickly which is causing the primary keys I’ve set up to fail. I’m looking into a way to slow down the writing to the database. Once we figure out the git problem, I’m going to push my code.

Learning Icelandic Through Mapping

with 2 Comments

Translating a website in another language is actually a very difficult task. Here are a few of the words I translated from the drop down menu for the land survey website. One I had these translated I chose staðfræðikort which translated into topography map however once here there are still a multitude of options, so I have been opening up each one to see where it is and the ones in Austerland (the Eastern Region, where Skalanes is located), are on the Lagarfljot river. I am now continuing to plow through the maps here and will switch keyword if need be.

 

atlaskort

aðalkort

fjllvegakort

aðalkort ferðautgafa

ferðkort

fornkort

fræðslukort

gervitunglamynd

groðurkort

grunnkort

göngukort

götukort

heildarkort

heroringjaraðskort

jarðfræðikort

jarðskjalftalkort

kort til serþarfa

loftmynd

minjakort

rettmyndakort

segulkort

serkort

sjokort

skipulagskort

staðfræðikort

sveitargelagakort

syniskort

Atlas map

primary card

mountain road map

primary card ferðautgafa

travel map

fornkort

education card

satellite image

vegetation maps

mapping

A map

street

overall map

heroringjaraðskort

geological maps

jarðskjalftalkort

card for special needs

Satelite

Historical maps

right image map

magnetic card

serko

charts

zoning map

topography maps

Country Argelaga map

son maps

Weeks of 29 November and 6 December

with No Comments

Weeks of 29 November and 6 December:

Lots of FISC meetings and grading, this week promises to be similar. Working with K and T on list management with Kanbanchi was the only directly useful thing I did this week. Replying to Oli and GPS setup are the things I’d most like to work on this week. GLI appears to be ready to support our proposal for Field Science as Wilderness so we can begin to plan that in more detail.

Logistics work for flights

with 2 Comments

Only being here for half a week, I didn’t really get that much done. The little bit that I did do was not in the area of Android, but in the area of logistics, since I am part of that team.

I started to look into flights and what the best possible arrangement is. I’ve started a document, which you can find in Field Science -> Iceland 2016 -> Logistics, called Possible Flights where I’m keeping track of what I find. Each possible option is in the form of a table. The table documents the departing and arriving cities and times/dates and any layovers that will occur. So far, I have one arrangement in the document, and below I’ve documented my general findings.

Since many of us will head to XSEDE in Miami right after we leave Iceland, it’s not really optimal (as of the flights I’ve found right now) to buy a round trip to Iceland. That means we will have to buy a lot of one-way tickets, which is what we ended up doing two years ago. However, one-way tickets straight to Iceland from Dayton or Indy are extremely expensive — more than just a round trip ticket. I guess they don’t want you buying a one-way there. I suspect it’s partially because of the small size of those airports. One-ways from larger airports are much cheaper. That’s why I think we would buy a one-way ticket to a larger airport (say Toronto, for example), a round trip from that airport to Iceland, then a one-way to Miami, and another one way back to an airport close to us (Indy or Dayton for example, or Columbus).

I worked some with Charlie and Tara on figuring on Kanbanchi to use for keeping track of to-do things. It looks like a really nice and useful tool. We figured out the hierarchy of it in terms of our projects… refer to Tara’s post for more information on the exact hierarchy. I’ve started making one for Field Day and those tasks, which you should be able to find in the Field Science -> Software folder.

This coming week, I hope to finish the Field Day Kanbanchi to-do, work some more on Android, and talk to Charlie about who’s going to go to Iceland next summer. Though, I might not get as much as I’d like to done, since I have a lot of interviews to do with CS tenure-track candidates.

To-do: Figure out to-do list

with No Comments

This week Kristin, Charlie, and I met a few times to figure out how to best utilize the Kanbanchi drive app for keeping track of progress on projects. Charlie made sure we had a solid framework of common terms to work with:

project – the level right underneath ‘Iceland 2016’, for example ‘soil sensors’, ‘ambiance’, ‘field day’, ‘bird survey’.

list – the columns in the kanbanchi layout. The different lists within each project are determined at the project level.

cards – the individual items within a list. Broadly speaking, cards are like tasks. They can be assigned to anyone shared on the document. They can contain documents, checklists, and tags. Cards can be given a ‘flag’ that is named by the user. Cards can be given a color. We decided that green will signify tasks we are working on actively, yellow will signify tasks we have not yet started, red will signify tasks that were started but then ran into some sort of trouble (no supplies, something broke etc), and grey tasks we have completed (cards also have a ‘done’ checkbox, for the extra satisfaction factor).

Here is a picture of my kanbanchi layout for the soil sensor platform:

Screen Shot 2015-12-06 at 7.59.21 PM

Sensor-wise, I am working on debugging the ph and conductivity probes. I have not been able to get any serial output from them but arduino isn’t given me any errors. My goal this week is to figure that out and to get the soil moisture sensor and photo-resistor hooked up and working with basic sketches.

 

1 11 12 13 14 15 16 17 22