When You Give A Classic’s Major a Blog Post (on the same day they see an archaeological dig)

with No Comments

Camping is always an adventure, even if said camping is in a schoolhouse.

The schoolhouse in Stöd is both clean and cozy, with a carpeted little atrium–that has become a kind of common space–and plenty of little nooks and crannies (like the upstairs foosball table, or the little office space I am currently using to write this blog post). Everyone has been impressed with the living situation, enjoying the space to roam and the opportunity to get a little bit of personal space during the quiet moments.

The day started busy, a quick but enjoyable breakfast and then a hop over to the dig site at Stöd. The site has been, thus far, a four-year venture– with multiple hands and great minds involved. The day before, Rannveig expressed that coming to work at the site was like a holiday, she only does it one month out of a year–so, the equivalent of four months of excavation. While four months may not seem like a lot of time, the site itself is exceedingly impressive. I am an Ancient Classics Major with a Medieval Archaeology minor, thus, the dig at Stöd was like walking into a candy store. While this is the first archaeological dig site I have viewed in progress, I have seen the final product of excavations and know a little bit about the process; I was very impressed by the amount the Stöd team had uncovered and how intact a lot of it appeared to be. Yes, the site does look like barebones to the naked eye–however, the number of walls and floors they have excavated and the length is surprising. You can actually imagine the structure there–whereas, there are a lot of sites (mostly older) that just look like a pile of rocks or scattered artifacts.

We were met at the site by Rannveig and Bjarni and educated on the history and rough outline of information about the site. What they have found is that there are the remains of two separate buildings, one bigger and older building and a smaller and newer building built inside the older. It is assumed that whoever created the smaller structure found the ruins of the older and found it more convenient and maybe offered more insulation to build within it. Additionally, the question that hangs in the balance is whether or not it was truly a settlement or just a waypoint (the latter being more common for Vikings to build). This depends on what DNA they find (especially in Midden heaps), if there are remnants of cattle then it is more likely that it is a settlement and not a waypoint.

After we were all caught up we parted ways, separating into teams. We had Porter, Lilli, Jordan, Li, and Mubi working on drones–flying the flight plans and collecting visual data on the site (the first batch of photos were high definition photos which will later be used for a 3-D display of sorts; the second half was with the NRA camera, to help see if there is anything below the surface by capturing the UV light from the plants). Another team (E, Katherine, Joyce, and Sydney) was in charge of the soil samples we collected at Solo. Meanwhile, C ran around answering questions and helping as the Jack-Of-All-Trades and vehicle driver. And I was left to soak up as much information about the site and feed my passion–getting a feel for what a dig looks like, meeting everyone, asking questions, and observing the excavation as it is and what it will hopefully turn into.

 

 

 

Since it was a holiday (Wit Monday, following Pentecost), the Stöd team was not digging today, however, they were available for questions and willing to share information. By about lunchtime I had been shown the artifacts (AMAZING! There are stones, a nail head, a part of an Arabic coin, some beautiful beads, etc.) and I had discussed the finds in their newest test pit (they found a bit of a wall and a hearth); while also asking some basic questions about identification of settlement and what the work looks like on a normal day.


Again, it was a holiday so all the businesses were closed today. Except, there was a wonderful restaurant/gift shop called Brekkan which welcomed us in and served us lunch. It was a fabulous meal! Baked Fish with a cream sauce, fries (or chips), some sweet dark bread, and salad with grapes. It was all delicious and very much appreciated. Everyone at the table had their fill (maybe even a little too much–I certainly felt like I had to be rolled out the door afterward) and sat, very satisfied. 

We came back to the schoolhouse to gather more layers (the wind was biting cold and the sun was just not warm enough to make up for it like our previous nine days) and to split up again. This time Lilli stayed behind to work on uploading the available drone photos, while the rest of the drone team headed back out to take the NRA photos. Soil people stayed behind to continue their diligent work in the dining room area of the schoolhouse kitchen (you gotta do what you gotta do).

