communication cube (ccube) software and handling documentation

Communication Cube (CCUBE) software and handling

documentation

Matthias Ohrnbergera, Daniel Vollmera

aInstitute of Earth and Environmental Science, University of Potsdam

Abstract

The CCUBE is a collaborative development between the seismology group@ University of Potsdam (mainboard and software), GEMPA GmbH (cube-plugin for seedLINK server), Omnirecs (casing, production and distribution)and the GFZ Potsdam (SIM-card board, routing of mainboard). The soft-and hardware system design is based on the experiences made at the Univer-sity of Potsdam with the WARAN system (seismo.geo.uni-potsdam.de/waranproj)aiming towards providing easy wireless access to near realtime seismologicaldata streams in the field for direct analysis. One major important designaspect of the hardware is the low power consumption of the complete acqui-sition and transmission system. Further, the use of meshed network tech-nologies for easy routing within sensor networks (or acquisition nodes) provesto be an favourable advantage in environments where obstacles are common(e.g. urban areas or region with strong topographic barriers on small scale).Finally the CCUBE software is open and can therefore be modified andadapted to the client’s own needs and operation scenarios (e.g. other digi-tizer equipment may be used given the availability of a seedlink plugin). Forconvenience a standard system as well as firmware updates can be installedfrom USB and the uboot system.

Keywords: Meshed sensor network, low power data acquisition, opensoftware

CCUBE Documentation Ohrnberger/Vollmer, University of Potsdam June 8, 2016

Contents

1 Introduction 4

2 CCUBE handling instructions 6

3 Software overview 73.1 Boot procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Communication settings . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Ethernet communication . . . . . . . . . . . . . . . . . 113.2.2 WLAN communication . . . . . . . . . . . . . . . . . . 123.2.3 GSM communication (2G/3G/4G) . . . . . . . . . . . 12

3.3 Acquisition settings . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1 seedlink . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 cube plugin and DATA-CUBE3 configuration . . . . . 14

3.4 CCUBE configuration . . . . . . . . . . . . . . . . . . . . . . 163.4.1 Check/Edit Data-Cube settings . . . . . . . . . . . . . 183.4.2 seedlink/cube plugin configuration . . . . . . . . . . . 203.4.3 Network interface configuration . . . . . . . . . . . . . 213.4.4 OpenVPN configuration . . . . . . . . . . . . . . . . . 22

3.5 Other software / access / control utilities . . . . . . . . . . . . 223.5.1 Operating status of CCUBE . . . . . . . . . . . . . . . 223.5.2 SSH access to CCUBE . . . . . . . . . . . . . . . . . . 233.5.3 UMTS-status information . . . . . . . . . . . . . . . . 24

4 Current version problems 254.1 Known bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Missing implementations . . . . . . . . . . . . . . . . . . . . . 25

5 Acknowledgments 25

Appendix A Script book 26Appendix A.1 connect umts manual.sh . . . . . . . . . . . . . . 26Appendix A.2 disconnect umts manual.sh . . . . . . . . . . . . 27Appendix A.3 cube fs.py . . . . . . . . . . . . . . . . . . . . . . 27Appendix A.4 cube stream.py . . . . . . . . . . . . . . . . . . . 28Appendix A.5 eeprom read.py: Reading out the eeprom infor-

mation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Appendix A.6 eeprom write.py . . . . . . . . . . . . . . . . . . 28

2

Appendix A.7 ext usb off.py . . . . . . . . . . . . . . . . . . . . 29Appendix A.8 ext usb on.py . . . . . . . . . . . . . . . . . . . . 29Appendix A.9 get default ethip.sh . . . . . . . . . . . . . . . . 30Appendix A.10 get default hostname.py . . . . . . . . . . . . . . 30Appendix A.11 get default lanip.py . . . . . . . . . . . . . . . . 30Appendix A.12 mount cubefs and download.sh . . . . . . . . . . 31Appendix A.13 mount cubefs and upload.sh . . . . . . . . . . . . 31Appendix A.14 status.sh . . . . . . . . . . . . . . . . . . . . . . 31Appendix A.15 umts led.py . . . . . . . . . . . . . . . . . . . . . 32Appendix A.16 umts on.py . . . . . . . . . . . . . . . . . . . . . 33Appendix A.17 umts off.py . . . . . . . . . . . . . . . . . . . . . 33Appendix A.18 wlan on.py . . . . . . . . . . . . . . . . . . . . . 33Appendix A.19 wlan off.py . . . . . . . . . . . . . . . . . . . . . 34Appendix A.20 wlan status.py . . . . . . . . . . . . . . . . . . . 34Appendix A.21 write cube config file.sh . . . . . . . . . . . . . . 34Appendix A.22 write seedlink and plugin ini.sh . . . . . . . . . . 35Appendix A.23 Obtaining the default WLAN IP address . . . . . 36Appendix A.24 Writing network interfaces files . . . . . . . . . . 36Appendix A.25 Configuring the CCUBE from master config file . 38

Appendix B Master config file example 43

Appendix C LED blinking codes 45

3

1. Introduction

The CCUBE (Communication-CUBE) is a modular communication unitallowing for the transmission of data recorded by the DATA-CUBE3 in (near)real time. The following interfaces can be used for transmission:

• WLAN (802.11bgn)

• UMTS/LTE/EDGE (optional)

• Ethernet (100Mbit/s)

The heart of the CCUBE is an ARIA-G25 board (ARM9 @ 400 MHz,256 MB RAM) running an embedded Linux system (Debian Wheezy withLINUX 3.14 kernel). The board is integrated into a newly designed main-board adding power-management and interfaces for reliable field operationpacked into a IP67 housing. The overall design aimed for as low powerconsumption as possible while providing near real-time wireless data trans-mission from Omnirecs DATA-CUBE3 digitizer equipment.

The CCUBE provides a seedlink server running a newly programmed plu-gin (cube plugin)for capturing the serial data stream from the DATA-CUBE3.The cube plugin converts the raw data into mseed blocks and handles the tim-ing information that is mixed within the data stream. The mseed data blocksare then handled by seedlink and stored within its ring buffer (realised astemporary file system in memory). Data can then be accessed in near real-time from the CCUBE’s seedlink server remotely via any of the availableinterfaces (Ethernet/WLAN/UMTS) using appropriate software tools im-plementing the seedlink protocol (e.g. seiscomp3, slinktool, geopsy, obspy,snuffler, etc.).

The ring buffer size of max 100 MB is sufficient to allow data recoveryafter transmission failure. Current configuration uses 50 MB ring buffer sizethat allows a buffer time of approximately 18 hours when recording at 100SPS (STEIM2 compression under typical noise conditions). As backup, theoriginal data is still available on DATA-CUBE3’s SD card after instrumentrecovery.

The standard CCUBE is delivered with ethernet and WLAN interface.LTE/UMTS radio cards are optionally available. Note that SIM card andtransmission policies/costs are not covered by Omnirecs. SIM card can be

4

easily exchanged using the securely tightened SIM card slot (screwed andsealed cap).

Typical field scenarios of the CCUBE are as following:

• Connect ethernet / WLAN to DSL-router and access data remotely

• Single station data roaming via LTE/UMTS

• Multi-Station meshed WLAN operation for in-field data access andanalysis

• Multi-Station meshed WLAN operation routing via DSL or UTMS tohome location.

Meshed network operations are realized using the B.A.T.M.A.N. advancedrouting protocol (see open-mesh.org and freifunk community→ freifunk.net,note: German website). Compared to older/alternative mesh routing pro-tocol implementations like olsrd, the advantage of the kernel-based batmansolution is its routing efficiency and reduced bandwidth requirement for ex-chaning the routing information within a multihop meshed network.

WLAN field tests have demonstrated an average 4 Mbit/sec transmissionrate along 800 m node distance (given appropriate antenna installation >=2m height, slight topography and few obstacles)

Power consumption have been measured in laboratory tests as:

• cpu idle after boot (360 mW)

• seedlink running (18% cpu-time): 400 mW

• seedlink + Ethernet: 700 mW

• seedlink + WLAN: 820 mW

• seedlink + UMTS sending: 1440 mW

• seedlink + UMTS idle (waiting for request): 640 mW

5

Please note that these values are the power consumption for the CCUBEonly (no DATA-CUBE3 or sensor). DATA-CUBE3 is further required to runin continuous GPS mode resulting in higher power consumption than the lowpower economic cycled mode!

