Field Day Application :)

by Kristin Muterspaw on 2015-10-05 with No Comments

We’ve begun work on the new $FieldScience Android application! This application is yet to be named, but what do people think of the name FieldDay? I think it’s snappy. 🙂 I created a shell in Android Studio and pushed the code to our Gitlab repo. All of the developers have been able to checkout the code locally to their machines. The old application has been archived and made read-only in Gitlab.

The current developers of the application — Nic, Charlie, and myself — met last week to discuss the details of the application. During the meeting we discussed the basic outline of what we want the application to do. There will be ‘skins’ for each sensor, and all of those will interact with a basic communications library that is built to interact with all of the sensors that we have. There are many things that the old application — Seshat — did well and we discussed those and the pieces of code we want to keep — camera option on sensor skins, writing to csv, sending to database. Android applications have very particular states and processes that they go through. Through some research, we have figured out that they way our old application handled those could have been part of the problem with it crashing a lot. There is still more research to be done in that area, because we don’t fully understand it but we are getting closer.

We are not going to focus on the aesthetics of the application right now, but we did decide that we liked the front/main screen of the old app and will keep it. I’ve added that to the new application with a few enhancements. I made the skins circles and made the colors stand out more. You can see the difference and changes below (Seshat is on the left, new application on the right). Prettier, don’t you think?

LightBlue Bean for Ambiance <3

by Kristin Muterspaw on 2015-10-03 with 2 Comments

After our meeting last Monday, we have decided to step away from Yoctopuce devices for any platform, but specifically the ambiance platform. Although, the Yoctopuce devices are nice, and have the ‘plug and play’ option, they are expensive and complex (in terms of debugging) compared to other options.

We are moving to Arduino-like design for the Ambiance platform. After some research, I found a device called the LightBlue Bean (see below). The LightBlue Bean is a very small device that is configured entirely through Bluetooth Low Energy. You can even upload code on the go with an Android or IPhone application, which is exactly what we need. The Bean has the same chipset as an Arduino, and even has a built in Temperature sensor. A key characteristic of the LightBlue Bean is the on-board battery. In the past, we’ve struggled with our sensor platforms drawing too much energy from our Nexii. We would have to pack extra charged battery packs, which would take up space in the limited space we have for our day. When you’re climbing a volcano or a glacier, it’s ideal to carry the least amount of weight as possible.

We’ve ordered about 4 of the LightBlue Beans and they should get here sometime this week. Once they arrive, we’ll play with them and attach sensors to see how well they work. Can’t wait to play with them!

Week of 20 September 2015

by Charlie Peck on 2015-09-28 with No Comments

Kristin and I wrote a long email to Oli @ Skalanes with a bunch of answers and questions for him, his reply arrived this morning. Spoke with Tara about soil sampling protocols and parameters, Erin about infrared imaging for the nest sites and scaling aerial imagery, and Deeksha and Eamon about data models and data conversion. We also talked about where all the various older sets are that need to be harvested and brought into the central data store on the field science machine.

Skalanes Nesting Birds

by Erin Lewis on 2015-09-28 with No Comments

After receiving Bernard Lundie’s information, I was able to make headway in nesting birds. He sent me a complete document that lists the birds he know that have nested around Skalanes including waterfowl, grouse, waders and passerines. Eider (waterfowl) and Arctic Terns seemed to be most common in terms of nesting. There is an extensive list, so know narrowing down a specific research question involving the survey of nesting birds will be key, because there are so many species. Do we look just more extensively at nesting arctic terns or do we just survey nest totals in the area, disregarding species. I also spoke with Earlham’s ornithologist, Wendy Tori and she sent me several papers on arctic terns. We talked a little bit about methods but she has never done anything quite like this. The final challenge this week has been getting the thermo camera. Still an issue that might take some more time.

Joys of Reconciliation

by Deeksha Srinath on 2015-09-28 with No Comments

I’ve mainly spent time working on identifying the specific differences in the formats of data we’ve used for the last two years.There are some differences between Iceland 2014 data and Nicaragua 2015 data,and even more significant differences between Iceland 2013 data and the rest of what we’ve collected.To be able to start putting together the pieces of what we have and effectively cleaning them up,we need to locate and tag everything we can find,which is what I’ve been upto.

I now have a master table of sorts of Iceland 2014 data and Nicaragua 2015 data,so I know what/where we need to add/modify so as to have a consistent pattern in our data.

I’ve been working on what additional functionalities we want our data model to accommodate before we go back,and how to fit in the pieces of whatever we do have into the data model we decide is best this year.

Web Development done Python-style

by Charlie Peck on 2015-09-28 with No Comments

Over the past couple weeks I’ve been looking into lightweight frameworks for doing web development. I’ve been experimenting with Flask, which is amazingly simple.

I did some python/bash scripting to manipulate data left over from Iceland, and cleaned it up so it would all fit into one database schema. This should be updated later to comply with some kind of standard we all decide on.

