diff --git a/docs/source/devices/devices.rst b/docs/source/devices/devices.rst
index acc9e12ef30ad6772289783f5cdf618da4139b3f..04c3faa6c470c89c6a211b582f39bed0900cfc35 100644
--- a/docs/source/devices/devices.rst
+++ b/docs/source/devices/devices.rst
@@ -1,47 +1,12 @@
-Using Devices
-=============
+Devices
+============
 
-The station exposes *devices*, each of which is a remote software object that manages part of the station. Each device has the following properties:
+RECV
+----------
 
-- It has a *state*,
-- Many devices manage and represent hardware in the station,
-- It exposes *read-only attributes*, that expose values from within the device or from the hardware it represents,
-- It exposes *read-write attributes*, that allow controlling the functionality of the device, or the hardware it represents,
-- It exposes *properties*, which are fixed configuration parameters (such as port numbers and timeouts).
+The `recv == Device("LTS/RECV/1")` device controls the RCUs, the LBA antennas, and HBA tiles. Central to its operation are the masks:
 
-To access a device, one creates a `Device` object. For example::
+- The `RCU_mask_RW` attribute is an array of `bool[N_RCUs]`. It controls which RCUs will actually be configured, when fields referring to RCUs are set. Any RCU for which the mask is False will not be configured when RCU control points are set.
+- The `Ant_mask_RW` attribute is an array of `bool[N_RCUs][N_Antennas_per_RCU]`. It controls which antennas will actually be configured, when fields referring to antennas are set. Any antenna for which the mask is False will not be configured when antenna control points are set.
 
-    device = Device("LTS/RECV/1")
-
-States
-------------
-
-The state of a device is then queried with `device.state()`. Each device can be in one of the following states:
-
-- `DevState.OFF`: The device is not operating,
-- `DevState.INIT`: The device is being initialised,
-- `DevState.STANDBY`: The device is initialised and ready to be configured further,
-- `DevState.ON`: The device is operational.
-- `DevState.FAULT`: The device is malfunctioning. Functionality cannot be counted on.
-- The `device.state()` function can throw an error, if the device cannot be reached at all. For example, because it's docker container has not been started.
-
-Each device provides the following functions to change state:
-
-- `off()`: Turn the device `OFF` from any state.
-- `initialise()`: Initialise the device from the `OFF` state, to bring it to the `STANDBY` state.
-- `on()`: Mark the device as operational, from the `STANDBY` state, bringing it to `ON`.
-
-Attributes
-------------
-
-The device can be operated in `ON` state, where it exposes *attributes* and *commands*. The attributes can be accessed as python properties, for example::
-
-    recv = Device("LTS/RECV/1")
-
-    # turn on all LED0s
-    recv.RCU_LED0_RW = [True] * 32
-
-    # retrieve the status of all LED0s
-    print(recv.RCU_LED0_R)
-
-The attributes with an `_R` suffix are monitoring points, reflecting the state of the hardware, and are thus read-only. The attributes with an `_RW` suffix are control points, reflecting the desired state of the hardware. They are read-write, where writing requests the hardware to set the specified value, and reading returns the last requested value.
+Typically, `N_RCUs == 32`, and `N_Antennas_per_RCU == 3`.
diff --git a/docs/source/devices/recv.rst b/docs/source/devices/recv.rst
deleted file mode 100644
index 04c3faa6c470c89c6a211b582f39bed0900cfc35..0000000000000000000000000000000000000000
--- a/docs/source/devices/recv.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-Devices
-============
-
-RECV
-----------
-
-The `recv == Device("LTS/RECV/1")` device controls the RCUs, the LBA antennas, and HBA tiles. Central to its operation are the masks:
-
-- The `RCU_mask_RW` attribute is an array of `bool[N_RCUs]`. It controls which RCUs will actually be configured, when fields referring to RCUs are set. Any RCU for which the mask is False will not be configured when RCU control points are set.
-- The `Ant_mask_RW` attribute is an array of `bool[N_RCUs][N_Antennas_per_RCU]`. It controls which antennas will actually be configured, when fields referring to antennas are set. Any antenna for which the mask is False will not be configured when antenna control points are set.
-
-Typically, `N_RCUs == 32`, and `N_Antennas_per_RCU == 3`.
diff --git a/docs/source/devices/using.rst b/docs/source/devices/using.rst
new file mode 100644
index 0000000000000000000000000000000000000000..acc9e12ef30ad6772289783f5cdf618da4139b3f
--- /dev/null
+++ b/docs/source/devices/using.rst
@@ -0,0 +1,47 @@
+Using Devices
+=============
+
+The station exposes *devices*, each of which is a remote software object that manages part of the station. Each device has the following properties:
+
+- It has a *state*,
+- Many devices manage and represent hardware in the station,
+- It exposes *read-only attributes*, that expose values from within the device or from the hardware it represents,
+- It exposes *read-write attributes*, that allow controlling the functionality of the device, or the hardware it represents,
+- It exposes *properties*, which are fixed configuration parameters (such as port numbers and timeouts).
+
+To access a device, one creates a `Device` object. For example::
+
+    device = Device("LTS/RECV/1")
+
+States
+------------
+
+The state of a device is then queried with `device.state()`. Each device can be in one of the following states:
+
+- `DevState.OFF`: The device is not operating,
+- `DevState.INIT`: The device is being initialised,
+- `DevState.STANDBY`: The device is initialised and ready to be configured further,
+- `DevState.ON`: The device is operational.
+- `DevState.FAULT`: The device is malfunctioning. Functionality cannot be counted on.
+- The `device.state()` function can throw an error, if the device cannot be reached at all. For example, because it's docker container has not been started.
+
+Each device provides the following functions to change state:
+
+- `off()`: Turn the device `OFF` from any state.
+- `initialise()`: Initialise the device from the `OFF` state, to bring it to the `STANDBY` state.
+- `on()`: Mark the device as operational, from the `STANDBY` state, bringing it to `ON`.
+
+Attributes
+------------
+
+The device can be operated in `ON` state, where it exposes *attributes* and *commands*. The attributes can be accessed as python properties, for example::
+
+    recv = Device("LTS/RECV/1")
+
+    # turn on all LED0s
+    recv.RCU_LED0_RW = [True] * 32
+
+    # retrieve the status of all LED0s
+    print(recv.RCU_LED0_R)
+
+The attributes with an `_R` suffix are monitoring points, reflecting the state of the hardware, and are thus read-only. The attributes with an `_RW` suffix are control points, reflecting the desired state of the hardware. They are read-write, where writing requests the hardware to set the specified value, and reading returns the last requested value.
diff --git a/docs/source/index.rst b/docs/source/index.rst
index 54c7e318a0bcde66e441ee335f0f10c65019f015..c5533f2d5bda42e0fa7baca6be3320e052f809c8 100644
--- a/docs/source/index.rst
+++ b/docs/source/index.rst
@@ -12,8 +12,8 @@ Welcome to LOFAR2.0 Station Control's documentation!
 
    installation
    remote_interfaces
