Some pictures, showing the church and the grave of Strauss, can be found here. (Click this link only if you are prepared for some hundreds of kilobytes, as all the pictures are on the same page.)
The purpose of the system is to measure 3 distances with a resolution of 0.1mm. The distances are in the 10-20m range. The devices used are DATA DISTOs, from Leica AG CH-9435 Heerbrugg. They were modified to run without the internal batteries, getting their power externally instead. These tiny devices (225 x 88 x 46mm) are mounted on solid bases outside the nave. Three holes with a diameter of 80mm were drilled through the walls and the lasers beam through them to the target markers on the other side.
The Installation Under The Roof
The connection of the DISTOs is via a RS232 to an interface logic, mounted on the wall. The enclosure of that interface includes a 7-channel temperature measurement facility. Temperatures at several points inside and outside of the church are measured to evaluate the effect of changes. There are two sensors near the DISTOs, two at the two targets, one in the zenith of the nave, two at the outside, just under the roof, to the north and the south of the church, respectively. Those at the targets and at the DISTOs are used primarily for compensation of the readings of the DISTOs (the speed of light in the atmosphere is a function of the temperature!). The others are there to get insight into any temperature related effects that can be the reason for the cracks.
The Installation In The Sacristy
From the location under the roof a cable runs down into the sacristy where the main part is located. First, the cable runs into a corresponding interface logic that translates the RS485 signals (on the cable) to their original levels (RS232 or TTL). From the interface the cable(s) run to a PC, one to a multiple serial port card and one to the parallel port. The DISTOs are connected each to a serial port, and the temperatur measuring subsystem is driven via the parallel port. Have a look at the front of the cabinet. (Sorry, the picture is of not so good quality.)
The PC (486, 66MHz, 8MB RAM and 300MB disk) runs under Linux. The access to the sources made it easy to implement a driver to support the SPI (MicroWire) protocol for the temperature subsystem. (The heart of it is a Maxim A/D-converter with a SPI-interface.) The SPI interface is realized on the parallel port and is represented as a character device under /dev. If you are interested in the source code of this driver, have a look in our download area. The driver is called something like spi*.tgz (the asterisk here indicates that we will name the driver in a way that tells what it is, followed by a revision and the ending of tgz (tar file, compressed with gzip)).
The measurements are performed by a user level software that is started periodically (currently once per hour, some minutes past the full hour). The raw readings undergo some plausibility checks (for the temperatures) and some for measurement uncertainity (the DISTO readings). If necessary, further readings are taken until the tolerance criteria are met. The data then is stored at multiple locations on the disk. The evaluation of this data is done at the Geodätisches Institut (Institute for Surveying) at the Technische Universität München, Germany.
Originally they collected the data via modem and an automated script in regular intervals. But since early in 2001 the system sends the data via email once a day. And having this nice feature we set it up to send an email whenever an abnormaly occurs (e.g. power fail). We had some power fails in the past; 2 occurred at Friday evening. Someone switched off the main circuit braker carelessly. So we noticed that not before Monday morning. Now we get an email within minutes in such a case and we can immediately call them to look after it - before they leave for the weekend.
We had only one hardware failure up to now (Mar 2002). The modem died. There were no crashes or hangs. But we had to reboot the system early in 2001 due to an upgrade of Linux and in October 2001 due to a major reconfiguration of our software. The latter reboot was just to assure that everything was ok and that we did not overlook some configuration parameters. There are no planned modifications for the next years.
To understand the principle have a look at this explanation. There are 8 distances to be measured - actually we monitor only changes in these distances. The sensors are connected to a box, which contains the counters and the interface logic. Additionally there is a temperature measuring system integrated. The data is sent to the PC (a laptop with Linux in this case) on request.
In Altomünster we needed a 9.th measurement channel. So, we took a Heidenhain interface and recycled a box (an interface we shipped to the customer in 1982 - still fully functional) for the connection to the PC. And unlike Rott, here the data is displayed on the screen, in addition to be saved on disk and mailed once per day. To make that as robust as reasonable the task was split into three parts: