Using Raspberry PI to control Märklin model railway – Part 1

For my latest project, the Mariannenbahn, I needed to find a way to control a Märklin model railway from different rooms. While this is obviously possible using multiple Märklin Central or Mobile Stations, it was not an option at the time as the project already hit its budgetary ceiling.

This solution is intended as a temporary replacement for an additional Märklin control device and research was done out of curiosity. Go and buy their stuff.

Thanks to an outstanding blog post on as well as Stefan Krauß’ homepage , a solid groundwork was already present.


The Märklin Digital Connector Box is a device containing a signal processor that generates the digital signal on the rails. It communicates with controllers, such as the Mobile Station , via CAN bus using a protocol defined and thankfully published by Märklin. It is therefore possible to use any device capable of transmitting data over CAN to control the model railway. Using a Raspberry PI together with a ready-made CAN extension module seemed like a good and safe solution, as various people already proved that this setup usually works.
Since it is usually common to use the Raspberry PI via SSH instead of a display connected, a piece of software taking commands via Ethernet and hand them over to the CAN bus is required. That way, it is possible to install the PI somewhere close to the Märklin Digital Connector Box and the railway layout. Connected to the LAN, it will take commands from any Ethernet-capable device such as personal computers or even smartphones. Gerhard Bertelsmann has written a wonderful C program called can2udp for exactly that purpose. It will hand over commands between Ethernet/UDP and the CAN bus.
As a final step, software to produce the actual commands to be transmitted to the Digital Connector Box is required. The most obvious solution available for this task is Rocrail.

CAN controller

After some research, I decided to get a PiCAN2 board form SK Pang Electronics . Getting it running is quite straightforward. On the downside, I found it inevitable to solder a 2-way header pin as jumper bridge to the board myself to be able to use the 120Ω terminator already present on the board.

Hardware installation

Activating the terminator resistance is described in the manual. Mounting the board is easy, it only fits one direction. It is possible to either use the DB9 Connector or the screw terminal on the PiCAN2 to connect it to the Märklin Connector Box. The pin assignment on the Märklin Connector Box is described by Stefan Krauß.

Software installation

I was using a Raspberry PI 2 running the latest Raspbian. I wasn’t able to get the PiCAN2 running with the latest (4.4.16) firmware though. I used rpi-update to go back to 4.1.21 which worked for me some time ago. I did not do any investigation on which exact version introduces the breaking changes. If you find out, please let me know. To install a working firmware, rpi-update can be used with the version’s commit hash:

Following the manual, the following three lines have to be appended to /boot/config.txt:

After a reboot, the CAN interface can be brought up.

See the troubleshooting section on information about how to verify the interface is up and running properly.


can2udp is a beautiful C program that hands over messages from Ethernet/UDP to CAN and back. The usage is:

Given the default setup, it is sufficient to call ./can2udp -f -v, which will bring up can2udp in foreground with verbose output. It will send a certain initialization package to the Märklin Digital Connector Box on startup.

Client software

Almost any literature on the topic is using Rocrail as client software. Due to the lack of any real alternative, it is what I am using too at the moment.

I do not really like Rocrail. It was supposed to be open source software licensed under GNUv2 until the owner apparently stared spamming ®s all over and shutting down their public GitHub repository, even admonishing others to remove their forks of the GNUv2 licensed code. To make matters worse, an annoying pop up dialog tries to lure users into buying a support key.

The setup described in this post simulates the use of a Märklin Mobile Station 2, so the setup for Rocrail is identically to that scenario and can be found on their webpage or on

Where to buy

I was able to get a Märklin Digital Connector Box (60113) together with the required Märklin 36VA Switched Mode Power Pack (66361) from a local retailer. Märklin appears not to be selling the Digital Connector Box anymore, but still its quite easy to get one on eBay or Amazon.


If the CAN interface is set up correctly, it will be listed in the output of ifconfig as can0. Both the bcm2835 and the mcp251x controllers must be listed in the output of lsmod. Errors in the initialization process will also show up in the output of dmesg. It might be wise to grep for bcm2835 there.


