Boeing 737-800 Home Cockpit (Linux-based, notably …)

Back in 2004 I started to think about how I could build a real airliner cockpit entirely based on Linux. I  At the end of 2017 (and with a grown family) this idea has evolved into a fun project. The way to that goal is still a long and a very creative one. But today I can share first of all a few specifications of how I proceeded with it and you will find a few images documenting the current status of my Boeing 737-800 (NG) home cockpit.

The first thing to think about when running linux is which flight simulator to pick. The number of candidates is barely countable … For entirely open source fanatics Flight Gear would be the way to go. However, X-Plane was my choice because of its highly sophisticated aerodynamics and visual simulation quality. And X-Plane is extendable on just about every side.

The second thing to think about is how to connect hardware to your Linux box and to the flight simulator itself, and then, which hardware to pick (or vice versa). Hardware there is much. But all available software interfaces are written for Windows-based flight simulators and most of them again for the Microsoft Flight Simulator itself. I have chosen the famous OpenCockpits set of I/O cards for my project and extended it with Leo Bodnar‘s even ore famous joystick and I/O cards.

The way to go was to invent my own interface to OpenCockpits and Leo Bodnar’s I/O cards. I call it xpiocards and it is managed as open source together with my colleague Hans who joins my linux home cockpit fate with his Airbus A320 cockpit. The difficult part was to reverse engineer the not-so-open Open Cockpits hardware communication (the blueprints are open, but the communication protocol is not). This yielded a highly stable USB communication to the client application usbiocards and to a even more stable TCP/IP communication to the xpserver server plugin in X-Plane. Since all the code is custom made I have full control over all issues and can correct bugs on the fly. This is not the case if you build a home cockpit with proprietary flight software. Isn’t it fun to have control over something so complex which is only enjoyable if your flight experience is free of glitches … especially at the last 100 feet prior to a difficult landing?

The great part of the current server client I/O application is that there is no need to manually edit plugin-side dataref list which is exchanged with the clients (in FSUIPC language: defining a list of offsets). The client (in fact any number of clients) simply subscribe to their specific datarefs which are then sent to them in regular intervals. In fact they are only sent if they are updated on the flight simulator side or updated on the client side. Isn’t this a marvellous idea? No need to exchange unnessesary data …

It all started with a few X-Plane datarefs being exchanged between X-Plane and a simple NAV radio panel based on OpenCockpits hardware. I have bought the I/O cards and panels and built the electronics myself. The weak part of OpenCockpits is the uneven backlighting capability and the “not so open” communication protocol of their I/O Cards.

A big progress has happened once my colleague Torsten from CockpitForYou has delivered the motorized B737 Throttle Quadrant. The package was huge and I had to get it from the cargo company office … since I do not own a car the picture above tells you how it can be done with our kids trailer: it is also a cargo bike!

The next great step forward was to complete the full B737 pedestal. For this Lausitz Aviation delivered a highly professional pedestal case in which I could mount the Open Cockpits panels and the underlying electronics.

The current final task was to mount a 55″ TV and also integrate and further develop the outdated OpenGC code into a fully functional Boeing 737 Primary Flight Display (PFD), Navigation Display (NAV) and Engine Indication and Crew Alterting System (EICAS) set of displays on a second monitor.

And yes: the best of all. My colleague Benedikt Stratmann from EADT is building the same beautiful plane with its full functionality by software as I am by hardware. So here you go: a big applause for EADT and their famous x737. You see the airplane above with the Air Greenland livery stationed at the Marina di Campo airport on the Elba island.