I’m beginning to like the idea of developing our data interfacing software under an api-based model of programming. I think it is beneficial to decouple the database from the front end. I’m considering developing a restful api that returns data in a JSON format that can be interpreted and displayed on screen by some kind of JavaScript-based web app. This may also give us the flexibility to later integrate data into Android or desktop apps as well.

One of the big tasks yet to do is to figure out how to send the data between the client application and the database server. Does anyone have any ideas as to how to do that?

Lasers! (And also other sensors)

by Tara Urner on 2015-09-28 with No Comments

Scanning optical organic matter sensor

Organic content can be measured in a variety of ways. The most accurate tests involve measuring the amount of combustable carbon-based matter in a sample by putting it in a chemical oven. In a test like the one pictured below, soil is allowed to sit undisturbed in a falcon tube for a period of time in which the available organic matter floats to the top.

I would like to use a combination of a laser and a photometer to make a scanning optical device that moves upward from the bottom of the tube. An arduino would log the values of intensity of the light that permeates the tube. The intensity would be reduced for the section of the range that is obstructed by organic matter (or mineral matter at the bottom). I will write software to measure the length of this band and then calculate the volume from this value (thickness*pi*r^2). This method would be faster and more consistent than measuring each band individually by eye.

Electrical Conductivity & PH Sensing Platform

This platform will also be designed for bench top use because soil samples need significant time to stabilize before accurate readings can be collected. I am focusing on sensors that connect via BNC because they seem to be the cheapest option for arduino interfacing.

The PH interface will be based on this implementation from Sparky’s Widgets (a great all around resource for electrode sensing applications).

I will try to build this interface for the pH probe first and then see how easy it is to modify to read EC. Sparky’s Widgets offers an integrated solution for purchase, but I would like to reengineer it myself if possible.

Temperature and Moisture Field Sensor

This is the only sensor platform I am designing for field use. Right now I am thinking I will design the temperature portion of the sensor to be used right after the soil core sample is taken. I am planning to use infrared sensing in the resulting ~10cm hole to measure soil temp. There are a lot of options out there for infrared sensing – here is a sparkfun sensor I am looking into. I need to get an idea of what precision is necessary for this application.

For moisture I am planning to use a very robust sensor from Adafruit that has been used by students in the past. Building the circuit for this sensor might be a good place to start since I have models to work off of.

NPK and Munsell Color Optical Sensor

A lot of soil nutrient tests involve chemical reactions leading to color changes. I am interesting in using RGB sensors to find a precise value for the color of a solution so I can determine it’s nutrient density. Munsell color test is the official color metric for soil research. I am now researching ways to use RGB LEDs and photosensor to test color of an object. A sensor capable of detecting color could be used for both bench-top NPK tests and Munsell color testing.

App dev thoughts

by Nic Arnold on 2015-09-28 with No Comments

Im slowly coming to the conclusion that the android platform is a tinkerer’s dream and that there are hardly any restrictions to get in your way (iOS I’m looking at you). I’ve spent the week continuing to learn the ways of java and android studio but have started to shift my thoughts to how to implement and set up the new $FIELDSCIENCE app. Through exploring the source code and the app itself I know the general nature of what is needed (i.e., ambiance, temp, notepad, etc) in the app and brain storming on new ways to implement them as well as taking note on the things I like from the original app. Things feel like they are starting to get rolling!

Yoctopuce and Bluetooth

by Kristin Muterspaw on 2015-09-28 with No Comments

I’ve been doing some research on Yoctopuce and using Bluetooth to communicate with devices, as opposed to USB communication. I could not find any information on using yocto devices with bluetooth. The only official available options are Wifi, USB or Ethernet. This is saddening. Our Yocto ambiance platform is really top-notch, but we need to get rid of cables. They are just not practical. They unplug randomly and we will lose a lot of data in that time. Bluetooth is the only practical option.

I’ve been looking into Arduino sensors on Sparkfun.com and Adafruit to see if we can get the same functionality (and precision) that we can with Yocto devices.

Gitlab, and archiving!

by Kristin Muterspaw on 2015-09-28 with No Comments

FINALLY, we have a stable Git environment. On hopper (cluster.earlham.edu) I’ve set-up something called Gitlab. Gitlab is an open source git repo hosting environment. For those of you that are familiar with Github, Gitlab is like a self-hosted version of that. I chose Gitlab because it’s private (in Github, you have to pay for a premium membership to have private repositories) and it’s cleaner and has better access control than just doing it through a user’s directory on the machine.

You can see the Gitlab setup here – Earlham Gitlab. There’s a group called field-science where we are going to host all our code. I’ve already created projects for our Android work. The old android code is now in the archive-android project. This means that it is read-only! Yay! Starting fresh for Android $FIELDSCIENCE app. There’s a new project called FieldScience that we will use for the new app, which I’ve already created the shell for in Android Studio and pushed it to the Gitlab. Yay for cleaning and organization.

On Gitlab, we will store the visualization code, the database code, the arduino/sensor code. All the code! This makes it a lot easier when trying to find stuff later (our old Arduino code is all over the place).

« 1 … 16 17 18 19 20 21 »