+   devices/using
    devices/devices
-   devices/recv
    control
    monitoring
    logs
diff --git a/docs/source/installation.rst~Stashed changes b/docs/source/installation.rst~Stashed changes
deleted file mode 100644
index 5735ec54af7d388d110e03175f4ae9f7a27c3b51..0000000000000000000000000000000000000000
--- a/docs/source/installation.rst~Stashed changes	
+++ /dev/null
@@ -1,61 +0,0 @@
-Installation
-==================
-
-You start with checking out the source code, f.e. the master branch, as well as the git submodules we use::
-
-  git clone https://git.astron.nl/lofar2.0/tango.git
-  cd tango
-  git submodule init
-  git submodule update
-
-Next, we bootstrap the system. This will build our docker images, start key ones, and load the base configuration. This may take a while::
-
-  cd docker-compose
-  make bootstrap
-
-If you lack access to LOFAR station hardware, load additional configurations to use the simulators instead::
-
-  for sim in ../CDB/\*-sim-config.json; do
-    ../sbin/update_ConfigDb.sh ../CDB${sim}-config.json
-  done
-
-Now we are ready to start the other containers::
-
-  make start
-
-and make sure they are all up and running::
-
-  make status
-
-You should see the following state:
-
-- Containers `astor`, `hdbpp-viewer`, `jive`, `log-viewer` and `pogo` will have State `Exit 1`. These are containers that are interactive X11 tools, and not needed for now,
-- Other containers have either State `Up` or `Exit 0`.
-
-If not, you can inspect why with `docker logs <container>`. Note that the containers will automatically be restarted on failure, and also if you reboot. Stop them explicitly to bring them down (`make stop <container>`).
-
-Initialisation
-----------------
-
-The following procedure describes how to initialise the system, which is required after installation and after a system reboot.
-
-The docker containers will automatically restart after a system reboot. But the Linux kernel will lose its required custom settings required by our ELK stack. To reconfigure the kernel parameters, run::
-
-  make start elk-configure-host
-  make restart elk
-
-We can now initialise the station configuration, that is, start all the software devices to control the station hardware, and to initialise the hardware with the configured default settings. Go to http://localhost:8888, start a new *Station Control* notebook, and initiate the software boot sequence::
-
-  # reset our boot device
-  boot.off()
-  assert boot.state() == DevState.OFF
-  boot.initialise()
-  assert boot.state() == DevState.STANDBY
-  boot.on()
-  assert boot.state() == DevState.ON
-
-  # start and initialise the other devices
-  boot.initialise_station()
-
-  # wait for the devices to be initialised
-