Continuous (also remote) monitoring of the environmental/operationalconditions are provided by logging of main board temperature and powersource input voltage. In case of power loss or unstable power conditions ahysteresis circuit for the variable input voltage (10,5-24 V) has been designedin order to avoid oscillating stop/start behaviour at low input voltage levelsof a power source. If voltage drops below 10,5 V the system will stop (agraceful shutdown is not yet implemented but considered for a future softwarerelease). At 11,4 V the system will be automatically re-started.

2. CCUBE handling instructions

Before going to the field we recommend strongly to prepare your CCUBEand DATA-CUBE3 in the laboratory to reduce possible pitfalls and unwantedrecording behaviour.

IMPORTANT: Using the DATA-CUBE3 as digitizer with the CCUBErequires the existence of a station identification file located on top of theDATA-CUBE3’s data partition. The file has to be named STATION.TXTand must contain only the DATA-CUBE3 ID (e.g. A8S or simil). TheCCUBE relies on this file to identify the attached DATA-CUBE3 device andto detect any changes during operation. Note that this has to be done onlyonce for each DATA-CUBE3. The additional ASCII file doesn’t inflict withthe normal operation of the DATA-CUBE3. It is absolutely safe to copy theSTATION.TXT to the data partition. No unwanted side effect will occurr.

We consider it best practice to connect the DATA-CUBE3 to the CCUBEusing a correctly configured 7 pole cable (see also http://tinyurl.com/hf6ay3hand 1) before powering the system.

The power is passed either from the CCUBE to the DATA-CUBE3 or inthe reverse direction, depending which of the systems is powered using anappropriate power source (e.g. lead-acid 12V battery). Don’t forget to attachthe GPS antenna to the DATA-CUBE3 as well as the WLAN antenna and/orthe UMTS antenna in case of using either one or both of these devices for

6

Figure 1: DATA-CUBE3 and CCUBE connected with a seven-pole cable providing powerand serial connection between both systems. .

communication. Both the CCUBE and DATA-CUBE3 will boot and beginoperation according to their respective settings.

Please note that there is a potential point of failure that may occur:the DATA-CUBE3 settings may have been set up indepedentely from theacquisition settings on the CCUBE. A problematic situation will arise whenin particular the sampling rate settings do not match. Then the mseed blockswritten by the plugin will produce either fake gaps or overlapping data blocks.However, the data recording on the DATA-CUBE3 will continue as describedby its corresponding CONFIG.TXT settings file.

3. Software overview

Almost all scripts and extra software provided has been added in thepath /usr/local/bin. Triggering/switching hardware components on and offis realized using python scripts and the GPL, LGPL and MIT licensed pythonlibrary ablib for the Aria G25 board (www.acmesystems.it/ablib, see alsoappendix for scripts). This dependence may change in a future release of the

7

software tools. Other scripts are mainly realized as bash scripts and may becalled within python scripts, other shell scripts or from command line.

Configuring the distinct operation modi of the CCUBE is currently basedon and divided into four mostly independent configuration issues:

• Data-Cube (or more general digitizer) configuration

• Digitizer dependent plugin settings

• Communication device settings and (wireless) data transmission con-figuration from CCUBE to anywhere else.

• openvpn configuration.

In the CCUBE software version until 1.5, the configuration settings haveto be entered in a couple of dynamically created webforms using the bot-tle python web microframework and its simple web-server coming with thispython package (www.bottlepy.org).

Starting from version 1.6 of the CCUBE software, we have introduced onemain configuration file that holds all configuration settings in a simple format(KEYWORD value pairs in a simple ASCII file). The location of this masterconfiguration file is /root and the configuration file name is hardcoded intothe script evaluating the config file information. Thus the configuration filehas to be named: CCUBE-MASTER-CONFIG.TXT and must be located inthe directory specified above. For changing the CCUBE behaviour one hasto edit the config file and then call the script /root/configure ccube.bash.

3.1. Boot procedure

The boot procedure has been tuned to secure a (re-)start of the system inthe last known state of communication and operation (acquisition) withoutthe need to interact or manually start up specific services. We consider theboot procedure as stable but it should be noted that not all possible situationsthat may occurr during a field campaign have already been tested thorougly.In case you experience some error, please report with detailed descriptionof the circumstances of the occurrence of the boot failure to [email protected] and [email protected].

During the boot procedure the status LEDs are all switched on for a shortmoment (see Fig.2) in order to test their functionality. In general the LEDs

8

Figure 2: LED status during boot procedure. All LEDs are switched on for a momentto indicate the functioning of the LEDs. After booting the LEDs give a diagnostic ofthe system’s operational status (see also table on http://tinyurl.com/hwvs3e8 or in thebackmatter C.7) .

provide a minimal diagnostic tool for the operational status of the CCUBEand eventual faulty conditions.

3.2. Communication settings

The main purpose of the CCUBE (as guessed from the name of the de-vice) is to provide simple means of direct in-field wireless or wired access tothe data stream recorded by the DATA-CUBE3 in near real-time. For thisreason the CCUBE is equipped with a standard wired ethernet interface (100MBit/s), a wireless lan device (802.11bgn) and a GSM modem device pro-viding 2G/3G or 4G capabilities given the availability of infrastructure (cellphone net coverage) and a valid SIM card. Further communication can beachieved via a serial line connection and a terminal program although thereis no intention to use this interface for data transmission. It is provided forsystem rescue and/or system setup for acquainted users of the CCUBE.

In the following we go through the currently supported setups for the indi-vidual communication interfaces. Note that the interfaces can be configuredas known from Debian based Linux systems by editing the /etc/network/interfaces

9

file and restarting the networking service by the command:

~$ service networking restart

The interface configuration as provided by using the web-interface is in-deed actually doing nothing else than stopping the networking service, re-writing the desired settings in local files named current xxx0 (replace xxxby any of the available device: eth, wlan, usb) that are linked into the/etc/network/interfaces file. Finally the networking service is started again.The re-writing of the currently valid interface dependent files is achieved bycalling the script /usr/local/bin/write interface file.sh with the appropriateoptions (see Appendix A.25). The sequence of command may then look like:

~$ service networking stop

~$ /usr/local/bin/write_interface_file.sh <args> ...

~$ service networking start

Using the script /usr/local/bin/write interface file.sh allows to use pre-defined modes of operation for the individual network interfaces (eth0, wlan0and usb0). We make use of interface templates that are then copied tointerface related file names (e.g. current wlan0) which are included in the/etc/network/interfaces description.

Important files related to the networking service are therefore:

• /etc/init.d/networking

• /etc/network/interfaces

• /etc/network/current eth0

• /etc/network/current wlan0

• /etc/network/current usb0

IMPORTANT: The hardware interfaces have to be correctly identified inthe boot procedure. Given the last configuration in use the interfaces haveeventually to be enabled or disabled by switching the power on or off.

10

Note: If devices are not configured the devices are switched off in orderto save power. This is true for both the wifi module as well as the gsmmodem module but not for the ethernet device. The power consumption ofthis device is minimal given there is no connection detected. The appropriatescripts for power switching (e.g. wlan on.py, umts off.py, etc.), connectionscripts for gsm modem dialup connection (e.g. connect umts.sh etc.) aswell as kernel module loading (e.g. batman adv.ko) will be triggered by theifup/ifdown mechanism used for starting the network interfaces. For detailscheck the template scripts in /etc/network.

Note: The default setting of the CCUBE is:

• eth0: providing a dhcp server for connecting easily with a RJ45 cableto a laptop

• wlan0: not configured, power off

• usb0 (2/3/4G modem): not configured, power off

In the following we will describe the predefined modes for the individualdevices (eth0, wlan0 and usb0).

3.2.1. Ethernet communication

Possible configuration of ethernet device:

• Mode 0: fixed IP address setup to allow connection from laptop withinthe same subnetwork - In order to avoid conflicts when connecting anumber of CCUBES on the same subnetwork we have derived a fixedscheme for computing the IP address from the CCUBE number. Thechosen subnetwork is in the address range of 192.168.x.x - the 3rd and4th byte in the IP4 number are computed as:i) 3rd byte: int(ccube number/100),ii) 4th byte: 100+(ccube number%100) (modulo).(please see also 4.1)

• Mode 1: same fixed IP address setup of the CCUBE as in Mode 0 butrunning dhcpd on the CCUBE in order to facilitate an easy connec-tion of a connected latop with an RJ45 cable and setting the Laptop’sethernet device to accept IP from dhcp server (CCUBE in this case)

