I never imagined I'd have a blog, nor the time to sufficiently manage one. But I thought I'd section off a place for it just in case I get around to it.

Sometimes I feel that I have something interesting enough to share, that might find an audience of readers, but again, it comes down to a sort of lack of time and prioritizing other things that need to be done in the limited amount of time available. So, the space and the infrastructure is here; I'll give it a try for now, but if the page becomes derilict, I will take it down.

Some likely topics for discussion that are likely to find place here include, but are not limited to: Linguistics (esp. fieldwork and analysis), University life, publishing, experiences of an expat/imigrant, and so on.

I welcome comments and discussion on whatever posts do eventually make it to the launched version of the site. Email me! In the longer run, I would eventually like to figure out how to provide infrastrucure for public comments here, such that any discussions can be made publicly.

October 2020

DIY (server) room monitor

2020•10•30 — Uppsala

Look at this, two blog posts in a the same month even. :) I'm writing up a little project I just finished.

Not long ago, I moved a computer that I had running more often than not out of the apartment. It wasn't really loud, but it was loud enough that it was annoying enough at night. With the machine out, the house is quiet; call me paranoid, but I don't like not having it in the house where I can see it all the time.

I decided on some kind of monitor, so I shopped around, but everything was either super pricey or didn't do what I wanted – motion detection, temperature, and humidity monitoring. About a year or so ago, I bought an Arduino and occasionally do something super spectacular like making LEDs blink. I thought this would be a perfect opportunity to do something useful and put together my own monitor. Here's the finished product – I'll walk through the steps in this post.

It's ugly, but it works. Here's the finished product, running with the sensor monitor output in the background.

I already had a PIR motion sensor that came with the Arduino kit but I never used it, so the first step was to learn how it worked. As it turns out, there's only one lead aside from the power cables; this lead reads hot when it detects motion. I googled the temperature-humidity sensor and it was similarly simple wiring, so I ordered one – the DHT11. I also didn't want to use my Arduino in a project that I envision as relatively permanent. It's fun to tinker with and it's overkill to monitor two sensors. So along with the temperature-humidity sensor, I ordered another board – STM32 "Blue Pill" – which is cheaper (about 2 euros) than the Arduino. It's still super overkill for two sensors, but the price is right. I also read that although it's also somewhat less user friendly, it's still programmable with the Arduino IDE, so it shouldn't be that much more complicated.

When my order arived, I got to work on a prototype. I wired up the PIR sensor and the DHT11 to my Arduino. I wanted to make the prototype with the Arduino beacuase I was already familiar with loading programs to the Arduino, which is relatively easy. The Blue Pill, on the other hand, is less user-friendly – it doesn't take programs directly via usb out of the box and the pins aren't labled the same way.

Here's the prototype hooked up to the Arduino. The PIR sensor is front-left and the DHT11 sensor is front-right. The red LED is on when the PIR sensor detects motion.

There was some minor configuration required to use the DHT11 sensor – a library needed to be installed, but it was all fairly straightforward. Then I literally copy-pasted the code from the PIR sensor tuturoal and the DHT sensor tutorial from the Arduino website to a single sketch. From there, I only needed to merge the 'setup' and 'loop' functions, and redefine one pin (both tutorials used pin 2 as sensor input). ...and hey, it works.

Next, I learned how to program the "Blue Pill". I followed the tutorial here to get started. As I mentioned, it was a little less user friendly, indeed, but with folloiwing the tutorial made it pretty painless. I only had trouble with the USB to TTL adapter – I crossed the TXD and RXD wires (derp!). I uploaded a few versions of the "Blink" sketch, one with serial output to make sure that I would actually be able to collect data from my sensors. That worked too. Alright.

In the meantime, I optimized the copy-pasted code – I had to remove the 'delay' function, which stops the whole loop. I also started thinking about a casing for this little device. My first thought was to put all the stuff in a jar and mount the sensors in the lid, but then I thought it would be best to keep the electronics away from anything metal. A wooden box would work, but then I thought an either completely vertical or completely horizontal mount point would lead to less than optimal coverage from the PIR sensor. I settled on a juice carton — existing hole for the PIR, and a good angle for the coverage.

Here's the prototype next to its future housing.

I started preparing the new housing, punching holes where the various components would be mounted

I threw some old batteries in the bottom to weight the whole thing down – wouldn't want it sliding around and making false readings on the motion sensor.

