Master of Data Science

Over 8 years ago I completed a Bachelor in Electronics Engineering, with a focus on embedded systems. Since then I have done primarily software engineering in embedded and web projects, sometimes combined in so-called “Internet of Things” (IoT) projects. Often there was a strong data- and signal-processing focus in these systems; from audio processing in microphone-arrays, to image processing for smart website builders. Recognizing the importance of data, I realized around 2 years ago I wanted to add a new skill-set to my engineering capabilities: Data Analysis and Machine Learning (ML).

And today I’m proud to say that I have successfully completed the Master in Data Science program at the Norwegian University of Life Sciences, as one the first batch to have this degree in Norway.

Master of Data Science thesis successfully defended. Left: me, Right: External sensor Lars Erik Solheim


Throughout my degree, I’ve kept the vast majority of my notes in the open-source way – public on Github. Over time I have distilled these into two resources covering the main topics of my work.

Embedded Machine Learning: Machine Learning applied to Embedded System, with a focus on-edge ML in low-cost, low-power sensors.

Machine Hearing: Using Machine Learning on audio, with a focus on general sound (less music and speech).


My masters thesis combined these two topics, and applied it to classification of everyday urban sounds for noise monitoring in smart cities. The report and all the code can be found on Github:

Environmental Sound Classification on Microcontrollers using Convolutional Neural Networks


Since Embedded Machine Learning is an emerging niche, the availability of software tools are not as good as for machine learning in general. To help with that I developed emlearn, an open-source ML inference engine tailored for micro-controllers and very small embedded systems. emlearn allows to convert models built with existing Python machine learning frameworks such as scikit-learn and Keras, and execute them on device using portable C code. The focus is on simple and efficient models such as Random Forests, Decision Trees, Naive Bayes, linear models. In this way, emlearn is a compliment to deep learning inference libraries for embedded devices, such as TFLite and X-CUBE-AI.



While the master degree was nominally a full time program, I kept doing engineering work for customers in the period. Projects have included:

Windportal. An interactive installation for advertising the Hywind off-shore windmill farms for Equinor. Made with ad-agency Dept and software developer Martin Stensgård.

dlock. A IoT doorlock system for retrofitting existing public infrastructure doors. Developed for municipality of Oslo as part of the Oslonøkkelen project, an app that allows inhabitants to access municipality services such as libraries and recycling stations outside of manned working-hours. Made in collaboration with IoT solutions provider Trygvis IO.

Since the start of this year, I have started to focus on machine learning projects. Especially things that incorporate my particular expertise: Embedded/Edge Machine Learning, Machine Learning for Audio, and Machine Learning on IoT sensor data. The first ML consulting project for Roest coffee is well underway (details to be announced). Going forward, most of my time is dedicated to products at my new startup, Soundsensing. However, there should also be some capacity for new consulting work.


Back from CERN

Bad blogger me, late as usual.
On Thursday I got back from a longer trip to CERN, Geneva. The purpose of the trip was to sit shift for the HLT subsystem in ALICE, on behalf of the University of Bergen. While not a prerequisite for completion, its was part of my senior project.

Due to the whole volcano ash thing, we had to take the train from Tønsberg, Norway to Geneva, Switzerland(!!). Actually we didn’t have to, but we wanted to go, and after 4 days of “ash clouds, maybe there will be a flight, maybe there wont” we decided to just get there on our own.
The trip turned out a bit less smooth because the ordinary night trains from Copenhagen to Basel were full, so we had to wait 8 hours in Copenhagen and switch between several small regional trains in Denmark in the middle of the night. But hey, we got to see Copenhagen also 😉

The mainline news coverage of the volcano ash business has been all but sickening, but the following little comic made me laugh hard. Especially because of the supposed-to-look-icelandish language used:

'Put 30 billion euro in the garbage can infront of the icelandish embassy tonight, and we will turn off the vulcano! Don't call the police!'

‘Put 30 billion euro in the garbage can in front of the Icelandic embassy tonight, and we will turn off the volcano! Don’t call the police!’

Down at CERN, most of the shifts were pretty uneventful as there was seldom “stable beams”. The beam refers to the particles being accelerated (in the LHC in ALICEs case), and stable means that collisions are happening in a controlled manner so that you can actually start data-taking.
So, when you’re not taking data, sitting shifts mostly means noting down problems that occur with your subsystem, and possibly notifying the on-call expect if deemed serious enough. Actually, being a shifter on HLT should be like that all the time, as it is supposed to be a completely autonomous system in this aspect.
I got to work a bit on my senior project, a bit on MyPaint, a bit on other things, but didn’t really get to be as productive as I would have liked. Especially on the night-shift, I found it hard to do any serious work. Strange, as I often have my most productive times after midnight when at home.

One thing I regret the most is packing too much clothes, and not bringing a camera. Even if we didn’t really do a lot of very exciting stuff, it still would have been nice to have pictures; Capturing the moment, binding the state of mind at that instant to something physical, for easier retrieval at a later time.