“Hexxeh/rpi-update,” GitHub. [Online]. Available: [Accessed: 07-Aug-2016]
“RocRail going closed source? • /r/modeltrains,” reddit, 14-Oct-2015. [Online]. Available: [Accessed: 07-Aug-2016]
Rocrail, “Welcome to Rocrail ®,”, 03-Aug-2016. [Online]. Available: [Accessed: 07-Aug-2016]
G. Bertelsmann, “M*rklin CS2 Gateway emulator,” GitHub, 2016. [Online]. Available: [Accessed: 07-Aug-2016]
SK Pang Electronics, “PiCAN2 CAN-Bus Board for Raspberry Pi 2/3 [RSP-PICAN2],” SK Pang Electronics, 2016. [Online]. Available: [Accessed: 07-Aug-2016]
Gebr Märklin & Cie GmbH, “Digital Connector Box | Märklin,” Märklin, 2016. [Online]. Available: [Accessed: 07-Aug-2016]
Gebr Märklin & Cie GmbH, “Mobile Station | Märklin,” Märklin, 27-Jul-2016. [Online]. Available: [Accessed: 07-Aug-2016]
Gebr. Märklin & Cie. GmbH, Göppingen, “Kommunikationsprotokoll Graphical User Interface Prozessor (GUI) <-> Gleisformat Prozessor (Gleis Format Prozessor) über CAN Transportierbar über Ethernet.” Gebr. Märklin & Cie. GmbH, Göppingen, 07-Feb-2012 [Online]. Available: [Accessed: 07-Aug-2016]
“CAN bus,” Wikipedia, the free encyclopedia. 29-Jul-2016 [Online]. Available: [Accessed: 06-Aug-2016]
S. Krauß, “Märklin Gleisbox als Zentrale,” Homepage Stefan Krauß, 2012. [Online]. Available: [Accessed: 06-Aug-2016]
S. Krauß, “Anschluss des CAN-Interfaces an die Gleisbox,” Homepage Stefan Krauß, 2012. [Online]. Available: [Accessed: 06-Aug-2016]
Decision Developments, “Controlling Märklin Digital Railroad with Raspberry Pi(Raspi) and Rocrail,” Controlling Märklin Digital Railroad with Raspberry Pi(Raspi) and Rocrail, 2016. [Online]. Available: [Accessed: 06-Aug-2016]

LoopBack + AngularJS authentication solution

In this article I’m going to describe the way I use LoopBack’s authentication service in connection with an AngularJS app on client side. While primarily based on the LoopBack getting started intermediate  tutorial, I tried to merge in John Papa’s style guidelines as well as a few other blog posts on the matter.

Server side

LoopBack offers a flexible system to build an authentication system that suits the demands of your application. The documentation on Users, Roles, RoleMappings, ACLs etc. is quite comprehensive , so I don’t feel like there is a lot to add on this side. AngularJS will use the automatically generated services in lbServices.js to communicate via the REST API.

Client side

Of course, everything we are going to do here is providing a nice user experience by hiding routes and endpoints the current user has no access on. Since all code can possibly be altered by the client, essential security measures are to be taken on server side.

Status broadcasts

As LoopBack already offers a solid groundwork, the only real addition is a broadcasting system offering authentication status changes so that all parts of the application can adapt to new situations accordingly. I picked up a lot of ideas from a wonderful article by Gert Hengeveld in which he introduces a broadcasting system based on constants for the respective authentication states. Angular’s broadcast system is a controversy topic and according to the widely recognized Angular Style Guide by John Papa , we should avoid using it at all. However, while I see the risks of event-spamming if we talk about inter-controller communication, an authentication state broadcasting system is probably the only case where I opt for Angular events.


The basic idea is that whenever a call to authService is made, we make sure to publish all relevant state changes using Angular broadcasts. These are, among others you might find useful in your application, LOGIN_SUCCESS , LOGIN_FAILED and LOGOUT_SUCCESS .
The following diagram is showing dependencies between the components in the discussed authentication-state broadcasting system. The dashed lines are injects.
Diagram that shows dependencies between components in the introduced authentication system.
Next, I tried to model a basic procedure where a user submits the login form and gets redirected to the application’s main page. Since the user is authenticated after that, the menu bar has to show differing items and maybe include the user name in the upper right corner. The diagram below shows all that.Sequence diagram of a basic login procedure.



