Datawell Manual Waves4 Operator
Datawell Manual Waves4 Operator
Operator Manual
2 Technical requirements 8
3 Installation 9
3.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Configuring 10
4.1 Setting up a network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Waves4 configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Buoyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3 Waved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Buoydrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 Log section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Receiver section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.3 Argos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.4 File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.5 iBuoy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.6 MkIII iBuoy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.7 RX-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.8 RX-C serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.9 RX-C Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.10 SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.11 MkIII SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.12 MkIII SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4 Wavedrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.1 Buoyd section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.2 Campaign section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Waves4rc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.1 Waved section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.2 Units section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Logging 67
5.1 Buoyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1 Program log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.2 SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.3 Argos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.4 iBuoy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Waved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2
5.2.1 CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Running 76
6.1 Starting a background program . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Buoyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.1 Starting as daemon (Linux only) . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Waved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.1 Starting as daemon (Linux only) . . . . . . . . . . . . . . . . . . . . . . 76
6.4 The Waves4 program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7 Troubleshooting 77
C Changelog 109
C.1 Version 5.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.2 Version 5.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.3 Version 5.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.4 Version 4.18.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.5 Version 4.16.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.6 Version 4.14.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.7 Version 4.12.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.8 Version 4.10.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.9 Version 4.8.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.10 Version 4.6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3
C.11 Version 4.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.12 Version 4.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.13 Version 4.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.14 Version 4.0.0-beta4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.15 Version 4.0.0-beta3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.16 Version 4.0.0-beta2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.17 Initial version 4.0.0-beta1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Bibliography 114
Glossary 115
4
1 Introduction
This is the Operator Manual for the Waves4 suite. The Operator Manual describes the parts of the
suite aimed at operators, like installation, configuration, maintenance and trouble shooting. The
manual also contains information regarding the custom protocols used in the suite.
The software suite consists of the following programs:
Buoyd Which receives and logs of the raw data received from the buoys.
Waved Which acts as a proxy server and gets the data from one or more buoyd receiver pro-
grams. The proxy processes the data and makes the data available for one or more Waves4
programs.
The Waves4 configurator This program is used to configure buoyd and waved during their exe-
cution.
The Waves4 program The user program to watch and monitor the received buoyd data. The
program also allows the user to (re)process the received data.
Normally the user does not use nor configure buoyd, waved, or the Waves4 configurator. The
user normally only uses the Waves4 program and is not aware of the other programs.
1.1 Programs
After the short introduction to the shipped programs, they are discussed more verbose in the sec-
tions below.
1.1.1 Buoyd
This program receives the data from a receiver, this program can receive all data send by the var-
ious Datawell buoys over the various links. So unlike the W@ves21 program, which had various
receiver programs1 this suite has one program to receive all kinds of buoy data. An overview of
the planned support can be found in table 1.1 below.
The program will normally run as background process2 . This means the software doesn’t need
to have a user logged into the system to work.
The software can receive the following buoys in alphabetic order:
HVA file This receiver module reads data from an HVA file and sends that at a rate of 1.28 Hz.
This module is intended for demonstration purposes and internal testing.
HXV file This receiver module reads data from an HXV file and sends that at a rate of 1.28 Hz.
This module is intended for demonstration purposes and internal testing.
RX-C over Ethernet This receiver module receives the data from an RX-C receiver via a TCP/IP
connection.
RX-C over a serial-port This receiver module receives the data from an RX-C receiver via the
serial port. The difference between the Ethernet and the serial port is the difference in the
configuration file, the data transmitted is the same.
RX-D This receiver module receives the data from an RX-D receiver via the serial port.
1
The programs are rfBuoy, iBuoy, GSM B UOY and O B UOY
2
Called a service under Windows, and daemon under Linux
5
SBD This receiver module receives the data from an e-mail server. The data is transmitted via the
Iridium satellite system.
Argos This receiver module receives the data from an e-mail server. The data is transmitted via
the Argos satellite system.
iBuoy This receiver module receives the data from the Internet.
This version of buoyd only supports the HF link, future versions will allow the other commu-
nication options; O RBCOMM and GSM and the Datawell DWR MkIII. Table 1.1 shows the support
matrix of various buoy types and their receivers.
RX-C (ethernet)
RX-C (serial)
OrbComm
Warec
Diwar
RX-D
iBuoy
Argos
Direc
GSM
SBD
XX
XX Receiver
XXX
Buoy XXX
X
Wavec - X - - - - - - - - -
DWR I - - X X X X - - - - -
DWR II - - X X X X - - - - -
WR /FL X - - - - - - - - - -
WR-SG - - - P P P ? ? P ? P
DWR MkIII - - - P P P ? ? P ? P
DWR-G - - - P P P ? ? P ? P
DWR4 - - - - P P ? ? P P P
Legend:
? Not yet determined how this combination will be implemented in the Waves4 suite.
1.1.2 Waved
This is a new program which is not available with the W@ves21 and SeaSaw21 program. Like
buoyd, waved runs as a background process. Waved collects the data from (multiple) buoyd
programs and stores the data in a generic XML file. Also the user software, the Waves4 program,
retrieves the measured and processed wave data from this program.
6
the package not all features might be available. The usage of the Waves4 program is not described
in this Operator Manual, refer to the accompanied User Manual for its usage.
7
2 Technical requirements
In general follow your OS recommendations, for the installation of the entire suite about 200 MB
is needed. On Linux systems the installer is much smaller since it uses the system libraries, which
will be installed if not already available.
The Waves4 suite uses UDP broadcast messages to automatically detect the various programs
on the network. For optimal usage of the suite these UDP broadcast messages should be allowed.
By default ports 2998 and 2999 are used, but these can be configured.
The software is tested on the following platforms:
• Windows
• Linux
If you wish to install the Waves4 suite on a Linux system, which is not listed above please
contact our sales department.
8
3 Installation
The software runs on both the Windows and Linux platform and it is also possible to have the
different programs running on different platforms. E.g. buoyd and waved on a Linux server while
the users use the Waves4 program on the Windows platform.
3.1 Windows
The software is delivered as an installation program on the installation USB flash drive. When
the USB flash drive is put in the USB port the autorun feature will start a webbrowser with the
installation page.
3.2 Linux
The installation on Linux requires to add the Datawell repository to the list of known repositories.
This is described in [Dat13b]. Then the packages will be shown in the list of new packages.
3.3 Upgrading
When upgrading the Waves4 suite all packages on all machines may need to be kept in sync.
Whether or not that is required will be listed in the release notes. In general Datawell will try to
avoid the mandatory upgrade of all parts, but when communication protocols change this might
be required.
9
4 Configuring
All programs, except the Waves4 configurator are configured with an XML configuration file. This
file can be given as startup parameter for the program, if not given it looks for the file in its default
locations. If the file is given as startup parameter and that file cannot be found it will also look at
the default locations. The default locations are:
• Buoyd
– Linux
* /etc/datawell/buoydrc
– Windows
* %ProgramData%/Datawell/buoydrc
• Waved
– Linux
* /etc/datawell/wavedrc
– Windows
* %ProgramData%/Datawell/wavedrc
receiver A receiver is a physical receiver – like the RX-C – or a non-physical receiver – like a
SBD e-mail message – . The id of a receiver shares the same name space as the ids of the
campaigns and every id should be unique throughout the network.
campaign A receiver receives one or more campaigns at any given time. A RX-C receiver re-
ceives one (over time the one it receives can change). A SBD receiver may receive multiple
campaigns.
The id of a campaign must be unique throughout the network. For receivers with only one
campaign it is the id of the receiver.
buoyd A running instance of buoyd. On the network all buoyd programs need to have an unique
id.
1
The settings in the Waves4 program do not need to be done if the defaults are good enough.
10
The uniqueness of the campaign ids is required so the automatic connection can find the proper
campaign. When using manual connections the ids aren’t used for the connection, but are still used
for other identification purposes.
When UDP broadcasts work on the network it is possible to get a list of campaigns on the
network by using the telnet connection. So before adding a new campaign to the network you can
get an overview of the campaigns already used on the network.
Figure 4.1: The main window of the Waves4 configurator after starting the application.
11
4.2.1 Settings
The settings dialogue as shown in figure 4.2, holds the configuration parameters of the Waves4
configurator.
Buoyd port This is the port number buoyd uses for UDP broadcast messages.
Waved port This is the port number waved uses for UDP broadcast messages.
Display details Configures the amount of details shown in the Waves4 configurator. By default
only the fields, which are used for normal configuration, are shown. In certain cases it might
be required to also modify not so commonly modified fields. By increasing the amount of
details these settings become visible.
Automatically issue a ‘save config’ command This setting is only used in the iBuoy receiver.
When an iBuoy setting is modified it is only modified in the RAM of the buoy. After the
buoy is powered down or reset the settings are loaded from the EEPROM. In order to make
the change permanent it needs to be saved to the EEPROM. This command can be issued
manually or automatically. By default settings are stored automatically; by clearing this
check box the settings will no longer be automatically saved.
4.2.2 Buoyd
Starting with version 4.18.0 the Waves4 configurator offers support for configuring buoyd. The
support is complete; this means it is no longer required to manually modify the buoydrc file.
When the Waves4 configurator is started with a new buoydrc file it is advisable to change
the display details in the settings to ‘Advanced’. Figure 4.3 shows the window after selecting the
buoyd server named ‘buoyd’.
When editing the fields in the window some fields may require buoyd to restart. Unlike the
receiver fields this restart is not done automatically, but requires a manual restart. Fields requiring
a restart have a note in their description. It is safe to wait with a restart until all fields in this
window are set to their final value:
The window shows the following fields:
ID This shows the ID of buoyd on the network. The ID must be unique on the network.
Note after changing this field buoyd must be restarted before the changes take effect.
12
Figure 4.3: The main window of the Waves4 configurator after selecting the buoyd server with
‘advanced’ display details.
Communication port This port hosts a TCP and UDP server. This port is used by waved to
connect to buoyd.
If you are running multiple instances of buoyd with one instance of waved on the same
network, make sure they all use the same port. (When using the same port it is not possible
to run multiple copies of buoyd on the same system.)
Warning make sure the firewall settings on the server where buoyd is running allows incom-
ing TCP and UDP traffic on the selected port.
Note after changing this field buoyd must be restarted before the changes take effect.
Server storage root This directory is the base directory to store the received data and log files.
Warning the path is the path on the server where buoyd is running, if the Waves4 configurator
runs on a different machine, make sure to select the proper path.
Note after changing this field buoyd must be restarted before the changes take effect.
Password This field contains the password required for configuring the settings of buoyd. The
display of the password always looks the same and cannot be used to determine whether or
not a password is set.
Note it is recommended to use the same password for waved and all buoyd instances on the
network.
13
Log severity This field determines the minimum severity of the log messages to be printed. Mes-
sages with a lower severity are not outputted.
Restart required The checkbox shows whether one or more settings, that require a restart, have
been modified.
Restart Restarts the server. Shortly after the button has been pressed the ‘Restart required’ check-
box should be cleared.
When changing the display details to ‘All’ the following extra fields appear:
Log domains This allows to manage the log domains for buoyd as described in §4.3.1.1.
Right-clicking on the buoyd server in the tree shows a menu, allowing to create new receivers
for the buoyd server. This shows the wizard as shown in figure 4.4.
ID The ID of a the new receiver. The ID must be unique for all buoyd instances on the network.
After entering these two field press the ‘Forward’ button. This asks more information regard-
ing the type of buoy, receiver, and file format used. When for a specific question only one valid
option is available the question will be skipped. After the selection is done the overview of the
choices as shown in figure 4.5 is shown.
Pressing ‘OK’ creates a disabled receiver with the selected basic settings. After the receiver
is created it needs to be configured further. After configuring the receiver needs to be enabled to
start its data acquisition.
14
Figure 4.5: The add receiver wizard’s selection overview.
4.2.2.1 SBD
The window, after expanding the tree and selecting the SBD receiver, is shown in figure 4.6. On
the right-hand side fields are visible. The fields correspond to the fields in the SBD receiver’s
configuration, as described in §4.3.10. Not all fields available in the configuration file are visible.
The ones not visible are fields that normally do not need to be configured, §4.2.1 describes how to
show these fields when they need to be configured.
Clicking on one of the ‘Edit’-buttons either toggles the flag or shows a dialogue to give a new
value. After editing the value it will be directly updated in buoyd. When the configuration is pro-
tected by a password (see §4.3) it will prompt for a password. This password will be remembered
for the rest of the session. Therefore it is recommended to use the same password for all buoyd
instances.
Right-clicking on the SBD receiver in the tree shows a menu, allowing to create new cam-
paigns for the SBD receiver. This shows a dialogue prompting for a campaign name and an IMEI
number, see figure 4.7.
After adding the campaign it will be visible in the tree. After selecting the new campaign its
settings become visible as shown in figure 4.8.
It shows the configuration of all messages available for that type of buoy. The messages are
described in the DWTP specifications [Dat13a]. Initially the Waves4 configurator will not know
the settings and set them to NaN values. Double clicking on a row in the settings shows a dialogue
which allows you to modify the settings for that specific message. This dialogue is shown in
figure 4.9.
In the dialogue the transmission interval and offset can be selected. The meaning of the offset
and interval are described in more detail in the DWTP specifications [Dat13a, §4.19.1 Communi-
cation option message configuration (0xFE1)]. Sending NaN values to the buoy is not allowed.
Starting with version 4.0.14 of the Waves4 configurator it is also possible to right-click on a
message and get the same functionality as for the iBuoy receiver. The functionality is described in
§4.2.2.3.1. Note whether or not this feature can return information depends on the buoy’s firmware
version.
15
Figure 4.6: The main window of the Waves4 configurator after selecting the SBD receiver.
16
Figure 4.8: The main window of the Waves4 configurator after selecting the ‘test’ campaign of the
SBD receiver.
17
4.2.2.2 Argos
Starting with version 4.12.0 the Waves4 configurator offers the same capabilities for the Argos
campaigns as for the SBD campaigns2 . The workings of the Argos configuration are analogue to
the workings the SBD configuration and not described in detail. The fields of the Argos campaign’s
configuration are described in §4.3.3.
4.2.2.3 iBuoy
Starting with version 4.14.0 the Waves4 configurator offers support for iBuoy campaigns3 . iBuoy
campaigns differ from both SBD and Argos campaigns. The fields of a campaign are shown in
figure 4.10.
Unlike the fields of the campaigns of other receivers, these fields have two extra buttons: The
download button to retrieve the settings of the field, and the task manager button to review the
status of the communication with the buoy. The edit button also behaves differently from the edit
button of the other fields.
2
Argos support has been added to the entire Waves4 suite starting with version 4.12.0.
3
iBuoy support has been added to the entire Waves4 suite starting with version 4.14.0.
18
iBuoy offers a direct two-way communication between the buoy and buoyd, therefore Datawell
created its own communication protocol [Dat16a] on top of a TCP/IP connection. When pressing
the download button the request for the fields contents will be sent to buoyd where it is stored as a
task. The status of a task can be reviewed in the task manager. When the buoy connects to buoyd
it first transmits the DWTP data buffered by the buoy, then buoyd will execute its pending tasks.
Once a task is processed the settings of buoyd are updated depending on the task and the changes
are also visible in the Waves4 configurator.
The same also happens when a field is modified with the ‘edit’ button; the field’s contents will
not be updated until the task has been executed properly.
Tasks are executed when the buoy connects to buoyd. It is likely there is no operator around
when this happens. Therefore the status of the execution is stored in the task manager and needs
to be manually removed after reviewing the status. The task manager button shows the status of
the task manager. Pressing the button opens the task manager.
When a new campaign is created the settings are unknown and tasks to download the setting
from the buoy are created automatically. The task dialogue as shown in figure 4.11 displays the
status of the tasks for a certain field. This dialogue allows to look at more details of a task, or
delete a task once it has been completed.
When the ‘Display details’ in the settings are increased several action buttons will be shown.
Depending on the level the following buttons are shown:
Advanced This shows the buttons to interact with the files on the buoy’s logger.
Get file list When pressing this button it requests the buoy to transmit the list of files stored
on the logger. §4.2.2.3.1 explains the usage in more detail.
Get file piece This button shows a dialogue, which allows the user to retreive a file or a part
of a file from the buoy’s logger. §4.2.2.3.1 explains the usage in more detail.
All This shows the buttons to issue very specific commands, which should only be used by ex-
perts.
Reset When this button is used the buoy will reset itself after the communication with
buoyd has finished.
Save config §4.2.1 describes the ‘Automatically issue a ‘save config’ command’ checkbox.
When this checkbox is not checked it is possible to manually issue the save config
command.
Recall config §4.2.1 describes the ‘Automatically issue a ‘save config’ command’ check-
box. When this checkbox is not checked it is possible revert the buoy’s settings to an
earlier state, by restoring the settings saved in the buoy’s EEPROM.
19
4.2.2.3.1 Retrieve data from the buoy’s logger
iBuoy has two ways to retrieve data from the buoy’s logger:
When requesting files the ‘Display details’ in the settings must be set to ‘Advanced’, or ‘All’.
This shows the ‘Get file list’ and ‘Get file piece’ button. When retrieving a file its exact name on
the logger must be known. When pressing the ‘Get file list’ button buoyd will ask the buoy to send
the list of files available on the logger.
Figure 4.12: The properties dialogue of the get file list task.
Once the task has been executed successfully the files on the logger are known and can be seen
in the properties of the ‘get file list’ task. This is shown in figure 4.12. When the task is not deleted
the list of files on the logger can directly be used in the ‘get file piece’ dialogue. The dialogue is
shown in figure 4.13.
In the dialogue, the drop-down entry lists the files on the logger, known by the Waves4 config-
urator. The other fields to enter are the offset of the first byte to retrieve and the number of bytes
to retrieve. The number of bytes to retrieve is limited to 65534. If more bytes of a file are wanted,
multiple retrieve commands can be issued. §5.1.4.3 explains the offset and count in more detail.
It also explains where the received data is stored.
20
It is also possible to retrieve a specific DWTP packet. Select a message in the list of messages.
Right-click on the message. A dialogue will be shown, allowing the user to select the date and
time of the wanted message. If the message with the wanted timestamp exists it will be send and
processed by waved. If the message does not exist, the buoy will look ahead for a message with a
greater timestamp and if one if found close to the wanted time, that message is sent instead. This
is useful for the GPS message since its exact timestamp is unknown.
4.2.3 Waved
Starting with version 4.16.0 the Waves4 configurator offers support for configuring waved. The
support is complete; this means it is no longer required to manually modify the wavedrc file.
When the Waves4 configurator is started with a new wavedrc file it is advisable to change the
display details in the settings to ‘Advanced’. Figure 4.14 shows the window after selecting the
waved server named ‘waved’.
Figure 4.14: The main window of the Waves4 configurator after selecting the waved server with
‘advanced’ display details.
When editing the fields in the window some fields may require waved to restart. Unlike the
campaign and receiver fields this restart is not done automatically, but requires a manual restart.
Fields requiring a restart have a note in their description. It is safe to wait with a restart until all
fields in this window are set to their final value:
The window shows the following fields:
ID This shows the ID of waved on the network. The ID must be unique on the network. Note
normally only one instance of waved should be run, in which case the ID is always unique.
21
Note after changing this field waved must be restarted before the changes take effect.
Communication port This port hosts a TCP and UDP server. This port is used by Waves4 to
connect to waved.
If you want to run multiple instances of waved on the same network, make sure they all use
a different port.
Warning make sure the firewall settings on the server where waved is running allows incom-
ing TCP and UDP traffic on the selected port.
Note after changing this field waved must be restarted before the changes take effect.
Server storage root This directory is the base directory to store the received data and log files.
Warning the path is the path on the server where waved is running, so when the Waves4
configurator runs on a different machine, make sure to select the proper path.
Note after changing this field waved must be restarted before the changes take effect.
Password This field contains the password required for configuring the settings of waved. The
display of the password always looks the same and cannot be used to determine whether or
not a password is set.
Note it is recommended to use the same password for waved and all buoyd instances on the
network.
Log severity This field determines the minimum severity of the log messages to be printed. Mes-
sages with a lower severity are not outputted.
Buoyd communication port The TCP and UDP port used to connect to buoyd. The value used
by buoyd is stored in its buoydrc file as described in §4.3.
Note after changing this field waved must be restarted before the changes take effect.
Restart required The checkbox shows whether one or more settings, that require a restart, have
been modified.
Restart Restarts the server. Shortly after the button has been pressed the ‘Restart required’ check-
box should be cleared.
When changing the display details to ‘All’ the following extra fields appear:
Log domains This allows to manage the log domains for waved as described in §4.3.1.1.
Stop This directly stops the waved server.
Warning after stopping the server it needs to be manually restarted in order to use waved
again.
Right-clicking on the waved server in the tree shows a menu, allowing to create new campaigns
for the waved server. This shows the dialogue as shown in figure 4.15.
The dialogue has the following fields:
Campaign The ID of a campaign as configured in buoyd. Depending on the type of receiver used
in buoyd the campaign name is the same as the receiver or the name is one of the campaigns
of the receiver.
Transmission port The TCP used by Waves4 to connect the campaign.
Warning make sure the firewall settings on the server where waved is running allows incom-
ing TCP traffic on the selected port.
This creates an enabled campaign with the selected settings.
22
Figure 4.15: The add campaign dialogue.
4.2.3.1 Campaign
Configuring the settings of a campaign can normally be done with the display details set to ‘Nor-
mal’. After selecting a campaign of the waved server it shows a window as shown in figure 4.16.
Enabled This flag controls whether the campaign is enabled or disabled. When the campaign is
disabled it will not receive new data from buoyd. Waves4 will still be able to receive the
cached data.
CSV Enabled This field determines whether or not there will be CSV output. The format of the
CSV output is described in §5.2.1.
23
When changing the display details to ‘Advanced’ the following extra fields appear:
Use verbose filename Controls the setting of the ‘use verbose filename’ field, as described in
§4.4.2.
CSV Month names as string Controls the setting of the ‘output directory month as string’ field,
as described in §4.4.2.1.
4.3 Buoydrc
The configuration of buoyd is stored in a custom XML format. It is possible to modify this file
manually, but that is not advised. The Waves4 configurator is able to fully modify the file. The
use of the Waves4 configurator for buoyd is described in §4.2.2.
The structure is a XML tree, whose root node is named buoydrc. All nodes are mandatory, but
nodes can have a default or a fixed value. These nodes can simply be defined as <node/> and its
default of fixed value is used.
The nodes in the structure are:
id
• Mandatory field.
• The id of buoyd. This id must be unique for all buoyd instances on the network. An
empty value is not allowed.
• Introduced in version 1 of the configuration format.
• Changing this field using the communication protocol requires buoyd to be restarted.
storage root
• Mandatory string.
• Introduced in version 1 of the configuration format.
• Behaviour of an empty field changed in version 4.18.0 of the Waves4 suite.
• Changing this field using the communication protocol requires buoyd to be restarted.
This directory is the base directory to store the received data and log files.
If the field is empty a default location is used. The default depends on the operating system:
24
Windows It selects the directory %ProgramData%/Datawell/buoyd/. The %ProgramData%
usually is the directory C:/ProgramData.
Linux It selects the directory /var/lib/datawell/buoyd/.
password
• Optional string.
• Introduced in version 4 of the configuration format.
This field contains the password required for configuring the settings of buoyd. If the field
is omitted the value is an empty string.
Note It is recommended to use the same password for all buoyd and waved instances on the
network. This makes using Waves4 configurator easier.
log
• Optional section.
• Introduced in version 4 of the configuration format.
This section configures the logger setting of buoyd. If the section is omitted the default
logger settings are used. The details of this section are described in §4.3.1.
<!−− A L i n u x s t y l e f i l e n a m e . −−>
<f i l e n a m e >/ mnt / d a t a / e x a m p l e . hxv </ f i l e n a m e >
25
</ r e c e i v e r >
<r e c e i v e r >
<!−−
! ! A RX−D r e c e i v e r a s e x p l a i n e d i n §4.3.4 .
! ! T h i s v e r s i o n i s u s e d on L i n u x u s i n g t h e
!! f i r s t s e r ia l port .
−−>
<i d >L o c a t i o n a l p h a RX−D Linux </ i d >
< t r a n s m i s s i o n p o r t >3001</ t r a n s m i s s i o n p o r t >
<r e c e i v e r >
<!−−
! ! A RX−D r e c e i v e r a s e x p l a i n e d i n §4.3.7 .
! ! T h i s v e r s i o n i s u s e d on Windows u s i n g t h e
! ! f i r s t s e r i a l port . ( Obviously i t i s not
! ! p o s s i b l e t o mix a L i n u x and Windows
!! configuration in a real configuration f i l e . )
−−>
<i d >L o c a t i o n a l p h a RX−D Windows </ i d >
< t r a n s m i s s i o n p o r t >3002</ t r a n s m i s s i o n p o r t >
<r e c e i v e r >
<!−−
! ! A RX−C r e c e i v e r , u s i n g t h e s e r i a l p o r t ,
! ! a s e x p l a i n e d i n §4.3.8 .
! ! T h i s v e r s i o n i s u s e d on L i n u x u s i n g
!! the f i r s t s e r i a l port .
−−>
<i d >L o c a t i o n a l p h a RX−C s e r i a l </ i d >
< t r a n s m i s s i o n p o r t >3003</ t r a n s m i s s i o n p o r t >
<!−−
! ! F o r u s a g e on Windows s e l e c t an
! ! a p p r o p r i a t e COM p o r t .
−−>
< r x c s e r i a l p o r t >/ dev / t t y S 0 </ r x c s e r i a l p o r t >
<h x v b u o y t y p e >WR−SG</ h x v b u o y t y p e >
< f i l e f o r m a t >HXV</ f i l e f o r m a t >
<t y p e >RX−C s e r i a l </ t y p e >
</ r e c e i v e r >
26
<r e c e i v e r >
<!−−
! ! A RX−C r e c e i v e r , u s i n g t h e E t h e r n e t p o r t ,
! ! a s e x p l a i n e d i n §4.3.8 .
! ! T h e r e i s no d i f f e r e n c e f o r L i n u x and
! ! Windows f o r t h i s r e c e i v e r .
−−>
<i d >L o c a t i o n a l p h a RX−C E t h e r n e t </ i d >
< t r a n s m i s s i o n p o r t >3004</ t r a n s m i s s i o n p o r t >
<r x c e t h e r n e t h o s t n a m e >
localhost
</ r x c e t h e r n e t h o s t n a m e >
< r x c e t h e r n e t p o r t >1180</ r x c e t h e r n e t p o r t >
<h v a b u o y t y p e >GPS−DWR4</ h v a b u o y t y p e >
<t y p e >RX−C E t h e r n e t </ t y p e >
</ r e c e i v e r >
</ b u o y d r c >
severity
• Mandatory field.
• Must contain one of the following values:
fatal For fatal errors.
error For errors.
warning For warnings.
information For information messages.
debug For debug messages.
• Introduced in version 4 of the configuration format.
This field determines the minimum severity of the log messages to be printed. Messages
with a lower severity are not outputted.
When this field is changed using the communication protocol it is recommended to restart
waved. When waved is not restarted the order of setting the log severities may differ from
the normal order. A restart sets the severities in the requested order. The different order is
not harmful, but may set loggers to unexpected severities.
Note Starting with version 4.18.0 of the Waves4 suite this field can also be modified in buoyd
with the communication protocol.
domain
27
Contains the overrides of the default severity for certain domains. The override can lower
or increase the severity. The details of this section are described in §4.3.1.1.
domain
• Mandatory field.
• Must contain a domain string.
• Introduced in version 4 of the configuration format.
The domain string determines which domain’s severity should be overridden. The available
domains in buoyd can be retrieved from buoyd by running buoyd --log-domains. The
available domains depend on the version of buoyd, during development of the software new
domains can be added or existing domains removed.
The domain path uses the forward slash ‘/’ as path separator, the initial path starts with a
leading forward slash. The asterisk ‘*’ can be used as wildcard for a domain. For example:
/* Selects every domain. This is the same as setting the global severity.
/modules/* Selects every domain under the modules. When this override is set its setting
will also be used when other sub-modules are added.
/modules/logger Selects the ‘logger’ sub-module in modules. Unlike the previous exam-
ple this version will only override the severity for the ‘logger’ sub-domain and won’t
change when more sub-modules are added in the future.
severity
• Mandatory field.
• Must contain one of the following values:
fatal For fatal errors.
error For errors.
warning For warnings.
information For information messages.
debug For debug messages.
• Introduced in version 4 of the configuration format.
This field determines the minimum severity of the log messages to be printed. Messages
with a lower severity are not outputted.
When this field is changed using the communication protocol it is recommended to restart
waved. When waved is not restarted the order of setting the log severities may differ from
the normal order. A restart sets the severities in the requested order. The different order is
not harmful, but may set loggers to unexpected severities.
Note Starting with version 4.18.0 of the Waves4 suite this field can also be modified in buoyd
with the communication protocol.
28
4.3.2 Receiver section
The receiver section contains several fields common to all receivers and depending on the type of
the receiver. A receiver section starts with the following fields:
id
The id of receiver. This id must be unique for all receivers of all buoyd instances on the
network.
transmission port
The port number the receiver starts a TCP network listener. When a program connects to
this network port it will receive all the data being received from the receiver. This is used
by waved to receive the data of a receiver.
Note the notes for the communication port apply here as well.
Older versions of buoyd stored the received data and log files without a campaign name and
without a file extension. This option allows to store the files with filenames including the
campaign name and a file extension.
Starting with version 10 of the configuration format the filenames have been modified. This
format is now always used.
type
The last field of the receiver is the type field. That this field is the last field looks a bit odd,
but it is caused by limitations regarding validating XML files. Due to this reasons the field
has a fixed value, so its value may be omitted.
The field has one of the following values:
Argos This is an e-mail based receiver, that gets its data from the Argos satellite system.
The other nodes in the receiver for this type are described in §4.3.3.
file The receiver is not a receiver, but receives its data from a file. This option is mainly used
for demonstration purposes. The other nodes in the receiver for this type are described
in §4.3.4.
iBuoy This is an Internet based receiver, that gets its data from, for example, the Iridium
satellite system. This receiver can only be used for buoys of the 4-series. For the MkIII
buoys use the MkIII iBuoy receiver instead. The other nodes in the receiver for this
type are described in §4.3.5.
MkIII iBuoy This is an Internet based receiver, that gets its data from, for example, the
Iridium satellite system. This receiver can only be used for the MkIII buoys. For
buoys of the 4-series use the iBuoy receiver instead. The other nodes in the receiver
for this type are described in §4.3.6.
MkIII SBD This is an e-mail based receiver, that gets its data from, the Iridium satellite
system. This receiver can only be used for the MkIII buoys. For buoys of the 4-series
use the SBD receiver instead. The other nodes in the receiver for this type are described
in §4.3.11.
29
MkIII SMS This is a SMS based receiver, that gets its data from, the GSM network. This
receiver can only be used for the MkIII buoys. The other nodes in the receiver for this
type are described in §4.3.12.
RX-D The receiver is a RX-D receiver. The other nodes in the receiver for this type are
described in §4.3.7.
RX-C serial This is the RX-C receiver using its serial port. The other nodes in the receiver
for this type are described in §4.3.8.
RX-C Ethernet This is the RX-C receiver using its Ethernet port. The distinction between
the RX-C types is only required due to the different settings. The receivers are the
same. The other nodes in the receiver for this type are described in §4.3.9.
SBD This is an e-mail based receiver, that gets its data from the Iridium satellite system.
The other nodes in the receiver for this type are described in §4.3.10.
4.3.3 Argos
This section was introduced in version 5 of the configuration format.
This receiver receives e-mail messages from the Argos satellite system. The Argos receiver
has the following fields:
enabled
• Mandatory field.
• Contains the e-mail address the Argos e-mails are received from.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to ‘[email protected]’.
• Introduced in version 5 of the configuration format.
• Mandatory field.
• Contains the filter of the subject for incoming Argos e-mail messages. When buoyd
looks at the e-mails on the POP3 server it filters them based on the sender and its
subject. E-mails not passing this filter are not retrieved and remain on the server. This
makes it possible to an e-mail account, which is also used for other e-mail. Note
Datawell recommends a dedicated e-mail account for Argos e-mail messages.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to: ‘Argos data’.
• Introduced in version 5 of the configuration format.
30
• Mandatory field.
• Must contain the hostname or IP address of the POP3 server.
• Introduced in version 5 of the configuration format.
• Mandatory field.
• If empty, the field defaults to 110.
• Must contain the port number of the POP3 server.
• Introduced in version 5 of the configuration format.
• Mandatory field.
• Must contain the user name used to log in the POP3 server.
• Introduced in version 5 of the configuration format.
• Mandatory field.
• Must contain the password used to log in the POP3 server.
• Introduced in version 5 of the configuration format.
campaign
Listing 4.2 contains an example of this receiver. Since the Waves4 configurator is used to
create the campaign sections they are ignored in this example.
< a r g o s e m a i l f r o m f i l t e r />
< a r g o s e m a i l s u b j e c t f i l t e r />
<a r g o s p o p 3 h o s t n a m e >y o u r . s e r v e r </ a r g o s p o p 3 h o s t n a m e >
<!−− <a r g o s p o p 3 p o r t n u m b e r /> would do t h e same . −−>
<a r g o s p o p 3 p o r t n u m b e r >110</ a r g o s p o p 3 p o r t n u m b e r >
31
<a r g o s p o p 3 p a s s w o r d >p a s s w o r d </ a r g o s p o p 3 p a s s w o r d >
<a r g o s p o p 3 u s e s s l >f a l s e </ a r g o s p o p 3 u s e s s l >
4.3.3.1 Campaign
This section was introduced in version 5 of the configuration format.
The section describes a campaign in the Argos receiver.
id
argos id
• Mandatory field.
• Must be in the range [0..228 ).
• The Argos ID of the Argos subscription. Every Argos ID can only be used for one
campaign. If multiple campaigns use the same Argos ID the behaviour is undefined.
Note The decimal Argos ID must be used in this field.
• Introduced in version 5 of the configuration format.
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR4
– DWR4
– GPS-DWR4
• Introduced in version 5 of the configuration format.
4.3.4 File
This receiver appends with the following fields:
filename
The file being ‘received’. This file is read at startup and then transmitted in a loop.
• Optional field.
• Must be in the range [1..65536).
• Defaults to 1.
• Introduced in version 2 of the configuration format.
32
The transmission speed is increased by this factor. For normal usage the factor should be
1. The easiest way to achieve this is by omitting the field. For demonstration purposes the
value can be increased.
Note high values might not work properly.
enabled
The last field added for this receiver type is the file format field. The field has one of the
following values:
HXV The other nodes for this type of receiver are described in §4.3.4.1.
BVA The other nodes for this type of receiver are described in §4.3.4.2.
HVA The other nodes for this type of receiver are described in §4.3.4.3.
The values are again fixed for validation and thus its value may be omitted.
4.3.4.1 HXV
This format appends with the following fields:
• WR-SG
• DWR MkIII
• DWR-G
33
4.3.4.2 BVA
Warning This format has not yet been implemented.
This format appends with the following fields:
• WR4
• DWR4
• GPS-DWR4
4.3.4.3 HVA
This format appends with the following fields:
• WR4
• DWR4
• GPS-DWR4
34
<!−− <t y p e /> would a l s o be v a l i d . −−>
<t y p e >f i l e </ t y p e >
</ r e c e i v e r >
4.3.5 iBuoy
This section was introduced in version 6 of the configuration format.
This receiver receives its data via the Internet. The iBuoy receiver has the following fields:
enabled
• Mandatory field.
• If empty, the field defaults to 1168.
• Must contain the port number which buoyd will use to communicate with the buoy.
The receiver will start a listener process on the selected TCP port. The buoy is con-
figured to connect to the server on this port number. The connection is initiated by
the buoy, this means the server’s firewall needs to allow incoming connections on this
port.
• Introduced in version 6 of the configuration format.
campaign
Listing 4.6 contains an example of this receiver. Since the Waves4 configurator is used to
create the campaign sections they are ignored in this example.
35
4.3.5.1 Campaign
This section was introduced in version 6 of the configuration format.
The section describes a campaign in the iBuoy receiver. Most fields contain the configuration
of the buoy itself. This information is initially configured using the setup menu on the console,
as described in [Dat15, §18.9 Electronics Unit]. This information can be requested from the buoy
using the Waves4 configurator. After the information has been received buoyd caches the values,
allowing the proper values to be shown in the Waves4 configurator.
id
buoy id
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR4
– DWR4
– GPS-DWR4
• Introduced in version 6 of the configuration format.
firmware revision
hatch uid
hull uid
36
• Mandatory string field.
• This field is part of the buoy’s configuration.
• The field is managed by buoyd. It is used to determine the hull UID of the buoy. In
newer versions of the DWR4 this number is the serial number of the hatch.
• Introduced in version 6 of the configuration format.
transmission interval
dial string 1
dial string 2
hostname 1
hostname 2
port 1
• Mandatory field.
• This field is part of the buoy’s configuration.
• Contains the primary port the buoy connects to.
• Introduced in version 6 of the configuration format.
port 2
• Mandatory field.
37
• This field is part of the buoy’s configuration.
• Contains the secondary port the buoy connects to.
• Introduced in version 6 of the configuration format.
settings
task
4.3.5.1.1 Settings
This section was introduced in version 6 of the configuration format.
Contains the configuration of the campaign in the buoy. The information is used by the Waves4
configurator to extract and modify the data.
At the moment it contains zero or more message sections. The message section contains:
msgid
interval
offset
update
• A mandatory section.
• This section contains the child nodes as described in §4.3.5.1.1.1.
• Introduced in version 6 of the configuration format.
38
4.3.5.1.1.1 Message update
This section was introduced in version 6 of the configuration format.
Contains the information regarding the last update of the configuration of this message.
timestamp
origin
4.3.5.1.2 Task
This section was introduced in version 6 of the configuration format.
The section describes the tasks of a campaign of the iBuoy receiver. This section is managed
by buoyd and the Waves4 configurator. Normally the Waves4 configurator creates a task and
buoyd executes the task the next time the buoy connects to buoyd. After the task is completed it
will remain in the list. This allows the user to look at the execution result in Waves4 configurator.
Then the task can be removed with the Waves4 configurator.
id
status
• Mandatory field.
• Must contain one of the following values:
new The task is new and has never been sent to the buoy.
executing The task is currently being executed5 .
error The task has been executed and an error occurred. The software will try to
execute the task again.
malformed The task has been successfully executed, but the data received could not
be handled by the decoder software. This state should normally not occur.
failed The task has been executed and an error occurred. The software will not try to
execute the task again.
succeeded The task has been successfully executed.
4
A future version of waved will be able to receive the information of the buoy and automatically update the settings
in buoyd.
5
This value is normally not stored in the file.
39
• Introduced in version 6 of the configuration format.
creation time
modification time
counter
action
reply
enabled
40
• Introduced in version 8 of the configuration format.
• Mandatory field.
• The field is initialised to 1168 upon creation of the receiver.
• Must contain the port number which buoyd will use to communicate with the buoy.
The receiver will start a listener process on the selected TCP port. The buoy is con-
figured to connect to the server on this port number. The connection is initiated by
the buoy, this means the server’s firewall needs to allow incoming connections on this
port.
• Introduced in version 8 of the configuration format.
campaign
Listing 4.7 contains an example of this receiver. Since the Waves4 configurator is used to
create the campaign sections they are ignored in this example.
4.3.6.1 Campaign
This section was introduced in version 8 of the configuration format.
The section describes a campaign in the MkIII iBuoy receiver. Most fields contain the con-
figuration of the buoy itself. This information is initially configured using the setup menu on the
console, as described in [Dat16b, §5.17 GSM-internet communication]. This information can be
requested from the buoy using the Waves4 configurator. After the information has been received
buoyd caches the values, allowing the proper values to be shown in the Waves4 configurator.
id
buoy id
41
• Mandatory string field.
• This field is part of the buoy’s configuration.
• The buoy ID is the ID of the buoy. This ID is configured in the buoy before deploy-
ment.
• Introduced in version 8 of the configuration format.
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR-SG
– DWR MkIII
– DWR-G
• Introduced in version 8 of the configuration format.
transmission interval
dial string 1
dial string 2
hostname 1
hostname 2
42
• This field is part of the buoy’s configuration.
• The secondary hostname the buoy connects to. It is specified in [Dat16b, §5.17.4
Setting the destination addresses and ports].
• Introduced in version 8 of the configuration format.
port 1
• Mandatory field.
• This field is part of the buoy’s configuration.
• Contains the primary port the buoy connects to. It is specified in [Dat16b, §5.17.4
Setting the destination addresses and ports].
• Introduced in version 8 of the configuration format.
port 2
• Mandatory field.
• This field is part of the buoy’s configuration.
• Contains the secondary port the buoy connects to. It is specified in [Dat16b, §5.17.4
Setting the destination addresses and ports].
• Introduced in version 8 of the configuration format.
ns00
csxx
task
4.3.6.1.1 Task
This section was introduced in version 8 of the configuration format.
The section describes the tasks of a campaign of the MkIII iBuoy receiver. This section is
managed by buoyd and the Waves4 configurator. Normally the Waves4 configurator creates a task
and buoyd executes the task the next time the buoy connects to buoyd. After the task is completed
it will remain in the list. This allows the user to look at the execution result in Waves4 configurator.
Then the task can be removed with the Waves4 configurator.
43
id
status
• Mandatory field.
• Must contain one of the following values:
new The task is new and has never been sent to the buoy.
executing The task is currently being executed6 .
error The task has been executed and an error occurred. The software will try to
execute the task again.
malformed The task has been successfully executed, but the data received could not
be handled by the decoder software. This state should normally not occur.
failed The task has been executed and an error occurred. The software will not try to
execute the task again.
succeeded The task has been successfully executed.
• Introduced in version 8 of the configuration format.
creation time
modification time
counter
action
• Mandatory section.
• Contains action data of the taks. The details of this section are described in §4.3.6.1.1.1
• Introduced in version 8 of the configuration format.
6
This value is normally not stored in the file.
44
reply
4.3.6.1.1.1 Action
This section was introduced in version 8 of the configuration format.
It contains the information of the task to be executed. This section is not fully specified since
its contents are closely tied to the version of buoyd. This section must not be modified by the user.
id
command
value
4.3.7 RX-D
The RX-D cannot be used to receive the 4-series buoys, therefore the file format received is always
the HXV format. This receiver appends with the following fields:
rx d serial port
The name of the serial port to open. The name depends on the platform i.e.:
Linux The name looks like /dev/ttySx where x is the device number, starting from zero.
Windows The name looks like COMx where x is the device number, starting from one.
enabled
45
• Introduced in version 5 of the configuration format.
buoy type
The type of the buoy being received, being one of:
• WR-SG
• DWR MkIII
• DWR-G
rx c serial port
The name of the serial port to open. The name depends on the platform i.e.:
Linux The name looks like /dev/ttySx where x is the device number, starting from zero.
Windows The name looks like COMx where x is the device number, starting from one.
enabled
The last field added for this receiver type is the file format field. The field has one of the
following values:
HXV The other nodes for this type of receiver are described in §4.3.8.1.
HVA The other nodes for this type of receiver are described in §4.3.8.2.
The values are again fixed for validation and thus its value may be omitted.
46
4.3.8.1 HXV
This receiver appends with the following fields:
• WR-SG
• DWR MkIII
• DWR-G
Listing 4.9: Example of a HXV RX-C receiver using the serial port on Linux.
<r e c e i v e r >
<i d >RX−C r e c e i v e r s e r i a l on Linux </ i d >
< t r a n s m i s s i o n p o r t >3000</ t r a n s m i s s i o n p o r t >
4.3.8.2 HVA
This receiver appends with the following fields:
• WR4
• DWR4
• GPS-DWR4
Listing 4.10: Example of a HVA RX-C receiver using the serial port on Windows.
<r e c e i v e r >
<i d >RX−C r e c e i v e r s e r i a l on Windows </ i d >
< t r a n s m i s s i o n p o r t >3000</ t r a n s m i s s i o n p o r t >
47
<t y p e >RX−C s e r i a l </ t y p e >
</ r e c e i v e r >
rx c ethernet hostname
The hostname or IP address of the RX-C receiver.
enabled
The last field added for this receiver type is the file format field. The field has one of the
following values:
HXV The other nodes for this type of receiver are described in §4.3.9.1.
HVA The other nodes for this type of receiver are described in §4.3.9.2.
The values are again fixed for validation and thus its value may be omitted.
4.3.9.1 HXV
This receiver appends with the following fields:
• WR-SG
• DWR MkIII
• DWR-G
Listing 4.11: Example of a HXV RX-C receiver using the Ethernet port.
<r e c e i v e r >
<i d >RX−C r e c e i v e r u s i n g t h e E t h e r n e t p o r t </ i d >
< t r a n s m i s s i o n p o r t >3000</ t r a n s m i s s i o n p o r t >
48
< r x c e t h e r n e t p o r t >1180</ r x c e t h e r n e t p o r t >
4.3.9.2 HVA
This receiver appends with the following fields:
hva buoy type
The type of the buoy being received, being one of:
• WR4
• DWR4
• GPS-DWR4
Listing 4.12: Example of a HVA RX-C receiver using the Ethernet port.
<r e c e i v e r >
<i d >RX−C r e c e i v e r u s i n g t h e E t h e r n e t p o r t </ i d >
< t r a n s m i s s i o n p o r t >3000</ t r a n s m i s s i o n p o r t >
4.3.10 SBD
This section was introduced in version 4 of the configuration format.
This receiver receives e-mail messages from the Iridium satellite system. The SBD receiver
has the following fields:
enabled
49
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Contains the e-mail address the SBD e-mails are received from.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to ‘[email protected]’.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Contains the filter of the subject for incoming SBD e-mail messages. When buoyd
looks at the e-mails on the POP3 server it filters them based on the sender and its
subject. E-mails not passing this filter are not retrieved and remain on the server. This
makes it possible to an e-mail account, which is also used for other e-mail. Note
Datawell recommends a dedicated e-mail account for SBD e-mail messages.
Warning It is not possible to use the same e-mail account for the 4-series and MkIII
buoys.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to: ‘SBD Msg From Unit: (d+)’.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Must contain the hostname or IP address of the POP3 server.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• If empty, the field defaults to 110.
• Must contain the port number of the POP3 server.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Must contain the user name used to log in the POP3 server.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Must contain the password used to log in the POP3 server.
• Introduced in version 4 of the configuration format.
50
sbd pop3 use ssl
• Mandatory field.
• Contains the e-mail address the SBD e-mails are sent from.
This field is used as sender field for the SBD e-mail messages.
• Introduced in version 4 of the configuration format.
sbd email to
• Mandatory field.
• Contains the e-mail address the SBD e-mails are sent to.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to ‘[email protected]’.
• Introduced in version 4 of the configuration format.
sbd email cc
• Mandatory field.
• Contains the e-mail address the SBD e-mails are sent CC’ed to.
This field is available as debugging aid. Normally the field can remain empty. It can be
set to a valid e-mail address so all e-mail messages sent are also sent a CC to another
mailbox.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Contains the formatter for the subject field for the e-mails send from buoyd to the buoy.
The text of the formatter is used as is, except when it encounters a percentage sign
‘%’, then the next character determines what happens:
i The formatter is replaced with the campaign’s IMEI number.
% The formatter is replaced with a single ‘%’.
All other values after the formatter are invalid.
This field must be included, but should normally be left empty. When empty it uses
the default value, which is set correctly for normal deployment.
• If empty, the field defaults to ‘%i’.
• Introduced in version 4 of the configuration format.
• Mandatory field.
• Must contain the hostname or IP address of the SMTP server.
51
• Introduced in version 4 of the configuration format.
• Mandatory field.
• If empty, the field defaults to 25.
• Must contain the port number of the SMTP server.
• Introduced in version 4 of the configuration format.
campaign
Listing 4.13 contains an example of this receiver. Since the Waves4 configurator is used to
create the campaign sections they are ignored in this example.
<s b d e m a i l f r o m f i l t e r />
<s b d e m a i l s u b j e c t f i l t e r />
<s b d p o p 3 h o s t n a m e >y o u r . s e r v e r </ s b d p o p 3 h o s t n a m e >
<!−− <s b d p o p 3 p o r t n u m b e r /> would do t h e same . −−>
<s b d p o p 3 p o r t n u m b e r >110</ s b d p o p 3 p o r t n u m b e r >
52
< s b d e m a i l s u b j e c t f o r m a t />
4.3.10.1 Campaign
This section was introduced in version 4 of the configuration format.
The section describes a campaign in the SBD receiver.
id
IMEI
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR4
– DWR4
– GPS-DWR4
• Introduced in version 4 of the configuration format.
settings
53
4.3.10.1.1 Settings
This section was introduced in version 4 of the configuration format.
Contains the configuration of the campaign in the buoy. The information is used by the Waves4
configurator to extract and modify the data.
At the moment it contains zero or more message sections. The message section contains:
msgid
• Mandatory number field.
• The field contains the msgid of the message. It contains a number that matches with a
hexadecimal value of a msgid as specified in the DWTP protocol [Dat13a].
• Introduced in version 4 of the configuration format.
interval
• Mandatory number field.
• Contains the interval field as specified in the DWTP protocol [Dat13a, §4.19 Buoy
communication messages].
• Introduced in version 4 of the configuration format.
offset
• Mandatory number field.
• Contains the offset field as specified in the DWTP protocol [Dat13a, §4.19 Buoy com-
munication messages].
• Introduced in version 4 of the configuration format.
update
• A mandatory section.
• This section contains the child nodes as described in §4.3.10.1.1.1.
• Introduced in version 4 of the configuration format.
4.3.10.1.1.1 Message update
This section was introduced in version 4 of the configuration format.
Contains the information regarding the last update of the configuration of this message.
timestamp
• Mandatory number field.
• Contains the number of seconds since midnight January first 1970. This value is the
same as the UNIX timestamp.
• Introduced in version 4 of the configuration format.
origin
• Mandatory string field.
• The origin of the modification. The value is one of:
user The setting was modified by a user of the software, usually using the Waves4
configurator.
buoy The settings were received from the buoy7 .
• Introduced in version 4 of the configuration format.
7
A future version of waved will be able to receive the information of the buoy and automatically update the settings
in buoyd.
54
4.3.11 MkIII SBD
This section was introduced in version 9 of the configuration format.
This receiver receives e-mail messages from the Iridium satellite system. The MkIII SBD
receiver has the following fields:
enabled
• Mandatory field.
• The field is initialised to proper default value upon creation of the receiver. Normally
the field should not be modified.
• Contains the e-mail address the SBD e-mails are received from.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• The field is initialised to proper default value upon creation of the receiver. Normally
the field should not be modified.
• Contains the filter of the subject for incoming SBD e-mail messages. When buoyd
looks at the e-mails on the POP3 server it filters them based on the sender and its
subject. E-mails not passing this filter are not retrieved and remain on the server. This
makes it possible to an e-mail account, which is also used for other e-mail. Note
Datawell recommends a dedicated e-mail account for SBD e-mail messages.
Warning It is not possible to use the same e-mail account for the MkIII and 4-series
buoys.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the hostname or IP address of the POP3 server.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the port number of the POP3 server.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the user name used to log in the POP3 server.
55
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the password used to log in the POP3 server.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Contains the e-mail address the SBD e-mails are sent from.
This field is used as sender field for the SBD e-mail messages.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• The field is initialised to proper default value upon creation of the receiver. Normally
the field should not be modified.
• Contains the e-mail address the SBD e-mails are sent to.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Contains the e-mail address the SBD e-mails are sent CC’ed to.
This field is available as debugging aid. Normally the field can remain empty. It can be
set to a valid e-mail address so all e-mail messages sent are also sent a CC to another
mailbox.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• The field is initialised to proper default value upon creation of the receiver. Normally
the field should not be modified.
• Contains the formatter for the subject field for the e-mails send from buoyd to the buoy.
The text of the formatter is used as is, except when it encounters a percentage sign
‘%’, then the next character determines what happens:
i The formatter is replaced with the campaign’s IMEI number.
% The formatter is replaced with a single ‘%’.
All other values after the formatter are invalid.
56
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the hostname or IP address of the SMTP server.
• Introduced in version 9 of the configuration format.
• Mandatory field.
• Must contain the port number of the SMTP server.
• Introduced in version 9 of the configuration format.
campaign
4.3.11.1 Campaign
This section was introduced in version 9 of the configuration format.
The section describes a campaign in the MkIII SBD receiver.
id
IMEI
57
• Introduced in version 9 of the configuration format.
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR-SG
– DWR MkIII
– DWR-G
• Introduced in version 9 of the configuration format.
settings
4.3.11.1.1 Settings
This section was introduced in version 9 of the configuration format.
Contains the configuration of the campaign in the buoy. The information is used by the Waves4
configurator to extract and modify the data.
At the moment it contains zero or more message sections. The message section contains:
msgid
interval
update
• A mandatory section.
• This section contains the child nodes as described in §4.3.11.1.1.1.
• Introduced in version 9 of the configuration format.
58
4.3.12 MkIII SMS
This section was introduced in version 10 of the configuration format.
This receiver receives SMS messages from the GSM network. system. The MkIII SMS re-
ceiver has the following fields:
enabled
campaign
4.3.12.1 Campaign
This section was introduced in version 10 of the configuration format.
The section describes a campaign in the MkIII SMS receiver.
id
phone number
59
• The phone number of the SIM card in the buoy. This is used both to connect to the
buoy and determine the buoy being received. The number must be in international
format.
• Introduced in version 10 of the configuration format.
buoy type
• Mandatory field.
• The type of the buoy being received, being one of:
– WR-SG
– DWR MkIII
– DWR-G
• Introduced in version 10 of the configuration format.
transmission interval
power mode
4.4 Wavedrc
The configuration of waved is stored in a custom XML format. It is possible to modify this file
manually, but that is not advised. The Waves4 configurator is able to fully modify the file. The
use of the Waves4 configurator for waved is described in §4.2.3.
The structure is a XML tree, whose root node is named wavedrc. All nodes are mandatory, but
nodes can have a default or a fixed value. These nodes can simply be defined as <node/> and its
default of fixed value is used.
The nodes in the structure are:
id
• Mandatory field.
• The id of waved. An empty value is not allowed.
• Introduced in version 1 of the configuration format.
• Changing this field using the communication protocol requires waved to be restarted.
communication port
• Mandatory field.
60
• If empty, the field defaults to 2998.
• This port is used for communication using UDP. This allows other parts of the Waves4
suite to find this waved instance on the network by means of an UDP broadcast mes-
sage.
The port is also used for communication using TCP. This is used to communicate with
Waves4 using the communication interface.
• Introduced in version 1 of the configuration format.
• Changing this field using the communication protocol requires waved to be restarted.
storage root
• Mandatory string.
• Introduced in version 1 of the configuration format.
• Behaviour of an empty field changed in version 4 of the configuration format.
• Changing this field using the communication protocol requires waved to be restarted.
This directory is the base directory to store the received data and log files. If the field is
empty a default location is used. The default depends on the operating system:
password
• Optional string.
• Introduced in version 4 of the configuration format.
This field contains the password required for configuring the settings of waved. If the field
is omitted the value is an empty string.
Note It is recommended to use the same password for all buoyd and waved instances on the
network. This makes using Waves4 configurator easier.
log
• Optional section.
• Introduced in version 4 of the configuration format.
This section configures the logger setting of waved. If the section is omitted the default
logger settings are used. The details of this section are the same as the log section of buoyd
and are described in §4.3.1.
buoyd One section. This section contains the child nodes as described in §4.4.1.
61
Listing 4.14: Example of a wavedrc file.
<wavedrc>
<v e r s i o n >2</ v e r s i o n >
<i d >L o c a t i o n a l p h a </ i d >
<p o r t />
<!−− A s t o r e r o o t on a L i n u x s y s t e m . −−>
< s t o r a g e r o o t >/ v a r / l o g / waved </ s t o r a g e r o o t >
<!−−
! ! A s t o r e r o o t on a Windows s y s t e m ,
! ! commented o u t s i n c e o n l y one may be g i v e n .
−−>
<!−− < s t o r a g e r o o t >D: \ d a t a \ waved </ s t o r a g e r o o t > −−>
<buoyd>
<c o m m u n i c a t i o n p o r t />
<s c a n t i m e o u t />
</ buoyd>
<campaign>
<i d >L o c a t i o n a l p h a f i l e </ i d >
< t r a n s m i s s i o n p o r t >4000</ t r a n s m i s s i o n p o r t >
</ campaign>
<campaign>
<i d >L o c a t i o n a l p h a RX−C E t h e r n e t </ i d >
< t r a n s m i s s i o n p o r t >4004</ t r a n s m i s s i o n p o r t >
<csv>
<e n a b l e d >t r u e </ e n a b l e d >
</ csv>
</ campaign>
</ wavedrc>
id
62
The id of campaign to receive. This id is configured in a buoydrc’s campaign as defined in
§4.3.2.
transmission port
The port number the receiver starts a TCP network listener. When a program connects to
this network port it will receive all the data being received from the receiver. This is used
by waved to receive the data of a receiver.
Note the notes for the communication port apply here as well.
enabled
Older versions of waved stored the received data and log files without a campaign name and
without a file extension. This option allows to store the files with filenames including the
campaign name and a file extension.
Note this does not affect the CSV filenames, they are always stored with an extension.
(Backwards compatibility is the reason to make this field optional.)
The behaviour of the field has been changed in version 4 of the configuration format. Before
version 4.16.0 of the Waves4 suite waved started a new connection with buoyd for every
campaign. Certain receiver types can host multiple campaigns. Waved has been improved to
only make one connection for these campaigns. This means one receiver can have multiple
values for this field. These receivers now always assume the flag has been set to ‘true’. The
affected receivers are:
• Argos
• iBuoy
• SBD
Starting with version 5 of the configuration format the filenames have been modified. This
format is now always used.
csv
• Optional section.
• Introduced in version 2 of the configuration format.
This section configures the CSV output of waved. If the section is omitted the CSV output
is disabled. The details of this section are described in §4.4.2.1.
63
4.4.2.1 CSV
The csv section has the following fields:
enabled
• Mandatory field.
• Must contain a boolean value.
• Introduced in version 2 of the configuration format.
This field determines whether or not there will be CSV output. The format of the CSV
output is described in §5.2.1.
The programs W@ves21 and rfBuoy log their data in directories where the month directories
have the name of the month. In order to keep compatibility with that directory structure it is
possible to use that for the CSV format.
If this option is set to ‘true’ the name of the month in the directory will be set to the name
of the month. If set to ‘false’ the directory name will be the number of the month.
4.5 Waves4rc
The configuration of Waves4 is stored in a custom XML format. This configuration file needs to
be modified in order to add new buoys to the network. The table below describes the fields in the
XML file.
The structure is a XML tree, whose root node is named waves4rc. All nodes are mandatory,
but nodes can have a default or a fixed value. These nodes can simply be defined as <node/> and
its default of fixed value is used.
The nodes in the structure are:
waved One section. This section contains the child nodes as described in §4.5.1.
<waved>
<c o m m u n i c a t i o n p o r t />
64
<s c a n t i m e o u t />
</waved>
</ w a v e s 4 r c >
hostname Optional
Starting with version 4.16.0 the field is no longer used.
direction
• Mandatory field.
• Must contain one of the following values:
rad For using radians as direction unit.
° For using degrees as direction unit.
• Introduced in version 7 of the configuration format.
duration
• Mandatory field.
• Must contain one of the following values:
s For using seconds as duration unit.
h For using hours as duration unit.
day For using days as duration unit.
week For using weeks as duration unit.
• Introduced in version 7 of the configuration format.
energy
• Mandatory field.
• Must contain one of the following values:
J For using joules as energy unit.
65
Wh For using watt-hours as energy unit.
• Introduced in version 7 of the configuration format.
gps position 9
• Mandatory field.
• Must contain one of the following values:
rad For using radians as gps position unit.
° For using degrees as gps position unit.
• Introduced in version 7 of the configuration format.
height 10
• Mandatory field.
• Must contain one of the following values:
m For using metres as height unit.
ft For using feet as height unit.
• Introduced in version 7 of the configuration format.
speed
• Mandatory field.
• Must contain one of the following values:
m/s For using metres per second as speed unit.
knot For using knots as speed unit.
• Introduced in version 7 of the configuration format.
temperature
• Mandatory field.
• Must contain one of the following values:
K For using kelvins as temperature unit.
°C For using degrees Celsius as temperature unit.
°F For using degrees Fahrenheit as temperature unit.
• Introduced in version 7 of the configuration format.
9
Note: this unit is not yet used.
10
Note: this unit is not yet used.
66
5 Logging
5.1 Buoyd
5.1.1 Program log files
When buoyd runs as a background process it logs status messages in log files. Note this feature
has been introduced in version 4.10.0 and some older parts of the program may not use the new
logging facility yet.
The files are stored in a directory named:
/storage root/log/%Y/%M
where:
storage root The location where buoyd stores its data. This location is configured in buoyd’s
configuration file, see §4.3.
%Y The year the log entry is created. The value always has the full year, e.g. 2014. The time is
the local time.
%M The month the log entry is created. The value always has two digits, e.g. 03 for March. The
time is the local time.
In this directory there will be a log file for every day of the month. The name of the file is:
%Y-%M-%D.log
where:
%Y The year the log entry is created. The value always has the full year, e.g. 2014. The time is
the local time.
%M The month the log entry is created. The value always has two digits, e.g. 03 for March. The
time is the local time.
%D The day the log entry is created. The value always has two digits. The time is the local time.
%Y The year the log entry is created. The value always has the full year, e.g. 2014. The time is
the local time.
%M The month the log entry is created. The value always has two digits, e.g. 03 for March. The
time is the local time.
%D The day the log entry is created. The value always has two digits. The time is the local time.
%h The hour of the day the log entry is created. The value always has two digits. The time is the
local time.
%m The minute of the hour the log entry is created. The value always has two digits. The time
is the local time.
%s The second of the minute the log entry is created. The value always has two digits. The time
is the local time.
67
%f The fraction of the second the log entry is created. The value always has six digits. The time
is the local time.
In most cases the fraction of the seconds are not interesting, but for trouble shooting the can,
at times, be very valuable.
FATAL A fatal error has occurred, this often causes the program to be terminated or a
subsystem to be disabled.
ERROR An error has occurred, the program can still continue, but if an error persists it
might be wise to contact Datawell.
WARN A warning has been issued, a minor failure occurred.
INFO The program gave a status message intended to get more information about the status
of the program.
DEBUG The program gave extra information to aid finding the cause of a problem in the
program.
%T The ID of the thread of the program which generated the log entry is created. This informa-
tion can normally be ignored and is mainly interesting for Datawell engineers.
5.1.2 SBD
The SBD based receivers log the received e-mail messages. The e-mail messages are stored in a
directory named:
/storage root/%R/%Y/%M
where:
storage root The location where buoyd stores its data. This location is configured in buoyd’s
configuration file, see §4.3.
%R The id of the receiver receiving the e-mail message. This field is the receiver id as configured
in §4.3.2.
%Y The year the data is received. The value always has the full year, e.g. 2014. The time is in
UTC. Note when replaying old data from a file the time may not match with the time of the
data in the file.
%M The month the data is received. The value always has two digits, e.g. 04 for April. The time
is in UTC. Note when replaying old data from a file the time may not match with the time
of the data in the file.
In this directory there will be a file for every e-mail message. The name of the file is:
%R}%Y-%M-%DT%hh%mm%sZ%E where:
%R The id of the receiver receiving the e-mail message. This field is the receiver id as configured
in §4.3.2.
%Y The year the e-mail message was ‘received’. The value always has the full year, e.g. 2014.
The time is the local time.
%M The month the e-mail message was ‘received’. The value always has two digits, e.g. 03 for
March. The time is in UTC.
%D The day the e-mail message was ‘received’. The value always has two digits. The time is in
UTC.
68
%h The hour of the day the e-mail message was ‘received’. The value always has two digits. The
time is in UTC.
%m The minute of the hour the e-mail message was ‘received’. The value always has two digits.
The time is in UTC.
%s The second of the minute the e-mail message was ‘received’. The value always has two digits.
The time is in UTC.
Since a timestamp with a one second resolution only allows for one e-mail per second the
‘received’ timestamp has a little twist. When the timestamp of the e-mail matches an existing
e-mail, the timestamp is increased by one second, until a unique name is found.
5.1.3 Argos
The Argos based receivers log the received e-mail messages. The e-mail messages are stored in a
directory named:
/storage root/%R/%Y/%M
where:
storage root The location where buoyd stores its data. This location is configured in buoyd’s
configuration file, see §4.3.
%R The id of the receiver receiving the e-mail message. This field is the receiver id as configured
in §4.3.2.
%Y The year the data is received. The value always has the full year, e.g. 2014. The time is in
UTC. Note when replaying old data from a file the time may not match with the time of the
data in the file.
%M The month the data is received. The value always has two digits, e.g. 04 for April. The time
is in UTC. Note when replaying old data from a file the time may not match with the time
of the data in the file.
In this directory there will be a file for every e-mail message. The name of the file is:
%R}%Y-%M-%DT%hh%mm%sZ%E where:
%R The id of the receiver receiving the e-mail message. This field is the receiver id as configured
in §4.3.2.
%Y The year the e-mail message was ‘received’. The value always has the full year, e.g. 2014.
The time is the local time.
%M The month the e-mail message was ‘received’. The value always has two digits, e.g. 03 for
March. The time is in UTC.
%D The day the e-mail message was ‘received’. The value always has two digits. The time is in
UTC.
%h The hour of the day the e-mail message was ‘received’. The value always has two digits. The
time is in UTC.
%m The minute of the hour the e-mail message was ‘received’. The value always has two digits.
The time is in UTC.
69
%s The second of the minute the e-mail message was ‘received’. The value always has two digits.
The time is in UTC.
Since a timestamp with a one second resolution only allows for one e-mail per second the
‘received’ timestamp has a little twist. When the timestamp of the e-mail matches an existing
e-mail, the timestamp is increased by one second, until a unique name is found.
5.1.4 iBuoy
iBuoy logs its data in two different file formats:
IBS iBuoy uses this file format to log the entire communication between buoyd and the buoy.
This logger logs its data per session and may or may not belong to a campaign buoyd is
configured for. When the connection is started buoyd does not know which campaign the
data belongs to so the data is logged in the receiver directory. The data logged with this
logger also contains the data stored by the DWTP logger.
DWTP iBuoy uses this file format to log the DWTP data transmitted from the buoy to buoyd. The
logger logs its data per session, but only of campaigns buoyd is configured for.
With the Waves4 configurator it is also possible to retreive files from the buoy’s logger card,
these files will also be processed by buoyd’s logging module.
5.1.4.1 IBS
The iBuoy based receivers log the communication between the buoy and buoyd. The logs are
stored in a directory named:
/storage root/%R/%Y/%M
where:
storage root The location where buoyd stores its data. This location is configured in buoyd’s
configuration file, see §4.3.
%R The id of the receiver receiving the data. This field is the receiver id as configured in §4.3.2.
%Y The year the data is received. The value always has the full year, e.g. 2014. The time is in
UTC. Note when replaying old data from a file the time may not match with the time of the
data in the file.
%M The month the data is received. The value always has two digits, e.g. 04 for April. The time
is in UTC. Note when replaying old data from a file the time may not match with the time
of the data in the file.
In this directory there will be a file for every session. The name of the file is:
%R-%S}%Y-%M-%DT%hh%mm%sZ%E where:
%R The id of the receiver receiving the data. This field is the receiver id as configured in §4.3.2.
%S The id of the receiver’s session. When a buoy connects to buoyd the session gets an ID.
This ID is used to log the data from different buoys. This is required since several buoy can
connect at the same moment. At the moment the buoy connects to buoyd, buoyd does not
know what the ID of the buoy is so it cannot use that ID for the log file.
%Y The year the connection was made. The value always has the full year, e.g. 2014. The time
is the local time.
70
%M The month the connection was made. The value always has two digits, e.g. 03 for March.
The time is in UTC.
%D The day the connection was made. The value always has two digits. The time is in UTC.
%h The hour of the day the connection was made. The value always has two digits. The time is
in UTC.
%m The minute of the hour the connection was made. The value always has two digits. The time
is in UTC.
%s The second of the minute the connection was made. The value always has two digits. The
time is in UTC.
5.1.4.2 DWTP
Contains the DWTP data logged by buoyd for an glsiBuoy receiver. The logs are stored in a
directory named:
/storage root/%C/%Y/%M
where:
storage root The location where buoyd stores its data. This location is configured in buoyd’s
configuration file, see §4.3.
%C The id of the campaign receiving the data. This field is the campaign id as configured in
§4.3.5.1.
%Y The year the data is received. The value always has the full year, e.g. 2014. The time is in
UTC. Note when replaying old data from a file the time may not match with the time of the
data in the file.
%M The month the data is received. The value always has two digits, e.g. 04 for April. The time
is in UTC. Note when replaying old data from a file the time may not match with the time
of the data in the file.
In this directory there will be a file for every session. The name of the file is:
%C}%Y-%M-%DT%hh%mm%sZ%E where:
71
%C The id of the campaign receiving the data. This field is the campaign id as configured in
§4.3.5.1.
%Y The year the connection was made. The value always has the full year, e.g. 2014. The time
is the local time.
%M The month the connection was made. The value always has two digits, e.g. 03 for March.
The time is in UTC.
%D The day the connection was made. The value always has two digits. The time is in UTC.
%h The hour of the day the connection was made. The value always has two digits. The time is
in UTC.
%m The minute of the hour the connection was made. The value always has two digits. The time
is in UTC.
%s The second of the minute the connection was made. The value always has two digits. The
time is in UTC.
%C The id of the campaign receiving the data. This field is the campaign id as configured in
§4.3.5.1.
The name of the file, is the name of the file on the logger. The data retreived from the logger,
contains a part of a file. The received data will be stored at the same offset as the original data. If
this results in undefined data in the file, this data will be set to the NUL-character. When the data
received was allready received before the data will be overwritten. During normal operations the
buoy only appends data to files, so they will be overwritten by the same data.
For example when the buoy’s SYSLOG.TXT contains:
01-01-1970 00:00:10 SYS: buoy started
Requested are 8 bytes starting at offset 11. The file retreived will look like:
···········00:00:10
Where · represents the NUL-character. When retreiveing 10 bytes starting at offset 0 the file will
look like:
01-01-1970·00:00:10
When retreiving 29 bytes starting at offset 0 the file will look like:
01-01-1970 00:00:10 SYS: buoy
This allows to retreive a data in multiple small parts and add more data when available. For
example, it is possible to get the entire SYSLOG.TXT at some point. Then only ask for the new
data after a while.
72
5.2 Waved
5.2.1 CSV
When the CSV output for waved is enabled (see §4.4.2.1) the program will create CSV files. The
CSV files are stored in a directory named:
/storage root/campaign/year/month
where:
storage root The location where waved stores its data. This location is configured in waved’s
configuration file, see §4.4.
campaign The name of the campaign, whose data is stored. This value is campaign name as
configured in §4.4.2.
year The year the data is received. The value always has the full year, e.g. 2013. The time is in
UTC. Note when replaying old data from a file the time may not match with the time of the
data in the file.
month The month the data is received. The value always has two digits, e.g. 05 for May. The
time is in UTC. Note when replaying old data from a file the time may not match with the
time of the data in the file.
Only for the month in the directory it can be stored as the name of the month by setting the
‘output directory month as string’ as described in §4.4.2.1.
The data is buffered and will be written every 15 minutes, starting at the full hour mark. After
writing, the files will be closed and can be used by other processes. When a file fails to open, the
data will be buffered until it is possible to write. The retry will happen at the next write interval,
15 minutes later.
The data in the CSV files, is the data transmitted by the buoy. The values of the fields and their
units are the same as in the DWTP-specifications [Dat13a].
• When a field contains a NaN value it is written as ‘NaN’ in the output.
5.2.1.1 Displacements
The displacements are stored in a file named:
campaign{id}year-month-day.csv
where:
campaign Is the same as campaign described in §5.2.1.
day The day the data is received. The value always has two digits, e.g. 01. The time is in UTC.
Note when replaying old data from a file the time may not match with the time of the data
in the file.
For example the file named ‘demo{displ}2013-05-01.csv’ contains the displacements of the
first of May 2013 for the campaign ‘demo’.
A new file is created every day. The file contains five columns:
73
1. • This field contains a timestamp. The format is based in the format used for the mes-
sages [Dat13a, §3.2, HF link header]. But it can also contain a fraction of a second, if
that value is not equal to 0.
• The timestamp is the UTC timestamp, when the first vector was received by waved, not
the time the vector was transmitted by the buoy. The time of all other displacements
are based on this value and the sampling frequency in the buoy. Note when replaying
old data from a file the time of the vectors will not be the time the data was initially
was received.
Note when replaying old data at an increased transmission rate, for example by in-
creasing the transmission speed factor in buoyd (see §4.3.4), the timestamp might not
be continuous.
2. This field contains the status of the vector and can be:
3. This field contains the heave displacement, see [Dat13a, §2.1.1 Decoding the real time data
to displacements] for more information.
4. This field contains the northern displacement, see [Dat13a, §2.1.1 Decoding the real time
data to displacements] for more information.
5. This field contains the western displacement, see [Dat13a, §2.1.1 Decoding the real time
data to displacements] for more information.
5.2.1.2 Messages
The displacements are stored in a file named:
campaign{id}year-month.csv
where:
id The type of CSV file. The value is the MsgID of the field [Dat13a, Chapter 4, Defined mes-
sages].
For example the file named ‘demo{0xF80}2013-05.csv’ contains the GPS location messages
of May 2013 for the campaign ‘demo’.
A new file is created every month.
In general the fields in the columns are a one on one representation of the messages in the
specifications except:
• The MsgID is not in the data; it can be determined from the filename.
• The CRC-4 checksum is not in the data; when it does not match, there is an error in the
message and the message is not decoded.
74
Next to these generic exceptions some messages have their own exceptions:
Primary directional spectrum message (0xF21) Instead of alternating the ‘Direction from’, and
‘Spread’ columns, these columns are stored after each other. First the 100 columns for the
‘Direction from’, then the 100 columns for the ‘Spread’.
Secondary directional spectrum message (0xF22 and 0xF28) Instead of alternating the ‘m2 ’,
‘n2 ’, and ‘K’ columns, these columns are stored after each other. First the 100 columns for
the ‘m2 ’, then the 100 columns for the ‘n2 ’ and finally the 100 columns for the ‘K’.
75
6 Running
This chapter describes how to run the various programs. But before doing so first it will be ex-
plained how to stop and start a background program.
6.2 Buoyd
This program is normally run as a background process, run buoyd -h to see all options.
6.3 Waved
This program is normally run as a background process, run waved -h to see all options.
76
7 Troubleshooting
When you run into problems or have further questions, please contact our software department at
[email protected].
77
A Wire communication protocol
This chapter describes the communication protocol used in the Waves4 suite. Versions prior to
version 4.10.0 used an older telnet based protocol. This protocol is not documented and considered
obsolete1 . Version 4.10.0 introduced a new protocol, which is described in this chapter. Waved
started to use this protocol starting with version 4.16.0.
A.1 General
The communication protocol has a few layers:
Protocol The low level message protocol. This protocol describes how the data is transmitted
over the network.
Commands The command level defines the commands available in the communication protocol.
This is allows the interaction between the applications in the Waves4 suite.
File system The file system contains the settings of the application. The commands allow inter-
action with the file system, allowing to remotely modify the settings of an application or
receiver.
A.1.1 Protocol
The protocol is used over a TCP/IP connection and is based on messages. Every message has a
13 byte header followed by its data. The header contains the following fields:
• 4 bytes containing a magic header. The header contains the following 4 bytes: 0x44, 0x57,
0x07, 0xA9. This is used to identify whether the communication partner uses the same
protocol.
This magic header has been introduced in version 4.16.0 of the Waves4 suite. Older versions
of the Waves4 suite do not contain a magic header and their header is 9 instead of 13 bytes.
These versions of the protocol are not compatible.
• 4 bytes containing the size of the rest of the message. The value is a 32 bit unsigned value
stored in network order.
The way to retrieve messages over the network is to receive 4 bytes, decode this to a value
x and then retrieve the next x bytes.
• 1 byte containing the type of message. The possible values are:
A The message contains an action. An action is a request to the communication partner to
do a certain action and return its result. The result can be a simple status value, but can
also return additional information.
R The message contains a reply. A reply is the answer to an action. Thus replies are only
send to reply to an action.
M The message contains a notification. A notification is much like an action, except there
is no reply. This is mainly used to send received data to listeners and status updates.
• 4 bytes containing the id of the message. The value is a 32 bit unsigned value stored in
network order.
The id depends on the type of message:
1
Even though parts of the Waves4 suite still use this protocol.
78
Action The id contains a value specified by the sender. This id should be unique so its
associated reply can be identified.
The easiest way is to use a sequence that increases with every call.
The id 0 is best avoided.
Reply The id contains the value of the action it replies to.
Notification The id is not used and should be 0.
The rest of the message contains the contents of the message. The contents can be binary or
text based.
A.1.2 Commands
The command interface is a text based protocol, where the connecting party sends actions to the
server and the server replies them. The server can also send notifications. The commands work on
a virtual file system allowing the user to query or modify settings.
Every server implements a basic set of commands and offers a basic set of files. The specific
implementations of these servers can extend the number of commands and files.
When interacting with the server there are two operation modi:
operator After issuing the Operator command the session will switch to operator mode.
In this mode there are different file system permissions and also certain commands are only
available in operator mode.
There is a third user, the system user. This user is used by the programs internally and not available
via the command interface.
For the file system interaction there are a few terms defined:
File name A file name is a string, which when looked up in the file system results in a file.
Directory name A file name is a string, which when looked up in the file system results in a
directory.
Path name A path name is a string, which is either a file name or a directory name
File A file is an item in the file system, representing a file. A file can be used to store or retrieve
data.
Node A directory is an item in the file system, representing either a file or a directory.
A.1.2.1 Exit
Version Introduced in version 4.10.0 of the Waves4 suite.
Description Lets the server close the connection with the client. Unlike the other commands this
command will not reply its status.
79
A.1.2.2 Get
Version Introduced in version 4.10.0 of the Waves4 suite.
File name
• A mandatory argument containing a string.
• Contains the name of an existing file in the file system. The contents of this file
will be returned.
Errors
A.1.2.3 Guest
Version Introduced in version 4.10.0 of the Waves4 suite.
A.1.2.4 Keepalive
Version Introduced in version 4.16.0 of the Waves4 suite.
Time-out
• A mandatory argument containing an unsigned number.
• Contains the transmission time-out in seconds before a new keepalive message is
sent. The value 0 means no time-out.
Description When the server has a non-zero keepalive time-out the server makes sure the server
transmits data at a regular interval. When, after time-out seconds, no data is transmitted the
server sends a notification message containing the string ‘ping’. This makes it possible for
the client to detect whether the network connection is still ‘alive’.
Warning The timing of the time-out interval may not use a high-precision timer.
80
A.1.2.5 Ls
Version Introduced in version 4.10.0 of the Waves4 suite. Modified in version 4.16.0 of the
Waves4 suite; the mtime’s timezone was not specified and was local time, it is now specified
as UTC.
Path name
• An optional argument containing a string. If omitted the contents of the root
directory are shown.
• Contains the name of an existing path in the file system.
The information contains a tab separated list of fields for every item:
Type Contains the type of the node. The possible types are:
f The node is a file.
d The node is a directory.
Other types could be added in a future version of the Waves4 suite.
Permission Contains the permission mask of the node. A permission mask consists of 6
characters:
1. Contains a ‘r’ if the system user is allowed to read the node.
Contains a ‘-’ if the system user is not allowed to read the node.
2. Contains a ‘w’ if the system user is allowed to write the node.
Contains a ‘-’ if the system user is not allowed to write the node.
3. Contains a ‘r’ if the operator is allowed to read the node.
Contains a ‘-’ if the operator is not allowed to read the node.
4. Contains a ‘w’ if the operator is allowed to write the node.
Contains a ‘-’ if the operator is not allowed to write the node.
5. Contains a ‘r’ if the guest is allowed to read the node.
Contains a ‘-’ if the guest is not allowed to read the node.
6. Contains a ‘w’ if the guest is allowed to write the node.
Contains a ‘-’ if the guest is not allowed to write the node.
Owner Contains the name of the user owning the file.
Size Contains the size of the node. The value depends on the type:
File Contains the size in bytes.
Directory Contains the number of elements in the directory.
Mtime Contains an UTC timestamp containing the last modification time of a node. The
value is the number of seconds since midnight of January first 1970.
ID Contains the ID – the name – of the node.
81
Errors
A.1.2.6 Operator
Version Introduced in version 4.10.0 of the Waves4 suite.
Password
• An optional argument containing a string. If omitted an empty password is used.
• Contains password required to switch to operator mode.
Description Changes the current user from guest to operator. The name of the operator depends
on the communication server. The main communication ports operator is a different operator
as a receiver’s operator.
Errors
A.1.2.7 Set
Version Introduced in version 4.10.0 of the Waves4 suite.
File name
• A mandatory argument containing a string.
• Contains the name of an existing file in the file system. The contents of this file
will be modified.
It is not possible to create new files with the set command.
Contents
• An optional argument containing a string.
• Contains the new contents of the file. The contents need to be compatible with
the type of the file.
In some cases an empty string is valid content, therefore the argument is optional.
Errors
82
A.1.2.8 Time
Version Introduced in version 4.10.0 of the Waves4 suite.
Description Returns the time on the server. This command is available for debugging purposes.
Returns The UTC time of the server in two tab separated fields:
1. The number of seconds since midnight of January first 1970. This value is the same as
the UNIX timestamp.
2. A string in the ISO time format. This format is human readable.
A.1.2.9 Tree
Version Introduced in version 4.16.0 of the Waves4 suite.
Path name
• An optional argument containing a string. If omitted the contents of the root
directory are shown.
• Contains the name of an existing path in the file system.
Description Recursively retrieves information regarding a node. The result of the function looks
a lot like the output of the Ls command. The main differences are:
The information contains a tab separated list of fields for every item:
Type Contains the type of the node. The possible types are:
f The node is a file.
d The node is a directory.
Other types could be added in a future version of the Waves4 suite.
Permission Contains the permission mask of the node. A permission mask consists of 6
characters:
1. Contains a ‘r’ if the system user is allowed to read the node.
Contains a ‘-’ if the system user is not allowed to read the node.
2. Contains a ‘w’ if the system user is allowed to write the node.
Contains a ‘-’ if the system user is not allowed to write the node.
83
3. Contains a ‘r’ if the operator is allowed to read the node.
Contains a ‘-’ if the operator is not allowed to read the node.
4. Contains a ‘w’ if the operator is allowed to write the node.
Contains a ‘-’ if the operator is not allowed to write the node.
5. Contains a ‘r’ if the guest is allowed to read the node.
Contains a ‘-’ if the guest is not allowed to read the node.
6. Contains a ‘w’ if the guest is allowed to write the node.
Contains a ‘-’ if the guest is not allowed to write the node.
Owner Contains the name of the user owning the file.
Size Contains the size of the node. The value depends on the type:
File Contains the size in bytes.
Directory Contains the number of elements in the directory.
Mtime Contains an UTC timestamp containing the last modification time of a node. The
value is the number of microseconds since midnight of January first 1970.
ID Contains the ID – the path and name – of the node.
Errors
• The path does not exist.
• The current user is not allowed to get the information of the path. Note when the
current user is not allowed to get information of child node this node’s children are
omitted and does not result in an error.
A.1.2.10 Whoami
Version Introduced in version 4.10.0 of the Waves4 suite.
Availability Available in operator and guest mode.
Arguments This function takes no arguments.
Description Returns the name of the current user.
Returns Returns the name of the current user. The name is ‘guest’ or the name associated with
the operator of this interface.
84
A.1.3.1.2 The file ‘system/version/minor’
Version Introduced in version 4.10.0 of the Waves4 suite.
Type Number
Description Holds the minor number of the application’s version. For version 4.10.0 it holds the
value 10.
Type Number
Description Holds the patch number of the application’s version. For version 4.10.0 it holds the
value 0.
Type String
Description Holds the version string of the application’s version. For version 4.10.0 it holds the
value 4.10.0.0.
Type Number
85
A.1.3.2.2 The file ‘system/protocol/generation version
Version Introduced in version 4.10.0 of the Waves4 suite.
Type String
Description Contains a version string specifying in which version of the Waves4 suite this gen-
eration number is introduced.
Type Number
Type String
Description Contains a version string specifying in which version of the Waves4 suite this level
number is introduced.
A.2 Buoyd
Buoyd has several communication interfaces, expanding the options of the general communication
interface. The extensions to the file system are available for the entire program. This is based on
the values in the configuration file. (See §4.3 for more information regarding the configuration.)
A.2.1 Program
The main program adds the commands are described in the following sections.
A.2.1.1 Application
The command to manipulate the application’s operation status.
Availability
Operation
• A mandatory argument containing a string containing:
86
restart Restarts the application. Changes to certain configuration fields require
the application to restart. This function allows to restart the application. (This
makes it possible to use the Waves4 configurator to restart the application
instead of using the system’s method to restart a background process.)
stop Stops the application.
Description Saves the configuration. This allows to store the configuration after it has been al-
tered.
Operation
• A mandatory argument containing a string containing:
create Creates a new log domain as described in §A.2.1.3.1.
remove Removes an existing log domain as described in §A.2.1.3.2.
A.2.1.3.1 Create
The subcommand to create log domains in buoyd.
Availability
Domain
• The field matches the ‘domain’ field as described in §4.3.1.1.
Severity
• The field matches the ‘severity’ field as described in §4.3.1.1.
Description The subcommand creates a log domain in buoyd. The change is applied directly, but
it does not take the order of setting log domains in account. This means the effective order
of the log domains may differ from the order after restarting the application.
87
A.2.1.3.2 Remove
The subcommand to remove log domains in buoyd.
Availability
ID
• The name of the directory in ‘/configuration/log/domains’ to remove. The name
must be an exiting directory name in this directory.
Description The subcommand removes a log domain in buoyd. This does not change the current
log level of the domain. The change takes effect after restarting the application.
A.2.1.4 Receiver
Version Introduced in version 4.18.0 of the Waves4 suite.
Operation
• A mandatory argument containing a string containing:
create Requests buoyd to create a new receiver as described in §A.2.1.4.1.
support matrix Requests buoyd for its support matrix as described in §A.2.1.4.2.
Description Allows the user to interact with the receiver settings of buoyd.
A.2.1.4.1 Create
Version Introduced in version 4.18.0 of the Waves4 suite.
The command to create receivers.
Availability
ID
• A mandatory argument containing a string.
• Contains a unique name for the new receiver to create.
Port The transmission port as described in §4.3.2.
Buoy type
• A mandatory argument containing a string.
• Contains the type of buoy being received.
• This field together with ‘Receiver type’ and ‘File format’ must be a supported
combination. See the ‘Remarks’.
Receiver type
88
• A mandatory argument containing a string.
• Contains the type of receiver being used.
• This field together with ‘Buoy type’ and ‘File format’ must be a supported com-
bination. See the ‘Remarks’.
File format
• A mandatory argument containing a string.
• Contains the file format of the data being received.
• This field together with ‘Buoy type’ and ‘Receiver type’ must be a supported
combination. See the ‘Remarks’.
Remarks The combination of ‘Buoy type’, ‘Receiver type’, and ‘File format’ must be a sup-
ported combination. The combination supported by buoyd can be obtained by running
‘buoyd --support-matrix’ from the console. Future versions of buoyd may add new
combinations to the list. (For backwards compatibility with older versions of buoyd there is
no intention to remove combinations from the list.)
Description Retrieves information regarding the supported ‘Buoy type’, ‘Receiver type’, and
‘File format’ in this version of buoyd.
Returns The list with supported ‘Buoy type’, ‘Receiver type’, and ‘File format’ combinations.
Every combination is on a separate line and every line contains three fields separated with
tabs:
When a buoy can be received with multiple receivers there are multiple lines starting with the
type of the buoy. (The output resembles the output of the command ‘buoyd --support-matrix’.)
A.2.2 Receiver
All receivers have commands available, some are common for all receivers. These are described
in appendix A.2.2.1. The sections after that section describe the command specific for a certain
receiver type.
A.2.2.1 Common
This section describes all commands available for all receivers.
89
A.2.2.1.1 Configuration store
Version Introduced in version 4.12.0 of the Waves4 suite. For the SBD receiver the command
was introduced in version 4.10.0 of the Waves4 suite.
Description Saves the configuration. This allows to store the configuration after it has been al-
tered.
A.2.2.1.2 Notifications
Version Introduced in version 4.10.0 of the Waves4 suite.
Status
• A mandatory argument containing a string containing ‘enable’ or ‘disable’.
• This indicates whether the notifications should be enabled or disabled.
Description Enables the notifications for the current connection. The notifications are unsolicited
messages send by the receiver. They contain status updates and received data. For configu-
ration the notifications are unwanted, for normal operation – receiving data – it is wanted.
This setting must be set per connection and is initially disabled. This allows the configurator
to connect and modify the settings. Waved needs to enable the notifications in order to
receive data.
A.2.2.1.3 Receiver
Version Introduced in version 4.12.0 of the Waves4 suite. For the SBD receiver the command
was introduced in version 4.10.0 of the Waves4 suite.
Operation
• A mandatory argument containing a string containing ‘start’ or ‘stop’.
• This is the operation the receiver should take, starting or stopping the receiver.
Description This command starts or stops receiving data for the receiver. When a receiver has
been stopped it is possible to modify the configuration. After starting the receiver the mod-
ified settings take effect.
Note: The modified settings are not stored permanently. In order to do so use the ‘configu-
ration store’ command appendix A.2.1.2.
A.2.2.2 iBuoy
The iBuoy receiver has its own set of commands. The commands can be issued after connecting
with the receiver.
The commands are described in the following sections.
90
A.2.2.2.1 Campaign
The command to manipulate the campaigns of the receiver.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new campaign as described in §A.2.2.2.1.1.
Description The command is used to manipulate campaigns for the iBuoy receiver.
A.2.2.2.1.1 Create
The subcommand to create campaigns for the iBuoy receiver.
Availability
Id
• A mandatory argument containing a string.
• Contains a unique name for the new campaign to create.
Buoy type
• A mandatory argument containing ‘DWR4’2 .
• Contains the name of the type of buoy being received. In the current version only
the DWR4 is supported, future releases of the Waves4 suite will support more
buoy types.
Buoy ID
• A mandatory argument containing a string.
• Contains the buoy ID given to the buoy. This ID must be unique.
Description The subcommand creates a new campaign with the default settings.
2
Future versions of the iBuoy receiver will support multiple buoy types, so this field is added for compatibility with
future versions of the software.
91
A.2.2.2.2 Task
The command to manipulate the tasks of the campaigns of the receiver. Tasks are created and
removed by the user. Buoyd will attempt to execute the task given and store its results. Once the
user has seen the result, he or she can then remove the task.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new task as described in §A.2.2.2.2.1.
remove Removes an existing task as described in §A.2.2.2.2.2.
Description The command is used to manipulate tasks of the campaigns for the iBuoy receiver.
A.2.2.2.2.1 Create
The subcommand to create tasks for the campaigns of the iBuoy receiver.
Availability
Campaign ID
• A mandatory argument containing a string.
• Contains the ID of the campaign for which the task is created.
Action
• A mandatory string argument containing data to send to the buoy. The format of
the data is defined in [Dat16a].
A.2.2.2.2.2 Remove
The subcommand to remove tasks for the campaigns of the iBuoy receiver.
Availability
Campaign ID
• A mandatory argument containing a string.
• Contains the ID of the campaign whose task will be removed.
92
Task ID
• A mandatory argument containing a string.
• Contains the ID of the task to remove.
Error codes
EBUSY While the task is being executed, it is not possible to remove the task.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new campaign as described in §A.2.2.3.1.1.
Description The command is used to manipulate campaigns for the iBuoy receiver.
A.2.2.3.1.1 Create
The subcommand to create campaigns for the MkIII iBuoy receiver.
Availability
Id
• A mandatory argument containing a string.
• Contains a unique name for the new campaign to create.
Buoy type
• A mandatory argument containing the type of buoy being received. The following
types are allowed:
– DWR MkIII
93
– DWR-G
– WR-SG
Buoy ID
• A mandatory argument containing a string.
• Contains the buoy ID given to the buoy. This ID must be unique.
Description The subcommand creates a new campaign with the default settings.
A.2.2.3.2 Task
The command to manipulate the tasks of the campaigns of the receiver. Tasks are created and
removed by the user. Buoyd will attempt to execute the task given and store its results. Once the
user has seen the result, he or she can then remove the task.
A.2.2.3.2.1 Create
The subcommand to create tasks for the campaigns of the MkIII iBuoy receiver.
94
A.2.2.3.2.2 Remove
The subcommand to remove tasks for the campaigns of the MkIII iBuoy receiver.
Availability
Campaign ID
• A mandatory argument containing a string.
• Contains the ID of the campaign whose task will be removed.
Task ID
• A mandatory argument containing a string.
• Contains the ID of the task to remove.
Error codes
EBUSY While the task is being executed, it is not possible to remove the task.
A.2.2.4 SBD
The SBD receiver has its own set of commands. The commands can be issued after connecting
with the receiver.
The commands are described in the following sections.
A.2.2.4.1 Campaign
The command to manipulate the campaigns of the receiver.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new campaign as described in §A.2.2.4.1.1.
email Sends an e-mail to the buoy associated with the campaign. The function is
descibed in more detail in §A.2.2.4.1.2.
Description The command is used to manipulate campaigns for the SBD receiver.
95
A.2.2.4.1.1 Create
The subcommand to create campaigns for the SBD receiver.
Availability
Id
• A mandatory argument containing a string.
• Contains a unique name for the new campaign to create.
Buoy type
• A mandatory argument containing ‘DWR4’3 .
• Contains the name of the type of buoy being received. In the current version only
the DWR4 is supported, future releases of the Waves4 suite will support more
buoy types.
IMEI
• A mandatory argument containing a string.
• Contains the IMEI number of the buoy’s modem. This number must be unique.
Description The subcommand creates a new campaign with the default settings for the messages.
A.2.2.4.1.2 E-mail
The subcommand to send e-mails to a buoy using the SBD communication option.
Availability
Id
• A mandatory argument containing a string.
• Contains the name of an existing campaign.
Attachment
• A mandatory argument containing data.
• The field is the last field and may contain the tab character.
• Contains the data to send as attachment to the buoy. The contents of the data are
not part of this protocol.
Description The subcommand sends an e-mail to a buoy that uses the SBD communication op-
tion. The e-mails are used to configure the buoy or retrieve information regarding its con-
figuration.
3
Future versions of the SBD receiver will support multiple buoy types, so this field is added for compatibility with
future versions of the software.
96
A.2.2.5 MkIII SBD
The MkIII SBD receiver has its own set of commands. The commands can be issued after con-
necting with the receiver.
The commands are described in the following sections.
A.2.2.5.1 Campaign
The command to manipulate the campaigns of the receiver.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new campaign as described in §A.2.2.5.1.1.
email Sends an e-mail to the buoy associated with the campaign. The function is
descibed in more detail in §A.2.2.5.1.2.
Description The command is used to manipulate campaigns for the MkIII SBD receiver.
A.2.2.5.1.1 Create
The subcommand to create campaigns for the MkIII SBD receiver.
Availability
Id
• A mandatory argument containing a string.
• Contains a unique name for the new campaign to create.
Buoy type
• A mandatory argument containing the type of buoy being received. The following
types are allowed:
– DWR MkIII
– DWR-G
– WR-SG
IMEI
• A mandatory argument containing a string.
• Contains the IMEI number of the buoy’s modem. This number must be unique.
Description The subcommand creates a new campaign with the default settings for the messages.
97
A.2.2.5.1.2 E-mail
The subcommand to send e-mails to a buoy using the MkIII SBD communication option.
Availability
Id
• A mandatory argument containing a string.
• Contains the name of an existing campaign.
Attachment
• A mandatory argument containing data.
• The field is the last field and may contain the tab character.
• Contains the data to send as attachment to the buoy. The contents of the data are
not part of this protocol.
Description The subcommand sends an e-mail to a buoy that uses the MkIII SBD communication
option. The e-mails are used to configure the buoy or retrieve information regarding its
configuration.
Availability
Operation
• A mandatory argument containing a string containing:
create Creates a new campaign as described in §A.2.2.6.1.1.
sms Sends a SMS message to the buoy associated with the campaign. The func-
tion is descibed in more detail in §A.2.2.6.1.2.
Description The command is used to manipulate campaigns for the MkIII SMS receiver.
98
A.2.2.6.1.1 Create
The subcommand to create campaigns for the MkIII SMS receiver.
A.2.2.6.1.2 SMS
The subcommand to send SMS messages to a buoy using the MkIII SMS communication option.
99
A.2.2.6.2 Configuration store
This command has been introduced in version 4.10.0 of the Waves4 suite, starting with version
4.12.0 this command became available for all receivers. It is decribed in §A.2.2.1.1.
A.2.2.7 Receiver
This command has been introduced in version 4.10.0 of the Waves4 suite, starting with version
4.12.0 this command became available for all receivers. It is decribed in §A.2.2.1.3.
A.3 Waved
Waved has several communication interfaces, expanding the options of the general communication
interface. The extensions to the file system are available for the entire program. This is based on
the values in the configuration file. (See §4.4 for more information regarding the configuration.)
A.3.1 Program
The main program adds the commands are described in the following sections.
A.3.1.1 Application
The command to manipulate the application’s operation status.
Availability
Operation
• A mandatory argument containing a string containing:
restart Restarts the application. Changes to certain configuration fields require
the application to restart. This function allows to restart the application. (This
makes it possible to use the Waves4 configurator to restart the application
instead of using the system’s method to restart a background process.)
stop Stops the application.
Availability
ID
• A mandatory argument containing a string.
100
• Contains a unique name for the new campaign to create.
Port The transmission port as described in §4.4.2.
Description Saves the configuration. This allows to store the configuration after it has been al-
tered.
Operation
• A mandatory argument containing a string containing:
create Creates a new log domain as described in §A.3.1.4.1.
remove Removes an existing log domain as described in §A.3.1.4.2.
A.3.1.4.1 Create
The subcommand to create log domains in waved.
Availability
Domain
• The field matches the ‘domain’ field as described in §4.3.1.1.
Severity
• The field matches the ‘severity’ field as described in §4.3.1.1.
Description The subcommand creates a log domain in waved. The change is applied directly, but
it does not take the order of setting log domains in account. This means the effective order
of the log domains may differ from the order after restarting the application.
101
A.3.1.4.2 Remove
The subcommand to remove log domains in waved.
Availability
ID
• The name of the directory in ‘/configuration/log/domains’ to remove. The name
must be an exiting directory name in this directory.
Description The subcommand removes a log domain in waved. This does not change the current
log level of the domain. The change takes effect after restarting the application.
A.3.2 Campaign
All campaign have commands available. Unlike buoyd’s receivers there is only one type of cam-
paign.
Description Saves the configuration. This allows to store the configuration after it has been al-
tered.
A.3.2.2 Cache
Version Introduced in version 4.16.0 of the Waves4 suite.
Operation
• A mandatory argument containing a string containing:
version Requests the cache’s format version number as described in §A.3.2.2.1
synchronise Requests the cache to synchronise its data with the file system as
described in §A.3.2.2.2
Description Allows the user to interact with the cached data of the campaign.
102
A.3.2.2.1 Version
The subcommand to request the version number of the cache format of a campaign in waved. Note
the format is the same for all campaigns.
A.3.2.2.2 Synchronise
The subcommand to request the cache of waved to synchronise its data with the file system. The
current implementation of the cache needs to close files and close the open XML groups. This
command makes sure that process happens and the latest files are linked to the internal FS tree.
Error codes
EBUSY When another process is already busy writing the cache. The error should be rare.
It is possible to attempt another synchronisation request. Preferably after a short delay.
Remarks The synchronising the of the cache is required for cache format 1. It has not been
determined whether or not it will be required for newer versions of the cache format.
A.3.2.3 Campaign
Version Introduced in version 4.16.0 of the Waves4 suite.
Operation
• A mandatory argument containing a string containing ‘start’ or ‘stop’.
• This is the operation the campaign should take, starting or stopping the campaign.
Description This command starts or stops receiving data for the campaign. When a campaign
has been stopped it is possible to modify its configuration. After starting the campaign the
modified settings take effect.
Note: The modified settings are not stored permanently. In order to do so use the ‘configu-
ration store’ command appendix A.3.2.1
103
A.3.2.4 Notifications
Version Introduced in version 4.16.0 of the Waves4 suite.
Status
• A mandatory argument containing a string containing ‘enable’ or ‘disable’.
• This indicates whether the notifications should be enabled or disabled.
Description Enables the notifications for the current connection. The notifications are unsolicited
messages send by the campaign. They contain status updates and received data. For config-
uration the notifications are unwanted, for normal operation – receiving data – it is wanted.
This setting must be set per connection and is initially disabled. This allows the configurator
to connect and modify the settings. The Waves4 program needs to enable the notifications
in order to receive data.
104
B Release notes
This chapter describes the caveats when upgrading to a newer version of the Waves4 suite. When
a version isn’t listed here it means no special care needs to be taken when upgrading to the newer
version.
• The configuration file of the Waves4 program prior to version 8 are no longer supported.
The configuration file of the Waves4 program has been changed. Old files are compatible
with the newer version. After manually upgrading to the newer file format the configuration
can no longer be used with older versions of the Waves4 program.
B.2 5.2.0
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
• The configuration file of the Waves4 program has been changed. Old files are compatible
with the newer version. After manually upgrading to the newer file format the configuration
can no longer be used with older versions of the Waves4 program.
B.3 5.0.0
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
The version of the buoyd configuration file is version 10. Starting with version 5.4.0 of the
Waves4 suite files prior to version 8 will no longer be supported.
The names of the files logged by buoyd have been changed to a different format. This also
makes the field use verbose filename field in buoydrc obsolete.
• The version of the waved configuration file is version 4. Starting with version 5.4.0 of the
Waves4 suite files prior to version 4 will no longer be supported.
The names of the files logged by waved have been changed to a different format. This also
makes the field use verbose filename field in wavedrc obsolete.
• The configuration file of the Waves4 program has been changed. Old files are compatible
with the newer version. After manually upgrading to the newer file format the configuration
can no longer be used with older versions of the Waves4 program.
The version of the Waves4 program configuration file is version 8. Starting with version
5.4.0 of the Waves4 suite files prior to version 8 will no longer be supported.
105
B.4 4.18.0
• The behaviour of an empty storage root field in buoydrc has changed. The new behaviour
has been described in §4.3.
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
• The configuration file of the Waves4 program has been changed. Old files are compatible
with the newer version. After manually upgrading to the newer file format the configuration
can no longer be used with older versions of the Waves4 program.
B.5 4.16.0
• The configuration file of waved has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of waved.
• The wire communication protocol (appendix A) has been changed. The new protocol is
not compatible with the previous version of the protocol. This means all application in the
Waves4 suite need to be upgraded to the same version in order to operate properly.
Since the Waves4 configurator can do the same as bat (and more), there will be no new
version of bat.
• The behaviour of an empty storage root field in wavedrc has changed. The new behaviour
has been described in §4.4.
• The default location of buoydrc and wavedrc has been changed on Windows. The new
location is described in chapter 4.
• The behaviour of the use verbose filename field in wavedrc has changed. The new be-
haviour has been described in §4.4.2.
• The field hostname in the waved section of waves4rc (§4.5.1) is no longer used.
• The section campaign of waves4rc (§4.5) is no longer used.
B.6 4.14.0
• The Power consumption widget in the Waves4 program’s delta energy signals now show the
real average instead of the delta between two measurements. This has been changed since
the delta only works properly when the time between two measurements is identical. If, for
example, there is a one hour gap in the data stream the delta would be higher than expected
even if the power consumption was the same over the entire period.
B.7 4.12.0
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
• Buoyd’s communication interface has been modified to support the Argos receiver. These
changes are not compatible with older versions of waved and the Waves4 configurator.
These programs need to be upgraded to the same version of buoyd in order to operate prop-
erly.
106
B.8 4.10.0
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
• Buoyd’s communication interface has been modified so its configuration can be modified by
the Waves4 configurator. These changes are not compatible with older versions of waved
and bat. These programs need to be upgraded to the same version of buoyd in order to
operate properly.
B.9 4.8.0
• The configuration file of the Waves4 program has been changed. Older files are automati-
cally upgraded to the new version. After upgrading the files can no longer be used in older
versions of the Waves4 program.
• The dialogue of the operational monitoring widget requires a monitor resolution of at least
1024 × 768.
B.10 4.6.0
• The configuration file of the Waves4 program has been changed. Older files are automati-
cally upgraded to the new version. After upgrading the files can no longer be used in older
versions of the Waves4 program.
• The format of waved’s cache has been modified. When upgrading the contents of the old
cache are ignored. This means when starting Waves4 program after the upgrade is will not
receive history from waved.
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
• The configuration file of waved has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of waved.
B.11 4.4.0
• It is now possible to generate CSV files in waved. In order to do so the configuration needs
to be updated.
B.12 4.2.0
• Starting with this version the usage of the Waves4 program is protected by a licence key.
Existing customers of the program should have received a licence key from our sales de-
partment, if not please contact our sales department. The programs waved and buoyd will
still function without a software licence, both now and in the future.
• The configuration file of the Waves4 program has been changed. Older files are automati-
cally upgraded to the new version. After upgrading the files can no longer be used in older
versions of the Waves4 program.
107
• The configuration file of buoyd has been changed. Old files are compatible with the newer
version. After manually upgrading to the newer file format the configuration can no longer
be used with older versions of buoyd.
B.13 4.0.0
All configuration files have been changed again and the old versions can no longer be used.
B.14 4.0.0-beta4
The fileformat of the configuration file of buoyd has been changed. The old configuration can’t be
used for the rxc class receivers.
B.15 4.0.0-beta2
The fileformat of the configuration file of buoyd has been changed. The old format can still be
used but some constructs have been deprecated.
The fileformat of the configuration file of waved has been changed. The old format can still
be used but some constructs have been deprecated.
108
C Changelog
This chapter lists all changes since the initial version of the Waves4 suite starting with the latest.
• The list widgets and the report widget are now able to export their contents to a CSV
file.
• It is now possible to open a file and convert to CSV.
• When opening a file a default set of widgets is shown, depending on the type of file
loaded.
• It is now possible to configure the displayed units for the trend widgets. They are
configured in the settings dialogue (the User Manual §3.1.1).
• The Spectrum (2D) widget has been improved: it now allows to configure the dis-
played signals.
• The Displacements widget has been improved: it now allows to configure the dis-
played signals.
109
Buoyd
- When the application runs in the foreground the log output is also written to the log
files instead of only to the console.
Waved
- When the application runs in the foreground the log output is also written to the log
files instead of only to the console.
Waves4 configurator
- This program can now configure all aspects of buoyd and waved. Thus it is no longer
required to directly edit the configuration files.
- The GPS position widget has been improved: it shows more positions and can be
zoomed. For the details look at the User Manual §2.2.4.
- Support for Debian Jessie i386 and Debian Jessie AMD64 has been added.
Buoyd
- Fixed a bug, where buoyd was not able to connect to Gmail on the Windows platform.
- Fixed a bug, where buoyd was not able to properly receive all SBD e-mail messages.
- Fixed an issues, where buoyd was not able properly connect to a SMTP server depend-
ing on the hostname of the system buoyd was running on.
Waved
- Fixed a bug, where waved was not able to receive multiple campaigns from an Argos
or SBD receiver.
- Fixed a bug, causing waved not to start on some systems.
110
C.7 Version 4.12.0
General
- Support for Ubuntu Precise Pangolin i386 and Ubuntu Precise Pangolin AMD64 has
been added.
- Support for Ubuntu Trusty Tahr i386 and Ubuntu Trusty Tahr AMD64 has been added.
- Support for Argos has been added.
Waved
- Fixed the displacement format for the CSV output of the MkIII buoys.
- Fixed a bug in the recalculation of the wave statistics. New samples were not correctly
added, causing old samples to be used.
- Fixed a bug in the recalculation of the spectral statistics. New spectra were not cor-
rectly added, causing old spectra to be used.
- Fixed a bug in the recalculation of the spectral statistics when invalid samples were
added. The tracking of invalid samples did not work correctly.
- Fixed the values of the filter delays for the wave statistics.
Buoyd
- The logging for the program itself in now done in log files in the storage directory
when buoyd runs as a background process.
Waved
- The CSV files generated for the MkIII buoys now use the ‘3’ prefix instead of the ‘F’
prefix.
- Added support to use the received displacements to recalculate the spectrum, spec-
tral parameters and the upcross statistics. (These values are used in the operational
monitoring widget in the Waves4 program.
- Implemented the operational monitoring widget. Usage of the widget requires a li-
cence for the operational module.
111
C.10 Version 4.6.0
General Support for Debian Wheezy i386 and Debian Wheezy AMD64 has been added.
Buoyd
Waved
- The HXV file format has been implemented for the RX-C.
- When the automatic network scan for buoyd fails waved tries to connect to buoyd on
the local host.
Waved
Documentation
112
- When the Waves4 program connects to buoyd and waved has a lot of cached data for
the selected campaign, the Waves4 program did not respond to user actions until all
cached data was processed. This has been fixed, the program remains responsive while
processing the cached data.
- A new power consumption widget has been added.
- Several widgets have extra settings, allowing to select the signals to be shown in the
widget.
Documentation
113
Bibliography
[Dat13a] Datawell. Datawell Waverider Transmission Protocol Specifications, 3.1.0 edition, 4
2013.
[Dat16b] Datawell. Datawell Waverider Reference Manual DWR-MkIII DWR-G WR-SG, septem-
ber 1, 2016 edition, 9 2016.
114
Glossary
4-series The family name of all 4-series buoy types. The the moment only the DWR4 is available.
4FSK-A 4FSK
4FSK-B 4FSK
Acoustic Current Meter The Acoustic Current Meter is an option in the DWR4
buoys. When this option is installed the buoy measures the speed and direction of the water
current at the water surface.
Argos ID A unique identifier for the Argos unit. Argos uses both 20-bit and 28-bit IDs. The
Waves4 suite supports both IDs.
Note Argos used both decimal and hexadecimal IDs. The decimal ID’s value is not equal to
the hexadecimal ID’s decimal representation. Datawell used the decimal ID in the Waves4
suite.
bat A helper program to find instances of waved on the network. This program has been re-
moved from the Waves4 suite in version 4.16.0. The Waves4 configurator can give the same
information and more.
broadcast A broadcast is a way to transmit a message to multiple computers on the local network.
This is used in the Waves4 suite to find other instances of buoyd and waved on the local
network. The broadcast can only be send over UDP, not over TCP.
buoyd The data acquisition program of the Waves4 suite. The program acquires data from the
RX-C receiver and logs it into HXV files for the MkIII buoys and in HVA files for the
4-series buoys. The program also allows other programs to connect to is and receive a copy
of the acquired data.
115
campaign A campaign or measurement campaign is the measure campaign at a specific location.
When a campaign lasts for several years the measurement might be done by different buoys.
Therefore the data is labelled to campaign and not a specific buoy or receiver.
iBuoy A communication service for the Datawell buoys using an Internet connection
116
network order Network order is also known as big-endian. It describes how values are transmit-
ted over a network.
RX-C A receiver that collects data from a MkIII buoy and sends it to a computer. The early
versions use the serial port to connect to a computer. Later models have an Ethernet port as
well. Even newer models can be used to receive data from a 4-series buoy.
RX-D A receiver that collects data from a MkIII buoy, using a serial port, and sends the data to a
computer.
SeaSaw21 A program used to show data received from Datawell buoys. This program shows the
operational information of MkIII and older buoys.
signal In the DWR4 the data is sent in packets, every packet contains one or more measurements.
Most packets contain related data, for example spectral parameters. This data can be shown
in a widget, where every measurement is called a signal. The widget can then show the trend
of this signal over a certain period. But it is also possible to see multiple related signals in
one widget, giving a better overview of the sea-state over a period of time.
telnet Telnet is a text-based communication protocol. The programs in the Waves4 suite uses this
protocol to communicate with each other.
Telnet is also the name of a program – available on both Linux and Windows – which allows
the users to use the telnet protocol. It is mainly interesting for debugging purposes.
Starting with version 4.10.0 the telnet interface is replaced with a new network protocol.
117
UDP User Datagram Protocol
UDP is a network protocol, used to send data between machines using a network. This
network protocol is simpler as TCP but lacks error detection and handling. Its main usage
in the Waves4 suite is to broadcast.
W@ves21 A program used to show data received from Datawell buoys. This program shows the
scientific information of MkIII and older buoys.
waved The data processing and distribution program of the Waves4 suite. The program connects
to one or more buoyd programs and gathers all data and make it available for the Waves4
program.
Waves4 Both the name of the Waves4 suite and the Waves4 program.
Waves4 configurator The program is introduced in version 4.10.0 of the Waves4 suite and is
used to configure buoyd and waved.
Waves4 program The program is able to show the data received from a buoy on a computer
system.
Waves4 suite The Waves4 suite is a software suite containing several programs, including buoyd,
waved and the Waves4 program.
widget A widget is a user interface element. It shows information to the user, for example the
current height of the heave or the latest spectrum.
118
D Libraries used
This chapter describes the external libraries used in the suite. The Windows installer ships the
libraries. Most of the libraries are licensed under the LGPL. In order to comply with the license
we will ship the source code of the libraries upon request. Alternatively you can also download
the sources from the websites of the manufacturers of the libraries.
The list below lists the software used and its license and official website, the sections below
list the licenses of the software.
• gettext runtime libraries, GNU Lesser General Public License, version 2.1
119
• JasPer, JasPer license
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
120
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ‘‘AS IS’’ AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--------------------------------------------------------------------------
Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
121
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not
be used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization of the copyright holder.
Both licenses are included here. Some of the standalone binaries are
under the GPL only; in particular, but not limited to,
tools/dbus-cleanup-sockets.c and test/decode-gcov.c. Each source code
file is marked with the proper copyright information - if you find a
file that isn’t marked please bring it to our attention.
This Academic Free License (the "License") applies to any original work of authorship (the "Original Work") whose owner (
b) to prepare derivative works ("Derivative Works") based upon the Original Work;
c) to distribute copies of the Original Work and Derivative Works to the public;
3) Grant of Source Code License. The term "Source Code" means the
preferred form of the Original Work for making modifications to it and
all available documentation describing how to modify the Original
Work. Licensor hereby agrees to provide a machine-readable copy of the
Source Code of the Original Work along with each copy of the Original
Work that Licensor distributes. Licensor reserves the right to satisfy
this obligation by placing a machine-readable copy of the Source Code
in an information repository reasonably calculated to permit
inexpensive and convenient access by You for as long as Licensor
continues to distribute the Original Work, and by publishing the
address of that information repository in a notice immediately
following the copyright notice that applies to the Original Work.
122
sell embodiments of any patent claims other than the licensed claims
defined in Section 2. No right is granted to the trademarks of
Licensor even if such marks are included in the Original Work. Nothing
in this License shall be interpreted to prohibit Licensor from
licensing under different terms from this License any Original Work
that Licensor otherwise would have a right to license.
11) Jurisdiction, Venue and Governing Law. Any action or suit relating
to this License may be brought only in the courts of a jurisdiction
wherein the Licensor resides or in which Licensor conducts its primary
business, and under the laws of that jurisdiction excluding its
123
conflict-of-law provisions. The application of the United Nations
Convention on Contracts for the International Sale of Goods is
expressly excluded. Any use of the Original Work outside the scope of
this License or after its termination shall be subject to the
A§ 101
requirements and penalties of the U.S. Copyright Act, 17 U.S.C. ^
et seq., the equivalent laws of other countries, and international
treaty. This section shall survive the termination of this License.
12) Attorneys Fees. In any action to enforce the terms of this License
or seeking damages relating thereto, the prevailing party shall be
entitled to recover its costs and expenses, including, without
limitation, reasonable attorneys’ fees and costs incurred in
connection with such action, including any appeal of such action. This
section shall survive the termination of this License.
15) Right to Use. You may use the Original Work in all ways not
otherwise restricted or conditioned by this License or by law, and
Licensor promises not to interfere with or be responsible for such
uses by You.
--
END OF ACADEMIC FREE LICENSE. The following is intended to describe the essential
differences between the Academic Free License (AFL) version 1.0 and other
open source licenses:
The Academic Free License is similar to the BSD, MIT, UoI/NCSA and Apache
licenses in many respects but it is intended to solve a few problems with
those licenses.
* The AFL contains a complete copyright grant to the software. The BSD
and Apache licenses are vague and incomplete in that respect.
* The AFL contains a complete patent grant to the software. The BSD, MIT,
UoI/NCSA and Apache licenses rely on an implied patent license and contain
no explicit patent grant.
* The AFL makes it clear that no trademark rights are granted to the
licensor’s trademarks. The Apache license contains such a provision, but the
BSD, MIT and UoI/NCSA licenses do not.
* The AFL includes the warranty by the licensor that it either owns the
copyright or that it is distributing the software under a license. None of
the other licenses contain that warranty. All other warranties are disclaimed,
as is the case for the other licenses.
* The AFL is itself copyrighted (with the right granted to copy and distribute
124
without modification). This ensures that the owner of the copyright to the
license will control changes. The Apache license contains a copyright notice,
but the BSD, MIT and UoI/NCSA licenses do not.
--
START OF GNU GENERAL PUBLIC LICENSE
--
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation’s software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author’s protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors’ reputations.
125
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
126
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients’ exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
127
apply and the section as a whole is intended to apply in other
circumstances.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
128
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
<one line to give the program’s name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than ‘show w’ and ‘show c’; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
129
THE SOFTWARE IS PROVIDED ‘‘AS IS’’, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of Keith Packard not be used in
advertising or publicity pertaining to distribution of the software without
specific, written prior permission. Keith Packard makes no
representations about the suitability of this software for any purpose. It
is provided "as is" without express or implied warranty.
2006-Jan-27
Introduction
============
o You can use this software for whatever you want, in parts or
full form, without having to pay us. (‘royalty-free’ usage)
o You may not pretend that you wrote this software. If you use
130
it, or only parts of it, in a program, you must acknowledge
somewhere in your documentation that you have used the
FreeType code. (‘credits’)
"""
Portions of this software are copyright © <year> The FreeType
Project (www.freetype.org). All rights reserved.
"""
Please replace <year> with the value from the FreeType version you
actually use.
Legal Terms
===========
0. Definitions
--------------
1. No Warranty
--------------
2. Redistribution
-----------------
131
o Redistribution of source code must retain this license file
(‘FTL.TXT’) unaltered; any additions, deletions or changes to
the original files must be clearly indicated in accompanying
documentation. The copyright notices of the unaltered,
original files must be preserved in all copies of source
files.
3. Advertising
--------------
Neither the FreeType authors and contributors nor you shall use
the name of the other for commercial, advertising, or promotional
purposes without specific prior written permission.
We suggest, but do not require, that you use one or more of the
following phrases to refer to this software in your documentation
or advertising materials: ‘FreeType Project’, ‘FreeType Engine’,
‘FreeType library’, or ‘FreeType Distribution’.
As you have not signed this license, you are not required to
accept it. However, as the FreeType Project is copyrighted
material, only this license, or another one contracted with the
authors, grants you the right to use, distribute, and modify it.
Therefore, by using, distributing, or modifying the FreeType
Project, you indicate that you understand and accept all the terms
of this license.
4. Contacts
-----------
http://www.freetype.org
132
This GCC Runtime Library Exception ("Exception") is an additional
permission under section 7 of the GNU General Public License, version
3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
bears a notice placed by the copyright holder of the file stating that
the file is governed by GPLv3 along with this Exception.
When you use GCC to compile a program, GCC may combine portions of
certain GCC header files and runtime libraries with the compiled
program. The purpose of this Exception is to allow compilation of
non-GPL (including proprietary) programs to use, in this way, the
header files and runtime libraries covered by this Exception.
0. Definitions.
"Target Code" refers to output from any compiler for a real or virtual
target processor architecture, in executable form or suitable for
input to an assembler, loader, linker and/or execution
phase. Notwithstanding that, Target Code does not include data in any
format that is used as a compiler intermediate representation, or used
for producing a compiler intermediate representation.
133
of this license document, but changing it is not allowed.
Preamble
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers’ and authors’ protection, the GPL clearly explains
that there is no warranty for this free software. For both users’ and
authors’ sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
0. Definitions.
134
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work’s
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
135
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work’s
users, your or third parties’ legal rights to forbid circumvention of
technological measures.
You may convey verbatim copies of the Program’s source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
136
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
137
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
7. Additional Terms.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
138
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
8. Termination.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
139
covered work, you indicate your acceptance of this License to do so.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
140
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
141
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
<one line to give the program’s name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate
parts of the General Public License. Of course, your program’s commands
might be different; for a GUI interface, you would use an "about box".
142
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<http://www.gnu.org/philosophy/why-not-lgpl.html>.
143
fitness for a particular purpose. This software is provided "AS IS", and you,
its user, assume the entire risk as to its quality and accuracy.
These conditions apply to any software derived from or based on the IJG code,
not just to the unmodified library. If you use our work, you ought to
acknowledge us.
Permission is NOT granted for the use of any IJG author’s name or company name
in advertising or publicity relating to this software or products derived from
it. This software may be referred to only as "the Independent JPEG Group’s
software".
We specifically permit and encourage the use of this software as the basis of
commercial products, provided that all warranty or liability claims are
assumed by the product vendor.
The Unix configuration script "configure" was produced with GNU Autoconf.
It is copyright by the Free Software Foundation but is freely distributable.
The same holds for its supporting scripts (config.guess, config.sub,
ltconfig, ltmain.sh). Another support script, install-sh, is copyright
by M.I.T. but is also freely distributable.
It appears that the arithmetic coding option of the JPEG spec is covered by
patents owned by IBM, AT&T, and Mitsubishi. Hence arithmetic coding cannot
legally be used without obtaining one or more licenses. For this reason,
support for arithmetic coding has been removed from the free JPEG software.
(Since arithmetic coding provides only a marginal gain over the unpatented
Huffman mode, it is unlikely that very many implementations will support it.)
So far as we are aware, there are no patent restrictions on the remaining
code.
The IJG distribution formerly included code to read and write GIF files.
To avoid entanglement with the Unisys LZW patent, GIF reading support has
been removed altogether, and the GIF writer has been simplified to produce
"uncompressed GIFs". This technique does not use the LZW algorithm; the
resulting GIF files are larger than usual, but are readable by all standard
GIF decoders.
144
D.12 GNU Lesser General Public License, ver-
sion 2.1
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
[This is the first released version of the Lesser GPL. It also counts
as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
145
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
146
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
147
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
148
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
149
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients’ exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
150
NO WARRANTY
<one line to give the library’s name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
151
D.13 GNU Library General Public License, ver-
sion 2.0
GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
Our method of protecting your rights has two steps: (1) copyright
the library, and (2) offer you this license which gives you legal
permission to copy, distribute and/or modify the library.
152
The reason we have a separate public license for some libraries is that
they blur the distinction we usually make between modifying or adding to a
program and simply using it. Linking a program with a library, without
changing the library, is in some sense simply using the library, and is
analogous to running a utility program or application program. However, in
a textual and legal sense, the linked executable is a combined work, a
derivative of the original library, and the ordinary General Public License
treats it as such.
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
153
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
154
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
155
than the cost of performing this distribution.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients’ exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
156
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
13. The Free Software Foundation may publish revised and/or new
versions of the Library General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
157
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
<one line to give the library’s name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
0. Additional Definitions.
158
"The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
a) under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
a) Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license
159
document.
5. Combined Libraries.
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
160
Library.
The Contributing Authors and Group 42, Inc. specifically permit, without
fee, and encourage the use of this source code as a component to
supporting the PNG file format in commercial products. If you use this
source code in a product, acknowledgment is not required but would be
appreciated.
161
* USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
* OF SUCH DAMAGE.
*/
========================
Overall copyright notice
========================
Copyright (c) 2009, 2010, 2011, 2012, 2013 by the mingw-w64 project
This license has been certified as open source. It has also been designated
as GPL compatible by the Free Software Foundation (FSF).
Disclaimer
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ‘‘AS IS’’ AND ANY EXPRESSED
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
========================================
getopt, getopt_long, and getop_long_only
========================================
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
162
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
* * * * * * *
===============================================================
gdtoa: Converting between IEEE floating point numbers and ASCII
===============================================================
* * * * * * *
163
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that the copyright notice and this permission notice and warranty
disclaimer appear in supporting documentation, and that the name of
the author or any of his current or former employers not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission.
* * * * * * *
=========================
Parts of the math library
=========================
* * * * * * *
* * * * * * *
164
<http://lists.debian.org/debian-legal/2004/12/msg00295.html>, it gives an
impression that the author could be willing to give an explicit
permission to distribute those files e.g. under a BSD style license. So
probably there is no problem here, although it could be good to get a
permission from the author and then add a license into the Cephes files
in MinGW runtime. At least on follow-up it is marked that debian sees the
version a-like BSD one. As MinGW.org (where those cephes parts are coming
from) distributes them now over 6 years, it should be fine.
===================================
Headers and IDLs imported from Wine
===================================
Some header and IDL files were imported from the Wine project. These files
are prominent maked in source. Their copyright belongs to contributors and
they are distributed under LGPL license.
Disclaimer
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
the OpenSSL License and the original SSLeay license apply to the toolkit.
See below for the actual license texts. Actually both licenses are BSD-style
Open Source licenses. In case of any license issues related to OpenSSL
please contact [email protected].
OpenSSL License
---------------
/* ====================================================================
165
* Copyright (c) 1998-2011 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* [email protected].
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ‘‘AS IS’’ AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* ([email protected]). This product includes software written by Tim
* Hudson ([email protected]).
*
*/
166
* as the author of the parts of the library used.
* This can be in the form of a textual message at program startup or
* in documentation (online or textual) provided with the package.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* "This product includes cryptographic software written by
* Eric Young ([email protected])"
* The word ’cryptographic’ can be left out if the rouines from the library
* being used are not cryptographic related :-).
* 4. If you include any Windows specific code (or a derivative thereof) from
* the apps directory (application code) you must include an acknowledgement:
* "This product includes software written by Tim Hudson ([email protected])"
*
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ‘‘AS IS’’ AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.]
*/
* Neither the name of the University of Cambridge nor the name of Google
Inc. nor the names of their contributors may be used to endorse or
promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
167
D.21 Pixman license
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
168