Post on 01-Jan-2017
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 mao@geo.uni-potsdam and daniel@geo.uni-potsdam.de.
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
echo "waiting 10 seconds ..."
sleep 10
echo connected
echo "ifconfig"
ifconfig $IP_DEV up
dhclient -v -pf /run/dhclient.eth1.pid $IP_DEV
26
echo "waiting 10 seconds ..."
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’)
flt3V = Pin(’W10’,’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
from ablib import Pin
from time import sleep
print "switch to cube data stream"
cube_power = Pin(’N7’,’OUTPUT’)
cube_stream = Pin(’S19’,’OUTPUT’)
flt5V = Pin(’W9’,’INPUT’)
flt3V = Pin(’W10’,’INPUT’)
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
bus = smbus.SMBus(0)
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
from ablib import Pin
from time import sleep
print "switch external USB off"
ext_usb_power = Pin(’N6’,’OUTPUT’)
ext_usb = Pin(’W12’,’OUTPUT’)
usb_flt5V = Pin(’W9’,’INPUT’)
usb_flt3V = Pin(’W10’,’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.
from ablib import Pin
from time import sleep
print "switch external USB on"
ext_usb_power = Pin(’N6’,’OUTPUT’)
ext_usb = Pin(’W12’,’OUTPUT’)
usb_flt5V = Pin(’W9’,’INPUT’)
usb_flt3V = Pin(’W10’,’INPUT’)
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
bus = smbus.SMBus(0)
address = 0x50
value3 = bus.read_byte_data(address,0x00)
#print "IP 3rd byte value: %d"% value
value4 = bus.read_byte_data(address,0x01)
#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
bus = smbus.SMBus(0)
address = 0x50
value3 = bus.read_byte_data(address,0x00)
#print "IP 3rd byte value: %d"% value
value4 = bus.read_byte_data(address,0x01)
#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
t=‘date +"%Y%m%d%H%M%S" -u‘
mount /dev/sda1 /mnt
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
t=‘date +"%Y%m%d%H%M%S" -u‘
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 }’|\
awk -F’:’ ’{ print $2}’ >> status
echo " " >> status
echo -n UMTS= >> status;ifconfig usb0 |\
grep inet |\
awk ’{ print $2 }’|\
awk -F’:’ ’{ print $2}’ >> status
echo " " >> status
echo -n BAT= >> status;ifconfig bat0 |\
grep inet |\
awk ’{ print $2 }’|\
awk -F’:’ ’{ print $2}’ >> status
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 = open("/sys/devices/leds.3/leds/umts_led/brightness","w")
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
from ablib import Pin
from time import sleep
print "switch umts on"
def umts_ledon():
value = open("/sys/devices/leds.3/leds/umts_led/brightness","w")
value.write(str(1))
value.close()
umts_power = Pin(’N4’,’OUTPUT’)
umts = Pin(’W12’,’OUTPUT’)
usb_flt5V = Pin(’W9’,’INPUT’)
usb_flt3V = Pin(’W10’,’INPUT’)
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
from ablib import Pin
from time import sleep
print "switch umts off"
def umts_ledoff():
value = open("/sys/devices/leds.3/leds/umts_led/brightness","w")
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
from ablib import Pin
from time import sleep
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’)
usb_flt5V = Pin(’W9’,’INPUT’)
usb_flt3V = Pin(’W10’,’INPUT’)
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
from ablib import Pin
from time import sleep
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’)
usb_flt5V = Pin(’W9’,’INPUT’)
usb_flt3V = Pin(’W10’,’INPUT’)
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
from ablib import Pin
from time import sleep
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
# 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_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 <daniel@geo.uni-potsdam.de>,
# Matthias Ohrnberger <mao@geo.uni-potsdam.de>
#
# 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 7 ]; then
printf "Calling script with illegal number of parameters!\n"
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 ...
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
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
mount /dev/sda1 /mnt
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, mao@geo.uni-potsdam.de
##
#
##############################################################
## 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, mao@geo.uni-potsdam.de
#
#############################################################
# 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