StrongLoop, “Controlling data access - LoopBack - Documentation,” Controlling data access. [Online]. Available: [Accessed: 29-Sep-2015]
StrongLoop, “Defining and using roles - LoopBack - Documentation,” Defining and using roles. [Online]. Available: [Accessed: 29-Sep-2015]
StrongLoop, “Authentication, authorization, and permissions - LoopBack - Documentation,” Authentication, authorization, and permissions. [Online]. Available: [Accessed: 29-Sep-2015]
G. Hengeveld, “Techniques for authentication in AngularJS applications: A collection of ideas for authentication & access control, Communicating session changes, The AuthService, Restricting element visibility, Restricting route access, The loginDialog directive, Read my other articles:,” Medium, 13-Mar-2014. [Online]. Available: [Accessed: 27-Sep-2015]
John Papa, “Angular Style Guide,” GitHub. [Online]. Available: [Accessed: 25-Sep-2015]
StrongLoop, “strongloop/loopback-getting-started-intermediate,” GitHub. [Online]. Available: [Accessed: 25-Sep-2015]

Cloud-hosted continuous integration solutions 2015

For a new project at work, we needed to setup a continuous integration routine. As we don’t really have the capacity to host it on our own, I decided to make a brief market analysis of the available solutions in late 2015.

While my research was done with a certain project configuration in mind (a web platform running Node.js with Angular), I’m sure it can be useful for other types of projects as well.

Travis CI

Extremely popular as a lot of open-source projects hosted on Github use their free plan. The documentation is comprehensive and clean [1] plus there are tons of related posts on stackoverflow. I also found a dedicated section on browser testing. They even offer to run your script on Mac hardware [2] allowing to test on the most recent versions of Safari. The downside however is the price. Their plans start from 129$ excl. VAT per month for 2 concurrent build jobs. [3] Also, your sources must be hosted on GitHub as there is no support for any other type of repository.


Codeship is definitely worth a look for small companies as they offer a free plan with 100 builds per month, as well as an unlimited personal plan for 49$ per month. However, this does not allow to reflect organizational hierarchies in terms of account management. The organizational plan is 99$ per month. [4] Codeship supports both Github and Bitbucket, however there is no way to use any other type of repository. [5] They also do not offer builds on Mac hardware. I skimmed over their documentation and it looked clearly arranged and pretty extensive. [6]

Circle CI

Circle CI offers the most generous free plan of all solutions. You get unlimited builds for one repository for free. Any additional container is 50$ [7]. Their documentation looks good with lots of real-world examples and technology-specific tutorials. I discovered a section on iOS builds on Mac hardware. [8] While this feature seems to be experimental at the moment, it might indicate that Circle CI is planning to offer Mac hardware for regular build jobs in the near future. As for SCM, only Github is supported. [9]

Jenkins CI on AWS

This section is hard to evaluate since I don’t have any experience how much resources Jenkins will actually use. However it is possible to answer a few obvious questions. You will have to spend a lot of time setting up and configuring Jenkins, even more so if you plan to use its EC2 features allowing it to scale by launching additional instances on demand. There is clearly no way to use Mac hardware and although there is no actual limit on build jobs, make sure you have set AWS billing alerts.


Since pricing policy differs from company to company, I decided to compare the first plans that offer unlimited builds on 2 concurrent jobs.

Price and feature comparison
Travis CI Codeship Circle CI Jenkins CI on EC2
Github yes yes yes yes
Bitbucket no yes no yes
Private SCM no no no yes
Mac Hardware yes no iOS no
Concurrent Jobs 2 1(2)* 2 ultd.
Ultd. Plans from 129$ 49$(99$**) 50$ ?
Setup easy easy easy hard
SSH Debugging no*** yes yes yes