So here you get a list on the current hardware / software setup:

  • Tuxedo Computers XUX_Cube
    • CPU I4790
    • 16 GB DDR RAM
    • 256 GB SSD
    • NVIDIA GTX 970
  • Debian Stretch
  • X-Plane 10.51 (X-Plane 11 in testing, but stability is more important for me than features)
  • Boeing 737 NG from Benedikt Stratmann (x737 @
  • CockpitForYou Motorized B737 Throttle Quadrant
  • Lausitz Aviation Pedestal case with custom made panel holes drilled by my great colleague K.
  • 2 original Boeing 727 seats (anyone has the rails to them?) from e-bay
  • Open Cockpits USB Expansion Card and 3 Master Cards (2 Master Cards for Pedestal and 1 Master Card for MCP / EFIS Panels)
  • Logitech Z623 Speakers and Subwoofer
  • 55″ NEC Multisync E556 for Visuals
  • 23″ Apple Cinema Display for Glass Cockpit and System
  • Trustmaster Joystick and a set of CH Pedals
  • Two old but highly stable Melcher Power Supplies (5V and 12V)
  • A heater for winter and a ventilator for summer: the home cockpit is currently mounted just under our roof in a non-insulated area.

And watch out for more. The flight controls are in progress …


Our cozy and beautiful home after the first snowfall of 2017 in the swiss lowland.

Solar Potential of Switzerland

The Swiss Federal Office of Energy SFOE, the Federal Office of Meteorology and Climatology MeteoSwiss, and the Federal Office of Topography swisstopo have created together with Meteotest a stunningly interactive and publicly accessible solar potential estimator for whole Switzerland.

Solar Potential Map of Switzerland

Solar Potential Map of Switzerland

Compared to traditional so-called GIS-type “solar cadasters” this one is really usable. By usable I mean:

  1. loads incredibly fast
  2. step-by-step increase of complexity
  3. order-of-magnitude yield and cost of PV and heating system within 10 seconds
  4. all the options for professional users upon demand
  5. last but not least: open government data!


One click to the solar yield calculation of your roof!

One click to the solar yield calculation of your roof!

I’m of course a bit biased since I created and provided the satellite-based solar irradiance data to the project as part of my engagement within MeteoSwiss. But try it out yourself!

The Darkest Spot in Switzerland

By analysis of our MeteoSwiss high quality satellite-based solar irradiance maps created by the Heliomont algorithm I’ve found that the sunniest place in Switzerland is close to the Monte Rosa hut of the Swiss Alpine Club SAC. During the calculation of the Solar Atlas of Switzerland (to be published as “The Solar Cadaster of Switzerland” on the Geoportal of the Swiss Government) I have also detected the absolutely DARKEST spot in Switzerland. Here it is:

The point lies at 636125 / 93050 (CH1903 / LV03 coordinate system) at the border between Switzerland and Italy. It has as sky view factor of 0.003. This is about the same sky view as found in a bottomless pit. There is no solar irradiance getting down there. The yearly mean solar irradiance is around 0.5 W m-2 (Watts per square meter; the average over most of Switzerland is well over 150 W m-2). The reason for this low predicted solar irradiance can be found in the Swiss elevation model DHM 25 at the spatial resolution of 25 m. These are the topographic elevations (m) of the darkest point including its 8 neighboring points:

2996 2622 3414
2763 2440 3457
3070 3131 3484

The center point lies between 200 – 1000 m lower than the surrounding grid points. Is this bottomless pit in beautiful landscape reality or a digital artifact?


The customer service of SwissTopo has kindly provided a credible answer: The darkest spot is indeed an artifact of the DHM25 dataset due to a contour line which was digitized 1000 m below its actual elevation:

Swisstopo also notes that the point of interest is located just outside the Swiss border. Swisstopo suggests to discontinue the use of the DHM25 elevation dataset in favor of the swissALTI3D dataset. DHM25 is however convenient since it extends across the Swiss borders. A feature which is for instance needed for Terrain horizon calculations. My current fix is to limit sky view in natural terrain to values above 0.5 (it may be lower in urban environments). In a next step swissAlti3D could be joined with high resolution topography datasets of surrounding countries. 

Flowering in the Greenhouse

During the last few decades flowering and leafing of temperate and boreal vegetation has advanced by several days in response to warming. The climate sensitivity, as inferred from long-term observations, is estimated to be 2.5-5.0 days per degree C warming. Wolkovich et al. now show in their letter to Nature, that this response cannot be replicated in field experiments where vegetation is artificially warmed: in these experiments the warming effect on vegetation phenology is 4.0-8.5 times lower than in long-term observations:

E. M. Wolkovich, B. Cook, J. Allen, T. Crimmins, J. Betancourt, S. Travers, S. Pau, J. Regetz, T. Davies, N. Kraft, T. Ault, K. Bolmgren, S. Mazer, G. McCabe, B. McGill, C. Parmesan, N. Salamin, M. Schwartz, and E. Cleland. Warming experiments underpredict plant phenological responses to climate change. Nature, 485:494–497, 2012. doi: 10.1038/nature11014.

Two author teams, This Rutishauser and I, and John Harte and Lara Kueppers, have been invited to comment the letter by Wolkovich et al. Our comment was published today in the same issue of Nature:

T. Rutishauser, R. Stöckli, J. Harte, and L. Kueppers. Climate change: Flowering in the greenhouse. Nature, 485:448–449, 2012. doi: 10.1038/485448a. [PDF]

We conclude and suggest:
– Temperature effects are not independent from effects of other environmental changes
– Phenology is much more than a linear correlate to annual mean air temperatures
– Wolkovich’s call for ecosystem model re-evaluation has to be taken seriously

Finally, a very interesting question arises from the work by Wolkovich et al.:

“Are temperature sensitivities derived from past phenological observations valid for application in a future, warmer climate?”
We haven’t found the answer in the scientific literature (yet!).

Reto and This

Digital Object Identifiers

Digital Object Identifiers (DOI’s) are often used to uniquely identify and reference digital content of written documents such as scientific publications or books. This is helpful to track a content over a long time period, where the actual location of the content may change, but any reference to it will have to stay the same.

DOI’s are not just suitable for electronic documents but in fact for any digital content. We have now created a DOI for our long term satellite-based Surface Radiation MVIRI Dataset from the Satellite Application Facility on Climate Monitoring by Rebekka Posselt, Richard Müller, Reto Stöckli and Jörg Trentmann (2011):

Remote Sensing of Solar Surface Radiation

We have processed a global irradiance and direct irradiance climate data record from the Meteosat first generation satellites (Meteosats 2 to 7, 1983–2005). The CDRs are available free of charge for all purposes from the EUMETSAT‘s Satellite Application Facility on Climate Monitoring Web User Interface at monthly, daily and hourly means at a spatial resolution of 0.03 degrees.

Climatologies of global (SIS) and direct beam (SID) surface radiation over Europe and Africa derived from Meteosat First Generation Satellites

The processing employed a climate version of the well known Heliosat algorithm combined with a open source clear sky model (gnu-MAGIC) using an eigenvector look-up table method. Modifications to the Heliosat method include a self-calibration algorithm as well as a running mean based clear sky retrieval algorithm.

More information to this dataset and related algorithms can be found on our CM SAF project web site at MeteoSwiss.

R. Posselt, R. W. Mueller, R. Stöckli, and J. Trentmann (2012). Remote sensing of solar surface radiation for climate monitoring — the CM-SAF retrieval in international comparison. Remote Sens. Environ., 118:186–198. doi: 10.1016/j.rse.2011.11.016.

How to “bluemarbelize” Google Maps?


Google Maps and Google Earth (hereafter Google Maps) are publicly available tools useful to visually explore the geography of our planet. Globally distributed high resolution satellite data are used as a background to dynamically map physical, geographical, historical, socio-economic or political thematic layers. Nowadays the average, educated person with access to the internet either interactively applies Google Maps for commercial or private activities or passively uses it through media coverage. Hence, the perception of the earth’s visual appearance is successively becoming based on this particular data source.

Google Maps have a highly advanced interface for simultaneously merging and displaying a complex set of data sources. The thematic layers of Google Maps are accurate and they often include real-time information. The background imagery, however, lacks some level of realism, identified here as a weak treatment of the underlying satellite data. Scientific and technical methods were for instance developed and applied in NASA’s Blue Marble Next Generation project (hereafter BMNG, to correct for such issues, and they could serve as a guideline to improve Google Maps. The aim of the following discussion is therefore to outline a few methods that could yield better spatial consistency of the satellite data used in Google Maps. It is important for educational and scientific purposes that the public perceives a realistic view of our planet.

The discussion is accompanied by the following slides, presented by me in a video conference at Google Zurich on 28 February 2012.

Problem Description

Himalaya in Google Maps

Google Maps offer amazing detail when viewed at the street, city and landscape scale. However, regional and continental views of our planet often appear rather discontinuous as a patchwork of different satellite scenes and as a mix of true and false color composites. Problematic regions also include those with a distinct seasonality such as temperate and boreal climates, regions with heavy cloudiness such as the tropics, and regions with high aerosol loads such as areas with biomass burning or with urban pollution.

Most discontinuities are a result of stitching temporally discontinuous satellite datasets with differing atmospheric disturbances, directional effects of the sun-earth-satellite viewing geometry, spectral differences between satellite sensors and last but not least the seasonal differences of the earth surface’s vegetation and snow cover. Most of these effects can be overcome if suitable satellite remote sensing algorithms are applied. We have demonstrated it for the BMNG at 500 m spatial resolution (Stöckli et al. 2005).

Possible Solutions

Himalaya in the Blue Marble Next Generation

In order to carry out a similar set of corrections for Google Maps, fundamental processing of satellite data using well established algorithms could firstly be applied to the satellite scenes used for Google Maps. Secondly, novel methods would have to be developed in order to optimizespatio-temporal compositing of those satellite scenes.

1) Scene Processing

The aim of scene processing is to retrieve the surface reflectance (visible and near-infrared spectral bands) or brightness temperature (infrared spectral bands) for cloud free pixels in each satellite scene. This is mandatory for the further retrieval of physical properties from a satellite dataset. It can be applied to most satellite sensors, including those used for Google Maps (e.g. Landsat, SPOT and probably even to GeoEye, Worldview and QuickBird). Scene processing can be computationally expensive but mature algorithms are publicly available from the science community (for instance the LEDAPS code; Masek et al. 2006). Scene processing requires the existence of level 1 or 1b satellite data including extensive metadata (like sensor calibration, geographic registration, satellite radiances etc.). Processed satellite images or image composites cannot be used for physical retrievals and corrections.

The following steps (among others) are carried out during scene processing:

  • registration & navigation
  • removal of geometric and radiometric artifacts
  • orthorectification
  • radiance (inter-) calibration degraded sensors (de Vries et al. 2007)
  • cloud masking (Khlopenkov and Trishchenko 2007)
  • correction of atmospheric effects (Vermote et al. 2002)
  • spectral conversion to pre-defined bands

Scene processing can yield cloud-free surface reflectances that also include per-pixel estimates of the retrieval error. This error can be defined heuristically from quality flags of each processing step. It can also be estimated by using bayesian algorithms, such as for instance a cloud mask based on an optimal estimation technique. Retrieval errors are an important input for scene compositing, where the clear sky surface reflectances are used for the estimation of model parameters.

2) Scene Compositing