Next I got to programming the Blue Pill. I took the optimized code from the Arduno and renamed the pins (I found a guide to the pin correspondences here – I haven't verified all of them since I only needed two pins, but those two worked). I uploaded the program to the Blue Pill.

Here's the Blue Pill getting programmed. The board needs to be connected to the computer via the USB to TTL adapter. Only after the board is programmed can the regular USB port be used to collect serial data.

First try with the upload and everything was working as it should.

Here's everything programmed and put together.

With everything working, it was time to start mounting the components in the housing. This part should have been fairly straight forward.

But after this picture was taken, I swapped out some of the longer wires for shorter ones in the breadboard, and once again I crosed two wires (double derp!), so once I got everything mounted it didn't work anymore :| Shit.

I rage quit at this point, it was like 2 am and I could't see straight anymore. I forgot to take a picure of the final insides – call me inexperienced, but it is only my third blog post after a;;. The next day I cut the front of the housing open so I could see properly. The crossed wires were obvious in 2 seconds. Once those wires were sorted, everything worked as it should. With that, I put everything together, and here's one last picture of the finished product.

There it is, a DIY motion-temperature-humidity sensor for a remote location. The code for the device can be found here. And if I keep up this blogging momentum, maybe in the next post, I'll write about how to handle the data stream on the local end.

Abandoned Blog (?)

2020•10•15 — Uppsala

So, the website is almost two years old, and there's still only one blog post to show for it. As I suspected, I didn't have|make the time to post much. I'm tempted to say "that all changes now", but I know it's probably not the case.

2020 has been an interesting year. While I feel like I've been quite busy, I spent a good part of the year without a formal employment. There's not much news in terms of conference presentations or new publications. But I have taught a few courses in Uppsala and Jena. Teaching these courses has been a really rewarding, albeit time consuming, experience

I suppose the main bit of development to report has to do with the new research direction that I've been working on with Volker Gast in Jena and Margot van den Berg in Utrecht. The common theme in these two cooperations is that we're using speech-to-text to automate spoken-language corpus building. Very briefly, raw spoken data in the form of mp4 is processed using a series of shell and python script, which chunks audio, speech-recognizes chunks, and builds a transcribed and time aligned Elan readable .eaf file.

In one case, we (van den Berg and I) worked on data processed in this way from the Surinamese Parliament — De Nationale Assemblée. We took a descriptive, variationist approach to the data, looking at features that have been described in other publications as distinctive in the Surinamese variety of Dutch. The results of our investigation show that a data heavy approach, such as the one we have taken, will lead to a more nuanced understanding of how particular features and thier distribution signal "Surinameseness".

In a more recent rendition, Volker Gast and I have been working on data from the European Parliament. So far, I have mainly been dealing with infrastructural issues. In the Europarl case, video files come with multiple embedded audio tracks; every bit of spoken language is translated simultaneously to all the other EU languages and these translations are embedded to the video file. Currently, the pipe extracts all these audio tracks and builds the Elan readable .eaf file with a transcription for each language track.

Screenshot of transcriptions as seen in ElanScreenshot of transcriptions resulting from the speech-to-text pipe as seen in Elan

We're still exploring possibilities for exactly how we will proceed with analysis of data, but we see enormous potential to address questions related to the translation studies and the multilingual mind.

Otherwise, I've been spending a lot of time honing technical skills, working with shell scripts and python, a little bit of web development (esp. things that will be useful for research infrastructure), and 'tinkering' a bit with hardware (arduinos and PCs). I received an invitation to Google's 'foobar' challenge, so I spent a few days on that and managed to pass the first three levels — no call from the recruiter yet, but actually I think I might prefer the freedom of research to a corporate job despite the instability.

I don't remember what I had in mind when I referred to my 'technical (r)evolution' in the first blog post, but I have kept up with learning and expanding my own technical capabilities. It's certainly worth the effort it takes to learn new things — generally I think it forces a more structured and more efficient way of working. Personally, I also find it quite satisfying to take such control over my own work flows.

December 2018

The making of a website

2018•12•19 — Uppsala

As academic researcher, the precarious nature of my continued employment is frequently at the back of my mind. Basically, I'm just about always always looking for my job. In doing so most recently, I have been checking out a lot of other departments, and I noticed many people who are at comparable tiers on the academic ladder have their own personal/professional websites. This got me thinking that I should make one too.

As per usual, I decided to do it my own way, rather than rely on some more common/user friendly/preconstructed/possibly constraining/possibly proprietary software routes for making the site. I decided I wanted to go at it from the bottom up — from scratch. I considered it to be a stepping stone in my own personal technical (r)evolution (this will possibly be the topic of my next blog post). So, I set out last week to learn enough of the web development trio — HTML-CSS-JavaScript — to get my own site up and running.

I had some previous experience with XML, Latex, R, and Python, so I wasn't completely in the dark in terms of how computers and scripting read, process, and render text. I had no illusion that making a website would be "easy", but I figured it must be at least managable — and it was. The basics of HTML were simple enough to learn, though it took a few tries to get the document structure right; bad structures became epecially apparent when I started adding style to the HTML with CSS.
Me making my website (dramatic reenactment).

Some aspects of the process were quite frustrating — the "stickiness" of top and side navidation menus, as well as trying to make Java tell the header to resize itself to accomodate an image (I gave up on that one), are a couple things that come to mind. Generally speaking, though, the whole thing was almost addicting. It's super satisfying to watch all your efforts come to life in the browswer before you.

In the end, it was a fun little project, but I certainly don't envy web developers. Nevertheless, I'm grateful to have experienced making a website and I'm very satisfied with the end result. I want to use the opportunity to advocate the learn-by-doing approach to getting stuff done, which is generally in-line with my teaching philosophy, and to say (esp. to all my humanities people) embrace technology, make it work for you, and do great things!