Senior project screenshot and X11+SSH tip

So, I have not really written that post describing my senior project yet (well, I have a draft…), but here is a visual teaser at least:


To get this nice image I had to do some X11 forwarding over SSH through an intermediate server. And since I’m probably not the only one with such needs and I’m bound to forget how I did it I will post it here.

Basically I used this excellent reference. But if you need trusted X11 forwarding (like with ssh -Y instead of -X) you need to generate an xauth file as an extra step when you’re on the remote server. That can be done with “xauth generate $DISPLAY .” And the “nolisten tcp” config option that you need to disable locally is usually found in /etc/X11/xinit/xserverrc
Additional heads up: if you try and connect with -X in addition to this manual forwarding you are setting up, you might get strange errors like “X connection to localhost:10.0 broken (explicit kill or server shutdown).” So don’t do that.

GPGPU in ALICE workshop

I’ve attended a small workshop/seminar in Bergen (at IFT) about nVidia CUDA and its use in the ALICE project at CERN. The goal for me and the other students from Vestfold University College was to get a concrete task for our senior project and to get up to speed on some of the things we need to get started.

The three days were heavily packed with information, so this will just be a tiny tiny summary. I will probably write up some posts explaining some parts in more detail later. If I can get a hold of the presentations given I will link them here.


Day 1:

Why parallelize and why GPGPU?

Computing units does not scale simply by frequency anymore so we need to parallelize to increase performance. GPUs are commodity hardware designed for massive parallelism driven forward by  a huge consumer market in 3D graphics => provides high performance, low cost, is flexible and easy to use compared to DSP, FPGA, custom vector CPUs etc.

The Nvidia CUDA platform

Describes the underlying hardware platform and a concept for accessing this from a high level language (C with some C++ and custom extensions). Current generation has approx 200 stream processors and is designed to have several thousand threads running at the same time. There are cards especially for GP-computing (Tesla-series), but for a lot of computations the high end GeForce cards are good enough. Practically all newer GPUs from nVidia is CUDA capable, all the way from the Ion found in netbooks/net-tops.

CUDA programming model

Functions called kernels are executed on the device. All threads will run this same code, differentiation on which threads do what is done by using their IDs in statements. Threads are grouped into blocks, blocks are grouped into grids.  The number of threads/blocks is specified on kernel invocation and used for scaling to different devices. Memory is divided into several parts, each of which needs be handled manually. Device <=> host transfers is also done manually.

Day 2:

The TPC and HLT in ALICE.

Incredibly high data rates, not feasible or wanted to store all raw data  => some processing/analysis needs to be done in real-time (“online”). This can be done now using a large cluster of machines (the HLT). Using GPUs will allow this cluster to consist of a smaller number of nodes => cheaper and will free resources for other things like offline analysis.

Optimizing CUDA code.

Calculations are fast, (global) memory is slow => Focus on reducing and optimizing memory access. Designed for massive parallelism => make sure your problem sizes are big enough and that you’re split the problem in a good way.

Day 3:


Basically the CUDA model + vendor/platform independence – C++ features, otherwise only minor differences => Should be easy to port to and understand when you know CUDA. Implementations on the way, also for CPUs (x86 with SSE and Cell) and DSPs (Texas Instruments). Likely to be a good candidate for scientific computing in the future.

CUDA-ified tracking code

We had a look at how CUDA has been implemented to do a task within the AliRoot framework used in the HLT allready. Some concept mismatches leads to having to wrap code in somewhat ugly ways.  Further uglified/complicated by the fact that the same code should be able to run on either the CPU or GPU.

Our task: Vertex finding

More about this in a later post!


I brought a camera along, but as I’m not used to having one with me I completely forgot to take pictures. We did get to see Bergen a little bit, tho we spent most of our time on the CUDA/CERN stuff.
And there was rain. Every day, all day pretty much. Not sure how I’d cope with that if I lived there.

Senior project confirmed

I will be implementing algorithms on nVidia graphic cards using CUDA for use at CERN. Its a collaboration project between my school, the university of Bergen and a university in Germany (presumably Heidelberg). While a lot of the specifics are still up in the air, it will most likely be for the High Level Trigger system for the ALICE sensor.

ALICE is the sensor system which will be used for studying the biggest particle collisions at CERN when their new particle accelerator gets up and running again this fall and throughout next year. They will be colliding lead nucleus in order to recreate the conditions that existed under 1 billionth of a second after the Big Bang.  In these experiments one hopes to find out more about quark-gluon plasma.

Needless to say this is a really exiting project for me. Not a lot of people are so lucky and get to work on such a grand thing for their senior project.  I expect plenty of good technical challenges. And who knows, maybe there is even an opportunity for more than a senior project here?

First up is an introductory course in Bergen on the 5th-7th of October to get up to speed and a concrete assignment. I also hope to get some exploratory coding with CUDA before that time.