The aim of scene compositing is to achieve spatial consistency by merging the corrected and masked scenes from above processing in time and space. Simple spatial stitching methods are often used, but they cannot provide spatial consistency. Often, neighboring scenes are from a different season or year and they do neither match solar illumination geometry nor the highly variable state of surface. A composite will then have visible boundaries where stitching took place. A better result can be achieved by temporal compositing from a stack of seasonally distributed scenes of the same area of interest. The composite for a given pixel, date, solar and view geometry is then calculated by use of a time series analysis approach. This requires the availability of satellite data with a high enough temporal revisit frequency (every month or less), or with long enough temporal coverage (many years of observation).

The following steps (among others) are required for scene compositing:

  • calculate surface BRDF effects
  • calculate seasonal dynamics of vegetation
  • remove gaps with temporal interpolation

All three steps are best calculated together in one single algorithm since they involve the inversion of semi-empirical models where 3-10 parameters have to be fitted to each pixel. The parameter space often is characterized by a high order of equifinality, thus the minimization of the involved cost function is not trivial. The simplest approach uses 2nd and 3rd order Fourier series and yields a mixed retrieval of BRDF and seasonality based on 2-3 parameters per pixel. If a BRDF model and a phenology model are both available, an optimal estimation or ensemble-based bayesian data assimilation could be applied to retrieve 6-8 parameters per pixel (Stöckli et al. 2011). In case of a poor temporal coverage, multi-sensor parameter estimation may be applied. This for instance means that a landcover-dependent set of BRDF parameters is firstly estimated at MODIS pixel scale. MODIS-based parameters are then down-scaled and applied to Landsat or SPOT resolution (Li et al. 2010).