11

• Mode 2: ethernet device on cube is configured as dhcp client expectingto receive an IP automatically from a dhcp server when plugged to anetwork.

3.2.2. WLAN communication

Possible configuration of the wifi interface:

• Mode 0: wifi is switched off → wifi device is powered off and device isremoved from the available network configuration.

• Mode 1: fixed IP address setup→ allows connection from wireless net-works within the same subnetwork - In order to avoid conflicts whenconnecting a number of CCUBES on the same subnetwork we havederived a fixed scheme for computing the IP address from the CCUBEnumber. The chosen ip is in the address range of the subnetwork172.16.x.x - the 3rd and 4th byte in the IP4 number are computedasi) 3rd byte: int(ccube number/100),ii) 4th byte: 100+ccube number%100 (modulo).

• Mode 2: same fixed IP address setup as Mode 1 for the CCUBE but thewifi card is running in the ad-hoc meshed network mode. Here we makeuse of the batman adv kernel module implementing the meshed networkon network layer 2 (s.a. https://www.open-mesh.org/projects/batman-adv/wiki/Wiki).

• Mode 3: wifi card is set in infrastructure mode as client to an existingWLAN node (router providing an IP-address via dhcp). Note that thisbehaviour is only available by editing the the interface file by hand. Noeasy access via the web-interface exists.

3.2.3. GSM communication (2G/3G/4G)

Possible configuration of gsm/umts modem device:

• Mode 0: umts is switched off → umts device is powered off and deviceis removed from the available network configuration.

• Mode 1,2,3: umts is switched on → umts device is powered on anduses the given APN to connect via umts (3G) to WWAN. Further theddclient service is started that enables a dynamic dns association withthe umts card.

12

Note 1): using Modes 1-3, the correct specification of the APN and theinformation for the dyndns client has to be added at least once when usinga (new) SIM Card. In our tests we have used ”www.dnsdynamic.org” and adefault host name that needs to be updated by the user by editing the file/etc/ddclient.conf.

Note 2): Currently we will only use UMTS mode for connection (3G).Both 2G and 4G is in principal supported by the GSM module. Connectingscripts however have to be adapted to make use of those capabilities.

3.3. Acquisition settings

Here we describe the specific acquisition settings tuned for the use ofthe CCUBE with the DATA-CUBE3. Note that exchanging the digitizer ispossible given a existing seedlink plugin for the digitzer and the data beingtransmitted from the digtizer to the CCUBE via an existing interface (serialor ethernet). Most probably a new cable has then to be confectionated.

The general concept pursued is the following:

