Long Day’s Journey Unto Ice

with No Comments

Today began at 7:30 when Charlie and Emi left to pick up the rental van at the airport in Egilsstaðir, roughly 30-45 minutes away. Sanne, who runs and maintains the house at Skalanes, drove them – and as much luggage as we could pack in – out to the parking area where we had one rental car waiting. They transferred people and luggage into the rental and drove off. The rest of us ate breakfast, cleaned up the house as best we could to help out Sanne and the others who run Skalanes (a group of 30 is arriving at Skalanes tomorrow!), and began to load up Sanne’s vehicle with all of the luggage we had not been able to send with Charlie and Emi. Once the luggage was loaded, we began walking out the drive while Sanne drove the luggage to the parking area and then turned around to pick us up and drive us the rest of the way. At the parking area, we were faced with a cold and windy wait as Charlie and Emi drove back. We amused ourselves with word games and hypothermia dances until finally they arrived.

Loading up the vehicles with luggage and humans took only a few minutes, and then we were off on our long drive back to Vik. We stopped for a few minutes at Glacier Lagoon so Marketing could get some nice picturesque footage of us in Iceland and briefly saw a seal – they occasionally swim up into the lagoon, which is apparently close to 200 meters deep due to the icebergs. Other than that, the drive was long and pretty uneventful, with stops only for restrooms and other necessities. At one of the gas stations we learned that today is a holiday here in Iceland (Whit Sunday, the day before Pentecost), and we were concerned that the grocery store here in Vik would be closed, preventing us from getting groceries for tomorrow. We made a short detour to Klaustur, where we knew there was a gas station/convenience store that would have some basic groceries available, and picked up materials to make some quick Mac and Cheese for dinner tonight and sandwich materials for lunch tomorrow.

When we pulled into Vik we discovered that the grocery store is in fact open today and we needn’t have worried, but the early shopping trip did allow us to begin working on dinner much sooner after we arrived. Everyone was tired and hungry, since we pulled into the hostel at 7 pm and had left Skalanes at 8:30 (or earlier) this morning. It’s after dinner now, and Charlie and Neil are working on getting the elevation platforms and drone ready for tomorrow, when we’ll be returning to the Sólheimajökull glacier. Rather than collecting soil samples like last time, we’ll be climbing on the glacier itself to collect geographical and volumetric data we’ll use to chart its recession over time. Nic is down with a nasty cluster headache, which is preventing him from helping get the drone ready. Yesterday I finished modifying and debugging the elevation platforms’ code, but now Charlie is trying to debug an issue with Field Day, the Android app we use to gather data from them. All in all, it’s a pretty regular night for us here, with a group playing Euchre in one area and tech gear exploded across another space.

Tomorrow we leave the Puffin Hostel at 9 am to meet our glacier guides at 10 and begin collecting data on the ice.

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.

Gitlab restored!

with No Comments

Unfortunately, I haven’t been able to do much work on the Field Day Android Application. In order for work to be done on that, Gitlab has to be working. Gitlab is where all of the repositories of our code live. And at the beginning of last week, Gitlab was broken.

Gitlab broke due to an accidental upgrade. It was upgraded on hopper from 7.14 -> 8.01 which is a massive upgrade. In versions > 8, there are 2 proxy servers — one the serves git requests (merge, commit, etc.) and one that does authentication. So, that broke Gitlab because there were additional configuration files to create and edit after that upgrade. So, I attempted to downgrade to the version we were using before (7.14) with yum. That was a bad idea. The downgrade with yum isn’t bulletproof and messed up some config files in the process.

Sigh, I upgraded back to 8.01 and tried to find the error. Apache, proxies, and web sockets. Gitlab uses proxies and web sockets, something that Apache (the web server running on hopper) isn’t particularly great at right now. Gitlab really wants to use another web server called Nginx (really, really wants to use Nginx). It even comes bundled with an Nginx install. I tried and failed many times to configure Apache to work with Gitlab and sockets and proxies, but it didn’t work. I couldn’t change the web server on hopper because there are other things relying on it.

I decided that Hopper is probably not the best place to put Gitlab. Alas, I moved it to Dali. Dali has a lot of space and is not running any web servers.Everything on the user side is the same, it just lives on a different machine now.

Fortunately, Gitlab comes packed with a way to create a backup of everything and restore from a backup. I created a backup of the current database, repositories, etc on hopper, installed Gitlab on Dali and restored from the backup I created. Poof. 8.01 is now running on Dali and can be accessible at gitlab.cluster.earlham.edu. I even went ahead and set up email notifications for push requests to repositories for the projects in field science and others that I’m working on.

Also, 8.01 is a whole lot better that 7.14 and much prettier!

Screen Shot 2015-10-26 at 1.35.30 PM

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.