Conclusions and Outlook

The key ideas outlined above are that scene compositing employs the temporal domain to guarantee consistency of the resulting composite in the spatial domain. The underlying data source has to be properly processed beforehand, and it needs to have a high enough temporal coverage. Such a framework has been successfully applied in the generation of the BMNG dataset. With little or no spatial dependencies involved, the required computations, specifically the model inversions for parameter estimation, can be parallelized very efficiently.

What has worked for the BMNG using MODIS data does not necessarily have to be applicable to other satellite data. NASA’s MODIS sensor offered well-calibrated data at a high temporal revisit frequency and the MODIS science team guaranteed that scene processing was carried out with state-of-the-art algorithms. The scene compositing employed for the BMNG project was therefore based on data that fulfilled very high technical and scientific standards.

In order to find out how Landsat and SPOT based global satellite composites could be generated, the following questions would need to be answered:

  • What kind of processing and compositing is applicable to the Landsat and SPOT satellite data (inventory of data sources)?
  • What kind of processing and compositing can be readily applied and yield good improvements (low hanging fruit)?
  • Which processing and compositing step would yield high improvements at a high investment (exceptionally sweet but high hanging fruit?)
  • Which scene processing has already been applied to Landsat and SPOT data (inventory of methods)?
  • Which scene compositing has already been applied to Landsat and SPOT data (inventory of methods)?
  • Which scientific and technical methods are available and have been successful (literature review)?
  • What are the most wanted user requirements (prioritize tasks)?
  • Which are the geographic areas that need most attention (prioritize region)?
  • Has anything similar been done at the MODIS, SPOT, Landsat science team (harvest knowledge, avoid duplication)?