I left with the drone group to continue my archaeology observation. I worked for a time creating a (ROUGH) sketch of the site, sitting in the grass and feeling the brisk cold wind. I certainly appreciated the blanket scarf I had picked up after lunch and the warm sun on my back. As I sat I heard unique bird calls, though I was unable to identify where they were coming from and what species was calling out. It is fascinating to observe the variety of birds that live in Iceland, so many species that are different from the ones I am used to in the States (in addition, I’ve grown up in Alabama and Indiana my whole life, which limits my avian knowledge to a limited area).
After sketching, I sat in Rannveig’s “office” (the back of a huge van, with camper chairs and a tiny table). This is where we discussed the different sections of the site (using my sketch as a reference), how it compares to other sites, the work she has done in the past, my research knowledge of Norse raiding and settlement in Ireland, and about the different jobs and activities Rannveig has done or is a part of throughout a year’s time. It is interesting to note, there are several positions open for archaeologists to become consultants for the government or building/electricity organizations, but it lasts about half the year due to weather constrictions.
The drone group finished up around 3:15pm (15:15) and we packed up. We were all eager to take showers in the pool facility and looking forward to taking a dip into the hot tub or swim in the pool. The facilities did not disappoint. We were all able to rinse off and enjoy the hot tub or pool, whichever suited the fancy. I noticed Joyce, Roger, C, Mubi, and Katherine floating around in the pool– while Sydney, E, and Lillian lounged in the hot tub (Rannveig joined the hot tub later–as did most of those swimming in the pool).

It took a bit of encouragement from Sydney to get me out in the open–the wind was still freezing, but this time I was wet from the shower and in a bathing suit. The hot tub appeared way too far away and when I opened the door the first time, and the wind hit me like a wall of ice. E later commented on how it appeared as if watching a cartoon– the door opened, I yelped, and the door was quickly closed again. However, nothing was colder than the 4-6 celsius cold tub. Sydney dipped inside first, staying in long enough for a photo! She later said it was as cold as the glacier runoff she had waded through at Solo (after dipping into the tub myself, I have a newfound appreciation for the determination Sydney, C, Jordan, and Porter had to science that day, at Solo– jeeeeez, it’s cold!). After a bit, most of us at least tried the cold tub– including Lilli, C, Rannveig, and I– which, honestly, really added to the whole swimming in Ice(land) experience.
In a minute, we are going to be treated to Grilled Cheeses and Tomato Soup made by Lilli and Porter. And C has recently collected all the NRA photos and pieced them together–now we wait for the code to be able to adjust the light according to the native plants.
Exciting new developments in Archaeology!!! Hopefully more is revealed as we continue to explore and experiment.

 

 

Ambiance and a Feather

with No Comments

So, it’s been a little while since my last post. Here’s a quick update. I assembled our ambiance platform using the Adafruit feather and two sensors: Altimeter and Temperature, Humidity and Pressure. The Adafruit feather is a tiny BLE capable micro controller (like a Light Blue Bean). We decided to go with the feather because the BLE chip it uses is Nordic, like the Red Bear Labs BLE Shield. With the Nordic chip we can make our own services with UUIDs. The Bean has a built-in set of UUIDs and communicates differently than the Nordic chip.

The platform sensors currently use two different communication protocols: I2C and SPI, but we decided that probably wasn’t going to be a problem. I was able to solder on the sensors to a prototyping board and upload a sketch. I tested without the BLE first time to make sure it was working. It was, thanks to sample code from Adafruit! Adafruit has a different BLE library but it’s all the same principal. I tested the BLE code with Field Day and all works well. A picture of the ambiance platform is below.

Light Blue Bean!

with No Comments

In my last post, I said that I was going to switch all of our individual fragments of sensors to one that is ‘Bluetooth Sensors.’ Since then, I have finished that and redesigned even more of Field Day.