* Only one concurrent job but 2 parallel test pipelines
** Organization plans including account management from 99$
*** Various blog posts indicate that they will launch a VM for you to debug your scripts



Vagrant – Provisioning

In the first part of this tutorial series, we set up a fully working vagrant environment with Ubuntu running on our guest machine.

As we used an existing box from Vagrant Cloud, we now going to figure out possibilities how to adapt this default machine according to our needs. In this post, how to install additional software using the Ubuntu package manager.

The most easy way to adapt our virtual machine according to our needs, is to simply run commands from the Ubuntu shell. In this post, we want to install the GNU Compiler Collection which can be done by  $ sudo apt-get install build-essential . We could now just ssh into our guest and install the package by hand, but that would require us to repeat this step every time we choose to destroy our virtual machine using $ vagrant destroy or move on to another host. Luckily, there is a way to have Vagrant doing this for us when initializing a new virtual environment. By adding the following lines to our existing Vagrantfile, we tell Vagrant to use a basic shell for provisioning. We can even specify a relative path to a bash script.

The file , located right next to our Vagrantfile, is now being used to provision our guest machine. Now we create that file with the following content:

This will make sure that our development environment always has this package installed.

Vagrant – First steps

For my latest work with the tesseract-ocr engine, I needed to set up a C++ development environment. Working with the GNU CC under Linux is not as painful and complex as it can be under Windows which I am currently running as my main OS. Additionally, I needed to be able to work on multiple machines. If you are looking for a way to synchronize development environments across different machines and workplaces, Vagrant is definitely worth a look. It runs under Linux, Mac OS X and Windows.

This post covers the set up of a development machine running Ubuntu with the basic GNU Compiler Collection installed.

Vagrant does not provide its own virtualization technology, instead it runs on top of the most common providers such as VirtualBox, VMWare or even AWS. Vagrant handles the process of downloading and installing an operating system, installing and configuring the required software on that machine and also simplifies the way that machine can be shared with collaborators e.g. via a SCM.


At first, we need to download a virtualizing software. I already got Oracles’s VirtualBox installed, which is why I chose it as my Vagrant virtualization provider. It is freely available as OpenSource software for both personal and enterprise use and can be easily installed from here.

Once we got our virtualization stack running, we can download Vagrant from and run the installer.

Configuration and first launch

To initialze Vagrant, we create a new directory for our project (note that this is most likely going to be the root directory for our repository). Open a terminal, navigate into that directory and run the command

to create an initial Vagrantfile. The Vagrantfile tells Vagrant what kind of environment needs to be set up. As we don’t want to download and install an operating system for our development environment on the guest machine, we are going to use some kind of base image called box in Vagrant. Vagrant Cloud offers a large variety of boxes from different vendors, and with different operating systems and software stacks installed. As mentioned above, we are going to have a basic Ubuntu installation which is why we choose ubuntu/trusty64 . To tell Vagrant which box to use, we have to open the Vagrantfile and modify the following line:

Note: We could have achieved this by running $ vagrant init ubuntu/trusty64 instead in the first place.

To boot and ssh into our virtual development machine, run the following two commands:

After a successful ssh connection, we end up in the Ubuntu shell in the home directory of the user vagrant . Vagrant automatically synchronizes directories between your host and the guest machine. By default, only the directory containing our Vagrantfile will be kept in sync. It is mounted under /vagrant in Ubuntu. Run the following commands on the guest to create an empty file in the synchronized folder:

This should list the newly created file, but also our Vagrantfile. The file testfile.txt should be present also in our hosts filesystem.


Run logout to close our ssh connection with the guest OS, and shut down the guest machine gracefully using


depending on whether we want to just suspend it into RAM, shut the VM down or completely destroy the VM including it’s disk and all of its contents. For more information about this topic, you might want to have a look at the corresponding Vagrant documentation article.

At this point, we got a fully working guest machine running Ubuntu Server 14.04 LTS (Trusty Tahr) with file system synchronization.

You might want to move on to Vagrant – Provisioning and take a look on provisioning a virtual machine using Vagrant.