Based on such an “inventory” a strategy could then be generated for how to improve, what to improve and where to improve at what cost. Even a partial execution of scene processing and compositing could result in a substantial improvements of the Landsat and SPOT based satellite layer used in Google Maps.


R. Stöckli, E. Vermote, N. Saleous, R. Simmon, and D. Herring. True color earth data set includes seasonal dynamics. EOS, 87(5):49, 55, 2006.

R. Stöckli, T. Rutishauser, I. Baker, M. Liniger, and A. S. Denning. A global reanalysis of vegetation phenology. J. Geophys. Res. – Biogeosciences, 116(G03020), 2011. doi: 10.1029/2010JG001545.

F. Li, D. L. B. Jupp, S. Reddy, L. Lymburner, N. Mueller, P. Tan, and A. Islam. An evaluation of the use of atmospheric and brdf correction to standardize landsat data. Ieee Journal of Selected Topics In Applied Earth Observations and Remote Sensing, 3(3):257–270, Sept. 2010. doi: 10.1109/JSTARS.2010.2042281.

C. de Vries, T. Danaher, R. Denham, P. Scarth, and S. Phinn. An operational radiometric calibration procedure for the landsat sensors based on pseudo-invariant target sites. Remote Sensing of Environment, 107(3):414–429, Apr. 2007. doi: 10.1016/j.rse.2006.09.019.

E. F. Vermote, N. Z. E. Saleous, and C. O. Justice. Atmospheric correction of MODIS data in the visible to middle infrared: first results. Remote Sens. Environ., 83:97–111, 2002.

J. Masek, E. Vermote, N. Saleous, R. Wolfe, F. Hall, K. Huemmrich, F. Gao, J. Kutler, and T. Lim. A landsat surface reflectance dataset for north america, 1990-2000. Ieee Geoscience and Remote Sensing Letters, 3 (1):68–72, Jan. 2006. doi: 10.1109/LGRS.2005.857030.

K. V. Khlopenkov and A. P. Trishchenko. Sparc: New cloud, snow, and cloud shadow detection scheme for historical 1-km avhhr data over canada. J Atmos Oceanic Tech, 24(3):322–343, Jan 2007. doi: 10.1175/JTECH1987.1.


Art from Space

I am working on a solar position and orbit predictor application for the International Space Station that will serve as planning tool for a new art project of Christian Waldvogel.

For updates visit his website

Satellite-based planning of Solar Energy Applications

My tasks at MeteoSwiss include the analyses of the spatial and temporal variability of the surface solar irradiance with special emphasis on the complex Alpine terrain and the diverse interactions of horizon, snow cover and cloudiness in this terrain. One major result of this work is a satellite-based climatology of solar irradiance including its radiation components derived from Meteosat Second Generation SEVIRI data back to 2004.

The potential yield of solar irradiance (kWh/m2) for Switzerland fo rthe period 2004-2009. The map was derived from Meteosat Second Generation satellite data with special emphasis on the complex interaction of topography, snow cover and cloudiness.

The data set can be used to evaluate the suitability of a photovoltaic or thermal power plant or for calculating the energy consumption of a building. The data set currently covers the area of Switzerland at a spatial resolution of around 1-2 km and a temporal resolution of 15 minutes. It can be extended to any location and region over Europe and Africa upon request, and it can be extended in time by unifying it with our long term climate data record based on the Meteosat First Generation satellite.

More information including a point of contact for ordering the data can be found on the MeteoSwiss Solar Energy website.