Gitlab, and archiving!
by on 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).

What has changed?! $FIELDSCIENCE & YoctoLib
by on with No Comments

In our $FIELDSCIENCE Android application we use a library from Yoctopuce.com called YoctoLib which works with hardware purchased from them. We use Yoctopuce hardware in our Ambiance platform, and in the Ambiance skin in the app.

This library and code was working — recognizes the USB Yoctopuce devices that are plugged into the device and reading sensor data from them — the last time I used it (~July). Since then, something has gone wrong. The application will no longer read data from the sensors plugged in. I finally got it to at least recognize the device, but no data is being read. I suspect that this happened because of the move to Android Studio. Android Studio must have internally changed the way it uses APIs, which is what I am trying to figure out.

This further pushes me to believe that switching to Bluetooth to use the Yocto devices is necessary. Since the Yocto devices have to plug in via USB, each time I need to test the code, I have to upload the code to the Android device and then unplug the device from the computer so I can plug in the Yocto devices. This makes it difficult for debugging. If the device is plugged into the computer, Android Studio will constantly log messages from any application in real-time to the screen. Android keeps log messages even if the device is unplugged, and will load them once the device is plugged back in, but it’s all the messages (which is A LOT) from the test at once. It’s hard to go back through and figure out where something went wrong.

Did I mention Android Studio?
by on with No Comments

This past week I’ve been working more on Android development for the $FIELDSCIENCE application that we develop.

I mentioned in my last post that we’ve moved from Eclipse IDE to Android Studio IDE, and that involves migrating projects. The migration from Eclipse to Android Studio is not as straight-forward as Google sets it out to be. Android Studio uses a different build process (gradle). The project architecture is set-up differently, and different files are created during the build process.

I finally think that our Android application is in the form that Android Studio needs, with an updated YoctoLib library! This code has been pushed to git on hopper and can be checked out from any machine, with authentication. I’m working on a ‘to-do’ document of getting the code and importing it into Android studio.

Archaeology Site Survey
by on with No Comments

I’ve been doing research on the archaeology site survey project — trying to determine where the sites are at Skalanes, without having to excavate the site. I’ve determined that people do what’s called a ‘Geophysical Survey’ which is a non-destructive way to determine where their are sites.

There are differents methods:

  • Electrical Resistance
    • Using (usually) four metal probes stuck into the ground measuring electrical resistance. Many archaeological site characteristics will have different electrical resistance from their surroundings. For example, a stone wall structure might impede the flow of electricity, and organic materials in soil might conduct electricity more easily.
  • Electromagnetic Conductivity
    • Measuring the conductivity of the soil. A magnetic field is created underground by sending a current with a known frequency and magnitude. The currents spur a secondary current in underground conductors that is picked up by a receiving coil. Less sensitive than resistance meters.
  • Magnetometers
    • Measuring the gradient of the magnetic field of the Earth ( gradiometers), provides resolution of small near-surface occurrences. Magnetometers react very strongly to iron and steel, brick, burned soil, and many types of rock, and archaeological features composed of these materials are very detectable. It is often possible to detect disturbances in organic material.
  • Ground Penetrating Radar

Android, Android, oh yeah and some more Android
by on with No Comments

The past week, I worked on a variety of things — setting up the wordpress, researching archaeology surveying techniques, and setting up our field science application with Android Studio.

In previous years, the IDE that we used for Android was Eclipse. As of earlier this year, Google is no longer supporting Eclipse as the Android IDE and has switched to Android Studio. Things are different in Android Studio and I’ve been working on trying to set up Seshat and get it working. I’ve been running into errors about gradles and builds and libraries, so I’m trying to figure out what’s going on there. I had it working, but realized that I needed to update the YoctoLib library, and when I did that things went down the drain again. Once I have it working I’m going to create a document that will explain what to do.

1 2 3 4