After I finished switching all the fragments to one, I dove into working on BLE connection with the Light Blue Bean (LBB). Unfortunately, the LBB does not do Bluetooth the same way the Red Bear Labs shield does. The LBB uses something called ‘Scratch Characteristics.’ These are built-in 5 characteristics that can be written and read from the client (in this case, Field Day) and the server (the LBB). These characteristics have set UUIDs, so that means I can’t use the custom UUIDs I set for the RBL’s sensor. After browsing some of the android SDK code from Punchthrough (the people that made the LBB), I was able to determine the UUIDs that are used for the characteristics. Since Field Day is going to have to determine what kind of device it is connected to, I redesigned it so that the fragment is cleaner and doesn’t do any of that work. There are separate classes for a Bluetooth Sensor, GATT Client, and Bluetooth Service. The Service talks to the Sensor and the Sensor talks to the GATT client and determines what type of device it is connected to by checking the UUIDs. All the Fragment does now is say when it wants to write a message or read a message.

Punchthrough has sample code available for arduino and reading and writing the scratch characteristics. The examples along with the SDK has proven helpful when rewriting the android code to accommodate for the Bean. Unfortunately, not many people have used the Bean with Android. All of the examples are with iOS. Field Day is able to read scratch characteristics just fine from the Bean, but is currently unable to write to any characteristics. One huge problem with the bean is that everything is Bluetooth. It’s not like arduino where you plug in the device to your computer to upload code and power it on. This means that the Bean can only be connected to one thing at a time and thus, is really hard to debug. Typically when debugging arduino devices, I’m able to plug the device into my computer and watch the Serial monitor for debugging code I’ve added in. With the Bean, I cannot. It’s blind debugging and it sucks. I’m still working on figuring out how to write a characteristic and have the bean read that characteristic, but I think I’m getting closer. I hope to finish that this week.

Handlers handling handles

with 1 Comment

After some testing of the Handler implementation in Field Day, I’ve determined that it is actually working! I was finally able to look at the data that I had been writing to the database.

Databases in Android are stored in internal (private) memory. There are Android apps that let you look at the files on your device, but only for external storage. The internal storage is private. What I ended up doing was adding a function to write the database from internal storage to external storage. Once it was on external storage, I used a SQLite Viewer Android app to look at the database and it looks good!

I did some research into the application state when the device screen is turned off. In our old application, Seshat, the activities would die when the screen was off. That’s not good. We want to be able to turn off the screen and hang the Android device from our person some how. It’s useful to have our hands free. After a couple hours of research, I determined the libraries we want to look at are in the PowerManager library on Android, particularly the PARTIAL_WAKE_LOCK state. I wrap the methods I want to happen when the screen is off in what are essentially ‘start’ and ‘stop’ methods. The methods were not executing with the screen off, so I researched some more. I think what will ultimately happen is switching the SensorSampleActivity to a Service. A Service in Android is one of the top priority processes. It’s one of the last to die to if the device needs more memory. It can continue running even if the Activity the started it has died. Since the Activity is now working, I’m going to hold off in converting it to a Service.

The last thing I worked on this week was Bluetooth LE in Android. Tara gave me a BLE shield with an Arduino attached to test my code with those devices. Android provides a BLE example in Android Studio so I’ve been working with that. However, the example they provide has deprecated code so I’m working on modifying it to the new setup. It’s not working yet, but I’ve only been working on it for a couple of hours!

sqlite-fieldday
Sample of sqlite database on Field Day

Databases, Threads, and aesthetics!

with No Comments

After getting most of the logistics sorted out, I’ve finally been able to get back to working on Field Day. Not a whole lot has been done because I spent most of my time working on logistics but I was able to get a few things done or started. The first thing I did was get rid of the black background for the Sensor Sample activity. We don’t have to keep it this color I was just tired of the black. I made it green because it reminded me of grass and being in the field. The next thing I added was EditTexts for Site, Sector, and Spot like Seshat had. In the data model, we also added a ‘Trip’ column but I didn’t think that there needed to be an option for that on the main screen. I put in option in the Settings page since it’s going to be constant throughout the entire trip. In Seshat, we had an option to select how often the stream to the database. I added that in Field Day as a Radio Group with customized buttons from 1 – 60 seconds. I haven’t done anything with those values yet but the visual and backbone is in place. (You can see these edits in the two pictures below — Sensor Sample on the left and Settings on the right). Ignore the ‘Table name for readings database’ on the Settings page for the time being because I have figured that out yet.

fielddaysettings

Gitlab, and archiving!

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

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?

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.