• Capture the data stream from the serial interface (USB) of the DATA-CUBE3 using the cube plugin (see also http://docs.gempa.de/cube/current).

• Buffering a configurable amount of data (max 100 MB) making use ofthe seedlink server software.

• Serving the acquired data streams at port 18000 at all available andconfigured interfaces by request via the seedlink protocol.

3.3.1. seedlink

The seedlink server and data acquisition using the cube plugin listeningon interface /dev/ttyUSB0 is started at boot time using the seiscomp3 (SC3)directory structures and the python script provided with SC3. Note thatSC3 is only used to start up or shut down the seedlink server running thecube plugin software. The startup and shutdown procedures may be subjectto change in the future to simplify the setup of the system (evtl. changingto the seiscomp 2.6 acq ctrl scripts, see also 4.1)

Important files:

• /etc/init.d/seiscomp

13

• /usr/local/bin/seiscomp

• /home/sysop/etc/key/station ?? ????

• /home/sysop/etc/key/seedlink/station ?? ????

• /home/sysop/var/lib/seedlink/seedlink.ini

• /home/sysop/var/lib/seedlink/cube.ini

• /home/sysop/var/lib/seedlink/cubeconfig.txt

• /home/sysop/var/lib/seedlink/STATION.TXT

• /home/sysop/var/log/seedlink.log

• /home/sysop/var/log/time-delay.log

• /home/sysop/var/log/gps-info.log

Most important are the files seedlink.ini and cube.ini together with cube-config.txt. When using the web-interface for configuration, the user does nothave to edit those files (or better: shouldn’t edit by hand).

3.3.2. cube plugin and DATA-CUBE3 configuration

In this section we want to shortly describe the cube plugin settings andthe communication with the DATA-CUBE3. Although the operation of theDATA-CUBE3 is fully independent of the CCUBE operation, it is of utter-most importance that the entries of the CONFIG.TXT file (located on theDATA-CUBE3 SD-card data partition) driving the behaviour of the DATA-CUBE3 recording is known and consistent with the information accessible bythe CCUBE.

In order to allow this consistency we maintain a copy of the file CON-FIG.TXT keeping the important information in the file cubeconfig.txt whichis then used by the cube plugin to read the required information for operation(sampling rate!). This workaround may change in future in case an automaticsampling rate recognition is implemented in the cube plugin software.

During the course of development, the parameters and keywords usedfor the cube plugin software have changed several times. We describe thecurrent options and the implemented call by seedlink as of June 8, 2016:

14

These are the contents of the cube.ini file:

[cube]

mode=1

gps_min_satellites=3

gps_dump_interval=1

gps_init_timestamps=3

max_jitter=-1

network="yy"

station="ABCDE"

location="00"

stream="HH"

channels=Z,N,E

A detailed description of the cube plugin is given on the Gempa website.Here we only refer to the editable values, which are:

• gps min satellites: specifies the number of minimum number of satel-lites that have to be received for a the time stamp to be valid (acceptedas valid). Typical value is 3.

• network, station, stream: these trhree values are used to create a namefor the recorded data streams that can be accessed via the seedlinkserver. Network is a two character code, station a 5 character code andstream is usaully one of HH, BH or simil as typically used in seedlinkSDS strcutures and following the mSEED conventions.

In order to reflect changes in the stream name, it is important that thecorresponding entries in the file seedlink.ini are also updated. Here, we workwith a template file and replace the network, station and stream informationaccordingly. The final call of the plugin is handled from the seedlink serverand the correponding entry in the seedlink.ini file reads:

plugin cube cmd="/home/sysop/bin/cube_plugin

-i /home/sysop/var/lib/seedlink/cube.ini

-s /dev/ttyUSB0

-c /home/sysop/var/lib/seedlink/cubeconfig.txt

-t /home/sysop/var/log/cube-delay-time.log

15

-e 2

-d /home/sysop/var/log/gps-cube-pos.log

--verbosity=3 -D"

timeout = 0

start_retry = 60

shutdown_wait = 10

The options for the cube plugin can be found from the help message:

root@CC000:/home/sysop/var/lib/seedlink# cube_plugin

Usage: cube_plugin [options] plugin_name

’plugin_name’ is the section name in config file; it is also used

as a signature in log messages

-v increase verbosity level

--verbosity=LEVEL verbosity level[0..4]

-c, --config=FILE load CUBE configuration from file instead of read from data stream

-d, --gps-file=FILE dump GPS position into given file

-D, --daemon run plugin in daemon mode

-e, --encoding=NUMBER set data output encoding. (1 -’DE_STEIM1’,2 - ’DE_STEIM2’)

-f, --offline=FILE read data from file instead of device

-i, --plugin-config=FILE read plugin configuration from given file

-m, --mode set the push-mode (available modes [0 = STDOUT|1 = SEEDLINK|2 = CAPS])

-t, --time-file=FILE file to push time-difference information

-s, --serial=FILE use the given device. By default /dev/ttyUSB0 will be used

-S, --sync-system-time synchronize system time with GPS

-w, --no-wait do not wait for initial GPS signal

-V, --version show version information

-h, --help print this help page and exit

We make use of the continuously growing gps-log file to trigger the dataLED in order to facilitate the user an option for visually controlling the dataacquisition processes running. The writing of the delay time information iscurrently set for debugging purpose. Further, this file could be used in anoffline procedure to resample the acquired data stream for timing corrections.

3.4. CCUBE configuration

For easier setup of the CCUBE, we have initially implemented a smallweb server using the bottle micro framework (www.bottlepy.org) to allow theuser to setup the CCUBE from dynamic html web forms. The configurationof the CCUBE via this web-interface has been the preferred choice untilsoftware version 1.5 of the CCUBE.

Please note that from software version 1.6, the use of the web-based con-figuration editing is no longer recommended! Based on different feedback bytest users and aiming to focus our effort on system stability instead of pro-gramming a web-based configuration tool, we have switched to an alternative

16

configuration method. From software version 1.6 on, we provide a simpleASCII configuration file that allows controlling all aspects of the CCUBEoperation by simple editing and running one bash script after editing thisconfiguration file.

Nevertheless - for the sake of completeness - we provide the web-basedconfiguration option until version 1.5 of the CCUBE software here.

Figure 3: Start page of web server with entry points for CCUBE configuration.

At startup the python based web server is configured to listen on allconfigured communication interfaces on the standard http port :80. On theroot node (http://ip:80/) a simple html page is provided with links to theindividual web forms. In particular the following link entries can be found:

• Check/Edit Data-CUBE settings

• seedlink/cube plugin configuration

• Network interface configuration

• Operating status of CCUBE

• SSH access to CCUBE

• UMTS-status info

17

3.4.1. Check/Edit Data-Cube settings

Obsolete from version 1.6 of CCUBE software!! Until version 1.5 theweb-form is used in the following way:

1. Pressing button ”get configuration parameters” triggers the followingaction: mounting the DATA-CUBE3, copy the files CONFIG.TXT andSTATION.TXT to local directories and read values in web-form. TheDATA-CUBE3 is NOT returned to streaming mode! NOTE: be patient!

2. Edit values as desired

3. Press button ”set and upload parameters”: writes settings from theweb-form into local files and copies to the DATA-CUBE3. THEN re-turns to streaming mode. NOTE: be patient!

Figure 4: Web form for changing settings of the DATA-CUBE3

The section in the master configuration file related to the editing of theabove values looks like (s.a. Appendix B):

#############################################################

# CUBE acquisition parameters section

# we may think of "ACTION GET/SET" parameter .... (?)

DIGITIZER-ID AAC

DIGITIZER-VERS 1 # may be 1 or 2 ... (different config files)

S_RATE 100 # one of 50, 100, 200, 400

P_AMPL 1 # one of 1, 2, 4, 8, 16, 32, 64

18

E_NAME MAMBA

# GPS_ON is going to be set to one (1) ALWAYS! not selectable

# rest of CUBE^3 configuration file is pre-set with fixed values

#############################################################

After editing the corresponding entries in the configuration file one needsto run the script /root/configure ccube.sh to effectuate the changes. Note:this should be done after editing ALL necessary changes, not only thoserelevant for the DATA-CUBE3 settings.

19

3.4.2. seedlink/cube plugin configuration

The web-form is obsolete from version 1.6 of CCUBE software!! fromversion 1.6 on, we specify all editable parameters of the seedlink / cube pluginparameters via the master config file

The section in the master configuration file related to the changeableparameters for the seedlink / cube plugin are shown here (s.a. AppendixB):

#############################################################

# seedlink / cube_plugin parameters

# parameters needed to setup up cube_plugin and seedlink

NETWORK yy

STATION ABCDE # check whether it may be 5 characters... (?)

# LOCATION 00 # not yet compatibel with plugin

STREAM HH

SATELLITES 3 # minimum number of satellites needed

#############################################################

After editing the corresponding entries in the configuration file one needsto run the script /root/configure ccube.sh to effectuate the changes. Note:this should be done after editing ALL necessary changes, not only thoserelevant for the seedlink/cube plugin settings.

20

3.4.3. Network interface configuration

The webform is obsolete from version 1.6 of CCUBE software!! Sinceversion 1.6, we use a small number of entries in the master configuration filefor sepcifying the communication behaviour of the CCUBE.

The section in the master configuration file related to the changeableparameters for the communication settings are shown here (s.a. AppendixB):

#############################################################

# Communication settings - specification of operation for

# all network devices: eth0 / wlan0 and usb0

ETHERMODE 2 # one of 0, 1, 2 - add as u need ...

ETHERIP 192.168.0.100 # derived from device eeprom

WLANMODE 0 # one of 0, 1, 2 - add as u need ...

WLANIP 172.16.0.100 # derived from device eeprom

WLANCHAN 1 # one of 1, 6, 12

UMTSMODE 0 # one of 0, 1, 2, 3, 4 -->

# 0G means OFF, 1G means AUTO, 2G, 3G, 4G

UMTSAPN internet.t-d1.de #

SIMPIN xxxx # pin in fulltext!

#############################################################

After editing the corresponding entries in the configuration file one needsto run the script /root/configure ccube.sh to effectuate the changes. Note:this should be done after editing ALL necessary changes, not only thoserelevant for the seedlink/cube plugin settings.

21

3.4.4. OpenVPN configuration

OpenVPN is installed and can be configured by an expert. Entries in theccube master configuration file are not yet used by the ”configure ccube.bash”script. They are intended to be eventually used in a future software release.Note that the entries are needed anyway to avoid breaking a succesful com-pletion of the configuration script.

#############################################################

# VPN settings - config for device tun0

# /etc/openvpn/client.conf

# NOTE: please fill VPNREMOTE variable even if you don’t

# want to use openvpn - it is needed for not breaking the

# general configure script!

VPNPROTO udp

VPNREMOTE 141.89.111.92 1194

#############################################################

3.5. Other software / access / control utilities

3.5.1. Operating status of CCUBE

The operating status of the CCUBE can be conveniently accessed viathe web-interface. It is a mere summary of the current system status - nomodifications are allowed here.

22

Figure 5: Dynamic web-page created for informing the user about the operation status ofthe CCUBE.

3.5.2. SSH access to CCUBE

For advanced users, the shellinabox utility allows to get an secure shellaccess to the CCUBE. However it needs to be noted, that there is no rootaccess possible. Furthermore, some keys of special characters are not recog-nized! We recommend therefore to use a normal terminal based ssh-clientprogram instead! In case, users do not have this possibility (e.g. windowsoperating system and no ssh-client installed) it may be convenient to accessthe CCUBE through this ssh web-based interface.

23

Figure 6: Shellinabox environment for ssh access to CCUBE (Note: no root shell!)

3.5.3. UMTS-status information

The operating status of the UMTS device can be accessed via the web-interface. It is used mainly for checking information about the amount ofdata transported, transport speed and simil. The result depends on theprovider and the script used for accessing the information from the provider.

24

4. Current version problems

4.1. Known bugs

• cube stream.py: when called twice without waiting for the data cubeto be responsive again - the ttyUSBx device number x changes from 0to 5 ... This creates a malfunctioning of the cube plugin that relies onthe correct specification of the serial device. The only way to deal withthis problem for the moment is to be patient! Once the problem hasoccurred, one has to remove the following file /etc/udev/rules.d/70-persistent-net.rules and to restart the CCUBE.

• seiscomp boot script: works during boot time - however: calling ”ser-vice seiscomp stop” does not work as expected - use ”/usr/local/bin/seiscompstop” or ”seiscomp stop” instead!

• starting and stopping seiscomp from scripting inside bottle does notwork properly - in particular we observed a strange port number phe-nomenon (lsof -i :80 shows e.g. seedlink listening to port 80) - this maylead to problems when restarting the bottle server (!)

• fixed IP setting on CCUBE ethernet device disables connection recog-nition (led does not show connectivity and no connection is possible...)

4.2. Missing implementations

• password protection for web-access and configuration

• automatic switch to most appropriate GSM speed - select 2G, 3G or4G depending on signal strength

• in web-server we need to integrate a spinning wheel when restartingData-CUBE or network or simil - further some buttons need to beblocked or enabled depending on the actual state of configuration.

5. Acknowledgments

During the last ten years (2006 to 2016) we have been working with ”our”(seismology group of the Institute of Earth and Environmental Science de-partment of the University of Potsdam, Germany) Wireless Array ANalysis(WARAN) equipment. The experience we obtained during field work has

25

been an essential ingredient to this newly developed hardware equipmentand the software developed and installed. All involved persons, i.e. students,colleagues and institutions who worked together with us in the prior develop-ment of the WARAN system are hereby acknowledged for their contributionsto test and improve the system. Outstanding and thus to be named are MarcWathelet, Alex Savvaidis and Daniela Kuhn. Finally we are also especiallythankful to Torsten Dahm who strongly supported the CCUBE developmentand has been always patient and believing in the progress and final successof this project.

Appendix A. Script book

Here we list some important scripts (python or bash) that can be usedon command line for accessing hardware and or obtaining system relevantinformation. All scripts can be found in directory /usr/local/bin

Appendix A.1. connect umts manual.sh

Utility for initiating the connection to your internet provider via the radiomodem card:

#!/bin/sh

# starting up umts hardware

umts_on.py

echo "waiting 15 seconds ..."

sleep 15

echo HUAWEI connect

# set shell variables to be accessible in chat scripts

if [ "$#" -eq 1 ]; then

export APN=$1

else

export APN="internet.t-d1.de"

fi

export DEVICE=/dev/ttyUSB4

IP_DEV=usb0 #eth1

# create temporary file catching output from umts modem

TMPFIL=/tmp/connect.$$

echo connecting

rm -f $TMPFIL

(

/usr/sbin/chat -E -s -V \

-f /etc/chatscripts/umts_start.chat < $DEVICE > $DEVICE

) 2>&1 |tee $TMPFIL

#echo " "n inet


sleep 10

echo connected

echo "ifconfig"

ifconfig $IP_DEV up

dhclient -v -pf /run/dhclient.eth1.pid $IP_DEV

26


sleep 10

echo "umts device connected and interface up"

echo "start dyndns client"

service ddclient start

exit 0

Appendix A.2. disconnect umts manual.sh

Utility for disconnecting the radio modem device:

#!/bin/sh

echo HUAWEI disconnect

# set shell variables to be accessible in chat scripts

#export DEVICE=/dev/ttyUSB1

export DEVICE=/dev/ttyUSB4

# set the IP Device

IP_DEV=usb0 #eth1

# create temporary file catching output from umts modem

TMPFIL=/tmp/disconnect.$$

echo disconnecting

rm -f $TMPFIL

(

/usr/sbin/chat -E -s -V \

-f /etc/chatscripts/umts_stop.chat < $DEVICE > $DEVICE

) 2>&1 |tee $TMPFIL

#echo " "n inet

# killing dhclient on interface eth1

echo "killing dhclient on interface usb0(eth1)"

kill ‘cat /run/dhclient.eth1.pid‘

echo "shutting device usb0"

ifconfig $IP_DEV down

#killing dyndns client

echo "stopping dyndns client for eth1"

service ddclient stop

# stopping umts hardware

umts_off.py

echo "umts device disconnected and interface down"

exit 0

Appendix A.3. cube fs.py

Utility for switching the USB device connected to the DATA-CUBE3 intothe ’fs’ (file-system) mode. Required for reading from / writing to the SD-card of the DATA-CUBE3. Typically needed when changing settings for theDATA-CUBE3 (like sampling rate change or simil):

#!/usr/bin/python

from ablib import Pin

from time import sleep

27

print "switch to cube file system"

cube_power = Pin(’N7’,’OUTPUT’)

#print "st"

cube_stream = Pin(’S19’,’OUTPUT’)

flt5V = Pin(’W9’,’INPUT’)


cube_power.digitalWrite(’LOW’)

cube_stream.digitalWrite(’LOW’)

Appendix A.4. cube stream.py

Utility for switching the USB device connected to the DATA-CUBE3 intothe ’stream’ mode. Required for reading raw digital data directly from theserial interface. If not called prior to starting the cube plugin no data can becaptured from the serial line and seedlink will wait forever to receive recordeddata.

#!/usr/bin/python



print "switch to cube data stream"

cube_power = Pin(’N7’,’OUTPUT’)

cube_stream = Pin(’S19’,’OUTPUT’)



cube_power.digitalWrite(’HIGH’)

sleep (10)

cube_stream.digitalWrite(’HIGH’)

Appendix A.5. eeprom read.py: Reading out the eeprom information

Utility for reading the eeprom information is called: eeprom read.py

#!/usr/bin/python

import smbus

import time

bus = smbus.SMBus(0)

address = 0x50

print bus

value = bus.read_byte_data(address,0x00)

print "IP 3rd byte value: %d"% value

value = bus.read_byte_data(address,0x01)

print "IP 4th byte value: %d"% value

value = bus.read_word_data(address,0x02)

print "hostname: %d" %value

Appendix A.6. eeprom write.py

Utility for writing individual bytes into the eeprom. Currently used tostore serial number information. Should be NEVER used by the user directly:

28

#!/usr/bin/python

import smbus

import time

import sys


address = 0x50

host = int(sys.argv[1])

print host

print bus

# write Byte 3 of IP4-adress

value=int(host/100)

bus.write_byte_data(address, 0x00, value)

time.sleep(1)

# write Byte 4 of IP4-adress

value=(host%100)+100

bus.write_byte_data(address, 0x01, value)

time.sleep(1)

# write hostnumber

bus.write_word_data(address, 0x02, host)

time.sleep(1)

Appendix A.7. ext usb off.py

Utility for switching the external USB device off:

#!/usr/bin/python



print "switch external USB off"

ext_usb_power = Pin(’N6’,’OUTPUT’)

ext_usb = Pin(’W12’,’OUTPUT’)

usb_flt5V = Pin(’W9’,’INPUT’)


ext_usb_power.digitalWrite(’HIGH’)

ext_usb.digitalWrite(’LOW’)

Appendix A.8. ext usb on.py

Utility for switching the external USB device on:

#!/usr/bin/python

# This switch on the external USB port for pendrive, camera and s.o.

# It’s not possible to use the GSM/UMTS/LTE connection with external USB on.



print "switch external USB on"

ext_usb_power = Pin(’N6’,’OUTPUT’)

ext_usb = Pin(’W12’,’OUTPUT’)



ext_usb_power.digitalWrite(’LOW’)

ext_usb.digitalWrite(’HIGH’)

29

Appendix A.9. get default ethip.sh

Utility for setting the default IP4 address of the ethernet device from theeeprom information:

#!/bin/bash

/usr/local/bin/eeprom_read.py |\

awk ’{if(NR==2) \

{ip=sprintf("192.168.%d",$5)};\

if(NR==3) \

{printf("%s.%d\n",ip,$5)}}’

Appendix A.10. get default hostname.py

Utility for setting the default hostname of the CCUBE from the eeprominformation:

#!/usr/bin/python

import smbus

import time


address = 0x50

value3 = bus.read_byte_data(address,0x00)

#print "IP 3rd byte value: %d"% value


#print "IP 4th byte value: %d"% value

valueh = bus.read_word_data(address,0x02)

#print "hostname: %d" %value

print("CC%03d" % valueh)

Appendix A.11. get default lanip.py

Utility for setting the default IP4 address of the WLAN device from theeeprom information:

#!/usr/bin/python

import smbus

import time


address = 0x50


#print "IP 3rd byte value: %d"% value


#print "IP 4th byte value: %d"% value

print "192.168."+str(value3)+"."+str(value4)

valueh = bus.read_word_data(address,0x02)

#print "hostname: %d" %value

30

Appendix A.12. mount cubefs and download.sh

Utility for obtaining CONFIG.TXT and STATION.TXT from the DATA-CUBE3:

#!/bin/sh

t=‘date +"%Y%m%d%H%M%S" -u‘

mount /dev/sda1 /mnt

dc=‘diff /mnt/CONFIG.TXT /home/sysop/var/lib/seedlink/cubeconfig.txt‘

# if configuration file differs, make backup and copy from cube

echo $dc

if [ "$dc" != "" ]

then

cp /home/sysop/var/lib/seedlink/cubeconfig.txt \

/home/sysop/var/lib/seedlink/cubeconfig.${t}.BUP

cp -f /mnt/CONFIG.TXT /home/sysop/var/lib/seedlink/cubeconfig.txt

fi

# if station file differs, make backup and copy from cube

ds=‘diff /mnt/STATION.TXT /home/sysop/var/lib/seedlink/STATION.TXT‘

echo $ds

if [ "$ds" != "" ]

then

cp /home/sysop/var/lib/seedlink/STATION.TXT \

/home/sysop/var/lib/seedlink/STATION.${t}.BUP

cp -f /mnt/STATION.TXT /home/sysop/var/lib/seedlink/STATION.TXT

fi

umount /mnt

exit 0

Appendix A.13. mount cubefs and upload.sh

Utility for writing CONFIG.TXT and STATION.TXT from CCUBE lo-cations to DATA-CUBE3 SD-card:

#!/bin/sh



cp -f /home/sysop/var/lib/seedlink/cubeconfig.txt /mnt/CONFIG.TXT

umount /mnt

exit 0

Appendix A.14. status.sh

Utility for checking the current operating status of the CCUBE. Includesread-out of temperature and battery voltage, communication device settingsand operation status:

#!/bin/sh


rm status

echo -n VER= > status;cat /etc/motd|\

grep CCUBE |\

awk ’{print $2 }’ >> status

echo " " >> status

31

echo -n ETH= >> status;ifconfig eth0 |\

grep inet |\

awk ’{ print $2 }’|

awk -F’:’ ’{ print $2}’ >> status

echo " " >> status

echo -n WLAN= >> status;ifconfig wlan0 |\

grep inet |\

awk ’{ print $2 }’|\


echo " " >> status

echo -n UMTS= >> status;ifconfig usb0 |\

grep inet |\



echo " " >> status

echo -n BAT= >> status;ifconfig bat0 |\

grep inet |\



echo " " >> status

if [ -e /dev/ttyUSB4 ]; then echo -n SIG= >> status

/usr/local/bin/sig_umts.sh|\

grep +CSQ: |\

awk ’{ print $2 }’ >> status

echo " " >> status

else

echo SIG="" >> status

fi

echo -n POW= >> status; /usr/local/bin/adc_power.py >> status

echo " " >> status

echo -n BATT= >> status;/usr/local/bin/adc_bat.py >> status

echo " " >> status

echo -n TEMP= >> status;/usr/local/bin/temp.py >> status

echo " " >> status

echo -n ROUTE= >> status;route -n|\

grep 0.0.0.0 |\

awk ’{print $2 }’ >>status

echo -n SEEDLINK= >> status;ps -ef|\

grep seedlink|\

awk ’{ print $2 " "$8 }’ |\

grep seedlink >> status

echo " " >> status

echo -n CUBE= >> status;ps -ef|\

grep cube_plugin|\

awk ’{ print $2 " "$8 }’ |\

grep cube_plugin >>status

echo " " >> status

exit

Appendix A.15. umts led.py

Utility for switching on the radio modem indicator LED:

#!/usr/bin/python

import sys

import time

print "Blinking User LED"

print "Enter CTRL+C to exit"

def ledon():

value = open("/sys/devices/leds.3/leds/umts_led/brightness","w")

value.write(str(1))

value.close()

def ledoff():


value.write(str(0))

value.close()

while True:

ledon()

time.sleep(.5)

ledoff()

time.sleep(.5)

32

Appendix A.16. umts on.py

Utility for physically enabling the radio modem (2G/3G/4G) device bypowering the modem and switching the USB mode:

#!/usr/bin/python

import sys



print "switch umts on"

def umts_ledon():


value.write(str(1))

value.close()

umts_power = Pin(’N4’,’OUTPUT’)

umts = Pin(’W12’,’OUTPUT’)



umts_power.digitalWrite(’LOW’)

umts.digitalWrite(’LOW’)

umts_ledon()

Appendix A.17. umts off.py

Utility for powering down the radio modem (2G/3G/4G) device:

#!/usr/bin/python



print "switch umts off"

def umts_ledoff():


value.write(str(0))

value.close()

umts_power = Pin(’N4’,’OUTPUT’)

umts = Pin(’W12’,’OUTPUT’)

umts_flt5V = Pin(’W9’,’INPUT’)

umts_flt3V = Pin(’W10’,’INPUT’)

umts_power.digitalWrite(’HIGH’)

umts.digitalWrite(’HIGH’)

umts_ledoff()

Appendix A.18. wlan on.py

Utility for powering the usb-wlan device. This will also trigger the inser-tion of the appropriate kernel module for the wi-fi card:

#!/usr/bin/python



def wlan_ledon():

value = open("/sys/devices/leds.3/leds/wlan_led/brightness","w")

value.write(str(1))

value.close()

33

print "switch wlan on"

wlan_power = Pin(’N5’,’OUTPUT’)



wlan_power.digitalWrite(’LOW’)

sleep(2)

wlan_ledon()

Appendix A.19. wlan off.py

Utility for shutting down the usb-wlan device:

#!/usr/bin/python



def wlan_ledoff():

value = open("/sys/devices/leds.3/leds/wlan_led/brightness","w")

value.write(str(0))

value.close()

print "switch wlan off"

wlan_power = Pin(’N5’,’OUTPUT’)



wlan_power.digitalWrite(’HIGH’)

wlan_ledoff()

Appendix A.20. wlan status.py

Utility for checking the actual status of the wlan device:

#!/usr/bin/python



print "check wlan status"

wlan_power = Pin(’N5’,’INPUT’)

print wlan_power.digitalRead()

Appendix A.21. write cube config file.sh

Utility for writing an appropriate DATA-CUBE3 CONFIG.TXT derivedfrom a template file and filling in the crucial parameters (e.g. sampling rate):

#!/bin/bash

# arguments: $DIGVERSION $DIGID $SRATE $GAIN $EXPNAME

# PATH should only include /usr/* if it runs after the mountnfs.sh script

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin

if [ "$#" -ne 5 ]; then

printf "Calling script with illegal number of parameters!\n"

printf "Usage: write_cube_config_file.sh DIGVERSION DIGID SRATE GAIN EXPNAME\n"

exit 0

fi

34

DIGVERSION=$1

DIGID=$2

SRATE=$3

GAIN=$4

EXPNAME=$5

# first make some backup of current configuration files

BKUP=‘date +"%Y%m%d%H%M%S"‘

cp /home/sysop/var/lib/seedlink/STATION.TXT /home/sysop/var/lib/seedlink/STATION.${BKUP}.BUP

cp /home/sysop/var/lib/seedlink/cubeconfig.txt /home/sysop/var/lib/seedlink/cubeconfig.${BKUP}.BUP

# now create correct STATION.TXT

echo $DIGID > /home/sysop/var/lib/seedlink/STATION.TXT

# depending on CUBECONFIG.TXT version, we use different templates

if [ $1 == "1" ]; then

TEMPLATE=/home/sysop/var/lib/seedlink/cubeconfig.template

elif [ $1 == "2" ]; then

TEMPLATE=/home/sysop/var/lib/seedlink/cubeconfig-v2.template

else

exit -1

fi

# only three parameters are adjusted...

RSTR=‘printf "s/+S_RATE/S_RATE=%s/g" $SRATE‘

sed -e${RSTR} $TEMPLATE > /tmp/a

RSTR=‘printf "s/+P_AMPL/P_AMPL=%s/g" $GAIN‘

sed -e${RSTR} /tmp/a > /tmp/b

RSTR=‘printf "s/+E_NAME/E_NAME=%s/g" $EXPNAME‘

sed -e${RSTR} /tmp/b > /home/sysop/var/lib/seedlink/cubeconfig.txt

rm -f /tmp/[abc]

# should be finished here

exit 0

Appendix A.22. write seedlink and plugin ini.sh

Utility for re-writing the necessary ’seedlink.ini’ and ’cube.ini’ from tem-plate files and filling in crucial parameters:

#!/bin/bash

# arguments: $NETWORK $STATION $LOCATION $STREAM $SATS



if [ "$#" -ne 5 ]; then


printf "Usage: write_seedlink_and_plugin_ini.sh NETWORK STATION LOCATION STREAM SATS\n"

exit 0

fi

NETWORK=$1

STATION=$2

LOCATION=$3

STREAM=$4

SATS=$5

# first make some backup of current configuration files

BKUP=‘date +"%Y%m%d%H%M%S"‘

cp /home/sysop/var/lib/seedlink/seedlink.ini \

/home/sysop/var/lib/seedlink/seedlinkini.${BKUP}.BUP

cp /home/sysop/var/lib/seedlink/cube.ini \

/home/sysop/var/lib/seedlink/cubeini.${BKUP}.BUP

# now create correct new cube.ini

printf "[cube]\n" > /home/sysop/var/lib/seedlink/cube.ini

printf "mode=1\n" >> /home/sysop/var/lib/seedlink/cube.ini

printf "gps_min_satellites=%d\n" ${SATS}>> /home/sysop/var/lib/seedlink/cube.ini

printf "gps_dump_interval=1\n" >> /home/sysop/var/lib/seedlink/cube.ini

printf "gps_init_timestamps=3\n" >> /home/sysop/var/lib/seedlink/cube.ini

35

printf "max_jitter=-1\n" >> /home/sysop/var/lib/seedlink/cube.ini

printf "network=\x22%s\x22\n" ${NETWORK}>> /home/sysop/var/lib/seedlink/cube.ini

printf "station=\x22%s\x22\n" ${STATION} >> /home/sysop/var/lib/seedlink/cube.ini

printf "location=\x22%s\x22\n" ${LOCATION} >> /home/sysop/var/lib/seedlink/cube.ini

printf "stream=\x22%s\x22\n" ${STREAM} >> /home/sysop/var/lib/seedlink/cube.ini

printf "channels=Z,N,E\n" >> /home/sysop/var/lib/seedlink/cube.ini

# now create new seedlink.ini

cp /home/sysop/var/lib/seedlink/seedlink.ini.template \

/home/sysop/var/lib/seedlink/seedlink.ini

printf "station %s description = \x22CCUBE station\x22\n" ${STATION} >> /home/sysop/var/lib/seedlink/seedlink.ini

printf "name = \x22%s\x22\n" ${STATION} >> /home/sysop/var/lib/seedlink/seedlink.ini

printf "network = \x22%s\x22\n" ${NETWORK} >> /home/sysop/var/lib/seedlink/seedlink.ini

# finally update key information in $SEISCOMP_ROOT/etc

FNAME=‘ printf "station_%s_%s" $NETWORK $STATION ‘

printf "# Binding references\nseedlink\n" > /home/sysop/etc/key/$FNAME

printf "# Activated plugins for category sources\n" > /home/sysop/etc/key/seedlink/$FNAME

printf "sources = ccube-test:cube\n" >> /home/sysop/etc/key/seedlink/$FNAME

# should be finished here

exit 0

Appendix A.23. Obtaining the default WLAN IP address

Utility for obtaining the default WLAN IP from the settings in the eep-rom: get default WLANIP.{sh,py} - There are versions in bash and python.

#!/bin/bash

/usr/local/bin/eeprom_read.py |\

awk ’{if(NR==2) \

{ip=sprintf("172.16.%d",$5)};\

if(NR==3) \

{printf("%s.%d\n",ip,$5)}}’

Appendix A.24. Writing network interfaces files

Utility for writing network interfaces files based on predefined devicemodes (s.a. ??): write interface files.sh

#!/bin/sh

# Author: Daniel Vollmer <[email protected]>,

# Matthias Ohrnberger <[email protected]>

#



if [ "$#" -ne 7 ]; then


printf "Usage: write_interface_file.sh ETHMODE ETHIP WLANMODE WLANIP CHANUM UMTSMODE UMTSAPN\n"

exit 0

fi

ETHERMODE=$1

ETHERIP=$2

WLANMODE=$3

WLANIP=$4

CHANUM=$5

UMTSMODE=$6

UMTSAPN=$7

date > /etc/network/current_interface_situation

echo $0 $1 $2 $3 $4 $5 $6 $7 >> /etc/network/current_interface_situation

36

#write_chat_file()

#{

# # make a backup first

# CURTIME=‘date -u +"%Y%m%d_%H%M%S"‘

# cp /etc/chatscripts/umts_start.chat /etc/chatscripts/umts_start.chat.${CURTIME}.bkup

# # now change umts chat-script - if APN has been changed ... (?)

# sed -e’s/UMTSAPN/APN=$UMTSAPN/g’ /etc/chatscripts/umts_start.chat > /tmp/chat.tmp

# mv /tmp/chat.tmp /etc/chatscripts/umts_start.chat

# return

#}

write_interface_file()

{

# make a backup first

CURTIME=‘date -u +"%Y%m%d_%H%M%S"‘

for i in /etc/network/current_*0; do

cp -L $i /etc/network/BACKUP/‘basename $i‘.${CURTIME}.bkup

done

# now re-write /etc/interfaces/current_*0 from template files using selected parameters

# first for ethernet interface

sed -e’s/E_T_H_E_R_I_P_A_D_D_R_E_S_S/’"$ETHERIP"’/g’ /etc/network/interfaces.tmpl.eth0.$ETHERMODE > /tmp/eth0.tmp

mv /tmp/eth0.tmp /etc/network/current_eth0

# now for wlan interface

sed -e’s/W_L_A_N_I_P_A_D_D_R_E_S_S/’"$WLANIP"’/g’ /etc/network/interfaces.tmpl.wlan0.$WLANMODE > /tmp/wlan0.tmp

sed -e’s/C_H_A_N_N_E_L_N_U_M_B_E_R/’"$CHANUM"’/g’ /tmp/wlan0.tmp > /etc/network/current_wlan0

# now for umts interface

sed -e’s/A_P_N_N_A_M_E/’"$UMTSAPN"’/g’ /etc/network/interfaces.tmpl.usb0.$UMTSMODE > /tmp/usb0.tmp

mv /tmp/usb0.tmp /etc/network/current_usb0

return

}

write_interface_file

exit 0

37

Appendix A.25. Configuring the CCUBE from master config file

From software version 1.6 of the CCUBE, the configuration has been sim-plified by providing one ASCII file that contains all necessary configurationinformation by simple ’¡keyword¿ ¡value¿’ pairs. The master configurationfile (s.a. Appendix B) is edited according to the user’s needs and then thescript configure ccube.bash is started. The script cross-checks the entries forvalidity and sets defaults where reasonably possible and necessary. Then theCCUBE re-starts the corresponding services or is rebooted (user selectableoption).

#!/bin/bash

# this is the ccube master script for configuration -

# the script will work on the file:

# /root/CCUBE-MASTER-CONFIG.TXT

#

# The script has the following functionality:

# 0) syntax checking / variable checking and identification of

# impossible combinations of settings or violations

# of parameter ranges or simil

# 1) the script will then:

# a) backup previous configuration files

# b) stop eventually running processes

# c) update all necessary configuration files

# d) upstart processes again OR reboot the system

#

# just in case the PATH is not set ...


export RETVAL # checksum for entries in configuration file - 20 entries --> checksum 210!

init_retval()

{

# first removing leftovers...

rm -f /tmp/digid /tmp/digvers /tmp/srate /tmp/gain /tmp/expname

rm -f /tmp/network /tmp/station /tmp/location /tmp/stream /tmp/sats

rm -f /tmp/ethmode /tmp/ethip /tmp/wlanmode /tmp/wlanip /tmp/wlanchan

rm -f /tmp/umtsmode /tmp/umtsapn /tmp/simpin

rm -f /tmp/vpnproto /tmp/vpnremote

#printf "I am here! init_retval\n"

RETVAL=$1

}

sum_retval()

{

#printf "I am here! sum_retval\n"

RETVAL=‘ echo $RETVAL $1 | awk ’{print $1+$2}’ ‘

}

check_file()

{

#printf "I am here! check_file\n"

# first argument is file to be checked ...

# second argument is used for creating some reasonable checksum (RETVAL)

# third argument tells us, whether a missing value is critical or not

# fourth argument is used as default is value is not critical

if [ -s $1 ]; then

sum_retval $2

return

else

if [ $3 == "critical" ]; then

# we can not guess a value here - we need to abort...

sum_retval -99

return

else

# now we need to set some default value - this is given as fourth argument ...

38

# we simply write this into the missing file ...

echo $4 > $1

sum_retval $2

return

fi

fi

}

do_syntax_checking()

{

init_retval -210

# we check each section individually ...

#####################

# first section

grep DIGITIZER-ID /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/digid

# if there is no digitizer id - we can’t go on ...

check_file /tmp/digid 1 critical

######

grep DIGITIZER-VERS /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/digvers

# we may assume version 2 - this should be backward compatibel?

check_file /tmp/digvers 2 setdefault 2

######

grep S_RATE /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/srate

# if this is missing, we can’t go on ...

check_file /tmp/srate 3 critical

######

grep P_AMPL /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/gain

# if this is missing, we can’t go on ...

check_file /tmp/gain 4 critical

######

grep E_NAME /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/expname

# we may live with a missing value here ...

check_file /tmp/expname 5 setdefault DUMMY

######

#####################

# second section

grep NETWORK /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/network

# we may live with a dummy value ... (really?)

check_file /tmp/network 6 setdefault XX

######

grep STATION /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/station

# I consider the missing station name as critical ...

check_file /tmp/station 7 critical

######

grep LOCATION /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/location

# we can live without this ...

check_file /tmp/location 8 setdefault 00

######

grep STREAM /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/stream

# we may give here also a default value ...

check_file /tmp/stream 9 setdefault HH

######

grep SATELLITES /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/sats

# we may give here also a default value ...

check_file /tmp/sats 10 setdefault 3

######

#####################

# third section

grep ETHERMODE /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/ethmode

# if not set, eth0 will brought up with fixed IP and running a dhcp server

check_file /tmp/ethmode 11 setdefault 2

######

grep ETHERIP /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/ethip

# if not set, eth0 will brought up with fixed IP and running a dhcp server

ethip=‘/usr/local/bin/get_default_ethip.sh‘

39

check_file /tmp/ethip 12 setdefault $ethip

######

# check what is inside ...

grep WLANMODE /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/wlanmode

# if not set, wlan0 will be turned off

check_file /tmp/wlanmode 13 setdefault 0

######

grep WLANIP /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/wlanip

# if not set, wlan0 will be turned off, but we set the default wlanip anyway

wlanip=‘/usr/local/bin/get_default_wlanip.sh‘

check_file /tmp/wlanip 14 setdefault $wlanip

######

grep WLANCHAN /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/wlanchan

# if not set, wlan0 will be turned off, but we set the default channel anyway

check_file /tmp/wlanip 15 setdefault 1

######

grep UMTSMODE /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/umtsmode

# check what is inside ...

check_file /tmp/umtsmode 16 setdefault 0

######

grep UMTSAPN /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/umtsapn

# if this is missing, we’ll never make a connection - this is critical

# however - if umts is turned off, we may skip this ...

if [ ‘cat /tmp/umtsmode‘ == 0 ]; then

check_file /tmp/umtsapn 17 setdefault 1

else

check_file /tmp/umtsapn 17 critical

fi

######

grep SIMPIN /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/simpin

# this is not yet implemented - we just set some dummy value ...

check_file /tmp/simpin 18 setdefault 1234

######

#####################

# fourth section

grep VPNPROTO /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/vpnproto

# I assume we can guess this ...

check_file /tmp/vpnproto 19 setdefault udp

######

grep VPNREMOTE /root/CCUBE-MASTER-CONFIG.TXT |\

awk ’substr($1,1,1)!="#" {print $2}’ > /tmp/vpnremote

# if this is missing, openvpn will not work ...

# this may be considered critical -

# set some dummy value, even if you don’t need openvpn to work ...

check_file /tmp/vpnremote 20 critical

######

####################

return

}

# first check the configuration file - if we get an error there,

# it would be wise to stop before doing anything ...

do_syntax_checking

#printf "%s\n" ${RETVAL}

if [ $RETVAL != "0" ]; then

printf "The configuration file produced errors - please check\n"

printf "Can’t continue configuration - doing nothing!\n"

printf "for resetting to default values run command: ccube_reset\n"

exit 0

fi

# if we are here - then the checking was ok and we can continue

#printf "%s\n" $RETVAL

################################

# first we stop relevant processes...

service seiscomp stop

#service openvpn stop

40

service networking stop

echo sleep for a second

sleep 1

###############################

# now we need to re-write configuration files given the

# information in the config file and exxtracted to the /tmp directory

#

# we start with updating the seedlink.ini and cube.ini files...

/usr/local/bin/write_seedlink_and_plugin_ini_from_tmp.sh

#

# now we continue with the CUBE^3 configuration

/usr/local/bin/write_cube_config_file_from_tmp.sh

/usr/local/bin/cube_fs.py

echo sleep for 5 seconds

sleep 5


echo sleep again for 5 seconds

sleep 5

## the following action is somehow prone to error...

cp /mnt/CONFIG.TXT /tmp/CONFIG.TXT

cp /mnt/STATION.TXT /tmp/STATION.TXT

cp /home/sysop/var/lib/seedlink/cubeconfig.txt /mnt/CONFIG.TXT

cp /home/sysop/var/lib/seedlink/STATION.TXT /mnt/.

## before umounting - sync...

sync

umount /mnt

/usr/local/bin/cube_stream.py

echo sleep for another 3 seconds

sleep 3

#

# finally we update the network / device configuration - this includes openvpn ...

#/usr/local/bin/write_openvpn_config_from_tmp.sh

/usr/local/bin/write_interface_file_from_tmp.sh

###############################

# now we may switch behaviour according to the argument given on command line ...

# reboot or restart processes...

# not used for the moment ... !!

#if [ $1 == "reboot" ]; then

#reboot

#else

service seiscomp start

service networking start

#service openvpn start

#fi

#############################################################

#############################################################

## example configuration file

#############################################################

##

## Configuration file for CCube - used with master-script

## version 0.1 - Tue Mar 8 11:40:53 CET 2016

## author: Matthias Ohrnberger, [email protected]

##

#

##############################################################

## CUBE acquisition parameters section

## we may think of "ACTION GET/SET" parameter .... (?)

#DIGITIZER-ID AAC

#DIGITIZER-VERS 1 # may be 1 or 2 ... (different config files)

#S_RATE 100 # one of 50, 100, 200, 400

#P_AMPL 1 # one of 1, 2, 4, 8, 16, 32, 64

#E_NAME MAMBA

## GPS_ON is going to be set to one (1) ALWAYS! not selectable

## rest of CUBE^3 configuration file is pre-set with fixed values

##############################################################

#

##############################################################

## seedlink / cube_plugin parameters

## parameters needed to setup up cube_plugin and seedlink

#NETWORK yy

#STATION ABCDE # check whether it may be 5 characters... (?)

## LOCATION 00 # not yet compatibel with plugin

#STREAM HH

41

#SATELLITES 3 # minimum number of satellites needed

##############################################################

#

##############################################################

## Communication settings - specification of operation for

## all network devices: eth0 / wlan0 and usb0

#ETHERMODE 1 # one of 0, 1, 2 - add as u need ...

#ETHERIP AUTO # derived from device eeprom

#WLANMODE 0 # one of 0, 1, 2 - add as u need ...

#WLANIP AUTO # derived from device eeprom

#WLANCHAN 1 # one of 1, 6, 12

#UMTSMODE 0 # one of 0, 1, 2, 3, 4 --> 0G,

## AUTO, 2G, 3G, or 4G

#UMTSAPN internet.t-d1.de #

##SIMPIN xxxx # pin in fulltext!

##############################################################

#

##############################################################

## VPN settings - config for device tun0

## /etc/openvpn/client.conf

#VPNPROTO udp

#VPNREMOTE 141.89.111.92 1194

##############################################################

#############################################################

42

Appendix B. Master config file example

#

# Configuration file for CCube - used with master-script

# version 0.1 - Tue Mar 8 11:40:53 CET 2016

# author: Matthias Ohrnberger, [email protected]

#

#############################################################

# CUBE acquisition parameters section

# we may think of "ACTION GET/SET" parameter .... (?)

DIGITIZER-ID AAC

DIGITIZER-VERS 1 # may be 1 or 2 ... (different config files)

S_RATE 100 # one of 50, 100, 200, 400

P_AMPL 1 # one of 1, 2, 4, 8, 16, 32, 64

E_NAME MAMBA

# GPS_ON is going to be set to one (1) ALWAYS! not selectable

# rest of CUBE^3 configuration file is pre-set with fixed values

#############################################################

#############################################################

# seedlink / cube_plugin parameters

# parameters needed to setup up cube_plugin and seedlink

NETWORK yy

STATION ABCDE # check whether it may be 5 characters... (?)

# LOCATION 00 # not yet compatibel with plugin

STREAM HH

SATELLITES 3 # minimum number of satellites needed

#############################################################

#############################################################

# Communication settings - specification of operation for

# all network devices: eth0 / wlan0 and usb0

ETHERMODE 2 # one of 0, 1, 2 - add as u need ...

ETHERIP 192.168.0.100 # derived from device eeprom

WLANMODE 0 # one of 0, 1, 2 - add as u need ...

WLANIP 172.16.0.100 # derived from device eeprom

WLANCHAN 1 # one of 1, 6, 12

UMTSMODE 0 # one of 0, 1, 2, 3, 4 -->

# 0G means OFF, 1G means AUTO, 2G, 3G, 4G

UMTSAPN internet.t-d1.de #

SIMPIN xxxx # pin in fulltext!

#############################################################

#############################################################

# VPN settings - config for device tun0

43

# /etc/openvpn/client.conf

# NOTE: please fill VPNREMOTE variable even if you don’t

# want to use openvpn - it is needed for not breaking the

# general configure script!

VPNPROTO udp

VPNREMOTE 141.89.111.92 1194

#############################################################

44

Appendix C. LED blinking codes

Figure C.7: Table showing the meaning of the LED blinking codes

45

communication cube (ccube) software and handling documentation

Documents